2007-11-21 04:45:47

by Andrew Morton

[permalink] [raw]
Subject: 2.6.24-rc3-mm1


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

- Added new git tree git-lblnet.patch: net labelling work (Paul Moore
<[email protected])

- Re-added Smack

- Dropped git-kbuild.patch - it broke the scsi build

- I'm offline until Sunday (as are certain other patch targets..)


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 tag v2.6.16-rc2-mm1
git-checkout -b local-v2.6.16-rc2-mm1 v2.6.16-rc2-mm1

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

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

- If you hit a bug in -mm and it 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.

- When reporting bugs in this kernel via email, please also rewrite the
email Subject: in some manner to reflect the nature of the bug. Some
developers filter by Subject: when looking for messages to read.

- Occasional snapshots of the -mm lineup are uploaded to
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/mm/ and are announced on
the mm-commits list. These probably are at least compilable.

- More-than-daily -mm snapshots may be found at
http://userweb.kernel.org/~akpm/mmotm/. These are almost certainly not
compileable.



Changes since 2.6.24-rc2-mm1:


origin.patch
git-acpi.patch
git-alsa.patch
git-arm-master.patch
git-arm.patch
git-avr32.patch
git-cifs.patch
git-cpufreq.patch
git-powerpc.patch
git-drm.patch
git-dvb.patch
git-hwmon.patch
git-gfs2-nmw.patch
git-hid.patch
git-hrt.patch
git-ieee1394.patch
git-infiniband.patch
git-input.patch
git-jfs.patch
git-kvm.patch
git-lblnet.patch
git-leds.patch
git-libata-all.patch
git-m32r.patch
git-md-accel.patch
git-mips.patch
git-mmc.patch
git-mtd.patch
git-ubi.patch
git-net.patch
git-netdev-all.patch
git-nfsd.patch
git-ocfs2.patch
git-parisc.patch
git-selinux.patch
git-s390.patch
git-sh.patch
git-scsi-misc.patch
git-scsi-rc-fixes.patch
git-sparc64.patch
git-unionfs.patch
git-v9fs.patch
git-watchdog.patch
git-wireless.patch
git-ipwireless_cs.patch
git-x86.patch
git-newsetup.patch
git-xfs.patch
git-cryptodev.patch
git-xtensa.patch

git trees

-ecryptfs-cast-page-index-to-loff_t-instead-of-off_t.patch
-fix-oops-in-toshiba_acpi-error-return-path.patch
-rtc_hctosys-expects-rtcs-in-utc-doc.patch
-rtcs-handle-nvram-better.patch
-rtc-ds1307-exports-nvram.patch
-drivers-video-ps3fb-fix-memset-size-error.patch
-w1-fix-memset-size-error.patch
-slab-fix-typo-in-allocation-failure-handling.patch
-serial-add-pnp-id-for-davicom-isa-336k-modem.patch
-sysctl-check-length-at-deprecated_sysctl_warning.patch
-cm40x0_csc-fix-debug-macros.patch
-lib-move-bitmapo-from-lib-y-to-obj-y.patch
-uml-fix-symlink-loops.patch
-rtc-tweak-driver-documentation-for-rtc-periodic.patch
-chipsfb-uses-depends-on-pci.patch
-uvesafb-fix-warnings-about-unused-variables-on-non-x86.patch
-oprofile-oops-when-profile_pc-return-0lu.patch
-uml-fix-recvmsg-return-value-checking.patch
-uml-update-address-space-affected-by-pud_clear.patch
-uml-update-address-space-affected-by-pud_clear-checkpatch-fixes.patch
-improve-cgroup-printks.patch
-improve-cgroup-printks-fix.patch
-drivers-video-s1d13xxxfbc-as-module-with-dbg.patch
-forbid-user-to-change-file-flags-on-quota-files.patch
-forbid-user-to-change-file-flags-on-quota-files-fix.patch
-lxfb-use-the-correct-msr-number-for-panel-support.patch
-lguest_userc-fix-memory-leak.patch
-video-sis-fix-negative-array-index.patch
-8250_pnp-add-support-for-lg-c1-express-dual-machines.patch
-proc-fix-proc_kill_inodes-to-kill-dentries-on-all-proc-superblocks.patch
-proc-fix-proc_kill_inodes-to-kill-dentries-on-all-proc-superblocks-checkpatch-fixes.patch
-migration-find-correct-vma-in-new_vma_page.patch
-memory-hotremove-unset-migrate-type-isolate-after-removal.patch
-make-getdelays-cgroupstats-aware.patch
-mm-speed-up-writeback-ramp-up-on-clean-systems.patch
-add-ioresouce_busy-flag-for-system-ram.patch
-acpi-make-acpi_procfs-default-to-y.patch
-spi-fix-double-free-on-spi_unregister_master.patch
-spi-fix-error-paths-on-txx9spi_probe.patch
-paride-pf-driver-fixes.patch
-drivers-misc-move-misplaced-pci_dev_puts.patch
-dmaengine-fix-broken-device-refcounting.patch
-atmel_serial-build-warnings-begone.patch
-hugetlb-follow_hugetlb_page-for-write-access.patch
-hugetlb-follow_hugetlb_page-for-write-access-fix.patch
-raid5-fix-unending-write-sequence.patch
-hugetlb-split-alloc_huge_page-into-private-and-shared-components.patch
-hugetlb-split-alloc_huge_page-into-private-and-shared-components-checkpatch-fixes.patch
-hugetlb-fix-quota-management-for-private-mappings.patch
-hugetlb-debit-quota-in-alloc_huge_page.patch
-hugetlb-allow-bulk-updating-in-hugetlb__quota.patch
-hugetlb-enforce-quotas-during-reservation-for-shared-mappings.patch
-mm-hugetlbc-make-a-function-static.patch
-hugetlb-fix-i_blocks-accounting.patch
-revert-task-control-groups-example-cpu-accounting-subsystem.patch
-fixes-to-the-bfs-filesystem-driver.patch
-linux-kernel-markers-fix-marker-mutex-not-taken-upon-module-load.patch
-linux-kernel-markers-document-format-string.patch
-linux-kernel-markers-fix-samples-to-follow-format-string-standard.patch
-acpi-sbs-fix-retval-warning.patch
-acpi-expose-_sun-in-proc-acpi-processor-info.patch
-powerpc-fix-fs_enet-module-build.patch
-fix-gregkh-driver-kobject-clean-up-rpadlpar-horrid-sysfs-abuse.patch
-jdelvare-i2c-i2c-dev-add-comments.patch
-jdelvare-i2c-i2c-slave-busy-only-if-has-driver.patch
-jdelvare-i2c-i2c-make-i2c_check_addr-static.patch
-jdelvare-i2c-i2c-pasemi-replace-obsolete-driverfs-reference.patch
-jdelvare-i2c-i2c-eeprom-hide-serial-to-non-root-users.patch
-jdelvare-i2c-i2c-eeprom-recognize-vgn-prefix-as-vaio.patch
-jdelvare-i2c-i2c-pasemi-fix-nack-detection.patch
-hwmon-replace-power-of-two-test-in-drivers-hwmon-adt7470c.patch
-cscope-build-warning.patch
-ide-mm-ide-use-drive-select-all-for-req_type_ata_task-in-execute_drive_cmd.patch
-ide-mm-ide-pmac-skip-conservative-pio-downgrade.patch
-ide-mm-ide-add-missing-hob-bit-clearing-to-ide_dump_ata_status.patch
-ide-mm-ide-dont-bug-on-unsupported-transfer-modes.patch
-blk_dev_idecd-help-remove-outdated-note.patch
-remove-references-to-net-modulestxt.patch
-megaraid-sas-convert-aen_mutex-to-the-mutex-api.patch
-update-kerneldoc-comments-in-drivers-scsi-scsicamc.patch
-libsas-convert-sas_proto-users-to-sas_protocol.patch
-libsas-fix-various-sparse-complaints.patch
-unionfs-clear-partial-read.patch
-usb-power-managementtxt-disconnect-clarification.patch
-iwlwifi-remove-unnecessary-code-in-iwl3945-and-iwl4965-drivers.patch
-git-x86-broke-lguest.patch
-git-x86-broke-xen-too.patch
-i386-fix-reboot-with-no-keyboard-attached.patch
-oprofile-op_model_athalonc-support-for-amd-family10h-barcelona-performance-counters.patch
-oprofile-op_model_athalonc-support-for-amd-family10h-barcelona-performance-counters-checkpatch-fixes.patch
-remove-extern-declarations-for-code-data-bss-resource.patch
-x86_64-do-not-clear-cpu_index-set-by-store_cpu_info.patch
-x86-typo-about-sequence-of-cpu_index-and-cpu_online-in.patch
-i386-and-x86_64-randomize-brk.patch
-i386-and-x86_64-randomize-brk-fix.patch
-i386-and-x86_64-randomize-brk-fix-2.patch
-x86-bitops_32h-style-cleanups.patch
-x86-check-boundary-in-count-setup_resource-called-by.patch
-arch-x86-remove-duplicate-includes.patch
-x86-arch_register_cpu-section-fix.patch
-i386-reboot-fixup-for-wrap-2c-board-sc1100-based.patch
-fix-wrong-proc-cpuinfo-on-x64.patch
-x86_64-clean-up-stack-allocation-and-free.patch
-x86_64-configure-stack-size.patch
-ia32-emu-remove-dead-code.patch
-x86_64-add-acpi-reboot-option.patch
-git-cryptodev-hifn_795x-fixes.patch
-xtensa-iss_net_setup-must-be-__init.patch
-i-oat-add-support-for-version-2-of-ioatdma-device.patch
-reiserfs-dont-drop-pg_dirty-when-releasing-sub-page-sized-dirty-file.patch
-rtc-release-correct-region-in-error-path.patch
-rtc-fallback-to-requesting-only-the-ports-we-actually-use.patch
-i5000_edac-no-need-to-__stringify-kbuild_basename.patch
-serial-only-use-pnp-irq-if-its-valid.patch
-sunrpc-xprtrdma-transportc-fix-use-after-free.patch
-fix-mm-utilckrealloc.patch
-fuse_file_alloc-fix-null-dereferences.patch
-tle62x0-driver-stops-ignoring-read-errors.patch
-rd-fix-data-corruption-on-memory-pressure.patch
-cris-gpio-undo-locks-before-returning.patch
-mips-undo-locking-on-error-path-returns.patch
-mips-undo-locking-on-error-path-returns-checkpatch-fixes.patch
-proc-simplify-and-correct-proc_flush_task.patch
-fix-param_sysfs_builtin-name-length-check.patch
-mark-sys_open-sys_read-exports-unused.patch
-sysctl-fix-token-ring-procname.patch
-gbefb-fix-section-mismatch-warnings.patch
-vmstat-fix-section-mismatch-warning.patch
-pidns-place-under-config_experimental.patch
-pidns-place-under-config_experimental-checkpatch-fixes.patch
-__do_irq-does-not-check-irq_disabled-when-irq_per_cpu-is-set.patch
-hibernate-fix-lockdep-report-2.patch
-smbfs-fix-debug-builds.patch
-fix-64kb-blocksize-in-ext3-directories.patch
-fix-64kb-blocksize-in-ext3-directories-checkpatch-fixes.patch
-uml-fix-spurious-irq-testing.patch
-uml-remove-last-include-of-libc-asm-pageh.patch
-uml-fix-build-for-config_tcp.patch
-uml-fix-build-for-config_printk.patch
-swap-delay-accounting-include-lock_page-delays.patch
-file-capabilities-allow-sigcont-within-session-v2.patch
-file-capabilities-allow-sigcont-within-session-v2-checkpatch-fixes.patch
-file-capabilities-allow-sigcont-within-session-v2-file-capabilities-remove-the-non-matching-uid-special-case-for-kill.patch
-feature-removal-schedule-remove-sa_-flags-entry.patch
-kernel-taskstatsc-fix-bogus-nlmsg_free.patch
-x86-show-cpuinfo-only-for-online-cpus.patch
-make-proc-acpi-ac_adapter-dependent-on-acpi_procfs.patch
-acpi-ac-update-ac-state-on-resume.patch
-keyspan-init-termios-properly.patch
-x86-disable-preemption-in-delay_tsc.patch
-oprofile-fix-oops-on-x86-32-bit.patch
-x86-early_quirks-cleanup.patch
-x86-dont-call-mce_create_device-on-cpu_up_prepare.patch
-aic94xx_sds-rename-flash_size.patch
-mips-pcspkr-build-fix.patch
-kernel-power-move-function-prototypes-to-header.patch
-cris-build-fixes-fix-csum_tcpudp_magic-declaration.patch
-cris-build-fixes-add-missing-syscalls.patch
-cris-build-fixes-hardirqh-include-asm-irqh.patch
-cris-build-fixes-atomich-needs-compilerh.patch
-cris-build-fixes-atomich-needs-compilerh-fix.patch
-cris-build-fixes-irq-fixes.patch
-cris-build-fixes-sys_crisc-needs-fsh.patch
-cris-build-fixes-add-baud-rate-defines.patch
-cris-build-fixes-update-eth_v10c-ethernet-driver.patch
-cris-build-fixes-update-eth_v10c-ethernet-driver-fix.patch
-cris-build-fixes-corrected-and-improved-nmi-and-irq-handling.patch
-cris-build-fixes-fixes-in-arch-cris-kernel-timec-checkpatch-fixes.patch
-cris-build-fixes-fixes-in-arch-cris-kernel-timec.patch
-cris-build-fixes-setupc-needs-paramh.patch
-cris-build-fixes-fix-crisksymsc.patch
-cris-build-fixes-defconfig-updates.patch
-cris-array_size-cleanup.patch
-cris-dont-include-bitopsh-in-posix_typesh.patch
-crisv10-serial-driver-rewrite-take-three.patch
-cris-remove-mtd_amstd-and-mtd_obsolete_chips-take-two.patch
-cris-remove-mtd_amstd-and-mtd_obsolete_chips-take-two-checkpatch-fixes.patch
-crisv10-fix-timer-interrupt-parameters.patch
-crisv10-improve-and-bugfix-fasttimer.patch
-crisv32-add-cache-flush-operations.patch

Merged into mainline or a subsystem tree

+update-checkpatchpl-to-version-012.patch
+file-capabilities-allow-sigcont-within-session-v2.patch
+cris-build-fixes-atomich-needs-compilerh.patch
+atmel_spi-labels-gpios-better.patch
+ps3-prefix-all-ps3-specific-kernel-modules-with.patch
+ps3fb-video-memory-size-cleanups.patch
+fix-boot-problem-with-iseries-lacking-hugepage-support.patch
+uml-build-fix.patch
+xen-mask-_page_pcd-from-ptes.patch
+pnp-increase-the-maximum-number-of-resources.patch
+pnp-increase-the-maximum-number-of-resources-fix.patch
+proc-fix-null-i_fop-oops.patch
+wait_task_stopped-dont-use-task_pid_nr_ns-lockless.patch
+proc-remove-races-from-proc_id_readdir.patch
+m68k-export-atari_keyb_init.patch
+amiga-zorro-bus-add-missing-zorro_device_remove.patch
+mac68k-mailing-list-addresss.patch
+tpm-tis-device-driver-locality-request.patch
+termios-document-callback-more-clearly.patch
+s3c24xx-ensure-we-only-configure-valid-gpios.patch
+ipmi-add-the-standard-watchdog-timeout-ioctls.patch
+s3c2410-add-bus-number-to-spi-gpio-driver.patch
+revert-keyspan-init-termios-properly.patch
+memory-hotplug-fix-fix-section-mismatch-in-vmammap_allock_block.patch
+memory-hotplug-x86_64-fix-section-mismatch-in-init_memory_mapping.patch
+fuse-fix-reading-past-eof.patch
+fuse-cleanup-add-fuse_get_attr_version.patch
+fuse-pass-open-flags-to-read-and-write.patch
+fuse-fix-fuse_file_ops-sending.patch
+fuse-fix-uninitialized-field-in-fuse_inode.patch
+fuse-fix-attribute-caching-after-rename.patch
+clone-prepare-to-recycle-clone_detached-and-clone_stopped-fix.patch

2.6.24 queue

-x86_64-efi-boot-support-efi-frame-buffer-v3.patch

Folded into x86_64-efi-boot-support-efi-frame-buffer.patch

+git-acpi-fixup.patch

Fix git-acpi.patch rejects

+agk-dm-dm-merge-max_hw_sector.patch
+agk-dm-dm-crypt-move-queue-functions.patch

device mapper tree updates

+gregkh-driver-kset-convert-to-kobj_sysfs_ops-vs-git-acpi.patch

Fix git-acpi versus driver tree

+intel-agp-enable-i915-recognition.patch

AGP fix

+time-fold-__get_realtime_clock_ts-into-getnstimeofday.patch

cleanup

+qlogic-infinipath-convert-ipath_eep_sem-to-mutex.patch
+fix-build-failure-when-config_infiniband_ipoib_cm-is-not-defined.patch

scsi things

+input-polled-device-timer-rounding.patch

input fix

+pata_sisc-add-packard-bell-easynote-k5305-to-laptops.patch
+ahci-invalid-use-of-writel-readl-with-iomap.patch
+libata-core-list-more-documentation-sources-for-reference.patch
+libata-iordy-handling.patch
+libata-sff-tf_load.patch
+pata_ali-add-mitac-8317-and-derivatives.patch
+pata_ali-lots-of-problems-still-showing-up-with-small-atapi-dma.patch
+pata_hpt37x-fix-cable-detect-bug-spotted-by-sergei.patch
+pata_isapnp-polled-devices.patch
+pata_pcmcia-minor-cleanups-and-support-for-dual-channel-cards.patch
+pata_ninja32-cardbus-ata-initial-support.patch
+libata-add-toshiba-mk1637gsx-to-spurious-command-completion-list.patch

sata/pata things

+ide-mm-sis5513-add-packard-bell-easynote-k5305-to-laptops.patch
+ide-mm-ide-dont-set-pio-mode-on-pre-eide-drives.patch
+ide-mm-siimage-remove-resetproc-method.patch
+ide-mm-ide-skip-ide_wait_not_busy-on-noprobe-disks.patch
+ide-mm-aec62xx-fix-kernel-oops-in-driver-s-probe-function.patch
+ide-mm-serverworks-cleanup-set_dma_mode-method.patch
+ide-mm-ide-disk-add-idedisk_set_doorlock-helper.patch
+ide-mm-ide-hopefully-fix-vdma-for-cs5520.patch
+ide-mm-cy82c693-correct-dma-modes-clipping.patch
+ide-mm-cy82c693-add-set_dma_mode-method.patch
+ide-mm-sgiioc4-add-ide_toggle_bounce-calls.patch
+ide-mm-icside-add-ide_toggle_bounce-calls.patch
+ide-mm-au1xxx-ide-add-ide_toggle_bounce-calls.patch
+ide-mm-ide-remove-ide_dma_on-and-dma_off_quietly-methods-from-ide_hwif_t.patch
+ide-mm-ide-cris-fix-dma-methods.patch
+ide-mm-atiixp-remove-dma_host_on-and-dma_host_off-methods.patch
+ide-mm-ide-move-drive-using_dma-check-to-callers-of-dma_host_on-method.patch
+ide-mm-ide-merge-dma_host_-on-off-methods-into-dma_host_set-method.patch

IDE tree updates

+ide-printk-fix.patch

fix it

+git-mips-fixup.patch

Fix rejects in git-mips.patch

+forcedeth-boot-delay-fix.patch

forcedeth fix

-nfs-stop-sillyname-renames-and-unmounts-from-racing.patch
-nfs-stop-sillyname-renames-and-unmounts-from-racing-fix.patch
-nfs-stop-sillyname-renames-and-unmounts-from-racing-fix-fix.patch
-nfs-stop-sillyname-renames-and-unmounts-from-racing-fix-fix-fix.patch
+nfs-stop-sillyname-renames-and-unmounts-from-racing-2.patch
+nfs-fix-up-problems-with-steves-sillyrename-fix.patch
+nfs-fix-nfs_free_unlinkdata.patch

Updated

-git-nfsd-fixup.patch

Unneeded

+git-nfsd-build-fix.patch

fix git-nfsd

+pci-add-pci-quirk-function-for-some-chipsets.patch
+drivers-pci-quirksc-coding-style-cleanup.patch
+more-sanity-checks-for-dmar.patch
+more-sanity-checks-for-dmar-checkpatch-fixes.patch

PCI updates

+pcie-fix-double-initialization-bug.patch

PCIE fix

+dell-cerc-support-for-megaraid_mbox.patch

scsi fix

+iommu-sg-merging-add-device_dma_parameters-structure.patch
+iommu-sg-merging-pci-add-device_dma_parameters-support.patch
+iommu-sg-merging-x86-make-pci-gart-iommu-respect-the-segment-size-limits.patch
+iommu-sg-merging-ppc-make-iommu-respect-the-segment-size-limits.patch
+iommu-sg-merging-ia64-make-sba_iommu-respect-the-segment-size-limits.patch
+iommu-sg-merging-alpha-make-pci_iommu-respect-the-segment-size-limits.patch
+iommu-sg-merging-sparc64-make-iommu-respect-the-segment-size-limits.patch
+iommu-sg-merging-parisc-make-iommu-respect-the-segment-size-limits.patch
+iommu-sg-merging-call-blk_queue_segment_boundary-in-__scsi_alloc_queue.patch
+iommu-sg-merging-sata_inic162x-use-pci_set_dma_max_seg_size.patch
+iommu-sg-merging-aacraid-use-pci_set_dma_max_seg_size.patch

iommu work

+ti-3410-5052-usb-serial-convert-td_open_close_lock-to-mutex.patch

USB driver cleanup

+git-x86-fixup.patch
+git-x86-thread_order-borkage.patch
+git-x86-thread_order-borkage-fix.patch
+git-x86-identify_cpu-fix.patch
+git-x86-memory_add_physaddr_to_nid-export-for-acpi-memhotplugko.patch
+git-x86-memory_add_physaddr_to_nid-export-for-acpi-memhotplugko-checkpatch-fixes.patch

Fixes to gix-x86.patch

+x86_64-make-sparsemem-vmemmap-the-default-memory-model-v2.patch

change x86_64 default memory model

+frv-fix-the-extern-declaration-of-kallsyms_num_syms.patch
+frv-arrange-things-such-that-bra-can-reach-from-the-trap.patch
+add-mike-christie-to-maintainers.patch
+wait_task_stopped-pass-correct-exit_code-to.patch
+isdn-validate-length-of-isdn_net_ioctl_cfgeaz.patch
+tty-add-the-new-termios2-ioctls-to-the-compatible.patch
+acpi-avoid-references-to-impossible-processors.patch

More 2.6.24 queue

+slub-move-kmem_cache_node-determination-into-add_full-and-add_partial-slub-workaround-for-lockdep-confusion.patch

Fix slub-move-kmem_cache_node-determination-into-add_full-and-add_partial.patch

+config_highpte-vs-sub-page-page-tables-fix-2.patch

Fix config_highpte-vs-sub-page-page-tables.patch some more

+vmstat-small-revisions-to-refresh_cpu_vm_stats.patch
+mm-dont-allow-ioremapping-of-ranges-larger-than-vmalloc-space.patch
+page-allocator-get-rid-of-the-list-of-cold-pages.patch
+page-allocator-get-rid-of-the-list-of-cold-pages-fix.patch
+mm-sparsec-check-the-return-value-of-sparse_index_alloc.patch

MM updates

+64bit-capability-support-legacy-support-fix.patch

Fix add-64-bit-capability-support-to-the-kernel.patch som emore

+smack-version-11c-simplified-mandatory-access-control-kernel.patch

smack

+m68knommu-removing-config-variable-dumptoflash.patch

m68knommu update

+pm-qos-remove-locks-around-blocking-notifier.patch

Fix PM qos patches

+m68k-array_size-cleanup.patch
+dio-array_size-cleanup.patch
+m68k-balance-ioremap-and-iounmap-in-m68k-atari-hades-pcic.patch
+nubus-kill-drivers-nubus-nubus_symsc.patch
+m68k-kill-arch-m68k-mac-mac_ksymsc.patch
+m68k-kill-arch-m68k-hp300-ksymsc.patch
+m68k-kill-arch-m68k-amiga-amiga_ksymsc.patch
+m68k-kill-arch-m68k-atari-atari_ksymsc.patch
+m68k-kill-arch-m68k-mvme16x-mvme16x_ksymsc.patch
+mac68k-macii-adb-comment-correction.patch
+mac68k-remove-dead-code.patch
+mac68k-add-nubus-card-definitions-and-a-typo-fix.patch
+mac68k-remove-dead-mac_adbkeycodes.patch

m68k stuff

+uml-arch-um-include-inith-needs-a-definition-of-__used.patch
+uml-improve-detection-of-host-cmov-checkpatch-fixes-fix.patch
+uml-tidy-pgtableh-fix.patch
+uml-remove-unused-variables-in-the-context-switcher.patch
+uml-convert-functions-to-void.patch
+uml-host-tls-diagnostics.patch
+uml-move-um_virt_to_phys.patch
+uml-header-untangling.patch
+uml-style-cleanup.patch
+uml-currenth-cleanup.patch
+uml-fix-page-table-data-sizes.patch
+uml-add-virt_to_pte.patch
+uml-simplify-sigsegv-handling.patch
+uml-use-ptrace-directly-in-libc-code.patch
+uml-kill-processes-instead-of-panicing-kernel.patch
+uml-add-missing-space.patch

UML updates

-procfs-detect-duplicate-names.patch

Updated

+use-__set_task_state-for-traced-stopped-tasks.patch

cleanup

+genericizing-iova-fix.patch

Fix genericizing-iova.patch

-mm-fix-blkdev-size-calculation-in-generic_write_checks.patch

Dropped

+fs-remove-dead-config-config_has_compat_epoll_event-symbol.patch
+alpha-parisc-removing-config-variable-debug_rwlock.patch
+document-i_sync-and-i_datasync.patch
+ps3-checkpatch-drivers-ps3-ps3-sys-managerc.patch
+ps3-checkpatch-drivers-ps3-ps3-vuartc.patch
+percpu-__percpu_alloc_mask-can-dynamically-size-percpu_data.patch
+i-oat-fixups-from-code-comments.patch
+printkc-use-unsigned-ints-instead-of-longs-for-logbuf-index.patch
+tpmc-fix-crash-during-device-removal.patch
+a-few-corrections-to-include-linux-kbuild.patch
+vt-bitlock-fix.patch
+avoid-divide-in-is_align.patch
+do_wait-remove-one-else-if-branch.patch

Misc

+atmel_spi-throughput-improvement.patch
+atmel_spi-chain-dma-transfers.patch

SPI updates

+gigaset-clean-up-urb-status-usage.patch
+gigaset-code-cleanups.patch
+bas_gigaset-suspend-support-v2.patch
+usb_gigaset-suspend-support-v3.patch
+gigaset-atomic-cleanup.patch

ISDN

+rtc-ds1302-rtc-support.patch
+rtc-ds1302-rtc-support-checkpatch-fixes.patch

RTC updates

+generic-gpio-gpio_chip-support-gpiolib-locking-simplified.patch

Fix generic-gpio-gpio_chip-support.patch

+add-buffer-head-related-helper-functions.patch
+ext2-add-block-bitmap-validation.patch
+ext3-add-block-bitmap-validation.patch
+ext4-add-block-bitmap-validation.patch
+ext4-add-block-bitmap-validation-fix.patch

ext2/3/4 runtie checks

-ridiculous-ext3-costs-was-re-page-fault-costs.patch

Dropped

-nfsd-fix-wrong-mnt_writer-count-in-rename.patch

Obsolete

+iget-stop-bfs-from-using-iget-and-read_inode-try-fix.patch

Fix iget-stop-bfs-from-using-iget-and-read_inode-try.patch

+add-dma-engine-driver-for-freescale-mpc85xx-processors-fix-fix.patch

Fix add-dma-engine-driver-for-freescale-mpc85xx-processors.patch

+embed-a-struct-path-into-struct-nameidata-instead-of-nd-dentrymnt-nfs4-fix.patch

Fix embed-a-struct-path-into-struct-nameidata-instead-of-nd-dentrymnt.patch

+use-struct-path-in-struct-svc_export-nfsd-fix-wrong-mnt_writer-count-in-rename.patch

Fix use-struct-path-in-struct-svc_export.patch some more

-suppress-aout-library-support-if-config_binfmt_aout.patch
-suppress-aout-library-support-if-config_binfmt_aout-checkpatch-fixes.patch
-usb-net2280-cant-have-a-function-called.patch
-usb-net2280-cant-have-a-function-called-checkpatch-fixes.patch
-mn10300-allocate-serial-port-uart-ids-for-on-chip-serial.patch
-mn10300-add-the-mn10300-am33-architecture-to-the-kernel.patch
-mn10300-add-the-mn10300-am33-architecture-to-the-kernel-fix.patch
-mn10300-add-the-mn10300-am33-architecture-to-the-kernel-ia64-fix.patch

Dropped

+add-the-namespaces-config-option.patch
+move-the-uts-namespace-under-uts_ns-option.patch
+move-the-ipc-namespace-under-ipc_ns-option.patch
+cleanup-the-code-managed-with-the-user_ns-option.patch
+cleanup-the-code-managed-with-the-user_ns-option-checkpatch-fixes.patch
+cleanup-the-code-managed-with-pid_ns-option.patch
+cleanup-the-code-managed-with-pid_ns-option-checkpatch-fixes.patch
+mark-net_ns-with-depends-on-namespaces.patch

Namespace updates

+proc-remove-module_license.patch
+proc-less-lock-operations-during-lookup.patch
+proc-simplify-function-prototypes.patch
+proc-remove-useless-check-on-symlink-removal.patch
+proc-remove-useless-checks-in-proc_register.patch
+proc-detect-duplicate-names-on-registration.patch
+proc-detect-duplicate-names-on-registration-fix.patch
+proc-implement-proc_single_file_operations.patch
+proc-rewrite-do_task_stat-to-correctly-handle-pid-namespaces.patch
+proc-seqfile-convert-proc_pid_statm.patch
+proc-proper-pidns-handling-for-proc-self.patch

procfs maintenance

+intel-iommu-pmen-support.patch
+intel-iommu-fault_reason_index_cleanuppatch.patch
+intel-iommu-fault_reason_index_cleanuppatch-fix.patch

Intel IOMMU updates

+tty-let-architectures-override-the-user-kernel-macros.patch
+tty-s390-support-for-termios2.patch
+moxa-first-pass-at-termios-reporting.patch
+n_tty-clean-up-old-code-to-follow-coding-style-and-mostly-checkpatch.patch
+rocket-first-pass-at-termios-reporting.patch
+rocket-dont-let-random-users-reset-the-controller.patch
+tty_audit-fix-checkpatch-complaint.patch
+tty_io-drag-screaming-into-coding-style-compliance.patch
+tty_ioctl-drag-screaming-into-compliance-with-the-coding.patch
+8250_early-coding-style.patch
+8250_gsc-coding-style.patch
+8250_hp300-coding-style.patch
+8250_hub6-codding-style.patch
+8250_pci-coding-style.patch
+serial8250-coding-style.patch
+8250-enable-rate-reporting-via-termios.patch
+serial_core-bring-mostly-into-line-with-coding-style.patch

tty/serial driver updates


3200 commits in 1255 patch files

All patches:

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



2007-11-21 05:51:57

by Dave Young

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1

Hi, andrew

modpost failed for me:
MODPOST 360 modules
ERROR: "empty_zero_page" [drivers/kvm/kvm.ko] undefined!
make[1]: *** [__modpost] Error 1
make: *** [modules] Error 2

Regards
dave

2007-11-21 05:56:19

by Kamezawa Hiroyuki

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1

I met.

CHK include/linux/version.h
CHK include/linux/utsrelease.h
CALL scripts/checksyscalls.sh
<stdin>:1389:2: warning: #warning syscall revokeat not implemented
<stdin>:1393:2: warning: #warning syscall frevoke not implemented
CHK include/linux/compile.h
make[1]: *** No rule to make target `arch/ia64/lib/copy_page-export.o', needed by `arch/ia64/lib/built-in.o'. Stop.
make: *** [arch/ia64/lib] Error 2

fix (for my config ?) is attached.

=
This was necessary to build.

Signed-off-by: KAMEZAWA Hiroyuki <[email protected]>

arch/ia64/lib/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

Index: linux-2.6.24-rc3-mm1/arch/ia64/lib/Makefile
===================================================================
--- linux-2.6.24-rc3-mm1.orig/arch/ia64/lib/Makefile
+++ linux-2.6.24-rc3-mm1/arch/ia64/lib/Makefile
@@ -2,7 +2,7 @@
# Makefile for ia64-specific library routines..
#

-obj-y := io.o copy_page-export.o
+obj-y := io.o

lib-y := __divsi3.o __udivsi3.o __modsi3.o __umodsi3.o \
__divdi3.o __udivdi3.o __moddi3.o __umoddi3.o \

2007-11-21 05:57:35

by Kamalesh Babulal

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1 - Build Failure on S390x

Hi Andrew,

The kernel build fails on S390x, with

arch/s390/kernel/ipl.c: In function `ipl_register_fcp_files':
arch/s390/kernel/ipl.c:415: error: `ipl_subsys' undeclared (first use in this function)
arch/s390/kernel/ipl.c:415: error: (Each undeclared identifier is reported only once
arch/s390/kernel/ipl.c:415: error: for each function it appears in.)
arch/s390/kernel/ipl.c: In function `ipl_init':
arch/s390/kernel/ipl.c:449: error: implicit declaration of function `firmware_register'
arch/s390/kernel/ipl.c:449: error: `ipl_subsys' undeclared (first use in this function)
arch/s390/kernel/ipl.c: In function `on_panic_show':
arch/s390/kernel/ipl.c:764: error: implicit declaration of function `shutdown_action_str'
arch/s390/kernel/ipl.c:764: error: `on_panic_action' undeclared (first use in this function)
arch/s390/kernel/ipl.c:764: warning: format argument is not a pointer (arg 3)
arch/s390/kernel/ipl.c:764: warning: format argument is not a pointer (arg 3)
arch/s390/kernel/ipl.c: In function `on_panic_store':
arch/s390/kernel/ipl.c:771: error: `SHUTDOWN_REIPL_STR' undeclared (first use in this function)
arch/s390/kernel/ipl.c:772: error: `on_panic_action' undeclared (first use in this function)
arch/s390/kernel/ipl.c:772: error: `SHUTDOWN_REIPL' undeclared (first use in this function)
arch/s390/kernel/ipl.c:773: error: `SHUTDOWN_DUMP_STR' undeclared (first use in this function)
arch/s390/kernel/ipl.c:775: error: `SHUTDOWN_DUMP' undeclared (first use in this function)
arch/s390/kernel/ipl.c:776: error: `SHUTDOWN_STOP_STR' undeclared (first use in this function)
arch/s390/kernel/ipl.c:778: error: `SHUTDOWN_STOP' undeclared (first use in this function)
arch/s390/kernel/ipl.c: At top level:
arch/s390/kernel/ipl.c:879: error: redefinition of 'ipl_register_fcp_files'
arch/s390/kernel/ipl.c:412: error: previous definition of 'ipl_register_fcp_files' was here
arch/s390/kernel/ipl.c:904: error: redefinition of 'ipl_init'
arch/s390/kernel/ipl.c:446: error: previous definition of 'ipl_init' was here
arch/s390/kernel/ipl.c:1050: error: `reipl_run' undeclared here (not in a function)
arch/s390/kernel/ipl.c:1050: error: initializer element is not constant
arch/s390/kernel/ipl.c:1050: error: (near initialization for `reipl_action.fn')
arch/s390/kernel/ipl.c:1058: error: redefinition of 'sys_dump_fcp_wwpn_show'
arch/s390/kernel/ipl.c:662: error: previous definition of 'sys_dump_fcp_wwpn_show' was here
arch/s390/kernel/ipl.c:1058: error: redefinition of 'sys_dump_fcp_wwpn_store'
arch/s390/kernel/ipl.c:662: error: previous definition of 'sys_dump_fcp_wwpn_store' was here
arch/s390/kernel/ipl.c:1058: error: redefinition of 'sys_dump_fcp_wwpn_attr'
arch/s390/kernel/ipl.c:662: error: previous definition of 'sys_dump_fcp_wwpn_attr' was here
arch/s390/kernel/ipl.c:1060: error: redefinition of 'sys_dump_fcp_lun_show'
arch/s390/kernel/ipl.c:664: error: previous definition of 'sys_dump_fcp_lun_show' was here
arch/s390/kernel/ipl.c:1060: error: redefinition of 'sys_dump_fcp_lun_store'
arch/s390/kernel/ipl.c:664: error: previous definition of 'sys_dump_fcp_lun_store' was here
arch/s390/kernel/ipl.c:1060: error: redefinition of 'sys_dump_fcp_lun_attr'
arch/s390/kernel/ipl.c:664: error: previous definition of 'sys_dump_fcp_lun_attr' was here
arch/s390/kernel/ipl.c:1062: error: redefinition of 'sys_dump_fcp_bootprog_show'
arch/s390/kernel/ipl.c:666: error: previous definition of 'sys_dump_fcp_bootprog_show' was here
arch/s390/kernel/ipl.c:1062: error: redefinition of 'sys_dump_fcp_bootprog_store'
arch/s390/kernel/ipl.c:666: error: previous definition of 'sys_dump_fcp_bootprog_store' was here
arch/s390/kernel/ipl.c:1062: error: redefinition of 'sys_dump_fcp_bootprog_attr'
arch/s390/kernel/ipl.c:666: error: previous definition of 'sys_dump_fcp_bootprog_attr' was here
arch/s390/kernel/ipl.c:1064: error: redefinition of 'sys_dump_fcp_br_lba_show'
arch/s390/kernel/ipl.c:668: error: previous definition of 'sys_dump_fcp_br_lba_show' was here
arch/s390/kernel/ipl.c:1064: error: redefinition of 'sys_dump_fcp_br_lba_store'
arch/s390/kernel/ipl.c:668: error: previous definition of 'sys_dump_fcp_br_lba_store' was here
arch/s390/kernel/ipl.c:1064: error: redefinition of 'sys_dump_fcp_br_lba_attr'
arch/s390/kernel/ipl.c:668: error: previous definition of 'sys_dump_fcp_br_lba_attr' was here
arch/s390/kernel/ipl.c:1066: error: redefinition of 'sys_dump_fcp_device_show'
arch/s390/kernel/ipl.c:670: error: previous definition of 'sys_dump_fcp_device_show' was here
arch/s390/kernel/ipl.c:1066: error: redefinition of 'sys_dump_fcp_device_store'
arch/s390/kernel/ipl.c:670: error: previous definition of 'sys_dump_fcp_device_store' was here
arch/s390/kernel/ipl.c:1066: error: redefinition of 'sys_dump_fcp_device_attr'
arch/s390/kernel/ipl.c:670: error: previous definition of 'sys_dump_fcp_device_attr' was here
arch/s390/kernel/ipl.c:1069: error: redefinition of 'dump_fcp_attrs'
arch/s390/kernel/ipl.c:673: error: previous definition of 'dump_fcp_attrs' was here
arch/s390/kernel/ipl.c:1078: error: redefinition of 'dump_fcp_attr_group'
arch/s390/kernel/ipl.c:682: error: previous definition of 'dump_fcp_attr_group' was here
arch/s390/kernel/ipl.c:1085: error: redefinition of 'sys_dump_ccw_device_show'
arch/s390/kernel/ipl.c:689: error: previous definition of 'sys_dump_ccw_device_show' was here
arch/s390/kernel/ipl.c:1085: error: redefinition of 'sys_dump_ccw_device_store'
arch/s390/kernel/ipl.c:689: error: previous definition of 'sys_dump_ccw_device_store' was here
arch/s390/kernel/ipl.c:1085: error: redefinition of 'sys_dump_ccw_device_attr'
arch/s390/kernel/ipl.c:689: error: previous definition of 'sys_dump_ccw_device_attr' was here
arch/s390/kernel/ipl.c:1088: error: redefinition of 'dump_ccw_attrs'
arch/s390/kernel/ipl.c:692: error: previous definition of 'dump_ccw_attrs' was here
arch/s390/kernel/ipl.c:1093: error: redefinition of 'dump_ccw_attr_group'
arch/s390/kernel/ipl.c:697: error: previous definition of 'dump_ccw_attr_group' was here
arch/s390/kernel/ipl.c:1101: error: redefinition of 'dump_set_type'
arch/s390/kernel/ipl.c:705: error: previous definition of 'dump_set_type' was here
arch/s390/kernel/ipl.c:1122: error: conflicting types for 'dump_type_show'
arch/s390/kernel/ipl.c:729: error: previous definition of 'dump_type_show' was here
arch/s390/kernel/ipl.c:1128: error: conflicting types for 'dump_type_store'
arch/s390/kernel/ipl.c:736: error: previous definition of 'dump_type_store' was here
arch/s390/kernel/ipl.c:1140: error: variable `dump_type_attr' has initializer but incomplete type
arch/s390/kernel/ipl.c:1140: error: conflicting types for 'dump_type_attr'
arch/s390/kernel/ipl.c:748: error: previous definition of 'dump_type_attr' was here
arch/s390/kernel/ipl.c:1141: error: unknown field `attr' specified in initializer
arch/s390/kernel/ipl.c:1141: error: extra brace group at end of initializer
arch/s390/kernel/ipl.c:1141: error: (near initialization for `dump_type_attr')
arch/s390/kernel/ipl.c:1141: warning: excess elements in struct initializer
arch/s390/kernel/ipl.c:1141: warning: (near initialization for `dump_type_attr')
arch/s390/kernel/ipl.c:1141: error: unknown field `show' specified in initializer
arch/s390/kernel/ipl.c:1141: warning: excess elements in struct initializer
arch/s390/kernel/ipl.c:1141: warning: (near initialization for `dump_type_attr')
arch/s390/kernel/ipl.c:1141: error: unknown field `store' specified in initializer
arch/s390/kernel/ipl.c:1141: warning: excess elements in struct initializer
arch/s390/kernel/ipl.c:1141: warning: (near initialization for `dump_type_attr')
arch/s390/kernel/ipl.c:1143: error: syntax error before '(' token
arch/s390/kernel/ipl.c: In function `dump_init':
arch/s390/kernel/ipl.c:1231: warning: passing arg 2 of `sysfs_create_file' from incompatible pointer type
arch/s390/kernel/ipl.c: In function `shutdown_actions_init':
arch/s390/kernel/ipl.c:1254: warning: passing arg 2 of `sysfs_create_file' from incompatible pointer type
arch/s390/kernel/ipl.c:1260: error: `shutdown_on_panic_nb' undeclared (first use in this function)
arch/s390/kernel/ipl.c: At top level:
arch/s390/kernel/ipl.c:237: warning: 'get_ipl_type' defined but not used
arch/s390/kernel/ipl.c:477: warning: 'ipl_action' defined but not used
arch/s390/kernel/ipl.c:682: warning: 'dump_fcp_attr_group' defined but not used
arch/s390/kernel/ipl.c:697: warning: 'dump_ccw_attr_group' defined but not used
arch/s390/kernel/ipl.c:748: warning: 'dump_type_attr' defined but not used
arch/s390/kernel/ipl.c:843: warning: 'do_dump' defined but not used
arch/s390/kernel/ipl.c:1049: warning: 'reipl_action' defined but not used
arch/s390/kernel/ipl.c:1146: warning: 'dump_run' defined but not used
make[1]: *** [arch/s390/kernel/ipl.o] Error 1
make: *** [arch/s390/kernel] Error 2
11/21/2007-06:02:16 Build the kernel. Failed rc = 2

--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.

2007-11-21 06:01:05

by Andrew Morton

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1

On Wed, 21 Nov 2007 13:51:47 +0800 "Dave Young" <[email protected]> wrote:

> Hi, andrew
>
> modpost failed for me:
> MODPOST 360 modules
> ERROR: "empty_zero_page" [drivers/kvm/kvm.ko] undefined!
> make[1]: *** [__modpost] Error 1
> make: *** [modules] Error 2
>

You're a victim of the hasty unexporting fad. Which architecture?
x86_64 I guess?

2007-11-21 06:03:44

by Dave Young

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1

On Nov 21, 2007 2:00 PM, Andrew Morton <[email protected]> wrote:
>
> On Wed, 21 Nov 2007 13:51:47 +0800 "Dave Young" <[email protected]> wrote:
>
> > Hi, andrew
> >
> > modpost failed for me:
> > MODPOST 360 modules
> > ERROR: "empty_zero_page" [drivers/kvm/kvm.ko] undefined!
> > make[1]: *** [__modpost] Error 1
> > make: *** [modules] Error 2
> >
>
> You're a victim of the hasty unexporting fad. Which architecture?
> x86_64 I guess?
>
Hi,
ia32 instead.

Regards
dave

2007-11-21 06:05:36

by Andrew Morton

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1 - Build Failure on S390x

On Wed, 21 Nov 2007 11:26:51 +0530 Kamalesh Babulal <[email protected]> wrote:

> The kernel build fails on S390x, with

Yes, sorry, I forgot to mention that. I got a large patch reject
between Greg's driver tree and the s390 tree and I couldn't be bothered
fixing it. s390 is busted in 2.6.24-rc3-mm1.

2007-11-21 06:08:55

by Andrew Morton

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1

On Wed, 21 Nov 2007 14:58:38 +0900 KAMEZAWA Hiroyuki <[email protected]> wrote:

> I met.
>
> CHK include/linux/version.h
> CHK include/linux/utsrelease.h
> CALL scripts/checksyscalls.sh
> <stdin>:1389:2: warning: #warning syscall revokeat not implemented
> <stdin>:1393:2: warning: #warning syscall frevoke not implemented
> CHK include/linux/compile.h
> make[1]: *** No rule to make target `arch/ia64/lib/copy_page-export.o', needed by `arch/ia64/lib/built-in.o'. Stop.
> make: *** [arch/ia64/lib] Error 2
>
> fix (for my config ?) is attached.
>
> =
> This was necessary to build.
>
> Signed-off-by: KAMEZAWA Hiroyuki <[email protected]>
>
> arch/ia64/lib/Makefile | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Index: linux-2.6.24-rc3-mm1/arch/ia64/lib/Makefile
> ===================================================================
> --- linux-2.6.24-rc3-mm1.orig/arch/ia64/lib/Makefile
> +++ linux-2.6.24-rc3-mm1/arch/ia64/lib/Makefile
> @@ -2,7 +2,7 @@
> # Makefile for ia64-specific library routines..
> #
>
> -obj-y := io.o copy_page-export.o
> +obj-y := io.o
>
> lib-y := __divsi3.o __udivsi3.o __modsi3.o __umodsi3.o \
> __divdi3.o __udivdi3.o __moddi3.o __umoddi3.o \

erp. Actually, it should be this:

--- a/arch/ia64/lib/Makefile~ia64-export-copy_page-to-modules-fix-fix
+++ a/arch/ia64/lib/Makefile
@@ -2,7 +2,7 @@
# Makefile for ia64-specific library routines..
#

-obj-y := io.o copy_page-export.o
+obj-y := io.o

lib-y := __divsi3.o __udivsi3.o __modsi3.o __umodsi3.o \
__divdi3.o __udivdi3.o __moddi3.o __umoddi3.o \
_

2007-11-21 06:11:38

by Kamalesh Babulal

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1 - Kernel Panic on IO-APIC

Hi Andrew,

Kernel panic's across different architectures like powerpc, x86_64,

Dentry cache hash table entries: 8388608 (order: 14, 67108864 bytes)
Inode-cache hash table entries: 4194304 (order: 13, 33554432 bytes)
Mount-cache hash table entries: 256
SMP alternatives: switching to UP code
ACPI: Core revision 20070126
..MP-BIOS bug: 8254 timer not connected to IO-APIC
Kernel panic - not syncing: IO-APIC + timer doesn't work! Try using the 'noapic' kernel parameter

--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.

2007-11-21 06:16:34

by Andrew Morton

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1

On Wed, 21 Nov 2007 14:03:34 +0800 "Dave Young" <[email protected]> wrote:

> On Nov 21, 2007 2:00 PM, Andrew Morton <[email protected]> wrote:
> >
> > On Wed, 21 Nov 2007 13:51:47 +0800 "Dave Young" <[email protected]> wrote:
> >
> > > Hi, andrew
> > >
> > > modpost failed for me:
> > > MODPOST 360 modules
> > > ERROR: "empty_zero_page" [drivers/kvm/kvm.ko] undefined!
> > > make[1]: *** [__modpost] Error 1
> > > make: *** [modules] Error 2
> > >
> >
> > You're a victim of the hasty unexporting fad. Which architecture?
> > x86_64 I guess?
> >
> Hi,
> ia32 instead.
>

oic. Like this, I guess.

--- a/arch/x86/kernel/i386_ksyms_32.c~git-x86-i386-export-empty_zero_page
+++ a/arch/x86/kernel/i386_ksyms_32.c
@@ -2,6 +2,7 @@
#include <asm/semaphore.h>
#include <asm/checksum.h>
#include <asm/desc.h>
+#include <asm/pgtable.h>

EXPORT_SYMBOL(__down_failed);
EXPORT_SYMBOL(__down_failed_interruptible);
@@ -22,3 +23,4 @@ EXPORT_SYMBOL(__put_user_8);
EXPORT_SYMBOL(strstr);

EXPORT_SYMBOL(csum_partial);
+EXPORT_SYMBOL(empty_zero_page);
_

2007-11-21 06:19:29

by Andrew Morton

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1 - Kernel Panic on IO-APIC

On Wed, 21 Nov 2007 11:41:23 +0530 Kamalesh Babulal <[email protected]> wrote:

> Hi Andrew,
>
> Kernel panic's across different architectures like powerpc, x86_64,

powerpc complains about IO-APICs??

> Dentry cache hash table entries: 8388608 (order: 14, 67108864 bytes)
> Inode-cache hash table entries: 4194304 (order: 13, 33554432 bytes)
> Mount-cache hash table entries: 256
> SMP alternatives: switching to UP code
> ACPI: Core revision 20070126
> ..MP-BIOS bug: 8254 timer not connected to IO-APIC
> Kernel panic - not syncing: IO-APIC + timer doesn't work! Try using the 'noapic' kernel parameter

ACPI or x86 breakage, I guess.

Did 'noapic' work?

2007-11-21 06:23:18

by Dave Young

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1

On Nov 21, 2007 2:15 PM, Andrew Morton <[email protected]> wrote:
>
> On Wed, 21 Nov 2007 14:03:34 +0800 "Dave Young" <[email protected]> wrote:
>
> > On Nov 21, 2007 2:00 PM, Andrew Morton <[email protected]> wrote:
> > >
> > > On Wed, 21 Nov 2007 13:51:47 +0800 "Dave Young" <[email protected]> wrote:
> > >
> > > > Hi, andrew
> > > >
> > > > modpost failed for me:
> > > > MODPOST 360 modules
> > > > ERROR: "empty_zero_page" [drivers/kvm/kvm.ko] undefined!
> > > > make[1]: *** [__modpost] Error 1
> > > > make: *** [modules] Error 2
> > > >
> > >
> > > You're a victim of the hasty unexporting fad. Which architecture?
> > > x86_64 I guess?
> > >
> > Hi,
> > ia32 instead.
> >
>
> oic. Like this, I guess.
>
> --- a/arch/x86/kernel/i386_ksyms_32.c~git-x86-i386-export-empty_zero_page
> +++ a/arch/x86/kernel/i386_ksyms_32.c
> @@ -2,6 +2,7 @@
> #include <asm/semaphore.h>
> #include <asm/checksum.h>
> #include <asm/desc.h>
> +#include <asm/pgtable.h>
>
> EXPORT_SYMBOL(__down_failed);
> EXPORT_SYMBOL(__down_failed_interruptible);
> @@ -22,3 +23,4 @@ EXPORT_SYMBOL(__put_user_8);
> EXPORT_SYMBOL(strstr);
>
> EXPORT_SYMBOL(csum_partial);
> +EXPORT_SYMBOL(empty_zero_page);
> _
>

Yes, passed :)

2007-11-21 08:25:16

by Kamalesh Babulal

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1 make headers_check fails

Hi Andrew,

The make headers_check fails,

CHECK include/linux/usb/gadgetfs.h
CHECK include/linux/usb/ch9.h
CHECK include/linux/usb/cdc.h
CHECK include/linux/usb/audio.h
CHECK include/linux/kvm.h
/root/kernels/linux-2.6.24-rc3/usr/include/linux/kvm.h requires asm/kvm.h, which does not exist in exported headers
make[2]: *** [/root/kernels/linux-2.6.24-rc3/usr/include/linux/.check.kvm.h] Error 1
make[1]: *** [linux] Error 2
make: *** [headers_check] Error 2


--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.

2007-11-21 08:33:34

by Andrew Morton

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1 make headers_check fails

On Wed, 21 Nov 2007 13:54:50 +0530 Kamalesh Babulal <[email protected]> wrote:

> The make headers_check fails,
>
> CHECK include/linux/usb/gadgetfs.h
> CHECK include/linux/usb/ch9.h
> CHECK include/linux/usb/cdc.h
> CHECK include/linux/usb/audio.h
> CHECK include/linux/kvm.h
> /root/kernels/linux-2.6.24-rc3/usr/include/linux/kvm.h requires asm/kvm.h, which does not exist in exported headers

hm, works for me, on i386 and x86_64. What's different over there?

2007-11-21 08:39:26

by Kamezawa Hiroyuki

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1 (sync is slow ?)

Hi, Andrew

I got following result in 'sync' command.
It was too slow. (memory controller config is off ;)
I attaches my .config.
==
[2.6.24-rc3-mm1]
[kamezawa@dr-test2 ~]$ dd if=/dev/zero of=./tmpfile bs=4096 count=100000
100000+0 records in
100000+0 records out
409600000 bytes (410 MB) copied, 1.46706 seconds, 279 MB/s
[kamezawa@dr-test2 ~]$ time sync

real 3m6.440s
user 0m0.000s
sys 0m0.133s


on, 2.6.23-rc2-mm1, 2.6.23-rc3 there was no problem.
==
[2.6.24-rc3]
[kamezawa@dr-test2 ~]$ dd if=/dev/zero of=tmpfile bs=4096 count=100000
100000+0 records in
100000+0 records out
409600000 bytes (410 MB) copied, 2.07717 seconds, 197 MB/s
[kamezawa@dr-test2 ~]$ time sync

real 0m9.935s
user 0m0.001s
sys 0m0.113s

[2.6.24-rc3]
[kamezawa@dr-test2 ~]$ dd if=/dev/zero of=./tmpfile bs=4096 count=100000
100000+0 records in
100000+0 records out
409600000 bytes (410 MB) copied, 1.37147 seconds, 299 MB/s
[kamezawa@dr-test2 ~]$ time sync[2.6.24-rc2-mm1]


real 0m11.718s
user 0m0.000s
sys 0m0.138s

==
-Kame


Attachments:
myconfig (46.38 kB)

2007-11-21 08:41:58

by Kamalesh Babulal

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1 make headers_check fails

Andrew Morton wrote:
> On Wed, 21 Nov 2007 13:54:50 +0530 Kamalesh Babulal <[email protected]> wrote:
>
>> The make headers_check fails,
>>
>> CHECK include/linux/usb/gadgetfs.h
>> CHECK include/linux/usb/ch9.h
>> CHECK include/linux/usb/cdc.h
>> CHECK include/linux/usb/audio.h
>> CHECK include/linux/kvm.h
>> /root/kernels/linux-2.6.24-rc3/usr/include/linux/kvm.h requires asm/kvm.h, which does not exist in exported headers
>
> hm, works for me, on i386 and x86_64. What's different over there?
Hi Andrew,

It fails on the powerpc box, with allyesconfig option.

--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.

2007-11-21 08:46:16

by Avi Kivity

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1 make headers_check fails

Kamalesh Babulal wrote:
> Andrew Morton wrote:
>
>> On Wed, 21 Nov 2007 13:54:50 +0530 Kamalesh Babulal <[email protected]> wrote:
>>
>>
>>> The make headers_check fails,
>>>
>>> CHECK include/linux/usb/gadgetfs.h
>>> CHECK include/linux/usb/ch9.h
>>> CHECK include/linux/usb/cdc.h
>>> CHECK include/linux/usb/audio.h
>>> CHECK include/linux/kvm.h
>>> /root/kernels/linux-2.6.24-rc3/usr/include/linux/kvm.h requires asm/kvm.h, which does not exist in exported headers
>>>
>> hm, works for me, on i386 and x86_64. What's different over there?
>>
> Hi Andrew,
>
> It fails on the powerpc box, with allyesconfig option.
>
>

How do we fix this? Export linux/kvm.h only on x86? Seems ugly.

--
Any sufficiently difficult bug is indistinguishable from a feature.

2007-11-21 08:47:21

by Kamezawa Hiroyuki

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1 (sync is slow ?)

On Wed, 21 Nov 2007 17:42:15 +0900
KAMEZAWA Hiroyuki <[email protected]> wrote:

> Hi, Andrew
>
> I got following result in 'sync' command.
> It was too slow. (memory controller config is off ;)
> I attaches my .config.
> ==
> [2.6.24-rc3-mm1]
> [kamezawa@dr-test2 ~]$ dd if=/dev/zero of=./tmpfile bs=4096 count=100000
> 100000+0 records in
> 100000+0 records out
> 409600000 bytes (410 MB) copied, 1.46706 seconds, 279 MB/s
> [kamezawa@dr-test2 ~]$ time sync
>
> real 3m6.440s
> user 0m0.000s
> sys 0m0.133s
>
Ah, one of cpu shows 100% iowait in 'top' command while this.

-Kame

2007-11-21 08:49:23

by Andrew Morton

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1 (sync is slow ?)

On Wed, 21 Nov 2007 17:42:15 +0900 KAMEZAWA Hiroyuki <[email protected]> wrote:

> Hi, Andrew
>
> I got following result in 'sync' command.
> It was too slow. (memory controller config is off ;)
> I attaches my .config.
> ==
> [2.6.24-rc3-mm1]
> [kamezawa@dr-test2 ~]$ dd if=/dev/zero of=./tmpfile bs=4096 count=100000
> 100000+0 records in
> 100000+0 records out
> 409600000 bytes (410 MB) copied, 1.46706 seconds, 279 MB/s
> [kamezawa@dr-test2 ~]$ time sync
>
> real 3m6.440s
> user 0m0.000s
> sys 0m0.133s
>
>
> on, 2.6.23-rc2-mm1, 2.6.23-rc3 there was no problem.
> ==
> [2.6.24-rc3]
> [kamezawa@dr-test2 ~]$ dd if=/dev/zero of=tmpfile bs=4096 count=100000
> 100000+0 records in
> 100000+0 records out
> 409600000 bytes (410 MB) copied, 2.07717 seconds, 197 MB/s
> [kamezawa@dr-test2 ~]$ time sync
>
> real 0m9.935s
> user 0m0.001s
> sys 0m0.113s
>
> [2.6.24-rc3]
> [kamezawa@dr-test2 ~]$ dd if=/dev/zero of=./tmpfile bs=4096 count=100000
> 100000+0 records in
> 100000+0 records out
> 409600000 bytes (410 MB) copied, 1.37147 seconds, 299 MB/s
> [kamezawa@dr-test2 ~]$ time sync[2.6.24-rc2-mm1]
>
>
> real 0m11.718s
> user 0m0.000s
> sys 0m0.138s

Well I wonder how we did that.

It seems OK here from a quick test (i386, ext3-on-IDE).

Maybe device driver/block breakage?

2007-11-21 08:54:37

by Robert P. J. Day

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1 make headers_check fails

On Wed, 21 Nov 2007, Avi Kivity wrote:

> Kamalesh Babulal wrote:
> > Andrew Morton wrote:
> >
> > > On Wed, 21 Nov 2007 13:54:50 +0530 Kamalesh Babulal
> > > <[email protected]> wrote:
> > >
> > >
> > > > The make headers_check fails,
> > > >
> > > > CHECK include/linux/usb/gadgetfs.h
> > > > CHECK include/linux/usb/ch9.h
> > > > CHECK include/linux/usb/cdc.h
> > > > CHECK include/linux/usb/audio.h
> > > > CHECK include/linux/kvm.h
> > > > /root/kernels/linux-2.6.24-rc3/usr/include/linux/kvm.h requires
> > > > asm/kvm.h, which does not exist in exported headers
> > > >
> > > hm, works for me, on i386 and x86_64. What's different over there?
> > >
> > Hi Andrew,
> >
> > It fails on the powerpc box, with allyesconfig option.
>
> How do we fix this? Export linux/kvm.h only on x86? Seems ugly.

i'm sure i'm going to humiliate myself for asking this, but shouldn't
i be able to reproduce the above by just running:

$ make ARCH=powerpc headers_install/headers_check

we've sort of had this discussion before where, IIRC, you should be
able to generate the appropriate arch-specific headers without having
the corresponding toolchain, no? so why can't i reproduce that error
on my x86 box?

rday
--

========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://crashcourse.ca
========================================================================

2007-11-21 08:55:05

by Kamalesh Babulal

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1- powerpc link failure

Hi Andrew,

The kernel build fails on powerpc while linking,

AS .tmp_kallsyms3.o
LD vmlinux.o
ld: TOC section size exceeds 64k
make: *** [vmlinux.o] Error 1

The patch posted at http://lkml.org/lkml/2007/11/13/414, solves this
failure.

--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.

2007-11-21 09:05:00

by Andrew Morton

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1 make headers_check fails

On Wed, 21 Nov 2007 03:52:08 -0500 (EST) "Robert P. J. Day" <[email protected]> wrote:

> On Wed, 21 Nov 2007, Avi Kivity wrote:
>
> > Kamalesh Babulal wrote:
> > > Andrew Morton wrote:
> > >
> > > > On Wed, 21 Nov 2007 13:54:50 +0530 Kamalesh Babulal
> > > > <[email protected]> wrote:
> > > >
> > > >
> > > > > The make headers_check fails,
> > > > >
> > > > > CHECK include/linux/usb/gadgetfs.h
> > > > > CHECK include/linux/usb/ch9.h
> > > > > CHECK include/linux/usb/cdc.h
> > > > > CHECK include/linux/usb/audio.h
> > > > > CHECK include/linux/kvm.h
> > > > > /root/kernels/linux-2.6.24-rc3/usr/include/linux/kvm.h requires
> > > > > asm/kvm.h, which does not exist in exported headers
> > > > >
> > > > hm, works for me, on i386 and x86_64. What's different over there?
> > > >
> > > Hi Andrew,
> > >
> > > It fails on the powerpc box, with allyesconfig option.
> >
> > How do we fix this? Export linux/kvm.h only on x86? Seems ugly.
>
> i'm sure i'm going to humiliate myself for asking this, but shouldn't
> i be able to reproduce the above by just running:
>
> $ make ARCH=powerpc headers_install/headers_check
>
> we've sort of had this discussion before where, IIRC, you should be
> able to generate the appropriate arch-specific headers without having
> the corresponding toolchain, no? so why can't i reproduce that error
> on my x86 box?
>

I can.

setenv ARCH powerpc
make mrproper
make allmodconfig
make headers_check

2007-11-21 09:08:37

by Robert P. J. Day

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1 make headers_check fails

On Wed, 21 Nov 2007, Andrew Morton wrote:

> On Wed, 21 Nov 2007 03:52:08 -0500 (EST) "Robert P. J. Day" <[email protected]> wrote:
... snip ...
> > i'm sure i'm going to humiliate myself for asking this, but shouldn't
> > i be able to reproduce the above by just running:
> >
> > $ make ARCH=powerpc headers_install/headers_check
> >
> > we've sort of had this discussion before where, IIRC, you should be
> > able to generate the appropriate arch-specific headers without having
> > the corresponding toolchain, no? so why can't i reproduce that error
> > on my x86 box?
> >
>
> I can.
>
> setenv ARCH powerpc
> make mrproper
> make allmodconfig
> make headers_check

ack. never mind, i just noticed that this is with the rc3-mm1 tree.
i was confused since, in the latest git tree, there is absolutely *no*
inclusion of <asm/kvm.h> anywhere in the tree, so clearly something
like that has been added in the mm tree.

sorry for the noise.

rday
--

========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://crashcourse.ca
========================================================================

2007-11-21 09:23:04

by Kamalesh Babulal

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1 - Kernel Panic on IO-APIC

Andrew Morton wrote:
> On Wed, 21 Nov 2007 11:41:23 +0530 Kamalesh Babulal <[email protected]> wrote:
>
>> Hi Andrew,
>>
>> Kernel panic's across different architectures like powerpc, x86_64,
>
> powerpc complains about IO-APICs??
>
>> Dentry cache hash table entries: 8388608 (order: 14, 67108864 bytes)
>> Inode-cache hash table entries: 4194304 (order: 13, 33554432 bytes)
>> Mount-cache hash table entries: 256
>> SMP alternatives: switching to UP code
>> ACPI: Core revision 20070126
>> ..MP-BIOS bug: 8254 timer not connected to IO-APIC
>> Kernel panic - not syncing: IO-APIC + timer doesn't work! Try using the 'noapic' kernel parameter
>
> ACPI or x86 breakage, I guess.
>
> Did 'noapic' work?
Hi Andrew,

Passing noapic works, but the kernel oops's

[ 97.161103] Unable to handle kernel NULL pointer dereference at 0000000000000009 RIP:
[ 97.193973] [<ffffffff802341df>] cpu_to_allnodes_group+0x69/0x7c
[ 97.245359] PGD 0
[ 97.257611] Oops: 0000 [1] SMP
[ 97.276638] last sysfs file:
[ 97.294417] CPU 0
[ 97.306620] Modules linked in:
[ 97.325066] Pid: 1, comm: swapper Not tainted 2.6.24-rc3-mm1 #1
[ 97.360514] RIP: 0010:[<ffffffff802341df>] [<ffffffff802341df>] cpu_to_allnodes_group+0x69/0x7c
[ 97.413287] RSP: 0000:ffff81012fabb650 EFLAGS: 00010286
[ 97.445363] RAX: ffffffff809bb060 RBX: ffff81012fabb650 RCX: 00000000000000ff
[ 97.488378] RDX: 0000000000000001 RSI: 000000000000013e RDI: 0000000000000100
[ 97.531413] RBP: ffff81012fabb680 R08: ffff81012fa88180 R09: 0000000000000000
[ 97.574428] R10: 0000000000000000 R11: 0000000000000000 R12: ffff810001005f50
[ 97.617394] R13: 0000000000000000 R14: ffff81012fa88180 R15: ffff810001005f40
[ 97.660421] FS: 0000000000000000(0000) GS:ffffffff806c3000(0000) knlGS:0000000000000000
[ 97.709327] CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
[ 97.743995] CR2: 0000000000000009 CR3: 0000000000201000 CR4: 00000000000006a0
[ 97.787021] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 97.830053] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 97.873036] Process swapper (pid: 1, threadinfo FFFF81012FABA000, task FFFF81012FAB8040)
[ 97.921993] Stack: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[ 97.971056] ffff810001005f40 ffff81012fabb700 ffff81012fabbdf0 ffffffff80235487
[ 98.016420] 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[ 98.060324] Call Trace:
[ 98.076657] [<ffffffff80235487>] build_sched_domains+0x1e1/0xc19
[ 98.113383] [<ffffffff8025072a>] __kernel_text_address+0x22/0x30
[ 98.150173] [<ffffffff8025b127>] check_chain_key+0x9c/0x15f
[ 98.184355] [<ffffffff8025d544>] mark_lock+0x3b/0x5b3
[ 98.215406] [<ffffffff8025db06>] mark_held_locks+0x4a/0x6a
[ 98.249027] [<ffffffff80284f4a>] get_page_from_freelist+0x42a/0x77d
[ 98.287362] [<ffffffff8025dda1>] trace_hardirqs_on+0x198/0x1c3
[ 98.323123] [<ffffffff8028527a>] get_page_from_freelist+0x75a/0x77d
[ 98.361429] [<ffffffff8025d544>] mark_lock+0x3b/0x5b3
[ 98.392427] [<ffffffff8025b127>] check_chain_key+0x9c/0x15f
[ 98.426621] [<ffffffff8034d01a>] number+0x115/0x21f
[ 98.456594] [<ffffffff8025072a>] __kernel_text_address+0x22/0x30
[ 98.493362] [<ffffffff8020d80c>] dump_trace+0x248/0x25d
[ 98.525493] [<ffffffff8025b127>] check_chain_key+0x9c/0x15f
[ 98.559678] [<ffffffff8025f03f>] __lock_acquire+0xdee/0xf06
[ 98.593868] [<ffffffff8025b127>] check_chain_key+0x9c/0x15f
[ 98.628038] [<ffffffff8025b127>] check_chain_key+0x9c/0x15f
[ 98.662225] [<ffffffff8025b127>] check_chain_key+0x9c/0x15f
[ 98.696370] [<ffffffff8025f03f>] __lock_acquire+0xdee/0xf06
[ 98.730563] [<ffffffff8025b127>] check_chain_key+0x9c/0x15f
[ 98.764689] [<ffffffff8025d544>] mark_lock+0x3b/0x5b3
[ 98.795767] [<ffffffff8025db06>] mark_held_locks+0x4a/0x6a
[ 98.829432] [<ffffffff8034d01a>] number+0x115/0x21f
[ 98.859460] [<ffffffff804ca267>] kprobe_flush_task+0x63/0xa9
[ 98.894166] [<ffffffff8034ddbd>] vsnprintf+0x58f/0x5d5
[ 98.925739] [<ffffffff8034de6b>] sprintf+0x68/0x6a
[ 98.955257] [<ffffffff8025f1c9>] lock_acquire+0x72/0xe0
[ 98.987363] [<ffffffff8025ca45>] lock_acquired+0x57/0x1d4
[ 99.020446] [<ffffffff8025f430>] lock_release+0x67/0x21a
[ 99.053079] [<ffffffff8025b127>] check_chain_key+0x9c/0x15f
[ 99.087261] [<ffffffff8025d544>] mark_lock+0x3b/0x5b3
[ 99.118328] [<ffffffff8025d544>] mark_lock+0x3b/0x5b3
[ 99.149394] [<ffffffff80236330>] arch_init_sched_domains+0x27/0x69
[ 99.187217] [<ffffffff802a5a5f>] dbg_redzone2+0x2a/0x52
[ 99.219320] [<ffffffff802a656b>] cache_alloc_debugcheck_after+0x16e/0x1cb
[ 99.260779] [<ffffffff802a8083>] kmem_cache_alloc+0x15e/0x182
[ 99.295944] [<ffffffff80236365>] arch_init_sched_domains+0x5c/0x69
[ 99.333768] [<ffffffff8098e501>] sched_init_smp+0x27/0x113
[ 99.367400] [<ffffffff8034ff35>] __bitmap_weight+0x78/0x8d
[ 99.401090] [<ffffffff8097e631>] kernel_init+0x12d/0x315
[ 99.433718] [<ffffffff804c6f57>] _spin_unlock_irq+0x2b/0x30
[ 99.467842] [<ffffffff8025dda1>] trace_hardirqs_on+0x198/0x1c3
[ 99.503534] [<ffffffff8025dda1>] trace_hardirqs_on+0x198/0x1c3
[ 99.539251] [<ffffffff8020d1b8>] child_rip+0xa/0x12
[ 99.569234] [<ffffffff8020c8cf>] restore_args+0x0/0x30
[ 99.600845] [<ffffffff8097e504>] kernel_init+0x0/0x315
[ 99.632426] [<ffffffff8020d1ae>] child_rip+0x0/0x12
[ 99.662455]
[ 99.671637] INFO: lockdep is turned off.
[ 99.695385]
[ 99.695385] Code: 48 03 42 08 49 89 04 24 48 83 c4 20 89 c8 5b 41 5c c9 c3 55
[ 99.750603] RIP [<ffffffff802341df>] cpu_to_allnodes_group+0x69/0x7c
[ 99.789632] RSP <ffff81012fabb650>

--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.

2007-11-21 09:30:32

by Andrew Morton

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1 - Kernel Panic on IO-APIC

On Wed, 21 Nov 2007 14:52:26 +0530 Kamalesh Babulal <[email protected]> wrote:

> Andrew Morton wrote:
> > On Wed, 21 Nov 2007 11:41:23 +0530 Kamalesh Babulal <[email protected]> wrote:
> >
> >> Hi Andrew,
> >>
> >> Kernel panic's across different architectures like powerpc, x86_64,
> >
> > powerpc complains about IO-APICs??
> >
> >> Dentry cache hash table entries: 8388608 (order: 14, 67108864 bytes)
> >> Inode-cache hash table entries: 4194304 (order: 13, 33554432 bytes)
> >> Mount-cache hash table entries: 256
> >> SMP alternatives: switching to UP code
> >> ACPI: Core revision 20070126
> >> ..MP-BIOS bug: 8254 timer not connected to IO-APIC
> >> Kernel panic - not syncing: IO-APIC + timer doesn't work! Try using the 'noapic' kernel parameter
> >
> > ACPI or x86 breakage, I guess.
> >
> > Did 'noapic' work?
> Hi Andrew,
>
> Passing noapic works,

OK.

> but the kernel oops's
>
> [ 97.161103] Unable to handle kernel NULL pointer dereference at 0000000000000009 RIP:
> [ 97.193973] [<ffffffff802341df>] cpu_to_allnodes_group+0x69/0x7c
> [ 97.245359] PGD 0
> [ 97.257611] Oops: 0000 [1] SMP
> [ 97.276638] last sysfs file:
> [ 97.294417] CPU 0
> [ 97.306620] Modules linked in:
> [ 97.325066] Pid: 1, comm: swapper Not tainted 2.6.24-rc3-mm1 #1
> [ 97.360514] RIP: 0010:[<ffffffff802341df>] [<ffffffff802341df>] cpu_to_allnodes_group+0x69/0x7c
> [ 97.413287] RSP: 0000:ffff81012fabb650 EFLAGS: 00010286
> [ 97.445363] RAX: ffffffff809bb060 RBX: ffff81012fabb650 RCX: 00000000000000ff
> [ 97.488378] RDX: 0000000000000001 RSI: 000000000000013e RDI: 0000000000000100
> [ 97.531413] RBP: ffff81012fabb680 R08: ffff81012fa88180 R09: 0000000000000000
> [ 97.574428] R10: 0000000000000000 R11: 0000000000000000 R12: ffff810001005f50
> [ 97.617394] R13: 0000000000000000 R14: ffff81012fa88180 R15: ffff810001005f40
> [ 97.660421] FS: 0000000000000000(0000) GS:ffffffff806c3000(0000) knlGS:0000000000000000
> [ 97.709327] CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
> [ 97.743995] CR2: 0000000000000009 CR3: 0000000000201000 CR4: 00000000000006a0
> [ 97.787021] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 97.830053] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [ 97.873036] Process swapper (pid: 1, threadinfo FFFF81012FABA000, task FFFF81012FAB8040)
> [ 97.921993] Stack: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> [ 97.971056] ffff810001005f40 ffff81012fabb700 ffff81012fabbdf0 ffffffff80235487
> [ 98.016420] 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> [ 98.060324] Call Trace:
> [ 98.076657] [<ffffffff80235487>] build_sched_domains+0x1e1/0xc19
> [ 98.113383] [<ffffffff8025072a>] __kernel_text_address+0x22/0x30
> [ 98.150173] [<ffffffff8025b127>] check_chain_key+0x9c/0x15f
> [ 98.184355] [<ffffffff8025d544>] mark_lock+0x3b/0x5b3
> [ 98.215406] [<ffffffff8025db06>] mark_held_locks+0x4a/0x6a
> [ 98.249027] [<ffffffff80284f4a>] get_page_from_freelist+0x42a/0x77d
> [ 98.287362] [<ffffffff8025dda1>] trace_hardirqs_on+0x198/0x1c3
> [ 98.323123] [<ffffffff8028527a>] get_page_from_freelist+0x75a/0x77d
> [ 98.361429] [<ffffffff8025d544>] mark_lock+0x3b/0x5b3
> [ 98.392427] [<ffffffff8025b127>] check_chain_key+0x9c/0x15f
> [ 98.426621] [<ffffffff8034d01a>] number+0x115/0x21f
> [ 98.456594] [<ffffffff8025072a>] __kernel_text_address+0x22/0x30
> [ 98.493362] [<ffffffff8020d80c>] dump_trace+0x248/0x25d
> [ 98.525493] [<ffffffff8025b127>] check_chain_key+0x9c/0x15f
> [ 98.559678] [<ffffffff8025f03f>] __lock_acquire+0xdee/0xf06
> [ 98.593868] [<ffffffff8025b127>] check_chain_key+0x9c/0x15f
> [ 98.628038] [<ffffffff8025b127>] check_chain_key+0x9c/0x15f
> [ 98.662225] [<ffffffff8025b127>] check_chain_key+0x9c/0x15f
> [ 98.696370] [<ffffffff8025f03f>] __lock_acquire+0xdee/0xf06
> [ 98.730563] [<ffffffff8025b127>] check_chain_key+0x9c/0x15f
> [ 98.764689] [<ffffffff8025d544>] mark_lock+0x3b/0x5b3
> [ 98.795767] [<ffffffff8025db06>] mark_held_locks+0x4a/0x6a
> [ 98.829432] [<ffffffff8034d01a>] number+0x115/0x21f
> [ 98.859460] [<ffffffff804ca267>] kprobe_flush_task+0x63/0xa9
> [ 98.894166] [<ffffffff8034ddbd>] vsnprintf+0x58f/0x5d5
> [ 98.925739] [<ffffffff8034de6b>] sprintf+0x68/0x6a
> [ 98.955257] [<ffffffff8025f1c9>] lock_acquire+0x72/0xe0
> [ 98.987363] [<ffffffff8025ca45>] lock_acquired+0x57/0x1d4
> [ 99.020446] [<ffffffff8025f430>] lock_release+0x67/0x21a
> [ 99.053079] [<ffffffff8025b127>] check_chain_key+0x9c/0x15f
> [ 99.087261] [<ffffffff8025d544>] mark_lock+0x3b/0x5b3
> [ 99.118328] [<ffffffff8025d544>] mark_lock+0x3b/0x5b3
> [ 99.149394] [<ffffffff80236330>] arch_init_sched_domains+0x27/0x69
> [ 99.187217] [<ffffffff802a5a5f>] dbg_redzone2+0x2a/0x52
> [ 99.219320] [<ffffffff802a656b>] cache_alloc_debugcheck_after+0x16e/0x1cb
> [ 99.260779] [<ffffffff802a8083>] kmem_cache_alloc+0x15e/0x182
> [ 99.295944] [<ffffffff80236365>] arch_init_sched_domains+0x5c/0x69
> [ 99.333768] [<ffffffff8098e501>] sched_init_smp+0x27/0x113
> [ 99.367400] [<ffffffff8034ff35>] __bitmap_weight+0x78/0x8d
> [ 99.401090] [<ffffffff8097e631>] kernel_init+0x12d/0x315
> [ 99.433718] [<ffffffff804c6f57>] _spin_unlock_irq+0x2b/0x30
> [ 99.467842] [<ffffffff8025dda1>] trace_hardirqs_on+0x198/0x1c3
> [ 99.503534] [<ffffffff8025dda1>] trace_hardirqs_on+0x198/0x1c3
> [ 99.539251] [<ffffffff8020d1b8>] child_rip+0xa/0x12
> [ 99.569234] [<ffffffff8020c8cf>] restore_args+0x0/0x30
> [ 99.600845] [<ffffffff8097e504>] kernel_init+0x0/0x315
> [ 99.632426] [<ffffffff8020d1ae>] child_rip+0x0/0x12
> [ 99.662455]
> [ 99.671637] INFO: lockdep is turned off.
> [ 99.695385]
> [ 99.695385] Code: 48 03 42 08 49 89 04 24 48 83 c4 20 89 c8 5b 41 5c c9 c3 55
> [ 99.750603] RIP [<ffffffff802341df>] cpu_to_allnodes_group+0x69/0x7c
> [ 99.789632] RSP <ffff81012fabb650>

urgh, mess. Enabling frame pointers might help here.

But we're cc'ing the right guy ;)

2007-11-21 09:44:22

by Kamalesh Babulal

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1 - Kernel Panic on IO-APIC

Andrew Morton wrote:
> On Wed, 21 Nov 2007 14:52:26 +0530 Kamalesh Babulal <[email protected]> wrote:
>
>> Andrew Morton wrote:
>>> On Wed, 21 Nov 2007 11:41:23 +0530 Kamalesh Babulal <[email protected]> wrote:
>>>
>>>> Hi Andrew,
>>>>
>>>> Kernel panic's across different architectures like powerpc, x86_64,
>>> powerpc complains about IO-APICs??
>>>
>>>> Dentry cache hash table entries: 8388608 (order: 14, 67108864 bytes)
>>>> Inode-cache hash table entries: 4194304 (order: 13, 33554432 bytes)
>>>> Mount-cache hash table entries: 256
>>>> SMP alternatives: switching to UP code
>>>> ACPI: Core revision 20070126
>>>> ..MP-BIOS bug: 8254 timer not connected to IO-APIC
>>>> Kernel panic - not syncing: IO-APIC + timer doesn't work! Try using the 'noapic' kernel parameter
>>> ACPI or x86 breakage, I guess.
>>>
>>> Did 'noapic' work?
>> Hi Andrew,
>>
>> Passing noapic works,
>
> OK.
>
>> but the kernel oops's
>>
>> [ 97.161103] Unable to handle kernel NULL pointer dereference at 0000000000000009 RIP:
>> [ 97.193973] [<ffffffff802341df>] cpu_to_allnodes_group+0x69/0x7c
>> [ 97.245359] PGD 0
>> [ 97.257611] Oops: 0000 [1] SMP
>> [ 97.276638] last sysfs file:
>> [ 97.294417] CPU 0
>> [ 97.306620] Modules linked in:
>> [ 97.325066] Pid: 1, comm: swapper Not tainted 2.6.24-rc3-mm1 #1
>> [ 97.360514] RIP: 0010:[<ffffffff802341df>] [<ffffffff802341df>] cpu_to_allnodes_group+0x69/0x7c
>> [ 97.413287] RSP: 0000:ffff81012fabb650 EFLAGS: 00010286
>> [ 97.445363] RAX: ffffffff809bb060 RBX: ffff81012fabb650 RCX: 00000000000000ff
>> [ 97.488378] RDX: 0000000000000001 RSI: 000000000000013e RDI: 0000000000000100
>> [ 97.531413] RBP: ffff81012fabb680 R08: ffff81012fa88180 R09: 0000000000000000
>> [ 97.574428] R10: 0000000000000000 R11: 0000000000000000 R12: ffff810001005f50
>> [ 97.617394] R13: 0000000000000000 R14: ffff81012fa88180 R15: ffff810001005f40
>> [ 97.660421] FS: 0000000000000000(0000) GS:ffffffff806c3000(0000) knlGS:0000000000000000
>> [ 97.709327] CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
>> [ 97.743995] CR2: 0000000000000009 CR3: 0000000000201000 CR4: 00000000000006a0
>> [ 97.787021] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>> [ 97.830053] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
>> [ 97.873036] Process swapper (pid: 1, threadinfo FFFF81012FABA000, task FFFF81012FAB8040)
>> [ 97.921993] Stack: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
>> [ 97.971056] ffff810001005f40 ffff81012fabb700 ffff81012fabbdf0 ffffffff80235487
>> [ 98.016420] 0000000000000000 0000000000000000 0000000000000000 0000000000000000
>> [ 98.060324] Call Trace:
>> [ 98.076657] [<ffffffff80235487>] build_sched_domains+0x1e1/0xc19
>> [ 98.113383] [<ffffffff8025072a>] __kernel_text_address+0x22/0x30
>> [ 98.150173] [<ffffffff8025b127>] check_chain_key+0x9c/0x15f
>> [ 98.184355] [<ffffffff8025d544>] mark_lock+0x3b/0x5b3
>> [ 98.215406] [<ffffffff8025db06>] mark_held_locks+0x4a/0x6a
>> [ 98.249027] [<ffffffff80284f4a>] get_page_from_freelist+0x42a/0x77d
>> [ 98.287362] [<ffffffff8025dda1>] trace_hardirqs_on+0x198/0x1c3
>> [ 98.323123] [<ffffffff8028527a>] get_page_from_freelist+0x75a/0x77d
>> [ 98.361429] [<ffffffff8025d544>] mark_lock+0x3b/0x5b3
>> [ 98.392427] [<ffffffff8025b127>] check_chain_key+0x9c/0x15f
>> [ 98.426621] [<ffffffff8034d01a>] number+0x115/0x21f
>> [ 98.456594] [<ffffffff8025072a>] __kernel_text_address+0x22/0x30
>> [ 98.493362] [<ffffffff8020d80c>] dump_trace+0x248/0x25d
>> [ 98.525493] [<ffffffff8025b127>] check_chain_key+0x9c/0x15f
>> [ 98.559678] [<ffffffff8025f03f>] __lock_acquire+0xdee/0xf06
>> [ 98.593868] [<ffffffff8025b127>] check_chain_key+0x9c/0x15f
>> [ 98.628038] [<ffffffff8025b127>] check_chain_key+0x9c/0x15f
>> [ 98.662225] [<ffffffff8025b127>] check_chain_key+0x9c/0x15f
>> [ 98.696370] [<ffffffff8025f03f>] __lock_acquire+0xdee/0xf06
>> [ 98.730563] [<ffffffff8025b127>] check_chain_key+0x9c/0x15f
>> [ 98.764689] [<ffffffff8025d544>] mark_lock+0x3b/0x5b3
>> [ 98.795767] [<ffffffff8025db06>] mark_held_locks+0x4a/0x6a
>> [ 98.829432] [<ffffffff8034d01a>] number+0x115/0x21f
>> [ 98.859460] [<ffffffff804ca267>] kprobe_flush_task+0x63/0xa9
>> [ 98.894166] [<ffffffff8034ddbd>] vsnprintf+0x58f/0x5d5
>> [ 98.925739] [<ffffffff8034de6b>] sprintf+0x68/0x6a
>> [ 98.955257] [<ffffffff8025f1c9>] lock_acquire+0x72/0xe0
>> [ 98.987363] [<ffffffff8025ca45>] lock_acquired+0x57/0x1d4
>> [ 99.020446] [<ffffffff8025f430>] lock_release+0x67/0x21a
>> [ 99.053079] [<ffffffff8025b127>] check_chain_key+0x9c/0x15f
>> [ 99.087261] [<ffffffff8025d544>] mark_lock+0x3b/0x5b3
>> [ 99.118328] [<ffffffff8025d544>] mark_lock+0x3b/0x5b3
>> [ 99.149394] [<ffffffff80236330>] arch_init_sched_domains+0x27/0x69
>> [ 99.187217] [<ffffffff802a5a5f>] dbg_redzone2+0x2a/0x52
>> [ 99.219320] [<ffffffff802a656b>] cache_alloc_debugcheck_after+0x16e/0x1cb
>> [ 99.260779] [<ffffffff802a8083>] kmem_cache_alloc+0x15e/0x182
>> [ 99.295944] [<ffffffff80236365>] arch_init_sched_domains+0x5c/0x69
>> [ 99.333768] [<ffffffff8098e501>] sched_init_smp+0x27/0x113
>> [ 99.367400] [<ffffffff8034ff35>] __bitmap_weight+0x78/0x8d
>> [ 99.401090] [<ffffffff8097e631>] kernel_init+0x12d/0x315
>> [ 99.433718] [<ffffffff804c6f57>] _spin_unlock_irq+0x2b/0x30
>> [ 99.467842] [<ffffffff8025dda1>] trace_hardirqs_on+0x198/0x1c3
>> [ 99.503534] [<ffffffff8025dda1>] trace_hardirqs_on+0x198/0x1c3
>> [ 99.539251] [<ffffffff8020d1b8>] child_rip+0xa/0x12
>> [ 99.569234] [<ffffffff8020c8cf>] restore_args+0x0/0x30
>> [ 99.600845] [<ffffffff8097e504>] kernel_init+0x0/0x315
>> [ 99.632426] [<ffffffff8020d1ae>] child_rip+0x0/0x12
>> [ 99.662455]
>> [ 99.671637] INFO: lockdep is turned off.
>> [ 99.695385]
>> [ 99.695385] Code: 48 03 42 08 49 89 04 24 48 83 c4 20 89 c8 5b 41 5c c9 c3 55
>> [ 99.750603] RIP [<ffffffff802341df>] cpu_to_allnodes_group+0x69/0x7c
>> [ 99.789632] RSP <ffff81012fabb650>
>
> urgh, mess. Enabling frame pointers might help here.
>
> But we're cc'ing the right guy ;)
>

The kernel was compiled with frame pointers enabled.
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.

2007-11-21 09:56:48

by Sam Ravnborg

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1 make headers_check fails

On Wed, Nov 21, 2007 at 10:44:40AM +0200, Avi Kivity wrote:
> Kamalesh Babulal wrote:
> >Andrew Morton wrote:
> >
> >>On Wed, 21 Nov 2007 13:54:50 +0530 Kamalesh Babulal
> >><[email protected]> wrote:
> >>
> >>
> >>>The make headers_check fails,
> >>>
> >>> CHECK include/linux/usb/gadgetfs.h
> >>> CHECK include/linux/usb/ch9.h
> >>> CHECK include/linux/usb/cdc.h
> >>> CHECK include/linux/usb/audio.h
> >>> CHECK include/linux/kvm.h
> >>>/root/kernels/linux-2.6.24-rc3/usr/include/linux/kvm.h requires
> >>>asm/kvm.h, which does not exist in exported headers
> >>>
> >>hm, works for me, on i386 and x86_64. What's different over there?
> >>
> >Hi Andrew,
> >
> >It fails on the powerpc box, with allyesconfig option.
> >
> >
>
> How do we fix this? Export linux/kvm.h only on x86? Seems ugly.

Is kvm x86 specific? Then move the .h file to asm-x86.
Otherwise no good idea...

Sam

2007-11-21 09:59:40

by Avi Kivity

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1 make headers_check fails

Sam Ravnborg wrote:
> On Wed, Nov 21, 2007 at 10:44:40AM +0200, Avi Kivity wrote:
>
>> Kamalesh Babulal wrote:
>>
>>> Andrew Morton wrote:
>>>
>>>
>>>> On Wed, 21 Nov 2007 13:54:50 +0530 Kamalesh Babulal
>>>> <[email protected]> wrote:
>>>>
>>>>
>>>>
>>>>> The make headers_check fails,
>>>>>
>>>>> CHECK include/linux/usb/gadgetfs.h
>>>>> CHECK include/linux/usb/ch9.h
>>>>> CHECK include/linux/usb/cdc.h
>>>>> CHECK include/linux/usb/audio.h
>>>>> CHECK include/linux/kvm.h
>>>>> /root/kernels/linux-2.6.24-rc3/usr/include/linux/kvm.h requires
>>>>> asm/kvm.h, which does not exist in exported headers
>>>>>
>>>>>
>>>> hm, works for me, on i386 and x86_64. What's different over there?
>>>>
>>>>
>>> Hi Andrew,
>>>
>>> It fails on the powerpc box, with allyesconfig option.
>>>
>>>
>>>
>> How do we fix this? Export linux/kvm.h only on x86? Seems ugly.
>>
>
> Is kvm x86 specific? Then move the .h file to asm-x86.
> Otherwise no good idea...
>
>

kvm.h is x86 specific today, but will be s390, ppc, ia64, and x86
specific tomorrow.

What about having a asm-generic/kvm.h with a nice #error? would that
suit?


--
error compiling committee.c: too many arguments to function

2007-11-21 10:16:26

by Avi Kivity

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1 make headers_check fails

Avi Kivity wrote:
>>>>>
>>>>>> The make headers_check fails,
>>>>>>
>>>>>> CHECK include/linux/usb/gadgetfs.h
>>>>>> CHECK include/linux/usb/ch9.h
>>>>>> CHECK include/linux/usb/cdc.h
>>>>>> CHECK include/linux/usb/audio.h
>>>>>> CHECK include/linux/kvm.h
>>>>>> /root/kernels/linux-2.6.24-rc3/usr/include/linux/kvm.h requires
>>>>>> asm/kvm.h, which does not exist in exported headers
>>>>>>
>>>>> hm, works for me, on i386 and x86_64. What's different over there?
>>>>>
>>>> Hi Andrew,
>>>>
>>>> It fails on the powerpc box, with allyesconfig option.
>>>>
>>>>
>>>>
>>> How do we fix this? Export linux/kvm.h only on x86? Seems ugly.
>>>
>>
>> Is kvm x86 specific? Then move the .h file to asm-x86.
>> Otherwise no good idea...
>>
>>
>
> kvm.h is x86 specific today, but will be s390, ppc, ia64, and x86
> specific tomorrow.
>
> What about having a asm-generic/kvm.h with a nice #error? would
> that suit?
>

headers_check continues to complain. Is the only recourse to add
asm/kvm.h for all archs?

--
error compiling committee.c: too many arguments to function

2007-11-21 10:33:45

by Robert P. J. Day

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1 make headers_check fails

On Wed, 21 Nov 2007, Avi Kivity wrote:

> headers_check continues to complain. Is the only recourse to add
> asm/kvm.h for all archs?

that's what's happened with other header files. see asm-*/auxvec.h,
for example.

rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://crashcourse.ca
========================================================================

2007-11-21 12:54:37

by Rene Herman

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1

On 21-11-07 07:08, Andrew Morton wrote:

>> fix (for my config ?) is attached.
>>
>> =
>> This was necessary to build.
>>
>> Signed-off-by: KAMEZAWA Hiroyuki <[email protected]>
>>
>> arch/ia64/lib/Makefile | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> Index: linux-2.6.24-rc3-mm1/arch/ia64/lib/Makefile
>> ===================================================================
>> --- linux-2.6.24-rc3-mm1.orig/arch/ia64/lib/Makefile
>> +++ linux-2.6.24-rc3-mm1/arch/ia64/lib/Makefile
>> @@ -2,7 +2,7 @@
>> # Makefile for ia64-specific library routines..
>> #
>>
>> -obj-y := io.o copy_page-export.o
>> +obj-y := io.o
>>
>> lib-y := __divsi3.o __udivsi3.o __modsi3.o __umodsi3.o \
>> __divdi3.o __udivdi3.o __moddi3.o __umoddi3.o \
>
> erp. Actually, it should be this:
>
> --- a/arch/ia64/lib/Makefile~ia64-export-copy_page-to-modules-fix-fix
> +++ a/arch/ia64/lib/Makefile
> @@ -2,7 +2,7 @@
> # Makefile for ia64-specific library routines..
> #
>
> -obj-y := io.o copy_page-export.o
> +obj-y := io.o
>
> lib-y := __divsi3.o __udivsi3.o __modsi3.o __umodsi3.o \
> __divdi3.o __udivdi3.o __moddi3.o __umoddi3.o \

Devil's in the invisible details? :-?

Rene.

2007-11-21 18:22:49

by Kirill A. Shutemov

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1: usb mouse doesn't work

USB mouse(Logitech M-BT58) doesn't work. TouchPad works.
dmesg after rmmod usbcore && modprobe uhci_hcd:

usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
USB Universal Host Controller Interface driver v3.0
ACPI: PCI Interrupt 0000:00:1d.0[A] -> Link [LNKE] -> GSI 10 (level, low)
-> IRQ 10
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 1
uhci_hcd 0000:00:1d.0: irq 10, io base 0x0000bf80
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
usb usb1: new device found, idVendor=0000, idProduct=0000
usb usb1: new device strings: Mfr=3, Product=2, SerialNumber=1
usb usb1: Product: UHCI Host Controller
usb usb1: Manufacturer: Linux 2.6.24-kas-alt1 uhci_hcd
usb usb1: SerialNumber: 0000:00:1d.0
ACPI: PCI Interrupt 0000:00:1d.1[B] -> Link [LNKF] -> GSI 11 (level, low)
-> IRQ 11
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 2
uhci_hcd 0000:00:1d.1: irq 11, io base 0x0000bf60
usb usb2: configuration #1 chosen from 1 choice
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
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.24-kas-alt1 uhci_hcd
usb usb2: SerialNumber: 0000:00:1d.1
ACPI: PCI Interrupt 0000:00:1d.2[C] -> Link [LNKG] -> GSI 9 (level, low)
-> IRQ 9
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 3
uhci_hcd 0000:00:1d.2: irq 9, io base 0x0000bf40
usb usb3: configuration #1 chosen from 1 choice
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
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.24-kas-alt1 uhci_hcd
usb usb3: SerialNumber: 0000:00:1d.2
ACPI: PCI Interrupt 0000:00:1d.3[D] -> Link [LNKH] -> GSI 7 (level, low)
-> IRQ 7
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 4
uhci_hcd 0000:00:1d.3: irq 7, io base 0x0000bf20
usb usb4: configuration #1 chosen from 1 choice
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 2 ports detected
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.24-kas-alt1 uhci_hcd
usb usb4: SerialNumber: 0000:00:1d.3
uhci_hcd 0000:00:1d.3: FGR not stopped yet!

--
Regards, Kirill A. Shutemov
+ Belarus, Minsk
+ Velesys LLC, http://www.velesys.com/
+ ALT Linux Team, http://www.altlinux.com/


Attachments:
(No filename) (3.04 kB)
signature.asc (189.00 B)
Digital signature
Download all attachments

2007-11-21 18:34:19

by Kirill A. Shutemov

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1

On [Tue, 20.11.2007 22:15], Andrew Morton wrote:
> On Wed, 21 Nov 2007 14:03:34 +0800 "Dave Young" <[email protected]> wrote:
>
> > On Nov 21, 2007 2:00 PM, Andrew Morton <[email protected]> wrote:
> > >
> > > On Wed, 21 Nov 2007 13:51:47 +0800 "Dave Young" <[email protected]> wrote:
> > >
> > > > Hi, andrew
> > > >
> > > > modpost failed for me:
> > > > MODPOST 360 modules
> > > > ERROR: "empty_zero_page" [drivers/kvm/kvm.ko] undefined!
> > > > make[1]: *** [__modpost] Error 1
> > > > make: *** [modules] Error 2
> > > >
> > >
> > > You're a victim of the hasty unexporting fad. Which architecture?
> > > x86_64 I guess?
> > >
> > Hi,
> > ia32 instead.
> >
>
> oic. Like this, I guess.
>
> --- a/arch/x86/kernel/i386_ksyms_32.c~git-x86-i386-export-empty_zero_page
> +++ a/arch/x86/kernel/i386_ksyms_32.c
> @@ -2,6 +2,7 @@
> #include <asm/semaphore.h>
> #include <asm/checksum.h>
> #include <asm/desc.h>
> +#include <asm/pgtable.h>
>
> EXPORT_SYMBOL(__down_failed);
> EXPORT_SYMBOL(__down_failed_interruptible);
> @@ -22,3 +23,4 @@ EXPORT_SYMBOL(__put_user_8);
> EXPORT_SYMBOL(strstr);
>
> EXPORT_SYMBOL(csum_partial);
> +EXPORT_SYMBOL(empty_zero_page);
> _

Symbol init_level4_pgt is needed by nvidia module. Is it really need to
unexport it?

--
Regards, Kirill A. Shutemov
+ Belarus, Minsk
+ Velesys LLC, http://www.velesys.com/
+ ALT Linux Team, http://www.altlinux.com/


Attachments:
(No filename) (1.40 kB)
signature.asc (189.00 B)
Digital signature
Download all attachments

2007-11-21 19:24:33

by Len Brown

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1 - Kernel Panic on IO-APIC

On Wednesday 21 November 2007 01:18, Andrew Morton wrote:
> On Wed, 21 Nov 2007 11:41:23 +0530 Kamalesh Babulal <[email protected]> wrote:

> > SMP alternatives: switching to UP code
> > ACPI: Core revision 20070126
> > ..MP-BIOS bug: 8254 timer not connected to IO-APIC

did previous kernels print this too?

> > Kernel panic - not syncing: IO-APIC + timer doesn't work! Try using the 'noapic' kernel parameter
>
> ACPI or x86 breakage, I guess.

If you suspect ACPI breakage, then try "acpi=off" or "acpi=noirq".

thanks,
-Len

2007-11-21 19:33:55

by Torsten Kaiser

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1 - Kernel Panic on IO-APIC

On Nov 21, 2007 10:29 AM, Andrew Morton <[email protected]> wrote:
> On Wed, 21 Nov 2007 14:52:26 +0530 Kamalesh Babulal <[email protected]> wrote:
>
> > Andrew Morton wrote:
> > > On Wed, 21 Nov 2007 11:41:23 +0530 Kamalesh Babulal <[email protected]> wrote:
> > >> ACPI: Core revision 20070126
> > >> ..MP-BIOS bug: 8254 timer not connected to IO-APIC
> > >> Kernel panic - not syncing: IO-APIC + timer doesn't work! Try using the 'noapic' kernel parameter

I seen an identical error.

> > > ACPI or x86 breakage, I guess.
> > >
> > > Did 'noapic' work?
> >
> > Passing noapic works,
>
> OK.

Not for me. I get a similar oops, but then the kernel panics

> > but the kernel oops's
> >
> > [ 97.161103] Unable to handle kernel NULL pointer dereference at 0000000000000009 RIP:
> > [ 97.193973] [<ffffffff802341df>] cpu_to_allnodes_group+0x69/0x7c
[snip]
> urgh, mess. Enabling frame pointers might help here.

CONFIG_FRAME_POINTER=y

The oops/panic that happens with noapic:
[ 35.866758] Initializing CPU#3
[ 35.868769] Stuck ??
[ 35.874043] Inquiring remote APIC #3...
[ 35.877896] ... APIC #3 ID: 03000000
[ 35.881523] ... APIC #3 VERSION: 80050010
[ 35.885587] ... APIC #3 SPIV: 000001ff
[ 35.889390] Brought up 1 CPUs
[ 35.892375] Unable to handle kernel NULL pointer dereference at
0000000000000009 RIP:
[ 35.897868] [<ffffffff8022fc5b>] cpu_to_allnodes_group+0x4b/0x60
[ 35.906464] PGD 0
[ 35.908523] Oops: 0000 [1] SMP
[ 35.911757] last sysfs file:
[ 35.914740] CPU 0
[ 35.916798] Modules linked in:
[ 35.919990] Pid: 1, comm: swapper Not tainted 2.6.24-rc3-mm1 #2
[ 35.925914] RIP: 0010:[<ffffffff8022fc5b>] [<ffffffff8022fc5b>]
cpu_to_allnodes_group+0x4b/0x60
[ 35.934734] RSP: 0000:ffff81011ff2bdb0 EFLAGS: 00010282
[ 35.940053] RAX: ffffffff8084d870 RBX: ffff810001005810 RCX: 0000000000000004
[ 35.947188] RDX: 0000000000000001 RSI: ffff81011ff26f68 RDI: ffff81011ff2bdb0
[ 35.954323] RBP: ffff81011ff2bdd0 R08: 2222222222222222 R09: 0000000000000000
[ 35.961457] R10: ffff81007ff1c200 R11: 0000000000000200 R12: ffff810001005800
[ 35.968592] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
[ 35.975727] FS: 0000000000000000(0000) GS:ffffffff807d4000(0000)
knlGS:0000000000000000
[ 35.983951] CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
[ 35.989701] CR2: 0000000000000009 CR3: 0000000000201000 CR4: 00000000000006a0
[ 35.996836] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 36.003971] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 36.011105] Process swapper (pid: 1, threadinfo FFFF81011FF2A000,
task FFFF81007FF2A000)
[ 36.019191] Stack: 0000000000000000 ffffffff807e8f98
0000000000000000 ffff810001005800
[ 36.027373] ffff81011ff2be80 ffffffff80230580 ffffffff8084d640
ffffffff8084d6e0
[ 36.034922] ffffffff8084d780 ffffffff8084d800 ffffffffffffffff
ffff81011ff26f68
[ 36.042247] Call Trace:
[ 36.044929] [<ffffffff80230580>] build_sched_domains+0x460/0x820
[ 36.051701] [<ffffffff805cf489>] mutex_lock_nested+0x199/0x2e0
[ 36.057624] [<ffffffff80230991>] arch_init_sched_domains+0x51/0x60
[ 36.063895] [<ffffffff8080e422>] sched_init_smp+0x22/0xe0
[ 36.069385] [<ffffffff80806825>] smp_cpus_done+0x25/0x30
[ 36.074791] [<ffffffff807fb739>] kernel_init+0x109/0x350
[ 36.080196] [<ffffffff8025a34f>] trace_hardirqs_on+0xbf/0x160
[ 36.086032] [<ffffffff805d03d2>] trace_hardirqs_on_thunk+0x35/0x3a
[ 36.092303] [<ffffffff8025a34f>] trace_hardirqs_on+0xbf/0x160
[ 36.098141] [<ffffffff8020cbc8>] child_rip+0xa/0x12
[ 36.103113] [<ffffffff8020c2df>] restore_args+0x0/0x30
[ 36.108345] [<ffffffff807fb630>] kernel_init+0x0/0x350
[ 36.113750] [<ffffffff8020cbbe>] child_rip+0x0/0x12
[ 36.118722]
[ 36.120236] INFO: lockdep is turned off.
[ 36.124170]
[ 36.124170] Code: 48 03 42 08 48 89 03 48 83 c4 18 89 c8 5b c9 c3
0f 1f 44 00
[ 36.133640] RIP [<ffffffff8022fc5b>] cpu_to_allnodes_group+0x4b/0x60
[ 36.140116] RSP <ffff81011ff2bdb0>
[ 36.143619] CR2: 0000000000000009
[ 36.146952] Kernel panic - not syncing: Attempted to kill init!

(gdb) list *0xffffffff8022fc5b
0xffffffff8022fc5b is in cpu_to_allnodes_group (kernel/sched.c:6073).
6068
6069 cpus_and(nodemask, nodemask, *cpu_map);
6070 group = first_cpu(nodemask);
6071
6072 if (sg)
6073 *sg = &per_cpu(sched_group_allnodes, group);
6074 return group;
6075 }
6076
6077 static void init_numa_sched_groups_power(struct sched_group *group_head)

Hope this stack trace is better.

Torsten

2007-11-21 19:48:52

by Torsten Kaiser

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1 - Kernel Panic on IO-APIC

On Nov 21, 2007 8:22 PM, Len Brown <[email protected]> wrote:
> On Wednesday 21 November 2007 01:18, Andrew Morton wrote:
> > On Wed, 21 Nov 2007 11:41:23 +0530 Kamalesh Babulal <[email protected]> wrote:
>
> > > SMP alternatives: switching to UP code
> > > ACPI: Core revision 20070126
> > > ..MP-BIOS bug: 8254 timer not connected to IO-APIC
>
> did previous kernels print this too?

Not since my last BIOS upgrade.

This is from what dmesg's I still had laying around:
2.6.22-rc6-mm1: No
2.6.23-rc1-mm1, 2.6.23-rc2-mm1, 2.6.23-rc3-mm1: Yes
2.6.23-rc3-mm1 after BIOS upgrade: No
2.6.23-rc4-mm1...2.6.24-rc2-mm1: No

> > > Kernel panic - not syncing: IO-APIC + timer doesn't work! Try using the 'noapic' kernel parameter
> >
> > ACPI or x86 breakage, I guess.
>
> If you suspect ACPI breakage, then try "acpi=off" or "acpi=noirq".

ACPI doesn't look guilty.
acpi=noirq:
[ 39.905884] Freeing SMP alternatives: 28k freed
[ 39.910674] ACPI: Core revision 20070126
[ 39.916542] ACPI: setting ELCR to 0e20 (from 0c20)
[ 39.921855] ExtINT not setup in hardware but reported by MP table
[ 39.928244] ..MP-BIOS bug: 8254 timer not connected to IO-APIC
[ 39.934586] Kernel panic - not syncing: IO-APIC + timer doesn't
work! Try using the 'noapic' kernel parameter
[ 39.934587]

acpi=off:
[ 0.000000] Freeing SMP alternatives: 28k freed
[ 0.000000] ExtINT not setup in hardware but reported by MP table
[ 0.000000] ..MP-BIOS bug: 8254 timer not connected to IO-APIC
[ 0.000000] Kernel panic - not syncing: IO-APIC + timer doesn't
work! Try using the 'noapic' kernel parameter
[ 0.000000]

Torsten

2007-11-21 21:45:40

by Laurent Riffard

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1: I/O error, system hangs

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.24-rc3-mm1
# Wed Nov 21 18:02:26 2007
#
# CONFIG_64BIT is not set
CONFIG_X86_32=y
# CONFIG_X86_64 is not set
CONFIG_X86=y
CONFIG_GENERIC_TIME=y
CONFIG_GENERIC_CMOS_UPDATE=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_SEMAPHORE_SLEEPERS=y
CONFIG_FAST_CMPXCHG_LOCAL=y
CONFIG_MMU=y
CONFIG_ZONE_DMA=y
CONFIG_QUICKLIST=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_GENERIC_BUG=y
# CONFIG_GENERIC_GPIO is not set
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_DMI=y
# CONFIG_RWSEM_GENERIC_SPINLOCK is not set
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
# CONFIG_ARCH_HAS_ILOG2_U32 is not set
# CONFIG_ARCH_HAS_ILOG2_U64 is not set
CONFIG_GENERIC_CALIBRATE_DELAY=y
# CONFIG_GENERIC_TIME_VSYSCALL is not set
# CONFIG_ZONE_DMA32 is not set
CONFIG_ARCH_POPULATES_NODE_MAP=y
# CONFIG_AUDIT_ARCH is not set
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_X86_BIOS_REBOOT=y
CONFIG_KTIME_SCALAR=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"

#
# General setup
#
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_TASKSTATS is not set
# CONFIG_AUDIT is not set
# CONFIG_IKCONFIG is not set
CONFIG_LOG_BUF_SHIFT=15
# CONFIG_CGROUPS is not set
CONFIG_FAIR_GROUP_SCHED=y
CONFIG_FAIR_USER_SCHED=y
# CONFIG_FAIR_CGROUP_SCHED is not set
CONFIG_SYSFS_DEPRECATED=y
# CONFIG_RELAY is not set
# CONFIG_NAMESPACES is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SYSCTL=y
CONFIG_EMBEDDED=y
CONFIG_UID16=y
CONFIG_SYSCTL_SYSCALL=y
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_ANON_INODES=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_SLAB=y
# CONFIG_SLUB is not set
# CONFIG_SLOB is not set
CONFIG_PROC_PAGE_MONITOR=y
CONFIG_RT_MUTEXES=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
# CONFIG_MODVERSIONS is not set
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y
CONFIG_BLOCK=y
# CONFIG_LBD is not set
# CONFIG_BLK_DEV_IO_TRACE is not set
# CONFIG_LSF is not set
# CONFIG_BLK_DEV_BSG is not set

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_DEFAULT_AS is not set
# CONFIG_DEFAULT_DEADLINE is not set
CONFIG_DEFAULT_CFQ=y
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="cfq"

#
# Processor type and features
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ=y
# CONFIG_HIGH_RES_TIMERS is not set
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
# CONFIG_SMP is not set
CONFIG_X86_PC=y
# CONFIG_X86_ELAN is not set
# CONFIG_X86_VOYAGER is not set
# CONFIG_X86_NUMAQ is not set
# CONFIG_X86_SUMMIT is not set
# CONFIG_X86_BIGSMP is not set
# CONFIG_X86_VISWS is not set
# CONFIG_X86_GENERICARCH is not set
# CONFIG_X86_ES7000 is not set
# CONFIG_X86_RDC321X is not set
# CONFIG_X86_VSMP is not set
CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y
# CONFIG_PARAVIRT_GUEST is not set
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMII is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUMM is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
CONFIG_MK7=y
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MEFFICEON is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MGEODEGX1 is not set
# CONFIG_MGEODE_LX is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_MVIAC7 is not set
# CONFIG_MPSC is not set
# CONFIG_MCORE2 is not set
# CONFIG_GENERIC_CPU is not set
# CONFIG_X86_GENERIC is not set
CONFIG_X86_CMPXCHG=y
CONFIG_X86_L1_CACHE_SHIFT=6
CONFIG_X86_XADD=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_USE_3DNOW=y
CONFIG_X86_TSC=y
CONFIG_X86_CMOV=y
CONFIG_X86_MINIMUM_CPU_FAMILY=4
CONFIG_HPET_TIMER=y
# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
CONFIG_PREEMPT=y
CONFIG_PREEMPT_BKL=y
CONFIG_X86_UP_APIC=y
CONFIG_X86_UP_IOAPIC=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_MCE=y
CONFIG_X86_MCE_NONFATAL=m
CONFIG_X86_MCE_P4THERMAL=y
CONFIG_VM86=y
# CONFIG_TOSHIBA is not set
# CONFIG_I8K is not set
CONFIG_X86_REBOOTFIXUPS=y
# CONFIG_MICROCODE is not set
CONFIG_X86_MSR=m
# CONFIG_X86_CPUID is not set
CONFIG_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set
CONFIG_VMSPLIT_3G=y
# CONFIG_VMSPLIT_3G_OPT is not set
# CONFIG_VMSPLIT_2G is not set
# CONFIG_VMSPLIT_2G_OPT is not set
# CONFIG_VMSPLIT_1G is not set
CONFIG_PAGE_OFFSET=0xC0000000
# CONFIG_X86_PAE is not set
CONFIG_ARCH_FLATMEM_ENABLE=y
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_SELECT_MEMORY_MODEL=y
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y
# CONFIG_DISCONTIGMEM_MANUAL is not set
# CONFIG_SPARSEMEM_MANUAL is not set
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
CONFIG_SPARSEMEM_STATIC=y
# CONFIG_SPARSEMEM_VMEMMAP_ENABLE is not set
CONFIG_SPLIT_PTLOCK_CPUS=4
# CONFIG_RESOURCES_64BIT is not set
CONFIG_ZONE_DMA_FLAG=1
CONFIG_BOUNCE=y
CONFIG_NR_QUICK=1
CONFIG_VIRT_TO_BUS=y
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
# CONFIG_EFI is not set
CONFIG_SECCOMP=y
# CONFIG_HZ_100 is not set
CONFIG_HZ_250=y
# CONFIG_HZ_300 is not set
# CONFIG_HZ_1000 is not set
CONFIG_HZ=250
CONFIG_KEXEC=y
CONFIG_PHYSICAL_START=0x100000
# CONFIG_RELOCATABLE is not set
CONFIG_PHYSICAL_ALIGN=0x100000
# CONFIG_COMPAT_VDSO is not set

#
# Power management options
#
CONFIG_PM=y
# CONFIG_PM_LEGACY is not set
# CONFIG_PM_DEBUG is not set
CONFIG_PM_SLEEP=y
CONFIG_SUSPEND_UP_POSSIBLE=y
CONFIG_SUSPEND=y
CONFIG_HIBERNATION_UP_POSSIBLE=y
CONFIG_HIBERNATION=y
CONFIG_PM_STD_PARTITION="/dev/hdb6"
CONFIG_ACPI=y
CONFIG_ACPI_SLEEP=y
# CONFIG_ACPI_PROCFS is not set
CONFIG_ACPI_PROCFS_POWER=y
CONFIG_ACPI_PROC_EVENT=y
# CONFIG_ACPI_AC is not set
# CONFIG_ACPI_BATTERY is not set
CONFIG_ACPI_BUTTON=y
CONFIG_ACPI_FAN=y
# CONFIG_ACPI_DOCK is not set
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_THERMAL=y
# CONFIG_ACPI_ASUS is not set
# CONFIG_ACPI_TOSHIBA is not set
CONFIG_ACPI_BLACKLIST_YEAR=0
CONFIG_ACPI_DEBUG=y
# CONFIG_ACPI_DEBUG_FUNC_TRACE is not set
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_SYSTEM=y
CONFIG_X86_PM_TIMER=y
# CONFIG_ACPI_CONTAINER is not set
# CONFIG_ACPI_SBS is not set
# CONFIG_APM is not set

#
# CPU Frequency scaling
#
# CONFIG_CPU_FREQ is not set
# CONFIG_CPU_IDLE is not set

#
# Bus options (PCI etc.)
#
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GOMMCONFIG is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_MMCONFIG=y
CONFIG_PCI_DOMAINS=y
# CONFIG_PCIEPORTBUS is not set
CONFIG_ARCH_SUPPORTS_MSI=y
# CONFIG_PCI_MSI is not set
# CONFIG_PCI_LEGACY is not set
# CONFIG_PCI_DEBUG is not set
CONFIG_HT_IRQ=y
CONFIG_ISA_DMA_API=y
CONFIG_ISA=y
# CONFIG_EISA is not set
# CONFIG_MCA is not set
# CONFIG_SCx200 is not set
# CONFIG_PCCARD is not set
# CONFIG_HOTPLUG_PCI is not set

#
# Executable file formats / Emulations
#
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_AOUT=m
CONFIG_BINFMT_MISC=m

#
# Networking
#
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=m
# CONFIG_PACKET_MMAP is not set
CONFIG_UNIX=y
CONFIG_XFRM=y
CONFIG_XFRM_USER=m
# CONFIG_XFRM_SUB_POLICY is not set
# CONFIG_XFRM_MIGRATE is not set
# CONFIG_NET_KEY is not set
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_ADVANCED_ROUTER=y
CONFIG_ASK_IP_FIB_HASH=y
# CONFIG_IP_FIB_TRIE is not set
CONFIG_IP_FIB_HASH=y
# CONFIG_IP_MULTIPLE_TABLES is not set
# CONFIG_IP_ROUTE_MULTIPATH is not set
CONFIG_IP_ROUTE_VERBOSE=y
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_IP_MROUTE is not set
# CONFIG_ARPD is not set
CONFIG_SYN_COOKIES=y
CONFIG_INET_AH=m
CONFIG_INET_ESP=m
CONFIG_INET_IPCOMP=m
CONFIG_INET_XFRM_TUNNEL=m
CONFIG_INET_TUNNEL=m
# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
# CONFIG_INET_XFRM_MODE_TUNNEL is not set
CONFIG_INET_XFRM_MODE_BEET=y
# CONFIG_INET_LRO is not set
CONFIG_INET_DIAG=m
CONFIG_INET_TCP_DIAG=m
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_CUBIC=y
CONFIG_DEFAULT_TCP_CONG="cubic"
# CONFIG_TCP_MD5SIG is not set
# CONFIG_IP_VS is not set
# CONFIG_IPV6 is not set
# CONFIG_INET6_XFRM_TUNNEL is not set
# CONFIG_INET6_TUNNEL is not set
# CONFIG_NETWORK_SECMARK is not set
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set

#
# Core Netfilter Configuration
#
CONFIG_NETFILTER_NETLINK=m
CONFIG_NETFILTER_NETLINK_QUEUE=m
CONFIG_NETFILTER_NETLINK_LOG=m
# CONFIG_NF_CONNTRACK_ENABLED is not set
# CONFIG_NF_CONNTRACK is not set
CONFIG_NETFILTER_XTABLES=m
CONFIG_NETFILTER_XT_TARGET_CLASSIFY=m
# CONFIG_NETFILTER_XT_TARGET_DSCP is not set
CONFIG_NETFILTER_XT_TARGET_MARK=m
CONFIG_NETFILTER_XT_TARGET_NFQUEUE=m
# CONFIG_NETFILTER_XT_TARGET_NFLOG is not set
# CONFIG_NETFILTER_XT_TARGET_TCPMSS is not set
CONFIG_NETFILTER_XT_MATCH_COMMENT=m
# CONFIG_NETFILTER_XT_MATCH_DCCP is not set
# CONFIG_NETFILTER_XT_MATCH_DSCP is not set
# CONFIG_NETFILTER_XT_MATCH_ESP is not set
# CONFIG_NETFILTER_XT_MATCH_LENGTH is not set
CONFIG_NETFILTER_XT_MATCH_LIMIT=m
CONFIG_NETFILTER_XT_MATCH_MAC=m
CONFIG_NETFILTER_XT_MATCH_MARK=m
CONFIG_NETFILTER_XT_MATCH_POLICY=m
# CONFIG_NETFILTER_XT_MATCH_MULTIPORT is not set
# CONFIG_NETFILTER_XT_MATCH_PKTTYPE is not set
# CONFIG_NETFILTER_XT_MATCH_QUOTA is not set
# CONFIG_NETFILTER_XT_MATCH_REALM is not set
CONFIG_NETFILTER_XT_MATCH_SCTP=m
# CONFIG_NETFILTER_XT_MATCH_STATISTIC is not set
CONFIG_NETFILTER_XT_MATCH_STRING=m
CONFIG_NETFILTER_XT_MATCH_TCPMSS=m
# CONFIG_NETFILTER_XT_MATCH_TIME is not set
# CONFIG_NETFILTER_XT_MATCH_U32 is not set
# CONFIG_NETFILTER_XT_MATCH_HASHLIMIT is not set

#
# IP: Netfilter Configuration
#
CONFIG_IP_NF_QUEUE=m
CONFIG_IP_NF_IPTABLES=m
CONFIG_IP_NF_MATCH_IPRANGE=m
CONFIG_IP_NF_MATCH_TOS=m
CONFIG_IP_NF_MATCH_RECENT=m
# CONFIG_IP_NF_MATCH_ECN is not set
# CONFIG_IP_NF_MATCH_AH is not set
# CONFIG_IP_NF_MATCH_TTL is not set
CONFIG_IP_NF_MATCH_OWNER=m
CONFIG_IP_NF_MATCH_ADDRTYPE=m
CONFIG_IP_NF_FILTER=m
CONFIG_IP_NF_TARGET_REJECT=m
CONFIG_IP_NF_TARGET_LOG=m
CONFIG_IP_NF_TARGET_ULOG=m
CONFIG_IP_NF_MANGLE=m
CONFIG_IP_NF_TARGET_TOS=m
CONFIG_IP_NF_TARGET_ECN=m
CONFIG_IP_NF_TARGET_TTL=m
# CONFIG_IP_NF_RAW is not set
CONFIG_IP_NF_ARPTABLES=m
CONFIG_IP_NF_ARPFILTER=m
# CONFIG_IP_NF_ARP_MANGLE is not set
# CONFIG_IP_DCCP is not set
# CONFIG_IP_SCTP is not set
# CONFIG_TIPC is not set
CONFIG_ATM=m
CONFIG_ATM_CLIP=m
# CONFIG_ATM_CLIP_NO_ICMP is not set
# CONFIG_ATM_LANE is not set
CONFIG_ATM_BR2684=m
# CONFIG_ATM_BR2684_IPFILTER is not set
# CONFIG_BRIDGE is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
CONFIG_NET_SCHED=y

#
# Queueing/Scheduling
#
CONFIG_NET_SCH_CBQ=m
CONFIG_NET_SCH_HTB=m
CONFIG_NET_SCH_HFSC=m
# CONFIG_NET_SCH_ATM is not set
CONFIG_NET_SCH_PRIO=m
# CONFIG_NET_SCH_RR is not set
CONFIG_NET_SCH_RED=m
CONFIG_NET_SCH_SFQ=m
CONFIG_NET_SCH_TEQL=m
CONFIG_NET_SCH_TBF=m
CONFIG_NET_SCH_GRED=m
CONFIG_NET_SCH_DSMARK=m
# CONFIG_NET_SCH_NETEM is not set
CONFIG_NET_SCH_INGRESS=m

#
# Classification
#
CONFIG_NET_CLS=y
CONFIG_NET_CLS_BASIC=m
CONFIG_NET_CLS_TCINDEX=m
CONFIG_NET_CLS_ROUTE4=m
CONFIG_NET_CLS_ROUTE=y
CONFIG_NET_CLS_FW=m
CONFIG_NET_CLS_U32=m
CONFIG_CLS_U32_PERF=y
CONFIG_CLS_U32_MARK=y
CONFIG_NET_CLS_RSVP=m
# CONFIG_NET_CLS_RSVP6 is not set
# CONFIG_NET_EMATCH is not set
CONFIG_NET_CLS_ACT=y
CONFIG_NET_ACT_POLICE=y
# CONFIG_NET_ACT_GACT is not set
# CONFIG_NET_ACT_MIRRED is not set
# CONFIG_NET_ACT_IPT is not set
# CONFIG_NET_ACT_NAT is not set
# CONFIG_NET_ACT_PEDIT is not set
# CONFIG_NET_ACT_SIMP is not set
CONFIG_NET_CLS_POLICE=y
# CONFIG_NET_CLS_IND is not set
CONFIG_NET_SCH_FIFO=y

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_HAMRADIO is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
# CONFIG_AF_RXRPC is not set

#
# Wireless
#
# CONFIG_CFG80211 is not set
# CONFIG_WIRELESS_EXT is not set
# CONFIG_MAC80211 is not set
# CONFIG_IEEE80211 is not set
# CONFIG_RFKILL is not set
# CONFIG_NET_9P is not set

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=m
# CONFIG_DEBUG_DRIVER is not set
# CONFIG_DEBUG_DEVRES is not set
# CONFIG_SYS_HYPERVISOR is not set
# CONFIG_CONNECTOR is not set
# CONFIG_MTD is not set
CONFIG_PARPORT=m
CONFIG_PARPORT_PC=m
# CONFIG_PARPORT_PC_FIFO is not set
# CONFIG_PARPORT_PC_SUPERIO is not set
# CONFIG_PARPORT_GSC is not set
# CONFIG_PARPORT_AX88796 is not set
CONFIG_PARPORT_1284=y
CONFIG_PNP=y
# CONFIG_PNP_DEBUG is not set

#
# Protocols
#
# CONFIG_ISAPNP is not set
# CONFIG_PNPBIOS is not set
CONFIG_PNPACPI=y
CONFIG_BLK_DEV=y
CONFIG_BLK_DEV_FD=m
# CONFIG_BLK_DEV_XD is not set
# CONFIG_PARIDE is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=m
CONFIG_BLK_DEV_CRYPTOLOOP=m
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_SX8 is not set
# CONFIG_BLK_DEV_UB is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=4096
CONFIG_BLK_DEV_RAM_BLOCKSIZE=1024
CONFIG_CDROM_PKTCDVD=m
CONFIG_CDROM_PKTCDVD_BUFFERS=8
# CONFIG_CDROM_PKTCDVD_WCACHE is not set
# CONFIG_ATA_OVER_ETH is not set
# CONFIG_MISC_DEVICES is not set
# CONFIG_IDE is not set

#
# SCSI device support
#
# CONFIG_RAID_ATTRS is not set
CONFIG_SCSI=m
CONFIG_SCSI_DMA=y
# CONFIG_SCSI_TGT is not set
CONFIG_SCSI_NETLINK=y
CONFIG_SCSI_PROC_FS=y

#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=m
CONFIG_CHR_DEV_ST=m
# CONFIG_CHR_DEV_OSST is not set
CONFIG_BLK_DEV_SR=m
CONFIG_BLK_DEV_SR_VENDOR=y
CONFIG_CHR_DEV_SG=m
# CONFIG_CHR_DEV_SCH is not set

#
# Some SCSI devices (e.g. CD jukebox) support multiple LUNs
#
CONFIG_SCSI_MULTI_LUN=y
CONFIG_SCSI_CONSTANTS=y
# CONFIG_SCSI_LOGGING is not set
# CONFIG_SCSI_SCAN_ASYNC is not set
CONFIG_SCSI_WAIT_SCAN=m

#
# SCSI Transports
#
CONFIG_SCSI_SPI_ATTRS=m
CONFIG_SCSI_FC_ATTRS=m
# CONFIG_SCSI_ISCSI_ATTRS is not set
# CONFIG_SCSI_SAS_LIBSAS is not set
# CONFIG_SCSI_SRP_ATTRS is not set
# CONFIG_SCSI_LOWLEVEL is not set
CONFIG_ATA=m
# CONFIG_ATA_NONSTANDARD is not set
CONFIG_ATA_ACPI=y
# CONFIG_SATA_AHCI is not set
# CONFIG_SATA_SVW is not set
# CONFIG_ATA_PIIX is not set
# CONFIG_SATA_MV is not set
# CONFIG_SATA_NV is not set
# CONFIG_PDC_ADMA is not set
# CONFIG_SATA_QSTOR is not set
# CONFIG_SATA_PROMISE is not set
# CONFIG_SATA_SX4 is not set
# CONFIG_SATA_SIL is not set
# CONFIG_SATA_SIL24 is not set
# CONFIG_SATA_SIS is not set
# CONFIG_SATA_ULI is not set
# CONFIG_SATA_VIA is not set
# CONFIG_SATA_VITESSE is not set
# CONFIG_SATA_INIC162X is not set
# CONFIG_PATA_ACPI is not set
# CONFIG_PATA_ALI is not set
# CONFIG_PATA_AMD is not set
# CONFIG_PATA_ARTOP is not set
# CONFIG_PATA_ATIIXP is not set
# CONFIG_PATA_CMD640_PCI is not set
# CONFIG_PATA_CMD64X is not set
# CONFIG_PATA_CS5520 is not set
# CONFIG_PATA_CS5530 is not set
# CONFIG_PATA_CS5535 is not set
# CONFIG_PATA_CS5536 is not set
# CONFIG_PATA_CYPRESS is not set
# CONFIG_PATA_EFAR is not set
CONFIG_ATA_GENERIC=m
# CONFIG_PATA_HPT366 is not set
# CONFIG_PATA_HPT37X is not set
# CONFIG_PATA_HPT3X2N is not set
# CONFIG_PATA_HPT3X3 is not set
# CONFIG_PATA_IT821X is not set
# CONFIG_PATA_IT8213 is not set
# CONFIG_PATA_JMICRON is not set
# CONFIG_PATA_LEGACY is not set
# CONFIG_PATA_TRIFLEX is not set
# CONFIG_PATA_MARVELL is not set
# CONFIG_PATA_MPIIX is not set
# CONFIG_PATA_OLDPIIX is not set
# CONFIG_PATA_NETCELL is not set
# CONFIG_PATA_NINJA32 is not set
# CONFIG_PATA_NS87410 is not set
# CONFIG_PATA_NS87415 is not set
# CONFIG_PATA_OPTI is not set
# CONFIG_PATA_OPTIDMA is not set
# CONFIG_PATA_PDC_OLD is not set
# CONFIG_PATA_QDI is not set
# CONFIG_PATA_RADISYS is not set
# CONFIG_PATA_RZ1000 is not set
# CONFIG_PATA_SC1200 is not set
# CONFIG_PATA_SERVERWORKS is not set
# CONFIG_PATA_PDC2027X is not set
# CONFIG_PATA_SIL680 is not set
# CONFIG_PATA_SIS is not set
CONFIG_PATA_VIA=m
# CONFIG_PATA_WINBOND is not set
# CONFIG_PATA_WINBOND_VLB is not set
CONFIG_PATA_PLATFORM=m
CONFIG_MD=y
CONFIG_BLK_DEV_MD=m
CONFIG_MD_LINEAR=m
CONFIG_MD_RAID0=m
CONFIG_MD_RAID1=m
CONFIG_MD_RAID10=m
CONFIG_MD_RAID456=m
CONFIG_MD_RAID5_RESHAPE=y
# CONFIG_MD_MULTIPATH is not set
# CONFIG_MD_FAULTY is not set
CONFIG_BLK_DEV_DM=m
# CONFIG_DM_DEBUG is not set
CONFIG_DM_CRYPT=m
CONFIG_DM_SNAPSHOT=m
CONFIG_DM_MIRROR=m
# CONFIG_DM_ZERO is not set
# CONFIG_DM_MULTIPATH is not set
# CONFIG_DM_DELAY is not set
CONFIG_DM_UEVENT=y
# CONFIG_FUSION is not set

#
# IEEE 1394 (FireWire) support
#
CONFIG_FIREWIRE=m
CONFIG_FIREWIRE_OHCI=m
# CONFIG_FIREWIRE_SBP2 is not set
CONFIG_IEEE1394=m

#
# Subsystem Options
#
# CONFIG_IEEE1394_VERBOSEDEBUG is not set

#
# Controllers
#
# CONFIG_IEEE1394_PCILYNX is not set
CONFIG_IEEE1394_OHCI1394=m

#
# Protocols
#
CONFIG_IEEE1394_VIDEO1394=m
# CONFIG_IEEE1394_SBP2 is not set
# CONFIG_IEEE1394_ETH1394_ROM_ENTRY is not set
# CONFIG_IEEE1394_ETH1394 is not set
CONFIG_IEEE1394_DV1394=m
CONFIG_IEEE1394_RAWIO=m
# CONFIG_I2O is not set
# CONFIG_MACINTOSH_DRIVERS is not set
CONFIG_NETDEVICES=y
# CONFIG_NETDEVICES_MULTIQUEUE is not set
# CONFIG_IFB is not set
CONFIG_DUMMY=m
CONFIG_BONDING=m
# CONFIG_MACVLAN is not set
# CONFIG_EQUALIZER is not set
CONFIG_TUN=m
# CONFIG_VETH is not set
# CONFIG_NET_SB1000 is not set
# CONFIG_IP1000 is not set
# CONFIG_ARCNET is not set
# CONFIG_PHYLIB is not set
CONFIG_NET_ETHERNET=y
CONFIG_MII=m
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
# CONFIG_CASSINI is not set
# CONFIG_NET_VENDOR_3COM is not set
# CONFIG_LANCE is not set
# CONFIG_NET_VENDOR_SMC is not set
# CONFIG_NET_VENDOR_RACAL is not set
# CONFIG_NET_TULIP is not set
# CONFIG_AT1700 is not set
# CONFIG_DEPCA is not set
# CONFIG_HP100 is not set
# CONFIG_NET_ISA is not set
# CONFIG_IBM_NEW_EMAC_ZMII is not set
# CONFIG_IBM_NEW_EMAC_RGMII is not set
# CONFIG_IBM_NEW_EMAC_TAH is not set
# CONFIG_IBM_NEW_EMAC_EMAC4 is not set
CONFIG_NET_PCI=y
# CONFIG_PCNET32 is not set
# CONFIG_AMD8111_ETH is not set
# CONFIG_ADAPTEC_STARFIRE is not set
# CONFIG_AC3200 is not set
# CONFIG_APRICOT is not set
# CONFIG_B44 is not set
# CONFIG_FORCEDETH is not set
# CONFIG_CS89x0 is not set
# CONFIG_EEPRO100 is not set
# CONFIG_E100 is not set
# CONFIG_FEALNX is not set
# CONFIG_NATSEMI is not set
CONFIG_NE2K_PCI=m
# CONFIG_8139CP is not set
# CONFIG_8139TOO is not set
# CONFIG_SIS900 is not set
# CONFIG_EPIC100 is not set
# CONFIG_SUNDANCE is not set
# CONFIG_TLAN is not set
# CONFIG_VIA_RHINE is not set
# CONFIG_SC92031 is not set
# CONFIG_NET_POCKET is not set
# CONFIG_NETDEV_1000 is not set
# CONFIG_NETDEV_10000 is not set
# CONFIG_TR is not set

#
# Wireless LAN
#
# CONFIG_WLAN_PRE80211 is not set
CONFIG_WLAN_80211=y
# CONFIG_IPW2100 is not set
# CONFIG_IPW2200 is not set
# CONFIG_LIBERTAS is not set
# CONFIG_AIRO is not set
# CONFIG_HERMES is not set
# CONFIG_ATMEL is not set
# CONFIG_USB_ATMEL is not set
# CONFIG_PRISM54 is not set
# CONFIG_USB_ZD1201 is not set
# CONFIG_HOSTAP is not set

#
# USB Network Adapters
#
# CONFIG_USB_CATC is not set
# CONFIG_USB_KAWETH is not set
# CONFIG_USB_PEGASUS is not set
# CONFIG_USB_RTL8150 is not set
# CONFIG_USB_USBNET is not set
# CONFIG_WAN is not set
# CONFIG_ATM_DRIVERS is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
# CONFIG_PLIP is not set
CONFIG_PPP=m
# CONFIG_PPP_MULTILINK is not set
CONFIG_PPP_FILTER=y
CONFIG_PPP_ASYNC=m
CONFIG_PPP_SYNC_TTY=m
CONFIG_PPP_DEFLATE=m
CONFIG_PPP_BSDCOMP=m
# CONFIG_PPP_MPPE is not set
CONFIG_PPPOE=m
CONFIG_PPPOATM=m
# CONFIG_PPPOL2TP is not set
# CONFIG_SLIP is not set
CONFIG_SLHC=m
# CONFIG_NET_FC is not set
# CONFIG_SHAPER is not set
# CONFIG_NETCONSOLE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set
# CONFIG_ISDN is not set
# CONFIG_PHONE is not set

#
# Input device support
#
CONFIG_INPUT=y
# CONFIG_INPUT_FF_MEMLESS is not set
# CONFIG_INPUT_POLLDEV is not set

#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_PSAUX=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
CONFIG_INPUT_JOYDEV=m
CONFIG_INPUT_EVDEV=m
# CONFIG_INPUT_EVBUG is not set

#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_LKKBD is not set
# CONFIG_KEYBOARD_XTKBD is not set
# CONFIG_KEYBOARD_NEWTON is not set
# CONFIG_KEYBOARD_STOWAWAY is not set
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
# CONFIG_MOUSE_PS2_ALPS is not set
# CONFIG_MOUSE_PS2_LOGIPS2PP is not set
# CONFIG_MOUSE_PS2_SYNAPTICS is not set
# CONFIG_MOUSE_PS2_LIFEBOOK is not set
# CONFIG_MOUSE_PS2_TRACKPOINT is not set
# CONFIG_MOUSE_PS2_TOUCHKIT is not set
# CONFIG_MOUSE_PS2_ELANTECH is not set
# CONFIG_MOUSE_SERIAL is not set
# CONFIG_MOUSE_APPLETOUCH is not set
# CONFIG_MOUSE_INPORT is not set
# CONFIG_MOUSE_LOGIBM is not set
# CONFIG_MOUSE_PC110PAD is not set
# CONFIG_MOUSE_VSXXXAA is not set
CONFIG_INPUT_JOYSTICK=y
CONFIG_JOYSTICK_ANALOG=m
# CONFIG_JOYSTICK_A3D is not set
# CONFIG_JOYSTICK_ADI is not set
# CONFIG_JOYSTICK_COBRA is not set
# CONFIG_JOYSTICK_GF2K is not set
# CONFIG_JOYSTICK_GRIP is not set
# CONFIG_JOYSTICK_GRIP_MP is not set
# CONFIG_JOYSTICK_GUILLEMOT is not set
# CONFIG_JOYSTICK_INTERACT is not set
# CONFIG_JOYSTICK_SIDEWINDER is not set
# CONFIG_JOYSTICK_TMDC is not set
# CONFIG_JOYSTICK_IFORCE is not set
# CONFIG_JOYSTICK_WARRIOR is not set
# CONFIG_JOYSTICK_MAGELLAN is not set
# CONFIG_JOYSTICK_SPACEORB is not set
# CONFIG_JOYSTICK_SPACEBALL is not set
# CONFIG_JOYSTICK_STINGER is not set
# CONFIG_JOYSTICK_TWIDJOY is not set
# CONFIG_JOYSTICK_DB9 is not set
# CONFIG_JOYSTICK_GAMECON is not set
# CONFIG_JOYSTICK_TURBOGRAFX is not set
# CONFIG_JOYSTICK_JOYDUMP is not set
# CONFIG_JOYSTICK_XPAD is not set
# CONFIG_INPUT_TABLET is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
CONFIG_INPUT_MISC=y
CONFIG_INPUT_PCSPKR=m
# CONFIG_INPUT_APANEL is not set
# CONFIG_INPUT_WISTRON_BTNS is not set
# CONFIG_INPUT_ATLAS_BTNS is not set
# CONFIG_INPUT_ATI_REMOTE is not set
# CONFIG_INPUT_ATI_REMOTE2 is not set
# CONFIG_INPUT_KEYSPAN_REMOTE is not set
# CONFIG_INPUT_POWERMATE is not set
# CONFIG_INPUT_YEALINK is not set
CONFIG_INPUT_UINPUT=m

#
# Hardware I/O ports
#
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
# CONFIG_SERIO_SERPORT is not set
# CONFIG_SERIO_CT82C710 is not set
# CONFIG_SERIO_PARKBD is not set
# CONFIG_SERIO_PCIPS2 is not set
CONFIG_SERIO_LIBPS2=y
# CONFIG_SERIO_RAW is not set
CONFIG_GAMEPORT=m
# CONFIG_GAMEPORT_NS558 is not set
# CONFIG_GAMEPORT_L4 is not set
# CONFIG_GAMEPORT_EMU10K1 is not set
# CONFIG_GAMEPORT_FM801 is not set

#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
CONFIG_VT_HW_CONSOLE_BINDING=y
# CONFIG_SERIAL_NONSTANDARD is not set
# CONFIG_NOZOMI is not set

#
# Serial drivers
#
CONFIG_SERIAL_8250=m
CONFIG_FIX_EARLYCON_MEM=y
# CONFIG_SERIAL_8250_PCI is not set
CONFIG_SERIAL_8250_PNP=m
CONFIG_SERIAL_8250_NR_UARTS=4
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
# CONFIG_SERIAL_8250_EXTENDED is not set

#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=m
# CONFIG_SERIAL_JSM is not set
CONFIG_UNIX98_PTYS=y
# CONFIG_LEGACY_PTYS is not set
CONFIG_PRINTER=m
# CONFIG_LP_CONSOLE is not set
# CONFIG_PPDEV is not set
# CONFIG_TIPAR is not set
# CONFIG_IPMI_HANDLER is not set
# CONFIG_HW_RANDOM is not set
# CONFIG_NVRAM is not set
CONFIG_RTC=m
# CONFIG_GEN_RTC is not set
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
# CONFIG_SONYPI is not set
# CONFIG_MWAVE is not set
# CONFIG_PC8736x_GPIO is not set
# CONFIG_NSC_GPIO is not set
# CONFIG_CS5535_GPIO is not set
# CONFIG_RAW_DRIVER is not set
# CONFIG_HPET is not set
# CONFIG_HANGCHECK_TIMER is not set
# CONFIG_TCG_TPM is not set
# CONFIG_TELCLOCK is not set
CONFIG_DEVPORT=y
CONFIG_I2C=y
CONFIG_I2C_BOARDINFO=y
CONFIG_I2C_CHARDEV=m

#
# I2C Algorithms
#
CONFIG_I2C_ALGOBIT=y
CONFIG_I2C_ALGOPCF=m
CONFIG_I2C_ALGOPCA=m

#
# I2C Hardware Bus support
#
# CONFIG_I2C_ALI1535 is not set
# CONFIG_I2C_ALI1563 is not set
# CONFIG_I2C_ALI15X3 is not set
# CONFIG_I2C_AMD756 is not set
# CONFIG_I2C_AMD8111 is not set
# CONFIG_I2C_ELEKTOR is not set
# CONFIG_I2C_I801 is not set
# CONFIG_I2C_I810 is not set
# CONFIG_I2C_PIIX4 is not set
# CONFIG_I2C_NFORCE2 is not set
# CONFIG_I2C_OCORES is not set
# CONFIG_I2C_PARPORT is not set
# CONFIG_I2C_PARPORT_LIGHT is not set
# CONFIG_I2C_PROSAVAGE is not set
# CONFIG_I2C_SAVAGE4 is not set
# CONFIG_I2C_SIMTEC is not set
# CONFIG_SCx200_ACB is not set
# CONFIG_I2C_SIS5595 is not set
# CONFIG_I2C_SIS630 is not set
# CONFIG_I2C_SIS96X is not set
# CONFIG_I2C_TAOS_EVM is not set
# CONFIG_I2C_STUB is not set
# CONFIG_I2C_TINY_USB is not set
CONFIG_I2C_VIA=m
CONFIG_I2C_VIAPRO=m
# CONFIG_I2C_VOODOO3 is not set
# CONFIG_I2C_PCA_ISA is not set

#
# Miscellaneous I2C Chip support
#
# CONFIG_DS1682 is not set
CONFIG_SENSORS_EEPROM=m
# CONFIG_SENSORS_PCF8574 is not set
# CONFIG_PCF8575 is not set
# CONFIG_SENSORS_PCA9539 is not set
# CONFIG_SENSORS_PCF8591 is not set
# CONFIG_SENSORS_MAX6875 is not set
# CONFIG_SENSORS_TSL2550 is not set
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
# CONFIG_I2C_DEBUG_CHIP is not set

#
# SPI support
#
# CONFIG_SPI is not set
# CONFIG_SPI_MASTER is not set
# CONFIG_W1 is not set
# CONFIG_POWER_SUPPLY is not set
CONFIG_HWMON=y
CONFIG_HWMON_VID=m
# CONFIG_SENSORS_ABITUGURU is not set
# CONFIG_SENSORS_ABITUGURU3 is not set
# CONFIG_SENSORS_AD7418 is not set
# CONFIG_SENSORS_ADM1021 is not set
# CONFIG_SENSORS_ADM1025 is not set
# CONFIG_SENSORS_ADM1026 is not set
# CONFIG_SENSORS_ADM1029 is not set
# CONFIG_SENSORS_ADM1031 is not set
# CONFIG_SENSORS_ADM9240 is not set
# CONFIG_SENSORS_ADT7470 is not set
# CONFIG_SENSORS_K8TEMP is not set
# CONFIG_SENSORS_ASB100 is not set
# CONFIG_SENSORS_ATXP1 is not set
# CONFIG_SENSORS_DS1621 is not set
# CONFIG_SENSORS_I5K_AMB is not set
# CONFIG_SENSORS_F71805F is not set
# CONFIG_SENSORS_F71882FG is not set
# CONFIG_SENSORS_F75375S is not set
# CONFIG_SENSORS_FSCHER is not set
# CONFIG_SENSORS_FSCPOS is not set
# CONFIG_SENSORS_FSCHMD is not set
# CONFIG_SENSORS_GL518SM is not set
# CONFIG_SENSORS_GL520SM is not set
# CONFIG_SENSORS_CORETEMP is not set
# CONFIG_SENSORS_IT87 is not set
# CONFIG_SENSORS_LM63 is not set
# CONFIG_SENSORS_LM75 is not set
# CONFIG_SENSORS_LM77 is not set
# CONFIG_SENSORS_LM78 is not set
CONFIG_SENSORS_LM80=m
# CONFIG_SENSORS_LM83 is not set
# CONFIG_SENSORS_LM85 is not set
# CONFIG_SENSORS_LM87 is not set
# CONFIG_SENSORS_LM90 is not set
# CONFIG_SENSORS_LM92 is not set
# CONFIG_SENSORS_LM93 is not set
# CONFIG_SENSORS_MAX1619 is not set
# CONFIG_SENSORS_MAX6650 is not set
# CONFIG_SENSORS_PC87360 is not set
# CONFIG_SENSORS_PC87427 is not set
# CONFIG_SENSORS_SIS5595 is not set
# CONFIG_SENSORS_DME1737 is not set
# CONFIG_SENSORS_SMSC47M1 is not set
# CONFIG_SENSORS_SMSC47M192 is not set
# CONFIG_SENSORS_SMSC47B397 is not set
# CONFIG_SENSORS_THMC50 is not set
CONFIG_SENSORS_VIA686A=m
# CONFIG_SENSORS_VT1211 is not set
# CONFIG_SENSORS_VT8231 is not set
CONFIG_SENSORS_W83781D=m
# CONFIG_SENSORS_W83791D is not set
# CONFIG_SENSORS_W83792D is not set
# CONFIG_SENSORS_W83793 is not set
# CONFIG_SENSORS_W83L785TS is not set
# CONFIG_SENSORS_W83627HF is not set
# CONFIG_SENSORS_W83627EHF is not set
# CONFIG_SENSORS_HDAPS is not set
# CONFIG_SENSORS_APPLESMC is not set
# CONFIG_HWMON_DEBUG_CHIP is not set
# CONFIG_WATCHDOG is not set

#
# Sonics Silicon Backplane
#
CONFIG_SSB_POSSIBLE=y
# CONFIG_SSB is not set

#
# Multifunction device drivers
#
# CONFIG_MFD_SM501 is not set

#
# Multimedia devices
#
CONFIG_VIDEO_DEV=m
CONFIG_VIDEO_V4L1=y
CONFIG_VIDEO_V4L1_COMPAT=y
CONFIG_VIDEO_V4L2=y
CONFIG_VIDEO_CAPTURE_DRIVERS=y
# CONFIG_VIDEO_ADV_DEBUG is not set
CONFIG_VIDEO_HELPER_CHIPS_AUTO=y
# CONFIG_VIDEO_VIVI is not set
# CONFIG_VIDEO_BT848 is not set
# CONFIG_VIDEO_PMS is not set
# CONFIG_VIDEO_BWQCAM is not set
# CONFIG_VIDEO_CQCAM is not set
# CONFIG_VIDEO_W9966 is not set
# CONFIG_VIDEO_CPIA is not set
# CONFIG_VIDEO_CPIA2 is not set
# CONFIG_VIDEO_SAA5246A is not set
# CONFIG_VIDEO_SAA5249 is not set
# CONFIG_TUNER_3036 is not set
# CONFIG_VIDEO_STRADIS is not set
# CONFIG_VIDEO_ZORAN is not set
# CONFIG_VIDEO_SAA7134 is not set
# CONFIG_VIDEO_MXB is not set
# CONFIG_VIDEO_DPC is not set
# CONFIG_VIDEO_HEXIUM_ORION is not set
# CONFIG_VIDEO_HEXIUM_GEMINI is not set
# CONFIG_VIDEO_CX88 is not set
# CONFIG_VIDEO_IVTV is not set
# CONFIG_VIDEO_CAFE_CCIC is not set
CONFIG_V4L_USB_DRIVERS=y
# CONFIG_VIDEO_PVRUSB2 is not set
# CONFIG_VIDEO_EM28XX is not set
# CONFIG_VIDEO_USBVISION is not set
# CONFIG_USB_VICAM is not set
# CONFIG_USB_IBMCAM is not set
# CONFIG_USB_KONICAWC is not set
# CONFIG_USB_QUICKCAM_MESSENGER is not set
# CONFIG_USB_ET61X251 is not set
# CONFIG_VIDEO_OVCAMCHIP is not set
# CONFIG_USB_W9968CF is not set
# CONFIG_USB_OV511 is not set
# CONFIG_USB_SE401 is not set
# CONFIG_USB_SN9C102 is not set
# CONFIG_USB_STV680 is not set
# CONFIG_USB_ZC0301 is not set
# CONFIG_USB_PWC is not set
# CONFIG_USB_ZR364XX is not set
# CONFIG_RADIO_ADAPTERS is not set
# CONFIG_DVB_CORE is not set
# CONFIG_DAB is not set

#
# Graphics support
#
CONFIG_AGP=m
# CONFIG_AGP_ALI is not set
# CONFIG_AGP_ATI is not set
# CONFIG_AGP_AMD is not set
# CONFIG_AGP_AMD64 is not set
# CONFIG_AGP_INTEL is not set
# CONFIG_AGP_NVIDIA is not set
# CONFIG_AGP_SIS is not set
# CONFIG_AGP_SWORKS is not set
CONFIG_AGP_VIA=m
# CONFIG_AGP_EFFICEON is not set
CONFIG_DRM=m
# CONFIG_DRM_TDFX is not set
# CONFIG_DRM_R128 is not set
CONFIG_DRM_RADEON=m
# CONFIG_DRM_MGA is not set
# CONFIG_DRM_SIS is not set
# CONFIG_DRM_VIA is not set
# CONFIG_DRM_SAVAGE is not set
# CONFIG_VGASTATE is not set
# CONFIG_VIDEO_OUTPUT_CONTROL is not set
CONFIG_FB=y
CONFIG_FIRMWARE_EDID=y
CONFIG_FB_DDC=y
CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y
# CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set
# CONFIG_FB_SYS_FILLRECT is not set
# CONFIG_FB_SYS_COPYAREA is not set
# CONFIG_FB_SYS_IMAGEBLIT is not set
# CONFIG_FB_SYS_FOPS is not set
CONFIG_FB_DEFERRED_IO=y
# CONFIG_FB_SVGALIB is not set
# CONFIG_FB_MACMODES is not set
# CONFIG_FB_BACKLIGHT is not set
CONFIG_FB_MODE_HELPERS=y
# CONFIG_FB_TILEBLITTING is not set

#
# Frame buffer hardware drivers
#
# CONFIG_FB_CIRRUS is not set
# CONFIG_FB_PM2 is not set
# CONFIG_FB_CYBER2000 is not set
# CONFIG_FB_ARC is not set
# CONFIG_FB_ASILIANT is not set
# CONFIG_FB_IMSTT is not set
# CONFIG_FB_VGA16 is not set
CONFIG_FB_VESA=y
# CONFIG_FB_EFI is not set
# CONFIG_FB_HECUBA is not set
# CONFIG_FB_HGA is not set
# CONFIG_FB_S1D13XXX is not set
# CONFIG_FB_NVIDIA is not set
# CONFIG_FB_RIVA is not set
# CONFIG_FB_I810 is not set
# CONFIG_FB_LE80578 is not set
# CONFIG_FB_INTEL is not set
# CONFIG_FB_MATROX is not set
CONFIG_FB_RADEON=y
CONFIG_FB_RADEON_I2C=y
# CONFIG_FB_RADEON_BACKLIGHT is not set
# CONFIG_FB_RADEON_DEBUG is not set
# CONFIG_FB_ATY128 is not set
# CONFIG_FB_ATY is not set
# CONFIG_FB_S3 is not set
# CONFIG_FB_SAVAGE is not set
# CONFIG_FB_SIS is not set
# CONFIG_FB_NEOMAGIC is not set
# CONFIG_FB_KYRO is not set
# CONFIG_FB_3DFX is not set
# CONFIG_FB_VOODOO1 is not set
# CONFIG_FB_VT8623 is not set
# CONFIG_FB_CYBLA is not set
# CONFIG_FB_TRIDENT is not set
# CONFIG_FB_ARK is not set
# CONFIG_FB_PM3 is not set
# CONFIG_FB_GEODE is not set
# CONFIG_FB_VIRTUAL is not set
# CONFIG_BACKLIGHT_LCD_SUPPORT is not set

#
# Display device support
#
# CONFIG_DISPLAY_SUPPORT is not set

#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
# CONFIG_VGACON_SOFT_SCROLLBACK is not set
CONFIG_VIDEO_SELECT=y
# CONFIG_MDA_CONSOLE is not set
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
# CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY is not set
# CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set
# CONFIG_FONTS is not set
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y
CONFIG_LOGO=y
CONFIG_LOGO_LINUX_MONO=y
CONFIG_LOGO_LINUX_VGA16=y
CONFIG_LOGO_LINUX_CLUT224=y

#
# Sound
#
CONFIG_SOUND=m

#
# Advanced Linux Sound Architecture
#
CONFIG_SND=m
CONFIG_SND_TIMER=m
CONFIG_SND_PCM=m
CONFIG_SND_HWDEP=m
CONFIG_SND_RAWMIDI=m
CONFIG_SND_SEQUENCER=m
# CONFIG_SND_SEQ_DUMMY is not set
CONFIG_SND_OSSEMUL=y
CONFIG_SND_MIXER_OSS=m
CONFIG_SND_PCM_OSS=m
CONFIG_SND_PCM_OSS_PLUGINS=y
CONFIG_SND_SEQUENCER_OSS=y
CONFIG_SND_RTCTIMER=m
CONFIG_SND_SEQ_RTCTIMER_DEFAULT=y
CONFIG_SND_DYNAMIC_MINORS=y
# CONFIG_SND_SUPPORT_OLD_API is not set
# CONFIG_SND_VERBOSE_PROCFS is not set
# CONFIG_SND_VERBOSE_PRINTK is not set
# CONFIG_SND_DEBUG is not set

#
# Generic devices
#
CONFIG_SND_AC97_CODEC=m
# CONFIG_SND_DUMMY is not set
# CONFIG_SND_VIRMIDI is not set
# CONFIG_SND_MTPAV is not set
# CONFIG_SND_MTS64 is not set
# CONFIG_SND_SERIAL_U16550 is not set
# CONFIG_SND_MPU401 is not set
# CONFIG_SND_PORTMAN2X4 is not set

#
# ISA devices
#
# CONFIG_SND_ADLIB is not set
# CONFIG_SND_AD1816A is not set
# CONFIG_SND_AD1848 is not set
# CONFIG_SND_ALS100 is not set
# CONFIG_SND_AZT2320 is not set
# CONFIG_SND_CMI8330 is not set
# CONFIG_SND_CS4231 is not set
# CONFIG_SND_CS4232 is not set
# CONFIG_SND_CS4236 is not set
# CONFIG_SND_DT019X is not set
# CONFIG_SND_ES968 is not set
# CONFIG_SND_ES1688 is not set
# CONFIG_SND_ES18XX is not set
# CONFIG_SND_SC6000 is not set
# CONFIG_SND_GUSCLASSIC is not set
# CONFIG_SND_GUSEXTREME is not set
# CONFIG_SND_GUSMAX is not set
# CONFIG_SND_INTERWAVE is not set
# CONFIG_SND_INTERWAVE_STB is not set
# CONFIG_SND_OPL3SA2 is not set
# CONFIG_SND_OPTI92X_AD1848 is not set
# CONFIG_SND_OPTI92X_CS4231 is not set
# CONFIG_SND_OPTI93X is not set
# CONFIG_SND_MIRO is not set
# CONFIG_SND_SB8 is not set
# CONFIG_SND_SB16 is not set
# CONFIG_SND_SBAWE is not set
# CONFIG_SND_SGALAXY is not set
# CONFIG_SND_SSCAPE is not set
# CONFIG_SND_WAVEFRONT is not set

#
# PCI devices
#
# CONFIG_SND_AD1889 is not set
# CONFIG_SND_ALS300 is not set
# CONFIG_SND_ALS4000 is not set
# CONFIG_SND_ALI5451 is not set
# CONFIG_SND_ATIIXP is not set
# CONFIG_SND_ATIIXP_MODEM is not set
# CONFIG_SND_AU8810 is not set
# CONFIG_SND_AU8820 is not set
# CONFIG_SND_AU8830 is not set
# CONFIG_SND_AZT3328 is not set
# CONFIG_SND_BT87X is not set
# CONFIG_SND_CA0106 is not set
# CONFIG_SND_CMIPCI is not set
# CONFIG_SND_CS4281 is not set
# CONFIG_SND_CS46XX is not set
# CONFIG_SND_CS5530 is not set
# CONFIG_SND_CS5535AUDIO is not set
# CONFIG_SND_DARLA20 is not set
# CONFIG_SND_GINA20 is not set
# CONFIG_SND_LAYLA20 is not set
# CONFIG_SND_DARLA24 is not set
# CONFIG_SND_GINA24 is not set
# CONFIG_SND_LAYLA24 is not set
# CONFIG_SND_MONA is not set
# CONFIG_SND_MIA is not set
# CONFIG_SND_ECHO3G is not set
# CONFIG_SND_INDIGO is not set
# CONFIG_SND_INDIGOIO is not set
# CONFIG_SND_INDIGODJ is not set
# CONFIG_SND_EMU10K1 is not set
# CONFIG_SND_EMU10K1X is not set
# CONFIG_SND_ENS1370 is not set
CONFIG_SND_ENS1371=m
# CONFIG_SND_ES1938 is not set
# CONFIG_SND_ES1968 is not set
# CONFIG_SND_FM801 is not set
# CONFIG_SND_HDA_INTEL is not set
# CONFIG_SND_HDSP is not set
# CONFIG_SND_HDSPM is not set
# CONFIG_SND_ICE1712 is not set
# CONFIG_SND_ICE1724 is not set
# CONFIG_SND_INTEL8X0 is not set
# CONFIG_SND_INTEL8X0M is not set
# CONFIG_SND_KORG1212 is not set
# CONFIG_SND_MAESTRO3 is not set
# CONFIG_SND_MIXART is not set
# CONFIG_SND_NM256 is not set
# CONFIG_SND_PCXHR is not set
# CONFIG_SND_RIPTIDE is not set
# CONFIG_SND_RME32 is not set
# CONFIG_SND_RME96 is not set
# CONFIG_SND_RME9652 is not set
# CONFIG_SND_SONICVIBES is not set
# CONFIG_SND_TRIDENT is not set
# CONFIG_SND_VIA82XX is not set
# CONFIG_SND_VIA82XX_MODEM is not set
# CONFIG_SND_VX222 is not set
# CONFIG_SND_YMFPCI is not set
CONFIG_SND_AC97_POWER_SAVE=y
CONFIG_SND_AC97_POWER_SAVE_DEFAULT=0

#
# USB devices
#
CONFIG_SND_USB_AUDIO=m
# CONFIG_SND_USB_USX2Y is not set
# CONFIG_SND_USB_CAIAQ is not set

#
# System on Chip audio support
#
# CONFIG_SND_SOC is not set

#
# SoC Audio support for SuperH
#

#
# Open Sound System
#
# CONFIG_SOUND_PRIME is not set
CONFIG_AC97_BUS=m
CONFIG_HID_SUPPORT=y
CONFIG_HID=m
# CONFIG_HID_DEBUG is not set
# CONFIG_HIDRAW is not set

#
# USB Input Devices
#
CONFIG_USB_HID=m
# CONFIG_USB_HIDINPUT_POWERBOOK is not set
# CONFIG_HID_FF is not set
# CONFIG_USB_HIDDEV is not set

#
# USB HID Boot Protocol drivers
#
# CONFIG_USB_KBD is not set
# CONFIG_USB_MOUSE is not set
CONFIG_USB_SUPPORT=y
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB_ARCH_HAS_EHCI=y
CONFIG_USB=m
# CONFIG_USB_DEBUG is not set

#
# Miscellaneous USB options
#
CONFIG_USB_DEVICEFS=y
CONFIG_USB_DEVICE_CLASS=y
CONFIG_USB_DYNAMIC_MINORS=y
CONFIG_USB_SUSPEND=y
# CONFIG_USB_PERSIST is not set
# CONFIG_USB_OTG is not set

#
# USB Host Controller Drivers
#
CONFIG_USB_EHCI_HCD=m
# CONFIG_USB_EHCI_SPLIT_ISO is not set
CONFIG_USB_EHCI_ROOT_HUB_TT=y
# CONFIG_USB_EHCI_TT_NEWSCHED is not set
# CONFIG_USB_ISP116X_HCD is not set
# CONFIG_USB_OHCI_HCD is not set
CONFIG_USB_UHCI_HCD=m
# CONFIG_USB_SL811_HCD is not set
# CONFIG_USB_R8A66597_HCD is not set

#
# USB Device Class drivers
#
# CONFIG_USB_ACM is not set
CONFIG_USB_PRINTER=m

#
# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support'
#

#
# may also be needed; see USB_STORAGE Help for more information
#
CONFIG_USB_STORAGE=m
# CONFIG_USB_STORAGE_DEBUG is not set
# CONFIG_USB_STORAGE_DATAFAB is not set
# CONFIG_USB_STORAGE_FREECOM is not set
# CONFIG_USB_STORAGE_ISD200 is not set
# CONFIG_USB_STORAGE_DPCM is not set
# CONFIG_USB_STORAGE_USBAT is not set
# CONFIG_USB_STORAGE_SDDR09 is not set
# CONFIG_USB_STORAGE_SDDR55 is not set
# CONFIG_USB_STORAGE_JUMPSHOT is not set
# CONFIG_USB_STORAGE_ALAUDA is not set
# CONFIG_USB_STORAGE_KARMA is not set
# CONFIG_USB_LIBUSUAL is not set

#
# USB Imaging devices
#
# CONFIG_USB_MDC800 is not set
# CONFIG_USB_MICROTEK is not set
# CONFIG_USB_MON is not set

#
# USB port drivers
#
# CONFIG_USB_USS720 is not set

#
# USB Serial Converter support
#
# CONFIG_USB_SERIAL is not set

#
# USB Miscellaneous drivers
#
# CONFIG_USB_EMI62 is not set
# CONFIG_USB_EMI26 is not set
# CONFIG_USB_ADUTUX is not set
# CONFIG_USB_AUERSWALD is not set
# CONFIG_USB_RIO500 is not set
# CONFIG_USB_LEGOTOWER is not set
# CONFIG_USB_LCD is not set
# CONFIG_USB_BERRY_CHARGE is not set
# CONFIG_USB_LED is not set
# CONFIG_USB_CYPRESS_CY7C63 is not set
# CONFIG_USB_CYTHERM is not set
# CONFIG_USB_PHIDGET is not set
# CONFIG_USB_IDMOUSE is not set
# CONFIG_USB_FTDI_ELAN is not set
# CONFIG_USB_APPLEDISPLAY is not set
# CONFIG_USB_SISUSBVGA is not set
# CONFIG_USB_LD is not set
# CONFIG_USB_TRANCEVIBRATOR is not set
# CONFIG_USB_IOWARRIOR is not set
# CONFIG_USB_TEST is not set
# CONFIG_USB_GOTEMP is not set

#
# USB DSL modem support
#
CONFIG_USB_ATM=m
# CONFIG_USB_SPEEDTOUCH is not set
# CONFIG_USB_CXACRU is not set
CONFIG_USB_UEAGLEATM=m
# CONFIG_USB_XUSBATM is not set

#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set
# CONFIG_MMC is not set
# CONFIG_NEW_LEDS is not set
# CONFIG_INFINIBAND is not set
CONFIG_EDAC=y

#
# Reporting subsystems
#
# CONFIG_EDAC_DEBUG is not set
CONFIG_EDAC_MM_EDAC=m
CONFIG_EDAC_AMD76X=m
# CONFIG_EDAC_E7XXX is not set
# CONFIG_EDAC_E752X is not set
# CONFIG_EDAC_I82875P is not set
# CONFIG_EDAC_I82975X is not set
# CONFIG_EDAC_I3000 is not set
# CONFIG_EDAC_I82860 is not set
# CONFIG_EDAC_R82600 is not set
# CONFIG_EDAC_I5000 is not set
# CONFIG_RTC_CLASS is not set
# CONFIG_DMADEVICES is not set
# CONFIG_AUXDISPLAY is not set
# CONFIG_VIRTUALIZATION is not set

#
# Userspace I/O
#
# CONFIG_UIO is not set

#
# Firmware Drivers
#
CONFIG_EDD=y
# CONFIG_DELL_RBU is not set
# CONFIG_DCDBAS is not set
CONFIG_DMIID=y

#
# File systems
#
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
# CONFIG_EXT2_FS_POSIX_ACL is not set
# CONFIG_EXT2_FS_SECURITY is not set
CONFIG_EXT2_FS_XIP=y
CONFIG_FS_XIP=y
CONFIG_EXT3_FS=y
CONFIG_EXT3_FS_XATTR=y
CONFIG_EXT3_FS_POSIX_ACL=y
# CONFIG_EXT3_FS_SECURITY is not set
# CONFIG_EXT4DEV_FS is not set
CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
CONFIG_FS_MBCACHE=y
CONFIG_REISER4_FS=m
# CONFIG_REISER4_DEBUG is not set
CONFIG_REISERFS_FS=m
# CONFIG_REISERFS_CHECK is not set
# CONFIG_REISERFS_PROC_INFO is not set
CONFIG_REISERFS_FS_XATTR=y
# CONFIG_REISERFS_FS_POSIX_ACL is not set
# CONFIG_REISERFS_FS_SECURITY is not set
# CONFIG_JFS_FS is not set
CONFIG_FS_POSIX_ACL=y
# CONFIG_XFS_FS is not set
# CONFIG_GFS2_FS is not set
# CONFIG_OCFS2_FS is not set
CONFIG_DNOTIFY=y
CONFIG_INOTIFY=y
CONFIG_INOTIFY_USER=y
# CONFIG_QUOTA is not set
# CONFIG_AUTOFS_FS is not set
CONFIG_AUTOFS4_FS=m
# CONFIG_FUSE_FS is not set

#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=m
CONFIG_JOLIET=y
# CONFIG_ZISOFS is not set
CONFIG_UDF_FS=m
CONFIG_UDF_NLS=y

#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=m
CONFIG_MSDOS_FS=m
CONFIG_VFAT_FS=m
CONFIG_FAT_DEFAULT_CODEPAGE=850
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
CONFIG_NTFS_FS=m
# CONFIG_NTFS_DEBUG is not set
# CONFIG_NTFS_RW is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_PROC_SYSCTL=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
# CONFIG_TMPFS_POSIX_ACL is not set
# CONFIG_HUGETLBFS is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_CONFIGFS_FS=m

#
# Layered filesystems
#
CONFIG_ECRYPT_FS=m
# CONFIG_UNION_FS is not set

#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_CRAMFS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_ROMFS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set
CONFIG_NETWORK_FILESYSTEMS=y
# CONFIG_NFS_FS is not set
# CONFIG_NFSD is not set
# CONFIG_SMB_FS is not set
CONFIG_CIFS=m
CONFIG_CIFS_STATS=y
# CONFIG_CIFS_STATS2 is not set
# CONFIG_CIFS_WEAK_PW_HASH is not set
CONFIG_CIFS_XATTR=y
CONFIG_CIFS_POSIX=y
# CONFIG_CIFS_DEBUG2 is not set
# CONFIG_CIFS_EXPERIMENTAL is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set

#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
# CONFIG_ACORN_PARTITION is not set
# CONFIG_OSF_PARTITION is not set
# CONFIG_AMIGA_PARTITION is not set
# CONFIG_ATARI_PARTITION is not set
# CONFIG_MAC_PARTITION is not set
CONFIG_MSDOS_PARTITION=y
# CONFIG_BSD_DISKLABEL is not set
# CONFIG_MINIX_SUBPARTITION is not set
# CONFIG_SOLARIS_X86_PARTITION is not set
# CONFIG_UNIXWARE_DISKLABEL is not set
# CONFIG_LDM_PARTITION is not set
# CONFIG_SGI_PARTITION is not set
# CONFIG_ULTRIX_PARTITION is not set
# CONFIG_SUN_PARTITION is not set
# CONFIG_KARMA_PARTITION is not set
# CONFIG_EFI_PARTITION is not set
# CONFIG_SYSV68_PARTITION is not set
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
CONFIG_NLS_CODEPAGE_437=m
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
CONFIG_NLS_CODEPAGE_850=m
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
CONFIG_NLS_ASCII=m
CONFIG_NLS_ISO8859_1=m
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
CONFIG_NLS_ISO8859_15=m
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
CONFIG_NLS_UTF8=m
# CONFIG_DLM is not set
CONFIG_INSTRUMENTATION=y
CONFIG_PROFILING=y
CONFIG_OPROFILE=m
# CONFIG_KPROBES is not set
# CONFIG_MARKERS is not set

#
# Kernel hacking
#
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_PRINTK_TIME=y
CONFIG_ENABLE_WARN_DEPRECATED=y
CONFIG_ENABLE_MUST_CHECK=y
CONFIG_MAGIC_SYSRQ=y
# CONFIG_UNUSED_SYMBOLS is not set
# CONFIG_PAGE_OWNER is not set
CONFIG_DEBUG_FS=y
# CONFIG_HEADERS_CHECK is not set
CONFIG_DEBUG_KERNEL=y
# CONFIG_DEBUG_SHIRQ is not set
# CONFIG_DETECT_SOFTLOCKUP is not set
# CONFIG_SCHED_DEBUG is not set
# CONFIG_SCHEDSTATS is not set
# CONFIG_TIMER_STATS is not set
CONFIG_DEBUG_SLAB=y
CONFIG_DEBUG_SLAB_LEAK=y
CONFIG_DEBUG_PREEMPT=y
# CONFIG_DEBUG_RT_MUTEXES is not set
# CONFIG_RT_MUTEX_TESTER is not set
CONFIG_DEBUG_SPINLOCK=y
CONFIG_DEBUG_MUTEXES=y
CONFIG_DEBUG_LOCK_ALLOC=y
CONFIG_PROVE_LOCKING=y
CONFIG_LOCKDEP=y
# CONFIG_LOCK_STAT is not set
# CONFIG_DEBUG_LOCKDEP is not set
CONFIG_TRACE_IRQFLAGS=y
CONFIG_DEBUG_SPINLOCK_SLEEP=y
CONFIG_DEBUG_LOCKING_API_SELFTESTS=y
CONFIG_STACKTRACE=y
# CONFIG_DEBUG_KOBJECT is not set
CONFIG_DEBUG_BUGVERBOSE=y
# CONFIG_DEBUG_INFO is not set
# CONFIG_DEBUG_VM is not set
# CONFIG_DEBUG_LIST is not set
# CONFIG_DEBUG_SG is not set
CONFIG_FRAME_POINTER=y
# CONFIG_PROFILE_LIKELY is not set
# CONFIG_FORCED_INLINING is not set
# CONFIG_BOOT_PRINTK_DELAY is not set
# CONFIG_DEBUG_SYNCHRO_TEST is not set
# CONFIG_RCU_TORTURE_TEST is not set
# CONFIG_FAULT_INJECTION is not set
# CONFIG_SAMPLES is not set
CONFIG_EARLY_PRINTK=y
CONFIG_DEBUG_STACKOVERFLOW=y
CONFIG_DEBUG_STACK_USAGE=y

#
# Page alloc debug is incompatible with Software Suspend on i386
#
CONFIG_DEBUG_RODATA=y
CONFIG_4KSTACKS=y
CONFIG_X86_FIND_SMP_CONFIG=y
CONFIG_X86_MPPARSE=y
CONFIG_DOUBLEFAULT=y

#
# Security options
#
CONFIG_KEYS=y
# CONFIG_KEYS_DEBUG_PROC_KEYS is not set
# CONFIG_SECURITY is not set
# CONFIG_SECURITY_FILE_CAPABILITIES is not set
CONFIG_XOR_BLOCKS=m
CONFIG_ASYNC_CORE=m
CONFIG_ASYNC_MEMCPY=m
CONFIG_ASYNC_XOR=m
CONFIG_CRYPTO=y
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_BLKCIPHER=m
CONFIG_CRYPTO_HASH=y
CONFIG_CRYPTO_MANAGER=y
CONFIG_CRYPTO_HMAC=y
# CONFIG_CRYPTO_XCBC is not set
# CONFIG_CRYPTO_NULL is not set
# CONFIG_CRYPTO_MD4 is not set
CONFIG_CRYPTO_MD5=y
CONFIG_CRYPTO_SHA1=m
CONFIG_CRYPTO_SHA256=m
CONFIG_CRYPTO_SHA512=m
# CONFIG_CRYPTO_WP512 is not set
# CONFIG_CRYPTO_TGR192 is not set
# CONFIG_CRYPTO_GF128MUL is not set
CONFIG_CRYPTO_ECB=m
CONFIG_CRYPTO_CBC=m
CONFIG_CRYPTO_PCBC=m
# CONFIG_CRYPTO_LRW is not set
# CONFIG_CRYPTO_XTS is not set
# CONFIG_CRYPTO_CTR is not set
# CONFIG_CRYPTO_CRYPTD is not set
CONFIG_CRYPTO_DES=m
# CONFIG_CRYPTO_FCRYPT is not set
CONFIG_CRYPTO_BLOWFISH=m
# CONFIG_CRYPTO_TWOFISH is not set
# CONFIG_CRYPTO_TWOFISH_586 is not set
# CONFIG_CRYPTO_SERPENT is not set
CONFIG_CRYPTO_AES=m
CONFIG_CRYPTO_AES_586=m
# CONFIG_CRYPTO_CAST5 is not set
# CONFIG_CRYPTO_CAST6 is not set
# CONFIG_CRYPTO_TEA is not set
CONFIG_CRYPTO_ARC4=m
# CONFIG_CRYPTO_KHAZAD is not set
# CONFIG_CRYPTO_ANUBIS is not set
# CONFIG_CRYPTO_SEED is not set
# CONFIG_CRYPTO_SALSA20 is not set
CONFIG_CRYPTO_DEFLATE=m
CONFIG_CRYPTO_MICHAEL_MIC=m
CONFIG_CRYPTO_CRC32C=m
# CONFIG_CRYPTO_CAMELLIA is not set
# CONFIG_CRYPTO_TEST is not set
# CONFIG_CRYPTO_AUTHENC is not set
# CONFIG_CRYPTO_HW is not set

#
# Library routines
#
CONFIG_BITREVERSE=y
CONFIG_CRC_CCITT=m
# CONFIG_CRC16 is not set
CONFIG_CRC_ITU_T=m
CONFIG_CRC32=y
# CONFIG_CRC7 is not set
CONFIG_LIBCRC32C=m
CONFIG_ZLIB_INFLATE=m
CONFIG_ZLIB_DEFLATE=m
CONFIG_LZO_COMPRESS=m
CONFIG_LZO_DECOMPRESS=m
CONFIG_TEXTSEARCH=y
CONFIG_TEXTSEARCH_KMP=m
CONFIG_TEXTSEARCH_BM=m
CONFIG_TEXTSEARCH_FSM=m
CONFIG_PLIST=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y


Attachments:
dmesg-2.6.24-rc3-mm1 (23.25 kB)
.config (47.53 kB)
Download all attachments

2007-11-21 22:23:17

by Andrew Morton

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1: usb mouse doesn't work

On Wed, 21 Nov 2007 20:23:46 +0200
"Kirill A. Shutemov" <[email protected]> wrote:

> USB mouse(Logitech M-BT58) doesn't work. TouchPad works.
> dmesg after rmmod usbcore && modprobe uhci_hcd:
>
> usbcore: registered new interface driver usbfs
> usbcore: registered new interface driver hub
> usbcore: registered new device driver usb
> USB Universal Host Controller Interface driver v3.0
> ACPI: PCI Interrupt 0000:00:1d.0[A] -> Link [LNKE] -> GSI 10 (level, low)
> -> IRQ 10
> 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 1
> uhci_hcd 0000:00:1d.0: irq 10, io base 0x0000bf80
> usb usb1: configuration #1 chosen from 1 choice
> hub 1-0:1.0: USB hub found
> hub 1-0:1.0: 2 ports detected
> usb usb1: new device found, idVendor=0000, idProduct=0000
> usb usb1: new device strings: Mfr=3, Product=2, SerialNumber=1
> usb usb1: Product: UHCI Host Controller
> usb usb1: Manufacturer: Linux 2.6.24-kas-alt1 uhci_hcd
> usb usb1: SerialNumber: 0000:00:1d.0
> ACPI: PCI Interrupt 0000:00:1d.1[B] -> Link [LNKF] -> GSI 11 (level, low)
> -> IRQ 11
> 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 2
> uhci_hcd 0000:00:1d.1: irq 11, io base 0x0000bf60
> usb usb2: configuration #1 chosen from 1 choice
> hub 2-0:1.0: USB hub found
> hub 2-0:1.0: 2 ports detected
> 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.24-kas-alt1 uhci_hcd
> usb usb2: SerialNumber: 0000:00:1d.1
> ACPI: PCI Interrupt 0000:00:1d.2[C] -> Link [LNKG] -> GSI 9 (level, low)
> -> IRQ 9
> 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 3
> uhci_hcd 0000:00:1d.2: irq 9, io base 0x0000bf40
> usb usb3: configuration #1 chosen from 1 choice
> hub 3-0:1.0: USB hub found
> hub 3-0:1.0: 2 ports detected
> 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.24-kas-alt1 uhci_hcd
> usb usb3: SerialNumber: 0000:00:1d.2
> ACPI: PCI Interrupt 0000:00:1d.3[D] -> Link [LNKH] -> GSI 7 (level, low)
> -> IRQ 7
> 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 4
> uhci_hcd 0000:00:1d.3: irq 7, io base 0x0000bf20
> usb usb4: configuration #1 chosen from 1 choice
> hub 4-0:1.0: USB hub found
> hub 4-0:1.0: 2 ports detected
> 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.24-kas-alt1 uhci_hcd
> usb usb4: SerialNumber: 0000:00:1d.3
> uhci_hcd 0000:00:1d.3: FGR not stopped yet!
>

I've had some strangenesses with USB lately. Sometimes running `lsusb'
makes the USB system notice a newly attached device.

Is that "FGR not stopped yet!" messgae new behaviour?

2007-11-21 22:25:53

by Andrew Morton

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1

On Wed, 21 Nov 2007 20:35:13 +0200
"Kirill A. Shutemov" <[email protected]> wrote:

> Symbol init_level4_pgt is needed by nvidia module. Is it really need to
> unexport it?

It's our clever way of reducing the tester base so we don't get so many
bug reports.

2007-11-21 22:42:00

by Andrew Morton

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1: I/O error, system hangs

On Wed, 21 Nov 2007 22:45:22 +0100
Laurent Riffard <[email protected]> wrote:

> Le 21.11.2007 05:45, Andrew Morton a ?crit :
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc3/2.6.24-rc3-mm1/
>
> Hello,
>
> My system hangs shortly after I logged in Gnome desktop. SysRq-W shows
> that a bunch of task are blocked in "D" state, they seem to wait for
> some I/O completion. I can try to hand-copy some data if requested.
>
> I found these messages in dmesg:
>
> ~$ grep -C2 end_request dmesg-2.6.24-rc3-mm1
> EXT3-fs: mounted filesystem with ordered data mode.
> sd 0:0:0:0: [sda] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK,SUGGEST_OK
> end_request: I/O error, dev sda, sector 16460
> ReiserFS: sda7: found reiserfs format "3.6" with standard journal
> ReiserFS: sda7: using ordered data mode
> --
> ReiserFS: sda7: Using r5 hash to sort names
> sd 0:0:1:0: [sdb] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK,SUGGEST_OK
> end_request: I/O error, dev sdb, sector 19632
> sd 0:0:1:0: [sdb] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK,SUGGEST_OK
> end_request: I/O error, dev sdb, sector 40037363
> Adding 1048568k swap on /dev/mapper/vglinux1-lvswap. Priority:-1 extents:1 across:1048568k
> lp0: using parport0 (interrupt-driven).
>
> These errors occur *only* with 2.6.24-rc3-mm1, they are 100% reproducible.
> 2.6.24-rc3 and 2.6.24-rc2-mm1 are fine.
>
> Maybe something is broken in pata_via driver ?
>

Could be - libata-reimplement-ata_acpi_cbl_80wire-using-ata_acpi_gtm_xfermask.patch
and pata_amd-pata_via-de-couple-programming-of-pio-mwdma-and-udma-timings.patch
touch pata_via.c.

2007-11-21 22:53:17

by Stephen Rothwell

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1- powerpc link failure

On Wed, 21 Nov 2007 13:36:30 +0530 Kamalesh Babulal <[email protected]> wrote:
>
> The kernel build fails on powerpc while linking,

Only for allyesconfig (or maybe some other config that builds a lot of
stuff in.

> AS .tmp_kallsyms3.o
> LD vmlinux.o
> ld: TOC section size exceeds 64k
> make: *** [vmlinux.o] Error 1
>
> The patch posted at http://lkml.org/lkml/2007/11/13/414, solves this
> failure.

However, that patch needs more testing especially to figure out what
performance effects it has. i.e. not for merging, yet.

--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/


Attachments:
(No filename) (659.00 B)
(No filename) (189.00 B)
Download all attachments

2007-11-22 03:04:18

by Kamezawa Hiroyuki

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1 (sync is slow ?)

On Wed, 21 Nov 2007 00:49:09 -0800
Andrew Morton <[email protected]> wrote:

> On Wed, 21 Nov 2007 17:42:15 +0900 KAMEZAWA Hiroyuki <[email protected]> wrote:
>
> > Hi, Andrew
> >
> > I got following result in 'sync' command.
> > It was too slow. (memory controller config is off ;)
> > I attaches my .config.
> > ==
> > [2.6.24-rc3-mm1]
> > [kamezawa@dr-test2 ~]$ dd if=/dev/zero of=./tmpfile bs=4096 count=100000
> > 100000+0 records in
> > 100000+0 records out
> > 409600000 bytes (410 MB) copied, 1.46706 seconds, 279 MB/s
> > [kamezawa@dr-test2 ~]$ time sync
> >
> > real 3m6.440s
> > user 0m0.000s
> > sys 0m0.133s

> Well I wonder how we did that.
>
> It seems OK here from a quick test (i386, ext3-on-IDE).
>
> Maybe device driver/block breakage?
>

I confirmed This slowdown is caused by git-scsi-misc.patch.
I'm sorry that I can't chase more and will be offline in this weekend.

This is scsi_mod information in /proc/modules
=
scsi_mod 409416 8 mptctl,sg,lpfc,scsi_transport_fc,mptspi,mptscsih,scsi_transport_spi,sd_mod, Live 0xa000000202818000
=

What information should I provide more ?

Thanks,
-Kame


2007-11-22 10:03:26

by Kirill A. Shutemov

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1 - Kernel Panic on IO-APIC

On [Wed, 21.11.2007 20:33], Torsten Kaiser wrote:
> On Nov 21, 2007 10:29 AM, Andrew Morton <[email protected]> wrote:
> > On Wed, 21 Nov 2007 14:52:26 +0530 Kamalesh Babulal <[email protected]> wrote:
> >
> > > Andrew Morton wrote:
> > > > On Wed, 21 Nov 2007 11:41:23 +0530 Kamalesh Babulal <[email protected]> wrote:
> > > >> ACPI: Core revision 20070126
> > > >> ..MP-BIOS bug: 8254 timer not connected to IO-APIC
> > > >> Kernel panic - not syncing: IO-APIC + timer doesn't work! Try using the 'noapic' kernel parameter
>
> I seen an identical error.

This bug is also reproducible with qemu.

--
Regards, Kirill A. Shutemov
+ Belarus, Minsk
+ Velesys LLC, http://www.velesys.com/
+ ALT Linux Team, http://www.altlinux.com/


Attachments:
(No filename) (763.00 B)
signature.asc (189.00 B)
Digital signature
Download all attachments

2007-11-22 10:16:51

by Kirill A. Shutemov

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1: usb mouse doesn't work

On [Wed, 21.11.2007 14:22], Andrew Morton wrote:
> On Wed, 21 Nov 2007 20:23:46 +0200
> "Kirill A. Shutemov" <[email protected]> wrote:
>
> > USB mouse(Logitech M-BT58) doesn't work. TouchPad works.
> > dmesg after rmmod usbcore && modprobe uhci_hcd:
> >
> > usbcore: registered new interface driver usbfs
> > usbcore: registered new interface driver hub
> > usbcore: registered new device driver usb
> > USB Universal Host Controller Interface driver v3.0
> > ACPI: PCI Interrupt 0000:00:1d.0[A] -> Link [LNKE] -> GSI 10 (level, low)
> > -> IRQ 10
> > 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 1
> > uhci_hcd 0000:00:1d.0: irq 10, io base 0x0000bf80
> > usb usb1: configuration #1 chosen from 1 choice
> > hub 1-0:1.0: USB hub found
> > hub 1-0:1.0: 2 ports detected
> > usb usb1: new device found, idVendor=0000, idProduct=0000
> > usb usb1: new device strings: Mfr=3, Product=2, SerialNumber=1
> > usb usb1: Product: UHCI Host Controller
> > usb usb1: Manufacturer: Linux 2.6.24-kas-alt1 uhci_hcd
> > usb usb1: SerialNumber: 0000:00:1d.0
> > ACPI: PCI Interrupt 0000:00:1d.1[B] -> Link [LNKF] -> GSI 11 (level, low)
> > -> IRQ 11
> > 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 2
> > uhci_hcd 0000:00:1d.1: irq 11, io base 0x0000bf60
> > usb usb2: configuration #1 chosen from 1 choice
> > hub 2-0:1.0: USB hub found
> > hub 2-0:1.0: 2 ports detected
> > 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.24-kas-alt1 uhci_hcd
> > usb usb2: SerialNumber: 0000:00:1d.1
> > ACPI: PCI Interrupt 0000:00:1d.2[C] -> Link [LNKG] -> GSI 9 (level, low)
> > -> IRQ 9
> > 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 3
> > uhci_hcd 0000:00:1d.2: irq 9, io base 0x0000bf40
> > usb usb3: configuration #1 chosen from 1 choice
> > hub 3-0:1.0: USB hub found
> > hub 3-0:1.0: 2 ports detected
> > 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.24-kas-alt1 uhci_hcd
> > usb usb3: SerialNumber: 0000:00:1d.2
> > ACPI: PCI Interrupt 0000:00:1d.3[D] -> Link [LNKH] -> GSI 7 (level, low)
> > -> IRQ 7
> > 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 4
> > uhci_hcd 0000:00:1d.3: irq 7, io base 0x0000bf20
> > usb usb4: configuration #1 chosen from 1 choice
> > hub 4-0:1.0: USB hub found
> > hub 4-0:1.0: 2 ports detected
> > 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.24-kas-alt1 uhci_hcd
> > usb usb4: SerialNumber: 0000:00:1d.3
> > uhci_hcd 0000:00:1d.3: FGR not stopped yet!
> >
>
> I've had some strangenesses with USB lately. Sometimes running `lsusb'
> makes the USB system notice a newly attached device.

No. But I have new messages in dmesg:

uhci_hcd 0000:00:1d.3: FGR not stopped yet!
uhci_hcd 0000:00:1d.2: FGR not stopped yet!
uhci_hcd 0000:00:1d.1: FGR not stopped yet!
uhci_hcd 0000:00:1d.0: FGR not stopped yet!


> Is that "FGR not stopped yet!" messgae new behaviour?

It is a new message since 2.6.24-rc3. I have never try -mm tree before.

--
Regards, Kirill A. Shutemov
+ Belarus, Minsk
+ Velesys LLC, http://www.velesys.com/
+ ALT Linux Team, http://www.altlinux.com/


Attachments:
(No filename) (3.90 kB)
signature.asc (189.00 B)
Digital signature
Download all attachments

2007-11-22 10:21:11

by Kirill A. Shutemov

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1

On x86_64 'uname -m' return 'x86'. It break many userspace programs. apt
and rpm for example.

--
Regards, Kirill A. Shutemov
+ Belarus, Minsk
+ Velesys LLC, http://www.velesys.com/
+ ALT Linux Team, http://www.altlinux.com/


Attachments:
(No filename) (231.00 B)
signature.asc (189.00 B)
Digital signature
Download all attachments

2007-11-22 17:07:16

by Alan Stern

[permalink] [raw]
Subject: Re: [linux-usb-devel] 2.6.24-rc3-mm1: usb mouse doesn't work

On Thu, 22 Nov 2007, Kirill A. Shutemov wrote:

> > > uhci_hcd 0000:00:1d.3: UHCI Host Controller
> > > uhci_hcd 0000:00:1d.3: new USB bus registered, assigned bus number 4
> > > uhci_hcd 0000:00:1d.3: irq 7, io base 0x0000bf20
> > > usb usb4: configuration #1 chosen from 1 choice
> > > hub 4-0:1.0: USB hub found
> > > hub 4-0:1.0: 2 ports detected
> > > 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.24-kas-alt1 uhci_hcd
> > > usb usb4: SerialNumber: 0000:00:1d.3
> > > uhci_hcd 0000:00:1d.3: FGR not stopped yet!
> > >
> >
> > I've had some strangenesses with USB lately. Sometimes running `lsusb'
> > makes the USB system notice a newly attached device.
>
> No. But I have new messages in dmesg:
>
> uhci_hcd 0000:00:1d.3: FGR not stopped yet!
> uhci_hcd 0000:00:1d.2: FGR not stopped yet!
> uhci_hcd 0000:00:1d.1: FGR not stopped yet!
> uhci_hcd 0000:00:1d.0: FGR not stopped yet!
>
>
> > Is that "FGR not stopped yet!" messgae new behaviour?
>
> It is a new message since 2.6.24-rc3. I have never try -mm tree before.

These messages could indicate a timing problem. You can see the code
that writes the messages near the end of wakeup_rh() in
drivers/usb/host/uhci-hcd.c.

The message gets written if the controller hardware hasn't turned off a
particular bit after a 4-us delay. If the udelay() function wasn't
working right, it could cause this problem.

Alan Stern

2007-11-22 18:40:55

by Marin Mitov

[permalink] [raw]
Subject: Re: [linux-usb-devel] 2.6.24-rc3-mm1: usb mouse doesn't work

On Thursday 22 November 2007 07:07:00 pm you wrote:
> On Thu, 22 Nov 2007, Kirill A. Shutemov wrote:
> > > > uhci_hcd 0000:00:1d.3: UHCI Host Controller
> > > > uhci_hcd 0000:00:1d.3: new USB bus registered, assigned bus number 4
> > > > uhci_hcd 0000:00:1d.3: irq 7, io base 0x0000bf20
> > > > usb usb4: configuration #1 chosen from 1 choice
> > > > hub 4-0:1.0: USB hub found
> > > > hub 4-0:1.0: 2 ports detected
> > > > 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.24-kas-alt1 uhci_hcd
> > > > usb usb4: SerialNumber: 0000:00:1d.3
> > > > uhci_hcd 0000:00:1d.3: FGR not stopped yet!
> > >
> > > I've had some strangenesses with USB lately. Sometimes running `lsusb'
> > > makes the USB system notice a newly attached device.
> >
> > No. But I have new messages in dmesg:
> >
> > uhci_hcd 0000:00:1d.3: FGR not stopped yet!
> > uhci_hcd 0000:00:1d.2: FGR not stopped yet!
> > uhci_hcd 0000:00:1d.1: FGR not stopped yet!
> > uhci_hcd 0000:00:1d.0: FGR not stopped yet!
> >
> > > Is that "FGR not stopped yet!" messgae new behaviour?
> >
> > It is a new message since 2.6.24-rc3. I have never try -mm tree before.
>
> These messages could indicate a timing problem. You can see the code
> that writes the messages near the end of wakeup_rh() in
> drivers/usb/host/uhci-hcd.c.
>
> The message gets written if the controller hardware hasn't turned off a
> particular bit after a 4-us delay. If the udelay() function wasn't
> working right, it could cause this problem.

udelay() _is_ OK for 2.6.24-rc3, so it is not the cause of the problem

Marin Mitov
>
> Alan Stern
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/


2007-11-23 00:19:37

by Andrew Morton

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1

On Thu, 22 Nov 2007 12:22:05 +0200 "Kirill A. Shutemov" <[email protected]> wrote:

> On x86_64 'uname -m' return 'x86'. It break many userspace programs. apt
> and rpm for example.
>

Yes, there have been various discussions about this. I think Sam is cooking up
a fix?

2007-11-23 00:49:36

by Thomas Gleixner

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1

On Thu, 22 Nov 2007, Andrew Morton wrote:

> On Thu, 22 Nov 2007 12:22:05 +0200 "Kirill A. Shutemov" <[email protected]> wrote:
>
> > On x86_64 'uname -m' return 'x86'. It break many userspace programs. apt
> > and rpm for example.
> >
>
> Yes, there have been various discussions about this. I think Sam is cooking up
> a fix?

http://lkml.org/lkml/2007/11/19/323

I push it Linus wards ASAP.

Thanks,

tglx

2007-11-23 01:39:24

by Gabriel C

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1

I have some warnings on each SCSI disc:


...

[ 30.724410] scsi 0:0:0:0: Direct-Access SEAGATE ST318406LW 0109 PQ: 0 ANSI: 3
[ 30.724419] scsi0:A:0:0: Tagged Queuing enabled. Depth 32
[ 30.724435] target0:0:0: Beginning Domain Validation
[ 30.724446] target0:0:0: Domain Validation Initial Inquiry Failed <--
[ 30.724572] target0:0:0: Ending Domain Validation
[ 30.729747] scsi 0:0:1:0: Direct-Access FUJITSU MAH3182MP 0114 PQ: 0 ANSI: 4
[ 30.729754] scsi0:A:1:0: Tagged Queuing enabled. Depth 32
[ 30.729771] target0:0:1: Beginning Domain Validation
[ 30.729780] target0:0:1: Domain Validation Initial Inquiry Failed <--
[ 30.729908] target0:0:1: Ending Domain Validation

...

no idea whatever this is related but buffered disk reads are 2.XX MB/sec and the box is somewhat laggy.

hdparm -t on sda and sdb reports :

/dev/sda:
Timing buffered disk reads: 8 MB in 3.26 seconds = 2.46 MB/sec

/dev/sdb:
Timing buffered disk reads: 8 MB in 3.56 seconds = 2.25 MB/sec

My IDE discs are fine.

Please let me know if you need my config or any other informations.


Gabriel

2007-11-23 02:51:40

by Alan Stern

[permalink] [raw]
Subject: Re: [linux-usb-devel] 2.6.24-rc3-mm1: usb mouse doesn't work

On Thu, 22 Nov 2007, Marin Mitov wrote:

> > > > I've had some strangenesses with USB lately. Sometimes running `lsusb'
> > > > makes the USB system notice a newly attached device.
> > >
> > > No. But I have new messages in dmesg:
> > >
> > > uhci_hcd 0000:00:1d.3: FGR not stopped yet!
> > > uhci_hcd 0000:00:1d.2: FGR not stopped yet!
> > > uhci_hcd 0000:00:1d.1: FGR not stopped yet!
> > > uhci_hcd 0000:00:1d.0: FGR not stopped yet!
> > >
> > > > Is that "FGR not stopped yet!" messgae new behaviour?
> > >
> > > It is a new message since 2.6.24-rc3. I have never try -mm tree before.
> >
> > These messages could indicate a timing problem. You can see the code
> > that writes the messages near the end of wakeup_rh() in
> > drivers/usb/host/uhci-hcd.c.
> >
> > The message gets written if the controller hardware hasn't turned off a
> > particular bit after a 4-us delay. If the udelay() function wasn't
> > working right, it could cause this problem.
>
> udelay() _is_ OK for 2.6.24-rc3, so it is not the cause of the problem

But is it OK for 2.6.24-rc3-mm1? Kirill said specifically that
2.6.24-rc3 does not display the message but 2.6.24-rc3-mm1 does.

Alan Stern

2007-11-23 04:13:21

by Andrew Morton

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1

On Fri, 23 Nov 2007 02:39:08 +0100 Gabriel C <[email protected]> wrote:

> I have some warnings on each SCSI disc:
>
>
> ...
>
> [ 30.724410] scsi 0:0:0:0: Direct-Access SEAGATE ST318406LW 0109 PQ: 0 ANSI: 3
> [ 30.724419] scsi0:A:0:0: Tagged Queuing enabled. Depth 32
> [ 30.724435] target0:0:0: Beginning Domain Validation
> [ 30.724446] target0:0:0: Domain Validation Initial Inquiry Failed <--
> [ 30.724572] target0:0:0: Ending Domain Validation
> [ 30.729747] scsi 0:0:1:0: Direct-Access FUJITSU MAH3182MP 0114 PQ: 0 ANSI: 4
> [ 30.729754] scsi0:A:1:0: Tagged Queuing enabled. Depth 32
> [ 30.729771] target0:0:1: Beginning Domain Validation
> [ 30.729780] target0:0:1: Domain Validation Initial Inquiry Failed <--
> [ 30.729908] target0:0:1: Ending Domain Validation
>

Don't know what would have caused that. But yes, something is wrong in
scsi land.

>
> no idea whatever this is related but buffered disk reads are 2.XX MB/sec and the box is somewhat laggy.
>
> hdparm -t on sda and sdb reports :
>
> /dev/sda:
> Timing buffered disk reads: 8 MB in 3.26 seconds = 2.46 MB/sec
>
> /dev/sdb:
> Timing buffered disk reads: 8 MB in 3.56 seconds = 2.25 MB/sec
>
> My IDE discs are fine.
>
> Please let me know if you need my config or any other informations.
>

And you're the second to report very slow scsi throughput in 2.6.24-rc3-mm1.

2007-11-23 05:19:23

by Kirill A. Shutemov

[permalink] [raw]
Subject: Re: [linux-usb-devel] 2.6.24-rc3-mm1: usb mouse doesn't work

On [Thu, 22.11.2007 21:51], Alan Stern wrote:
> On Thu, 22 Nov 2007, Marin Mitov wrote:
>
> > > > > I've had some strangenesses with USB lately. Sometimes running `lsusb'
> > > > > makes the USB system notice a newly attached device.
> > > >
> > > > No. But I have new messages in dmesg:
> > > >
> > > > uhci_hcd 0000:00:1d.3: FGR not stopped yet!
> > > > uhci_hcd 0000:00:1d.2: FGR not stopped yet!
> > > > uhci_hcd 0000:00:1d.1: FGR not stopped yet!
> > > > uhci_hcd 0000:00:1d.0: FGR not stopped yet!
> > > >
> > > > > Is that "FGR not stopped yet!" messgae new behaviour?
> > > >
> > > > It is a new message since 2.6.24-rc3. I have never try -mm tree before.
> > >
> > > These messages could indicate a timing problem. You can see the code
> > > that writes the messages near the end of wakeup_rh() in
> > > drivers/usb/host/uhci-hcd.c.
> > >
> > > The message gets written if the controller hardware hasn't turned off a
> > > particular bit after a 4-us delay. If the udelay() function wasn't
> > > working right, it could cause this problem.
> >
> > udelay() _is_ OK for 2.6.24-rc3, so it is not the cause of the problem
>
> But is it OK for 2.6.24-rc3-mm1? Kirill said specifically that
> 2.6.24-rc3 does not display the message but 2.6.24-rc3-mm1 does.

How can I test it?

--
Regards, Kirill A. Shutemov
+ Belarus, Minsk
+ Velesys LLC, http://www.velesys.com/
+ ALT Linux Team, http://www.altlinux.com/


Attachments:
(No filename) (1.39 kB)
signature.asc (189.00 B)
Digital signature
Download all attachments

2007-11-23 05:55:59

by Gabriel C

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1

Andrew Morton wrote:
> On Fri, 23 Nov 2007 02:39:08 +0100 Gabriel C <[email protected]> wrote:
>
>> I have some warnings on each SCSI disc:
>>
>>
>> ...
>>
>> [ 30.724410] scsi 0:0:0:0: Direct-Access SEAGATE ST318406LW 0109 PQ: 0 ANSI: 3
>> [ 30.724419] scsi0:A:0:0: Tagged Queuing enabled. Depth 32
>> [ 30.724435] target0:0:0: Beginning Domain Validation
>> [ 30.724446] target0:0:0: Domain Validation Initial Inquiry Failed <--
>> [ 30.724572] target0:0:0: Ending Domain Validation
>> [ 30.729747] scsi 0:0:1:0: Direct-Access FUJITSU MAH3182MP 0114 PQ: 0 ANSI: 4
>> [ 30.729754] scsi0:A:1:0: Tagged Queuing enabled. Depth 32
>> [ 30.729771] target0:0:1: Beginning Domain Validation
>> [ 30.729780] target0:0:1: Domain Validation Initial Inquiry Failed <--
>> [ 30.729908] target0:0:1: Ending Domain Validation
>>
>
> Don't know what would have caused that. But yes, something is wrong in
> scsi land.

Actually I'm lucky the author didn't fix that FIXME in scsi_transport_spi.c and I still can boot ;)

>
>> no idea whatever this is related but buffered disk reads are 2.XX MB/sec and the box is somewhat laggy.
>>
>> hdparm -t on sda and sdb reports :
>>
>> /dev/sda:
>> Timing buffered disk reads: 8 MB in 3.26 seconds = 2.46 MB/sec
>>
>> /dev/sdb:
>> Timing buffered disk reads: 8 MB in 3.56 seconds = 2.25 MB/sec
>>
>> My IDE discs are fine.
>>
>> Please let me know if you need my config or any other informations.
>>
>
> And you're the second to report very slow scsi throughput in 2.6.24-rc3-mm1.
>

I found the commit which cause these problems , it is in git-scsi-misc patch and reverting it fixes both problems for me.

http://git.kernel.org/?p=linux/kernel/git/jejb/scsi-misc-2.6.git;a=commitdiff_plain;h=8655a546c83fc43f0a73416bbd126d02de7ad6c0;hp=5bc717b6bdaaf52edf365eb7d9d8c89fec79df5d


2007-11-23 06:05:17

by Kirill A. Shutemov

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1

On [Fri, 23.11.2007 01:48], Thomas Gleixner wrote:
> On Thu, 22 Nov 2007, Andrew Morton wrote:
>
> > On Thu, 22 Nov 2007 12:22:05 +0200 "Kirill A. Shutemov" <[email protected]> wrote:
> >
> > > On x86_64 'uname -m' return 'x86'. It break many userspace programs. apt
> > > and rpm for example.
> > >
> >
> > Yes, there have been various discussions about this. I think Sam is cooking up
> > a fix?
>
> http://lkml.org/lkml/2007/11/19/323
>
> I push it Linus wards ASAP.
diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index 116b03a..7aa1dc6 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -11,10 +11,9 @@ endif
$(srctree)/arch/x86/Makefile%: ;

ifeq ($(CONFIG_X86_32),y)
+ UTS_MACHINE := i386
include $(srctree)/arch/x86/Makefile_32
else
+ UTS_MACHINE := x86_64
include $(srctree)/arch/x86/Makefile_64
endif

Many programs expect i686 on Pentium II.

--
Regards, Kirill A. Shutemov
+ Belarus, Minsk
+ Velesys LLC, http://www.velesys.com/
+ ALT Linux Team, http://www.altlinux.com/


Attachments:
(No filename) (1.02 kB)
signature.asc (189.00 B)
Digital signature
Download all attachments

2007-11-23 07:32:29

by Laurent Riffard

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1: I/O error, system hangs


Le 21.11.2007 23:41, Andrew Morton a ?crit :
> On Wed, 21 Nov 2007 22:45:22 +0100
> Laurent Riffard <[email protected]> wrote:
>
>> Le 21.11.2007 05:45, Andrew Morton a ?crit :
>>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc3/2.6.24-rc3-mm1/
>> Hello,
>>
>> My system hangs shortly after I logged in Gnome desktop. SysRq-W shows
>> that a bunch of task are blocked in "D" state, they seem to wait for
>> some I/O completion. I can try to hand-copy some data if requested.
>>
>> I found these messages in dmesg:
>>
>> ~$ grep -C2 end_request dmesg-2.6.24-rc3-mm1
>> EXT3-fs: mounted filesystem with ordered data mode.
>> sd 0:0:0:0: [sda] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK,SUGGEST_OK
>> end_request: I/O error, dev sda, sector 16460
>> ReiserFS: sda7: found reiserfs format "3.6" with standard journal
>> ReiserFS: sda7: using ordered data mode
>> --
>> ReiserFS: sda7: Using r5 hash to sort names
>> sd 0:0:1:0: [sdb] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK,SUGGEST_OK
>> end_request: I/O error, dev sdb, sector 19632
>> sd 0:0:1:0: [sdb] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK,SUGGEST_OK
>> end_request: I/O error, dev sdb, sector 40037363
>> Adding 1048568k swap on /dev/mapper/vglinux1-lvswap. Priority:-1 extents:1 across:1048568k
>> lp0: using parport0 (interrupt-driven).
>>
>> These errors occur *only* with 2.6.24-rc3-mm1, they are 100% reproducible.
>> 2.6.24-rc3 and 2.6.24-rc2-mm1 are fine.
>>
>> Maybe something is broken in pata_via driver ?
>>
>
> Could be - libata-reimplement-ata_acpi_cbl_80wire-using-ata_acpi_gtm_xfermask.patch
> and pata_amd-pata_via-de-couple-programming-of-pio-mwdma-and-udma-timings.patch
> touch pata_via.c.

None of the above...

I did a bisection, it spotted git-scsi-misc.patch.
I just run 2.6.24-rc3-mm1 + revert-git-scsi-misc.patch, and it works fine.

I guess commit 8655a546c83fc43f0a73416bbd126d02de7ad6c0 "[SCSI] Do not
requeue requests if REQ_FAILFAST is set" is the real culprit. The other
commits are touching documentation or drivers I don't use. I'll try
to revert only this one this evening.

--
laurent


2007-11-23 07:51:21

by Hannes Reinecke

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1: I/O error, system hangs

Laurent Riffard wrote:
> Le 21.11.2007 23:41, Andrew Morton a ?crit :
>> On Wed, 21 Nov 2007 22:45:22 +0100
>> Laurent Riffard <[email protected]> wrote:
>>
>>> Le 21.11.2007 05:45, Andrew Morton a ?crit :
>>>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc3/2.6.24-rc3-mm1/
>>> Hello,
>>>
>>> My system hangs shortly after I logged in Gnome desktop. SysRq-W shows
>>> that a bunch of task are blocked in "D" state, they seem to wait for
>>> some I/O completion. I can try to hand-copy some data if requested.
>>>
>>> I found these messages in dmesg:
>>>
>>> ~$ grep -C2 end_request dmesg-2.6.24-rc3-mm1
>>> EXT3-fs: mounted filesystem with ordered data mode.
>>> sd 0:0:0:0: [sda] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK,SUGGEST_OK
>>> end_request: I/O error, dev sda, sector 16460
>>> ReiserFS: sda7: found reiserfs format "3.6" with standard journal
>>> ReiserFS: sda7: using ordered data mode
>>> --
>>> ReiserFS: sda7: Using r5 hash to sort names
>>> sd 0:0:1:0: [sdb] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK,SUGGEST_OK
>>> end_request: I/O error, dev sdb, sector 19632
>>> sd 0:0:1:0: [sdb] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK,SUGGEST_OK
>>> end_request: I/O error, dev sdb, sector 40037363
>>> Adding 1048568k swap on /dev/mapper/vglinux1-lvswap. Priority:-1 extents:1 across:1048568k
>>> lp0: using parport0 (interrupt-driven).
>>>
>>> These errors occur *only* with 2.6.24-rc3-mm1, they are 100% reproducible.
>>> 2.6.24-rc3 and 2.6.24-rc2-mm1 are fine.
>>>
>>> Maybe something is broken in pata_via driver ?
>>>
>> Could be - libata-reimplement-ata_acpi_cbl_80wire-using-ata_acpi_gtm_xfermask.patch
>> and pata_amd-pata_via-de-couple-programming-of-pio-mwdma-and-udma-timings.patch
>> touch pata_via.c.
>
> None of the above...
>
> I did a bisection, it spotted git-scsi-misc.patch.
> I just run 2.6.24-rc3-mm1 + revert-git-scsi-misc.patch, and it works fine.
>
> I guess commit 8655a546c83fc43f0a73416bbd126d02de7ad6c0 "[SCSI] Do not
> requeue requests if REQ_FAILFAST is set" is the real culprit. The other
> commits are touching documentation or drivers I don't use. I'll try
> to revert only this one this evening.
>
Hmm. Weird. I'll have a look into it. Apparently I'll be returning an error where
I shouldn't. Checking ...

Cheers,

Hannes
--
Dr. Hannes Reinecke zSeries & Storage
[email protected] +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N?rnberg
GF: Markus Rex, HRB 16746 (AG N?rnberg)

2007-11-23 08:59:56

by Andreas Herrmann

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1

On Fri, Nov 23, 2007 at 08:05:44AM +0200, Kirill A. Shutemov wrote:
> On [Fri, 23.11.2007 01:48], Thomas Gleixner wrote:
> > On Thu, 22 Nov 2007, Andrew Morton wrote:
> >
> > > On Thu, 22 Nov 2007 12:22:05 +0200 "Kirill A. Shutemov" <[email protected]> wrote:
> > >
> > > > On x86_64 'uname -m' return 'x86'. It break many userspace programs. apt
> > > > and rpm for example.
> > > >
> > >
> > > Yes, there have been various discussions about this. I think Sam is cooking up
> > > a fix?
> >
> > http://lkml.org/lkml/2007/11/19/323
> >
> > I push it Linus wards ASAP.
> diff --git a/arch/x86/Makefile b/arch/x86/Makefile
> index 116b03a..7aa1dc6 100644
> --- a/arch/x86/Makefile
> +++ b/arch/x86/Makefile
> @@ -11,10 +11,9 @@ endif
> $(srctree)/arch/x86/Makefile%: ;
>
> ifeq ($(CONFIG_X86_32),y)
> + UTS_MACHINE := i386
> include $(srctree)/arch/x86/Makefile_32
> else
> + UTS_MACHINE := x86_64
> include $(srctree)/arch/x86/Makefile_64
> endif
>
> Many programs expect i686 on Pentium II.


Yes, but this is done during boot.
Then the kernel overwrites "i386" to become "i686" for such CPUs.
That is why I've seen "x66" after boot when UTS_MACHINE at build-time
was "x86" with 'make ARCH=x86'.
For more details see:

http://marc.info/?l=linux-kernel&m=119521309415545&w=2


Regards,

Andreas

2007-11-23 11:38:22

by Hannes Reinecke

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1: I/O error, system hangs

Fix SPI Domain validation

This fixes a thinko of the FAILFAST handling: when we get
a request with FAILFAST set, we still have to evaluate the
PREEMPT flag to decide if this request should be passed through.

Signed-off-by: Hannes Reinecke <[email protected]>

diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 13e7e09..9ec1566 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -1284,13 +1284,15 @@ int scsi_prep_state_check(struct scsi_device *sdev, struct request *req)
/*
* If the devices is blocked we defer normal commands.
*/
- if (!(req->cmd_flags & REQ_PREEMPT))
- ret = BLKPREP_DEFER;
- /*
- * Return failfast requests immediately
- */
- if (req->cmd_flags & REQ_FAILFAST)
- ret = BLKPREP_KILL;
+ if (!(req->cmd_flags & REQ_PREEMPT)) {
+ /*
+ * Return failfast requests immediately
+ */
+ if (req->cmd_flags & REQ_FAILFAST)
+ ret = BLKPREP_KILL;
+ else
+ ret = BLKPREP_DEFER;
+ }
break;
default:
/*


Attachments:
scsi-misc-fix-spi-validation (0.99 kB)

2007-11-23 16:21:19

by Alan Stern

[permalink] [raw]
Subject: Re: [linux-usb-devel] 2.6.24-rc3-mm1: usb mouse doesn't work

On Fri, 23 Nov 2007, Kirill A. Shutemov wrote:

> On [Thu, 22.11.2007 21:51], Alan Stern wrote:
> > On Thu, 22 Nov 2007, Marin Mitov wrote:
> >
> > > > > > I've had some strangenesses with USB lately. Sometimes running `lsusb'
> > > > > > makes the USB system notice a newly attached device.
> > > > >
> > > > > No. But I have new messages in dmesg:
> > > > >
> > > > > uhci_hcd 0000:00:1d.3: FGR not stopped yet!
> > > > > uhci_hcd 0000:00:1d.2: FGR not stopped yet!
> > > > > uhci_hcd 0000:00:1d.1: FGR not stopped yet!
> > > > > uhci_hcd 0000:00:1d.0: FGR not stopped yet!
> > > > >
> > > > > > Is that "FGR not stopped yet!" messgae new behaviour?
> > > > >
> > > > > It is a new message since 2.6.24-rc3. I have never try -mm tree before.
> > > >
> > > > These messages could indicate a timing problem. You can see the code
> > > > that writes the messages near the end of wakeup_rh() in
> > > > drivers/usb/host/uhci-hcd.c.
> > > >
> > > > The message gets written if the controller hardware hasn't turned off a
> > > > particular bit after a 4-us delay. If the udelay() function wasn't
> > > > working right, it could cause this problem.
> > >
> > > udelay() _is_ OK for 2.6.24-rc3, so it is not the cause of the problem
> >
> > But is it OK for 2.6.24-rc3-mm1? Kirill said specifically that
> > 2.6.24-rc3 does not display the message but 2.6.24-rc3-mm1 does.
>
> How can I test it?

Add some printk statements to the wakeup_rh() routine: Display the
value of inw(uhci->io_addr + USBCMD) in hex, both before and after the
udelay(4) line. Try doing this for both 2.6.24-rc3 and 2.6.24-rc3-mm1
so you can compare the values for the two different kernels.

Also, enable CONFIG_PRINTK_TIME.

Alan Stern

2007-11-23 17:52:43

by Laurent Riffard

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1: I/O error, system hangs

Le 23.11.2007 12:38, Hannes Reinecke a ?crit :
> Hannes Reinecke wrote:
>> Laurent Riffard wrote:
>>> Le 21.11.2007 23:41, Andrew Morton a ?crit :
>>>> On Wed, 21 Nov 2007 22:45:22 +0100
>>>> Laurent Riffard <[email protected]> wrote:
>>>>
>>>>> Le 21.11.2007 05:45, Andrew Morton a ?crit :
>>>>>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc3/2.6.24-rc3-mm1/
>>>>> Hello,
>>>>>
>>>>> My system hangs shortly after I logged in Gnome desktop. SysRq-W shows
>>>>> that a bunch of task are blocked in "D" state, they seem to wait for
>>>>> some I/O completion. I can try to hand-copy some data if requested.
>>>>>
>>>>> I found these messages in dmesg:
>>>>>
>>>>> ~$ grep -C2 end_request dmesg-2.6.24-rc3-mm1
>>>>> EXT3-fs: mounted filesystem with ordered data mode.
>>>>> sd 0:0:0:0: [sda] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK,SUGGEST_OK
>>>>> end_request: I/O error, dev sda, sector 16460
>>>>> ReiserFS: sda7: found reiserfs format "3.6" with standard journal
>>>>> ReiserFS: sda7: using ordered data mode
>>>>> --
>>>>> ReiserFS: sda7: Using r5 hash to sort names
>>>>> sd 0:0:1:0: [sdb] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK,SUGGEST_OK
>>>>> end_request: I/O error, dev sdb, sector 19632
>>>>> sd 0:0:1:0: [sdb] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK,SUGGEST_OK
>>>>> end_request: I/O error, dev sdb, sector 40037363
>>>>> Adding 1048568k swap on /dev/mapper/vglinux1-lvswap. Priority:-1 extents:1 across:1048568k
>>>>> lp0: using parport0 (interrupt-driven).
>>>>>
>>>>> These errors occur *only* with 2.6.24-rc3-mm1, they are 100% reproducible.
>>>>> 2.6.24-rc3 and 2.6.24-rc2-mm1 are fine.
>>>>>
>>>>> Maybe something is broken in pata_via driver ?
>>>>>
>>>> Could be - libata-reimplement-ata_acpi_cbl_80wire-using-ata_acpi_gtm_xfermask.patch
>>>> and pata_amd-pata_via-de-couple-programming-of-pio-mwdma-and-udma-timings.patch
>>>> touch pata_via.c.
>>> None of the above...
>>>
>>> I did a bisection, it spotted git-scsi-misc.patch.
>>> I just run 2.6.24-rc3-mm1 + revert-git-scsi-misc.patch, and it works fine.
>>>
>>> I guess commit 8655a546c83fc43f0a73416bbd126d02de7ad6c0 "[SCSI] Do not
>>> requeue requests if REQ_FAILFAST is set" is the real culprit. The other
>>> commits are touching documentation or drivers I don't use. I'll try
>>> to revert only this one this evening.

I can confirm : reverting commit 8655a546c83fc43f0a73416bbd126d02de7ad6c0
does fix the problem.

>> Hmm. Weird. I'll have a look into it. Apparently I'll be returning an error where
>> I shouldn't. Checking ...
>>
> Ok, found it. We are blocking even special commands (ie requests with PREEMPT not set)
> when FAILFAST is set. Which is clearly wrong. The attached patch fixes this.

Sorry, it's not enough. 2.6.24-rc3-mm1 + your patch still hangs with I/O errors.

--
laurent

2007-11-24 00:49:33

by Alexey Dobriyan

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1 - Kernel Panic on IO-APIC

On Tue, Nov 20, 2007 at 10:18:39PM -0800, Andrew Morton wrote:
> On Wed, 21 Nov 2007 11:41:23 +0530 Kamalesh Babulal <[email protected]> wrote:
>
> > Hi Andrew,
> >
> > Kernel panic's across different architectures like powerpc, x86_64,
>
> powerpc complains about IO-APICs??
>
> > Dentry cache hash table entries: 8388608 (order: 14, 67108864 bytes)
> > Inode-cache hash table entries: 4194304 (order: 13, 33554432 bytes)
> > Mount-cache hash table entries: 256
> > SMP alternatives: switching to UP code
> > ACPI: Core revision 20070126

Hmm. same date here. It's Asus P5B-E motheboard

> > ..MP-BIOS bug: 8254 timer not connected to IO-APIC
> > Kernel panic - not syncing: IO-APIC + timer doesn't work! Try using the 'noapic' kernel parameter
>
> ACPI or x86 breakage, I guess.
>
> Did 'noapic' work?

No! The box freezes somewhere after "Freeing unused kernel memory"...

Bisection points to git-x86.patch, though.

git-bisect start
# good: [f05092637dc0d9a3f2249c9b283b973e6e96b7d2] Linux 2.6.24-rc3
git-bisect good f05092637dc0d9a3f2249c9b283b973e6e96b7d2
# bad: [46c8c396d2c87b786a7fac615c289f85a18e53ce] w1-build-fix
git-bisect bad 46c8c396d2c87b786a7fac615c289f85a18e53ce
# bad: [4e22f4852c48e1eddfe04299e78c0456164abe86] frv-move-dma-macros-to-scatterlisth-for-consistency
git-bisect bad 4e22f4852c48e1eddfe04299e78c0456164abe86
# bad: [4e22f4852c48e1eddfe04299e78c0456164abe86] frv-move-dma-macros-to-scatterlisth-for-consistency
git-bisect bad 4e22f4852c48e1eddfe04299e78c0456164abe86
# good: [d5135f31313af2be37d8ccb71e2a42f8e221d8c4] ide-mm-ide-disk-extend-timeout-for-pio-out-commands
git-bisect good d5135f31313af2be37d8ccb71e2a42f8e221d8c4
# good: [6be815e83f506f4c39a46cf59014e29a95c5e6c4] iommu-sg-merging-call-blk_queue_segment_boundary-in-__scsi_alloc_queue
git-bisect good 6be815e83f506f4c39a46cf59014e29a95c5e6c4
# good: [6be815e83f506f4c39a46cf59014e29a95c5e6c4] iommu-sg-merging-call-blk_queue_segment_boundary-in-__scsi_alloc_queue
git-bisect good 6be815e83f506f4c39a46cf59014e29a95c5e6c4
# bad: [c792db6d06114a85e33a27c89e9e979f11b951c4] slub-fix-coding-style-violations
git-bisect bad c792db6d06114a85e33a27c89e9e979f11b951c4
# bad: [c792db6d06114a85e33a27c89e9e979f11b951c4] slub-fix-coding-style-violations
git-bisect bad c792db6d06114a85e33a27c89e9e979f11b951c4
# bad: [76f3939b76ff557f73720b57a16716196f04e407] x86_64-make-sparsemem-vmemmap-the-default-memory-model-v2
git-bisect bad 76f3939b76ff557f73720b57a16716196f04e407
# good: [b8ba611566d8799a979b190d4bb14305ca64ee0e] sis-fb-driver-_ioctl32_conversion-functions-do-not-exist-in-recent-kernels
git-bisect good b8ba611566d8799a979b190d4bb14305ca64ee0e
# good: [e34995928859308d2abef1709332e2b12d36db2f] git-ipwireless_cs
git-bisect good e34995928859308d2abef1709332e2b12d36db2f
# bad: [f520abbbe11bc8253714bcd34aaaf19bdf82189e] git-x86-identify_cpu-fix
git-bisect bad f520abbbe11bc8253714bcd34aaaf19bdf82189e


I honestly tried fresh #mm from x86 tree -- the one which ends at commit
70be766db1105c0fc9aed8e954d0c343c1eda067 "x86: Add the RDC machine
specific reboot fixup". FWIW, commit "x86: validate against ACPI motherboard
resources" is innocent. After "x86: make stack size configurable" damn thing
wouldn't build and applying fixets from -mm doesn't help at 3AM.

Again, it's late here, I'll recheck today.

2007-11-24 06:43:12

by James Bottomley

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1: I/O error, system hangs


On Fri, 2007-11-23 at 18:52 +0100, Laurent Riffard wrote:
> Le 23.11.2007 12:38, Hannes Reinecke a écrit :
> > Hannes Reinecke wrote:
> >> Laurent Riffard wrote:
> >>> Le 21.11.2007 23:41, Andrew Morton a écrit :
> >>>> On Wed, 21 Nov 2007 22:45:22 +0100
> >>>> Laurent Riffard <[email protected]> wrote:
> >>>>
> >>>>> Le 21.11.2007 05:45, Andrew Morton a écrit :
> >>>>>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc3/2.6.24-rc3-mm1/
> >>>>> Hello,
> >>>>>
> >>>>> My system hangs shortly after I logged in Gnome desktop. SysRq-W shows
> >>>>> that a bunch of task are blocked in "D" state, they seem to wait for
> >>>>> some I/O completion. I can try to hand-copy some data if requested.
> >>>>>
> >>>>> I found these messages in dmesg:
> >>>>>
> >>>>> ~$ grep -C2 end_request dmesg-2.6.24-rc3-mm1
> >>>>> EXT3-fs: mounted filesystem with ordered data mode.
> >>>>> sd 0:0:0:0: [sda] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK,SUGGEST_OK
> >>>>> end_request: I/O error, dev sda, sector 16460
> >>>>> ReiserFS: sda7: found reiserfs format "3.6" with standard journal
> >>>>> ReiserFS: sda7: using ordered data mode
> >>>>> --
> >>>>> ReiserFS: sda7: Using r5 hash to sort names
> >>>>> sd 0:0:1:0: [sdb] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK,SUGGEST_OK
> >>>>> end_request: I/O error, dev sdb, sector 19632
> >>>>> sd 0:0:1:0: [sdb] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK,SUGGEST_OK
> >>>>> end_request: I/O error, dev sdb, sector 40037363
> >>>>> Adding 1048568k swap on /dev/mapper/vglinux1-lvswap. Priority:-1 extents:1 across:1048568k
> >>>>> lp0: using parport0 (interrupt-driven).
> >>>>>
> >>>>> These errors occur *only* with 2.6.24-rc3-mm1, they are 100% reproducible.
> >>>>> 2.6.24-rc3 and 2.6.24-rc2-mm1 are fine.
> >>>>>
> >>>>> Maybe something is broken in pata_via driver ?
> >>>>>
> >>>> Could be - libata-reimplement-ata_acpi_cbl_80wire-using-ata_acpi_gtm_xfermask.patch
> >>>> and pata_amd-pata_via-de-couple-programming-of-pio-mwdma-and-udma-timings.patch
> >>>> touch pata_via.c.
> >>> None of the above...
> >>>
> >>> I did a bisection, it spotted git-scsi-misc.patch.
> >>> I just run 2.6.24-rc3-mm1 + revert-git-scsi-misc.patch, and it works fine.
> >>>
> >>> I guess commit 8655a546c83fc43f0a73416bbd126d02de7ad6c0 "[SCSI] Do not
> >>> requeue requests if REQ_FAILFAST is set" is the real culprit. The other
> >>> commits are touching documentation or drivers I don't use. I'll try
> >>> to revert only this one this evening.
>
> I can confirm : reverting commit 8655a546c83fc43f0a73416bbd126d02de7ad6c0
> does fix the problem.
>
> >> Hmm. Weird. I'll have a look into it. Apparently I'll be returning an error where
> >> I shouldn't. Checking ...
> >>
> > Ok, found it. We are blocking even special commands (ie requests with PREEMPT not set)
> > when FAILFAST is set. Which is clearly wrong. The attached patch fixes this.
>
> Sorry, it's not enough. 2.6.24-rc3-mm1 + your patch still hangs with I/O errors.

I think the problem is the way we treat BLOCKED and QUIESCED (the latter
is the state that the domain validation uses and which we cannot kill
fastfail on). It's definitely wrong to kill fastfail requests when the
state is QUIESCE.

This patch (which is applied on top of Hannes original) separates the
BLOCK and QUIESCE states correctly ... does this fix the problem?

James

diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 13e7e09..a7cf23a 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -1279,18 +1279,21 @@ int scsi_prep_state_check(struct scsi_device *sdev, struct request *req)
"rejecting I/O to dead device\n");
ret = BLKPREP_KILL;
break;
- case SDEV_QUIESCE:
case SDEV_BLOCK:
/*
- * If the devices is blocked we defer normal commands.
- */
- if (!(req->cmd_flags & REQ_PREEMPT))
- ret = BLKPREP_DEFER;
- /*
* Return failfast requests immediately
*/
if (req->cmd_flags & REQ_FAILFAST)
ret = BLKPREP_KILL;
+
+ /* fall through */
+
+ case SDEV_QUIESCE:
+ /*
+ * If the devices is blocked we defer normal commands.
+ */
+ if (!(req->cmd_flags & REQ_PREEMPT))
+ ret = BLKPREP_DEFER;
break;
default:
/*


2007-11-24 12:04:24

by KOSAKI Motohiro

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1 (sync is slow ?)

Hi, Andrew

> > Hi, Andrew
> >
> > I got following result in 'sync' command.
> > It was too slow. (memory controller config is off ;)
> > I attaches my .config.
> > ==
(snip)
>
> Well I wonder how we did that.
>
> It seems OK here from a quick test (i386, ext3-on-IDE).
>
> Maybe device driver/block breakage?

I tested x86, ext3-on-SATA(/dev/sda).
It seems works well.

Hmm...


--
kosaki


2007-11-24 12:57:26

by Laurent Riffard

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1: I/O error, system hangs



Le 24.11.2007 07:42, James Bottomley a écrit :
> On Fri, 2007-11-23 at 18:52 +0100, Laurent Riffard wrote:
>> Le 23.11.2007 12:38, Hannes Reinecke a écrit :
>>> Hannes Reinecke wrote:
>>>> Laurent Riffard wrote:
>>>>> Le 21.11.2007 23:41, Andrew Morton a écrit :
>>>>>> On Wed, 21 Nov 2007 22:45:22 +0100
>>>>>> Laurent Riffard <[email protected]> wrote:
>>>>>>
>>>>>>> Le 21.11.2007 05:45, Andrew Morton a écrit :
>>>>>>>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc3/2.6.24-rc3-mm1/
>>>>>>> Hello,
>>>>>>>
>>>>>>> My system hangs shortly after I logged in Gnome desktop. SysRq-W shows
>>>>>>> that a bunch of task are blocked in "D" state, they seem to wait for
>>>>>>> some I/O completion. I can try to hand-copy some data if requested.
>>>>>>>
>>>>>>> I found these messages in dmesg:
>>>>>>>
>>>>>>> ~$ grep -C2 end_request dmesg-2.6.24-rc3-mm1
>>>>>>> EXT3-fs: mounted filesystem with ordered data mode.
>>>>>>> sd 0:0:0:0: [sda] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK,SUGGEST_OK
>>>>>>> end_request: I/O error, dev sda, sector 16460
>>>>>>> ReiserFS: sda7: found reiserfs format "3.6" with standard journal
>>>>>>> ReiserFS: sda7: using ordered data mode
>>>>>>> --
>>>>>>> ReiserFS: sda7: Using r5 hash to sort names
>>>>>>> sd 0:0:1:0: [sdb] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK,SUGGEST_OK
>>>>>>> end_request: I/O error, dev sdb, sector 19632
>>>>>>> sd 0:0:1:0: [sdb] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK,SUGGEST_OK
>>>>>>> end_request: I/O error, dev sdb, sector 40037363
>>>>>>> Adding 1048568k swap on /dev/mapper/vglinux1-lvswap. Priority:-1 extents:1 across:1048568k
>>>>>>> lp0: using parport0 (interrupt-driven).
>>>>>>>
>>>>>>> These errors occur *only* with 2.6.24-rc3-mm1, they are 100% reproducible.
>>>>>>> 2.6.24-rc3 and 2.6.24-rc2-mm1 are fine.
>>>>>>>
>>>>>>> Maybe something is broken in pata_via driver ?
>>>>>>>
>>>>>> Could be - libata-reimplement-ata_acpi_cbl_80wire-using-ata_acpi_gtm_xfermask.patch
>>>>>> and pata_amd-pata_via-de-couple-programming-of-pio-mwdma-and-udma-timings.patch
>>>>>> touch pata_via.c.
>>>>> None of the above...
>>>>>
>>>>> I did a bisection, it spotted git-scsi-misc.patch.
>>>>> I just run 2.6.24-rc3-mm1 + revert-git-scsi-misc.patch, and it works fine.
>>>>>
>>>>> I guess commit 8655a546c83fc43f0a73416bbd126d02de7ad6c0 "[SCSI] Do not
>>>>> requeue requests if REQ_FAILFAST is set" is the real culprit. The other
>>>>> commits are touching documentation or drivers I don't use. I'll try
>>>>> to revert only this one this evening.
>> I can confirm : reverting commit 8655a546c83fc43f0a73416bbd126d02de7ad6c0
>> does fix the problem.
>>
>>>> Hmm. Weird. I'll have a look into it. Apparently I'll be returning an error where
>>>> I shouldn't. Checking ...
>>>>
>>> Ok, found it. We are blocking even special commands (ie requests with PREEMPT not set)
>>> when FAILFAST is set. Which is clearly wrong. The attached patch fixes this.
>> Sorry, it's not enough. 2.6.24-rc3-mm1 + your patch still hangs with I/O errors.
>
> I think the problem is the way we treat BLOCKED and QUIESCED (the latter
> is the state that the domain validation uses and which we cannot kill
> fastfail on). It's definitely wrong to kill fastfail requests when the
> state is QUIESCE.
>
> This patch (which is applied on top of Hannes original) separates the
> BLOCK and QUIESCE states correctly ... does this fix the problem?


No, it doesn't help... (2.6.24-rc3-mm1 + your patch still has problems)


> James
>
> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
> index 13e7e09..a7cf23a 100644
> --- a/drivers/scsi/scsi_lib.c
> +++ b/drivers/scsi/scsi_lib.c

> @@ -1279,18 +1279,21 @@ int scsi_prep_state_check(struct scsi_device *sdev, struct request *req)
> "rejecting I/O to dead device\n");
> ret = BLKPREP_KILL;
> break;
> - case SDEV_QUIESCE:
> case SDEV_BLOCK:
> /*
> - * If the devices is blocked we defer normal commands.
> - */
> - if (!(req->cmd_flags & REQ_PREEMPT))
> - ret = BLKPREP_DEFER;
> - /*
> * Return failfast requests immediately
> */
> if (req->cmd_flags & REQ_FAILFAST)
> ret = BLKPREP_KILL;
> +
> + /* fall through */
> +
> + case SDEV_QUIESCE:
> + /*
> + * If the devices is blocked we defer normal commands.
> + */
> + if (!(req->cmd_flags & REQ_PREEMPT))
> + ret = BLKPREP_DEFER;
> break;
> default:
> /*
>

2007-11-24 13:27:09

by James Bottomley

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1: I/O error, system hangs

On Sat, 2007-11-24 at 13:57 +0100, Laurent Riffard wrote:
> Le 24.11.2007 07:42, James Bottomley a écrit :
> > On Fri, 2007-11-23 at 18:52 +0100, Laurent Riffard wrote:
> >> Le 23.11.2007 12:38, Hannes Reinecke a écrit :
> >>> Hannes Reinecke wrote:
> >>>> Laurent Riffard wrote:
> >>>>> Le 21.11.2007 23:41, Andrew Morton a écrit :
> >>>>>> On Wed, 21 Nov 2007 22:45:22 +0100
> >>>>>> Laurent Riffard <[email protected]> wrote:
> >>>>>>
> >>>>>>> Le 21.11.2007 05:45, Andrew Morton a écrit :
> >>>>>>>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc3/2.6.24-rc3-mm1/
> >>>>>>> Hello,
> >>>>>>>
> >>>>>>> My system hangs shortly after I logged in Gnome desktop. SysRq-W shows
> >>>>>>> that a bunch of task are blocked in "D" state, they seem to wait for
> >>>>>>> some I/O completion. I can try to hand-copy some data if requested.
> >>>>>>>
> >>>>>>> I found these messages in dmesg:
> >>>>>>>
> >>>>>>> ~$ grep -C2 end_request dmesg-2.6.24-rc3-mm1
> >>>>>>> EXT3-fs: mounted filesystem with ordered data mode.
> >>>>>>> sd 0:0:0:0: [sda] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK,SUGGEST_OK
> >>>>>>> end_request: I/O error, dev sda, sector 16460
> >>>>>>> ReiserFS: sda7: found reiserfs format "3.6" with standard journal
> >>>>>>> ReiserFS: sda7: using ordered data mode
> >>>>>>> --
> >>>>>>> ReiserFS: sda7: Using r5 hash to sort names
> >>>>>>> sd 0:0:1:0: [sdb] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK,SUGGEST_OK
> >>>>>>> end_request: I/O error, dev sdb, sector 19632
> >>>>>>> sd 0:0:1:0: [sdb] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK,SUGGEST_OK
> >>>>>>> end_request: I/O error, dev sdb, sector 40037363
> >>>>>>> Adding 1048568k swap on /dev/mapper/vglinux1-lvswap. Priority:-1 extents:1 across:1048568k
> >>>>>>> lp0: using parport0 (interrupt-driven).
> >>>>>>>
> >>>>>>> These errors occur *only* with 2.6.24-rc3-mm1, they are 100% reproducible.
> >>>>>>> 2.6.24-rc3 and 2.6.24-rc2-mm1 are fine.
> >>>>>>>
> >>>>>>> Maybe something is broken in pata_via driver ?
> >>>>>>>
> >>>>>> Could be - libata-reimplement-ata_acpi_cbl_80wire-using-ata_acpi_gtm_xfermask.patch
> >>>>>> and pata_amd-pata_via-de-couple-programming-of-pio-mwdma-and-udma-timings.patch
> >>>>>> touch pata_via.c.
> >>>>> None of the above...
> >>>>>
> >>>>> I did a bisection, it spotted git-scsi-misc.patch.
> >>>>> I just run 2.6.24-rc3-mm1 + revert-git-scsi-misc.patch, and it works fine.
> >>>>>
> >>>>> I guess commit 8655a546c83fc43f0a73416bbd126d02de7ad6c0 "[SCSI] Do not
> >>>>> requeue requests if REQ_FAILFAST is set" is the real culprit. The other
> >>>>> commits are touching documentation or drivers I don't use. I'll try
> >>>>> to revert only this one this evening.
> >> I can confirm : reverting commit 8655a546c83fc43f0a73416bbd126d02de7ad6c0
> >> does fix the problem.
> >>
> >>>> Hmm. Weird. I'll have a look into it. Apparently I'll be returning an error where
> >>>> I shouldn't. Checking ...
> >>>>
> >>> Ok, found it. We are blocking even special commands (ie requests with PREEMPT not set)
> >>> when FAILFAST is set. Which is clearly wrong. The attached patch fixes this.
> >> Sorry, it's not enough. 2.6.24-rc3-mm1 + your patch still hangs with I/O errors.
> >
> > I think the problem is the way we treat BLOCKED and QUIESCED (the latter
> > is the state that the domain validation uses and which we cannot kill
> > fastfail on). It's definitely wrong to kill fastfail requests when the
> > state is QUIESCE.
> >
> > This patch (which is applied on top of Hannes original) separates the
> > BLOCK and QUIESCE states correctly ... does this fix the problem?
>
>
> No, it doesn't help... (2.6.24-rc3-mm1 + your patch still has problems)

OK, could you post dmesgs again, please. I actually tested this with an
aic79xx card, and for me it does cause Domain Validation to succeed
again.

James


2007-11-24 14:34:27

by Adrian Bunk

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1 make headers_check fails

On Wed, Nov 21, 2007 at 10:58:21AM +0100, Sam Ravnborg wrote:
> On Wed, Nov 21, 2007 at 10:44:40AM +0200, Avi Kivity wrote:
> > Kamalesh Babulal wrote:
> > >Andrew Morton wrote:
> > >
> > >>On Wed, 21 Nov 2007 13:54:50 +0530 Kamalesh Babulal
> > >><[email protected]> wrote:
> > >>
> > >>
> > >>>The make headers_check fails,
> > >>>
> > >>> CHECK include/linux/usb/gadgetfs.h
> > >>> CHECK include/linux/usb/ch9.h
> > >>> CHECK include/linux/usb/cdc.h
> > >>> CHECK include/linux/usb/audio.h
> > >>> CHECK include/linux/kvm.h
> > >>>/root/kernels/linux-2.6.24-rc3/usr/include/linux/kvm.h requires
> > >>>asm/kvm.h, which does not exist in exported headers
> > >>>
> > >>hm, works for me, on i386 and x86_64. What's different over there?
> > >>
> > >Hi Andrew,
> > >
> > >It fails on the powerpc box, with allyesconfig option.
> > >
> > >
> >
> > How do we fix this? Export linux/kvm.h only on x86? Seems ugly.
>
> Is kvm x86 specific? Then move the .h file to asm-x86.
> Otherwise no good idea...

What about adding a whitelist in hdrcheck.sh?

For all practical purposes in userspace the compile error due to the
non-existing asm header should be fine, so there's no reason to change
the code in such cases.

> Sam

cu
Adrian

--

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

2007-11-24 17:44:37

by James Bottomley

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1: I/O error, system hangs

Probing intermittent failures in Domain Validation, even with the fixes
applied leads me to the conclusion that there are further problems with
this commit:

commit fc5eb4facedbd6d7117905e775cee1975f894e79
Author: Hannes Reinecke <[email protected]>
Date: Tue Nov 6 09:23:40 2007 +0100

[SCSI] Do not requeue requests if REQ_FAILFAST is set

The essence of the problems is that you're causing REQ_FAILFAST to
terminate commands with error on requeuing conditions, some of which are
relatively common on most SCSI devices. While this may be the correct
behaviour for multi-path, it's certainly wrong for the previously
understood meaning of REQ_FAILFAST, which was don't retry on error,
which is why domain validation and other applications use it to control
error handling, but don't expect to get failures for a simple requeue
are now spitting errors.

I honestly can't see that, even for the multi-path case, returning an
error when we're over queue depth is the correct thing to do (it may not
matter to something like a symmetrix, but an array that has a non-zero
cost associated with a path change, like a CPQ HSV or the AVT
controllers, will show fairly large slow downs if you do this). Even if
this is the desired behaviour (and I think that's a policy issue),
DID_NO_CONNECT is almost certainly the wrong error to be sending back.

This patch fixes up domain validation to work again correctly, however,
I really think it's just a bandaid. Do you want to rethink the above
commit?

James

Index: BUILD-2.6/drivers/scsi/scsi_lib.c
===================================================================
--- BUILD-2.6.orig/drivers/scsi/scsi_lib.c 2007-11-24 11:25:20.000000000 -0600
+++ BUILD-2.6/drivers/scsi/scsi_lib.c 2007-11-24 11:26:22.000000000 -0600
@@ -1552,7 +1552,8 @@ static void scsi_request_fn(struct reque
break;

if (!scsi_dev_queue_ready(q, sdev)) {
- if (req->cmd_flags & REQ_FAILFAST) {
+ if ((req->cmd_flags & REQ_FAILFAST) &&
+ !(req->cmd_flags & REQ_PREEMPT)) {
scsi_kill_request(req, q);
continue;
}


2007-11-24 17:55:15

by Gabriel C

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1: I/O error, system hangs

James Bottomley wrote:
> On Sat, 2007-11-24 at 13:57 +0100, Laurent Riffard wrote:
>> Le 24.11.2007 07:42, James Bottomley a écrit :
>>> On Fri, 2007-11-23 at 18:52 +0100, Laurent Riffard wrote:
>>>> Le 23.11.2007 12:38, Hannes Reinecke a écrit :
>>>>> Hannes Reinecke wrote:
>>>>>> Laurent Riffard wrote:
>>>>>>> Le 21.11.2007 23:41, Andrew Morton a écrit :
>>>>>>>> On Wed, 21 Nov 2007 22:45:22 +0100
>>>>>>>> Laurent Riffard <[email protected]> wrote:
>>>>>>>>
>>>>>>>>> Le 21.11.2007 05:45, Andrew Morton a écrit :
>>>>>>>>>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc3/2.6.24-rc3-mm1/
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> My system hangs shortly after I logged in Gnome desktop. SysRq-W shows
>>>>>>>>> that a bunch of task are blocked in "D" state, they seem to wait for
>>>>>>>>> some I/O completion. I can try to hand-copy some data if requested.
>>>>>>>>>
>>>>>>>>> I found these messages in dmesg:
>>>>>>>>>
>>>>>>>>> ~$ grep -C2 end_request dmesg-2.6.24-rc3-mm1
>>>>>>>>> EXT3-fs: mounted filesystem with ordered data mode.
>>>>>>>>> sd 0:0:0:0: [sda] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK,SUGGEST_OK
>>>>>>>>> end_request: I/O error, dev sda, sector 16460
>>>>>>>>> ReiserFS: sda7: found reiserfs format "3.6" with standard journal
>>>>>>>>> ReiserFS: sda7: using ordered data mode
>>>>>>>>> --
>>>>>>>>> ReiserFS: sda7: Using r5 hash to sort names
>>>>>>>>> sd 0:0:1:0: [sdb] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK,SUGGEST_OK
>>>>>>>>> end_request: I/O error, dev sdb, sector 19632
>>>>>>>>> sd 0:0:1:0: [sdb] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK,SUGGEST_OK
>>>>>>>>> end_request: I/O error, dev sdb, sector 40037363
>>>>>>>>> Adding 1048568k swap on /dev/mapper/vglinux1-lvswap. Priority:-1 extents:1 across:1048568k
>>>>>>>>> lp0: using parport0 (interrupt-driven).
>>>>>>>>>
>>>>>>>>> These errors occur *only* with 2.6.24-rc3-mm1, they are 100% reproducible.
>>>>>>>>> 2.6.24-rc3 and 2.6.24-rc2-mm1 are fine.
>>>>>>>>>
>>>>>>>>> Maybe something is broken in pata_via driver ?
>>>>>>>>>
>>>>>>>> Could be - libata-reimplement-ata_acpi_cbl_80wire-using-ata_acpi_gtm_xfermask.patch
>>>>>>>> and pata_amd-pata_via-de-couple-programming-of-pio-mwdma-and-udma-timings.patch
>>>>>>>> touch pata_via.c.
>>>>>>> None of the above...
>>>>>>>
>>>>>>> I did a bisection, it spotted git-scsi-misc.patch.
>>>>>>> I just run 2.6.24-rc3-mm1 + revert-git-scsi-misc.patch, and it works fine.
>>>>>>>
>>>>>>> I guess commit 8655a546c83fc43f0a73416bbd126d02de7ad6c0 "[SCSI] Do not
>>>>>>> requeue requests if REQ_FAILFAST is set" is the real culprit. The other
>>>>>>> commits are touching documentation or drivers I don't use. I'll try
>>>>>>> to revert only this one this evening.
>>>> I can confirm : reverting commit 8655a546c83fc43f0a73416bbd126d02de7ad6c0
>>>> does fix the problem.
>>>>
>>>>>> Hmm. Weird. I'll have a look into it. Apparently I'll be returning an error where
>>>>>> I shouldn't. Checking ...
>>>>>>
>>>>> Ok, found it. We are blocking even special commands (ie requests with PREEMPT not set)
>>>>> when FAILFAST is set. Which is clearly wrong. The attached patch fixes this.
>>>> Sorry, it's not enough. 2.6.24-rc3-mm1 + your patch still hangs with I/O errors.
>>> I think the problem is the way we treat BLOCKED and QUIESCED (the latter
>>> is the state that the domain validation uses and which we cannot kill
>>> fastfail on). It's definitely wrong to kill fastfail requests when the
>>> state is QUIESCE.
>>>
>>> This patch (which is applied on top of Hannes original) separates the
>>> BLOCK and QUIESCE states correctly ... does this fix the problem?
>>
>> No, it doesn't help... (2.6.24-rc3-mm1 + your patch still has problems)
>
> OK, could you post dmesgs again, please. I actually tested this with an
> aic79xx card, and for me it does cause Domain Validation to succeed
> again.
>

Are the patches indeed to fix that problem as well ?

http://lkml.org/lkml/2007/11/23/5

> James

Gabriel

2007-11-24 18:04:18

by James Bottomley

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1: I/O error, system hangs


On Sat, 2007-11-24 at 18:54 +0100, Gabriel C wrote:
> James Bottomley wrote:
> > On Sat, 2007-11-24 at 13:57 +0100, Laurent Riffard wrote:
> >> Le 24.11.2007 07:42, James Bottomley a écrit :
> >>> On Fri, 2007-11-23 at 18:52 +0100, Laurent Riffard wrote:
> >>>> Le 23.11.2007 12:38, Hannes Reinecke a écrit :
> >>>>> Hannes Reinecke wrote:
> >>>>>> Laurent Riffard wrote:
> >>>>>>> Le 21.11.2007 23:41, Andrew Morton a écrit :
> >>>>>>>> On Wed, 21 Nov 2007 22:45:22 +0100
> >>>>>>>> Laurent Riffard <[email protected]> wrote:
> >>>>>>>>
> >>>>>>>>> Le 21.11.2007 05:45, Andrew Morton a écrit :
> >>>>>>>>>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc3/2.6.24-rc3-mm1/
> >>>>>>>>> Hello,
> >>>>>>>>>
> >>>>>>>>> My system hangs shortly after I logged in Gnome desktop. SysRq-W shows
> >>>>>>>>> that a bunch of task are blocked in "D" state, they seem to wait for
> >>>>>>>>> some I/O completion. I can try to hand-copy some data if requested.
> >>>>>>>>>
> >>>>>>>>> I found these messages in dmesg:
> >>>>>>>>>
> >>>>>>>>> ~$ grep -C2 end_request dmesg-2.6.24-rc3-mm1
> >>>>>>>>> EXT3-fs: mounted filesystem with ordered data mode.
> >>>>>>>>> sd 0:0:0:0: [sda] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK,SUGGEST_OK
> >>>>>>>>> end_request: I/O error, dev sda, sector 16460
> >>>>>>>>> ReiserFS: sda7: found reiserfs format "3.6" with standard journal
> >>>>>>>>> ReiserFS: sda7: using ordered data mode
> >>>>>>>>> --
> >>>>>>>>> ReiserFS: sda7: Using r5 hash to sort names
> >>>>>>>>> sd 0:0:1:0: [sdb] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK,SUGGEST_OK
> >>>>>>>>> end_request: I/O error, dev sdb, sector 19632
> >>>>>>>>> sd 0:0:1:0: [sdb] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK,SUGGEST_OK
> >>>>>>>>> end_request: I/O error, dev sdb, sector 40037363
> >>>>>>>>> Adding 1048568k swap on /dev/mapper/vglinux1-lvswap. Priority:-1 extents:1 across:1048568k
> >>>>>>>>> lp0: using parport0 (interrupt-driven).
> >>>>>>>>>
> >>>>>>>>> These errors occur *only* with 2.6.24-rc3-mm1, they are 100% reproducible.
> >>>>>>>>> 2.6.24-rc3 and 2.6.24-rc2-mm1 are fine.
> >>>>>>>>>
> >>>>>>>>> Maybe something is broken in pata_via driver ?
> >>>>>>>>>
> >>>>>>>> Could be - libata-reimplement-ata_acpi_cbl_80wire-using-ata_acpi_gtm_xfermask.patch
> >>>>>>>> and pata_amd-pata_via-de-couple-programming-of-pio-mwdma-and-udma-timings.patch
> >>>>>>>> touch pata_via.c.
> >>>>>>> None of the above...
> >>>>>>>
> >>>>>>> I did a bisection, it spotted git-scsi-misc.patch.
> >>>>>>> I just run 2.6.24-rc3-mm1 + revert-git-scsi-misc.patch, and it works fine.
> >>>>>>>
> >>>>>>> I guess commit 8655a546c83fc43f0a73416bbd126d02de7ad6c0 "[SCSI] Do not
> >>>>>>> requeue requests if REQ_FAILFAST is set" is the real culprit. The other
> >>>>>>> commits are touching documentation or drivers I don't use. I'll try
> >>>>>>> to revert only this one this evening.
> >>>> I can confirm : reverting commit 8655a546c83fc43f0a73416bbd126d02de7ad6c0
> >>>> does fix the problem.
> >>>>
> >>>>>> Hmm. Weird. I'll have a look into it. Apparently I'll be returning an error where
> >>>>>> I shouldn't. Checking ...
> >>>>>>
> >>>>> Ok, found it. We are blocking even special commands (ie requests with PREEMPT not set)
> >>>>> when FAILFAST is set. Which is clearly wrong. The attached patch fixes this.
> >>>> Sorry, it's not enough. 2.6.24-rc3-mm1 + your patch still hangs with I/O errors.
> >>> I think the problem is the way we treat BLOCKED and QUIESCED (the latter
> >>> is the state that the domain validation uses and which we cannot kill
> >>> fastfail on). It's definitely wrong to kill fastfail requests when the
> >>> state is QUIESCE.
> >>>
> >>> This patch (which is applied on top of Hannes original) separates the
> >>> BLOCK and QUIESCE states correctly ... does this fix the problem?
> >>
> >> No, it doesn't help... (2.6.24-rc3-mm1 + your patch still has problems)
> >
> > OK, could you post dmesgs again, please. I actually tested this with an
> > aic79xx card, and for me it does cause Domain Validation to succeed
> > again.
> >
>
> Are the patches indeed to fix that problem as well ?
>
> http://lkml.org/lkml/2007/11/23/5

That dmesg is from an unknown SCSI card exhibiting Domain Validation
problems, so it's a reasonable probability, yes ... but you'll need the
additional hack I just did to prevent further intermittent failures.

James


2007-11-24 18:04:50

by Gabriel C

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1 (sync is slow ?)

kosaki wrote:
> Hi, Andrew
>
>>> Hi, Andrew
>>>
>>> I got following result in 'sync' command.
>>> It was too slow. (memory controller config is off ;)
>>> I attaches my .config.
>>> ==
> (snip)
>> Well I wonder how we did that.
>>
>> It seems OK here from a quick test (i386, ext3-on-IDE).
>>
>> Maybe device driver/block breakage?

Try revert

http://git.kernel.org/?p=linux/kernel/git/jejb/scsi-misc-2.6.git;a=commitdiff_plain;h=8655a546c83fc43f0a73416bbd126d02de7ad6c0;hp=5bc717b6bdaaf52edf365eb7d9d8c89fec79df5d

See also :
http://lkml.org/lkml/2007/11/23/5

and search for '2.6.24-rc3-mm1: I/O error, system hangs' on LKML

>
> I tested x86, ext3-on-SATA(/dev/sda).
> It seems works well.
>
> Hmm...

IDE/SATA is fine here as well just SCSI broke


Regards,

Gabriel

2007-11-24 18:09:20

by Gabriel C

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1: I/O error, system hangs

James Bottomley wrote:
> On Sat, 2007-11-24 at 18:54 +0100, Gabriel C wrote:
>> James Bottomley wrote:
>>> On Sat, 2007-11-24 at 13:57 +0100, Laurent Riffard wrote:
>>>> Le 24.11.2007 07:42, James Bottomley a écrit :
>>>>> On Fri, 2007-11-23 at 18:52 +0100, Laurent Riffard wrote:
>>>>>> Le 23.11.2007 12:38, Hannes Reinecke a écrit :
>>>>>>> Hannes Reinecke wrote:
>>>>>>>> Laurent Riffard wrote:
>>>>>>>>> Le 21.11.2007 23:41, Andrew Morton a écrit :
>>>>>>>>>> On Wed, 21 Nov 2007 22:45:22 +0100
>>>>>>>>>> Laurent Riffard <[email protected]> wrote:
>>>>>>>>>>
>>>>>>>>>>> Le 21.11.2007 05:45, Andrew Morton a écrit :
>>>>>>>>>>>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc3/2.6.24-rc3-mm1/
>>>>>>>>>>> Hello,
>>>>>>>>>>>
>>>>>>>>>>> My system hangs shortly after I logged in Gnome desktop. SysRq-W shows
>>>>>>>>>>> that a bunch of task are blocked in "D" state, they seem to wait for
>>>>>>>>>>> some I/O completion. I can try to hand-copy some data if requested.
>>>>>>>>>>>
>>>>>>>>>>> I found these messages in dmesg:
>>>>>>>>>>>
>>>>>>>>>>> ~$ grep -C2 end_request dmesg-2.6.24-rc3-mm1
>>>>>>>>>>> EXT3-fs: mounted filesystem with ordered data mode.
>>>>>>>>>>> sd 0:0:0:0: [sda] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK,SUGGEST_OK
>>>>>>>>>>> end_request: I/O error, dev sda, sector 16460
>>>>>>>>>>> ReiserFS: sda7: found reiserfs format "3.6" with standard journal
>>>>>>>>>>> ReiserFS: sda7: using ordered data mode
>>>>>>>>>>> --
>>>>>>>>>>> ReiserFS: sda7: Using r5 hash to sort names
>>>>>>>>>>> sd 0:0:1:0: [sdb] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK,SUGGEST_OK
>>>>>>>>>>> end_request: I/O error, dev sdb, sector 19632
>>>>>>>>>>> sd 0:0:1:0: [sdb] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK,SUGGEST_OK
>>>>>>>>>>> end_request: I/O error, dev sdb, sector 40037363
>>>>>>>>>>> Adding 1048568k swap on /dev/mapper/vglinux1-lvswap. Priority:-1 extents:1 across:1048568k
>>>>>>>>>>> lp0: using parport0 (interrupt-driven).
>>>>>>>>>>>
>>>>>>>>>>> These errors occur *only* with 2.6.24-rc3-mm1, they are 100% reproducible.
>>>>>>>>>>> 2.6.24-rc3 and 2.6.24-rc2-mm1 are fine.
>>>>>>>>>>>
>>>>>>>>>>> Maybe something is broken in pata_via driver ?
>>>>>>>>>>>
>>>>>>>>>> Could be - libata-reimplement-ata_acpi_cbl_80wire-using-ata_acpi_gtm_xfermask.patch
>>>>>>>>>> and pata_amd-pata_via-de-couple-programming-of-pio-mwdma-and-udma-timings.patch
>>>>>>>>>> touch pata_via.c.
>>>>>>>>> None of the above...
>>>>>>>>>
>>>>>>>>> I did a bisection, it spotted git-scsi-misc.patch.
>>>>>>>>> I just run 2.6.24-rc3-mm1 + revert-git-scsi-misc.patch, and it works fine.
>>>>>>>>>
>>>>>>>>> I guess commit 8655a546c83fc43f0a73416bbd126d02de7ad6c0 "[SCSI] Do not
>>>>>>>>> requeue requests if REQ_FAILFAST is set" is the real culprit. The other
>>>>>>>>> commits are touching documentation or drivers I don't use. I'll try
>>>>>>>>> to revert only this one this evening.
>>>>>> I can confirm : reverting commit 8655a546c83fc43f0a73416bbd126d02de7ad6c0
>>>>>> does fix the problem.
>>>>>>
>>>>>>>> Hmm. Weird. I'll have a look into it. Apparently I'll be returning an error where
>>>>>>>> I shouldn't. Checking ...
>>>>>>>>
>>>>>>> Ok, found it. We are blocking even special commands (ie requests with PREEMPT not set)
>>>>>>> when FAILFAST is set. Which is clearly wrong. The attached patch fixes this.
>>>>>> Sorry, it's not enough. 2.6.24-rc3-mm1 + your patch still hangs with I/O errors.
>>>>> I think the problem is the way we treat BLOCKED and QUIESCED (the latter
>>>>> is the state that the domain validation uses and which we cannot kill
>>>>> fastfail on). It's definitely wrong to kill fastfail requests when the
>>>>> state is QUIESCE.
>>>>>
>>>>> This patch (which is applied on top of Hannes original) separates the
>>>>> BLOCK and QUIESCE states correctly ... does this fix the problem?
>>>> No, it doesn't help... (2.6.24-rc3-mm1 + your patch still has problems)
>>> OK, could you post dmesgs again, please. I actually tested this with an
>>> aic79xx card, and for me it does cause Domain Validation to succeed
>>> again.
>>>
>> Are the patches indeed to fix that problem as well ?
>>
>> http://lkml.org/lkml/2007/11/23/5
>
> That dmesg is from an unknown SCSI card exhibiting Domain Validation
> problems, so it's a reasonable probability, yes ... but you'll need the
> additional hack I just did to prevent further intermittent failures.

My controller is:

03:0e.0 SCSI storage controller [0100]: Adaptec AIC-7892P U160/m [9005:008f] (rev 02)

I'll try the patches in a bit.

>
> James
>

Gabriel

2007-11-24 18:28:23

by Gabriel C

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1: I/O error, system hangs

Gabriel C wrote:
> James Bottomley wrote:
>> On Sat, 2007-11-24 at 18:54 +0100, Gabriel C wrote:
>>> James Bottomley wrote:
>>>> On Sat, 2007-11-24 at 13:57 +0100, Laurent Riffard wrote:
>>>>> Le 24.11.2007 07:42, James Bottomley a écrit :
>>>>>> On Fri, 2007-11-23 at 18:52 +0100, Laurent Riffard wrote:
>>>>>>> Le 23.11.2007 12:38, Hannes Reinecke a écrit :
>>>>>>>> Hannes Reinecke wrote:
>>>>>>>>> Laurent Riffard wrote:
>>>>>>>>>> Le 21.11.2007 23:41, Andrew Morton a écrit :
>>>>>>>>>>> On Wed, 21 Nov 2007 22:45:22 +0100
>>>>>>>>>>> Laurent Riffard <[email protected]> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Le 21.11.2007 05:45, Andrew Morton a écrit :
>>>>>>>>>>>>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc3/2.6.24-rc3-mm1/
>>>>>>>>>>>> Hello,
>>>>>>>>>>>>
>>>>>>>>>>>> My system hangs shortly after I logged in Gnome desktop. SysRq-W shows
>>>>>>>>>>>> that a bunch of task are blocked in "D" state, they seem to wait for
>>>>>>>>>>>> some I/O completion. I can try to hand-copy some data if requested.
>>>>>>>>>>>>
>>>>>>>>>>>> I found these messages in dmesg:
>>>>>>>>>>>>
>>>>>>>>>>>> ~$ grep -C2 end_request dmesg-2.6.24-rc3-mm1
>>>>>>>>>>>> EXT3-fs: mounted filesystem with ordered data mode.
>>>>>>>>>>>> sd 0:0:0:0: [sda] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK,SUGGEST_OK
>>>>>>>>>>>> end_request: I/O error, dev sda, sector 16460
>>>>>>>>>>>> ReiserFS: sda7: found reiserfs format "3.6" with standard journal
>>>>>>>>>>>> ReiserFS: sda7: using ordered data mode
>>>>>>>>>>>> --
>>>>>>>>>>>> ReiserFS: sda7: Using r5 hash to sort names
>>>>>>>>>>>> sd 0:0:1:0: [sdb] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK,SUGGEST_OK
>>>>>>>>>>>> end_request: I/O error, dev sdb, sector 19632
>>>>>>>>>>>> sd 0:0:1:0: [sdb] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK,SUGGEST_OK
>>>>>>>>>>>> end_request: I/O error, dev sdb, sector 40037363
>>>>>>>>>>>> Adding 1048568k swap on /dev/mapper/vglinux1-lvswap. Priority:-1 extents:1 across:1048568k
>>>>>>>>>>>> lp0: using parport0 (interrupt-driven).
>>>>>>>>>>>>
>>>>>>>>>>>> These errors occur *only* with 2.6.24-rc3-mm1, they are 100% reproducible.
>>>>>>>>>>>> 2.6.24-rc3 and 2.6.24-rc2-mm1 are fine.
>>>>>>>>>>>>
>>>>>>>>>>>> Maybe something is broken in pata_via driver ?
>>>>>>>>>>>>
>>>>>>>>>>> Could be - libata-reimplement-ata_acpi_cbl_80wire-using-ata_acpi_gtm_xfermask.patch
>>>>>>>>>>> and pata_amd-pata_via-de-couple-programming-of-pio-mwdma-and-udma-timings.patch
>>>>>>>>>>> touch pata_via.c.
>>>>>>>>>> None of the above...
>>>>>>>>>>
>>>>>>>>>> I did a bisection, it spotted git-scsi-misc.patch.
>>>>>>>>>> I just run 2.6.24-rc3-mm1 + revert-git-scsi-misc.patch, and it works fine.
>>>>>>>>>>
>>>>>>>>>> I guess commit 8655a546c83fc43f0a73416bbd126d02de7ad6c0 "[SCSI] Do not
>>>>>>>>>> requeue requests if REQ_FAILFAST is set" is the real culprit. The other
>>>>>>>>>> commits are touching documentation or drivers I don't use. I'll try
>>>>>>>>>> to revert only this one this evening.
>>>>>>> I can confirm : reverting commit 8655a546c83fc43f0a73416bbd126d02de7ad6c0
>>>>>>> does fix the problem.
>>>>>>>
>>>>>>>>> Hmm. Weird. I'll have a look into it. Apparently I'll be returning an error where
>>>>>>>>> I shouldn't. Checking ...
>>>>>>>>>
>>>>>>>> Ok, found it. We are blocking even special commands (ie requests with PREEMPT not set)
>>>>>>>> when FAILFAST is set. Which is clearly wrong. The attached patch fixes this.
>>>>>>> Sorry, it's not enough. 2.6.24-rc3-mm1 + your patch still hangs with I/O errors.
>>>>>> I think the problem is the way we treat BLOCKED and QUIESCED (the latter
>>>>>> is the state that the domain validation uses and which we cannot kill
>>>>>> fastfail on). It's definitely wrong to kill fastfail requests when the
>>>>>> state is QUIESCE.
>>>>>>
>>>>>> This patch (which is applied on top of Hannes original) separates the
>>>>>> BLOCK and QUIESCE states correctly ... does this fix the problem?
>>>>> No, it doesn't help... (2.6.24-rc3-mm1 + your patch still has problems)
>>>> OK, could you post dmesgs again, please. I actually tested this with an
>>>> aic79xx card, and for me it does cause Domain Validation to succeed
>>>> again.
>>>>
>>> Are the patches indeed to fix that problem as well ?
>>>
>>> http://lkml.org/lkml/2007/11/23/5
>> That dmesg is from an unknown SCSI card exhibiting Domain Validation
>> problems, so it's a reasonable probability, yes ... but you'll need the
>> additional hack I just did to prevent further intermittent failures.
>
> My controller is:
>
> 03:0e.0 SCSI storage controller [0100]: Adaptec AIC-7892P U160/m [9005:008f] (rev 02)
>
> I'll try the patches in a bit.

With your patches my problem(s) are solved. Domain Validation works again.

...

[ 32.179521] scsi 0:0:0:0: Direct-Access SEAGATE ST318406LW 0109 PQ: 0 ANSI: 3
[ 32.179540] scsi0:A:0:0: Tagged Queuing enabled. Depth 32
[ 32.179554] target0:0:0: Beginning Domain Validation
[ 32.188553] target0:0:0: wide asynchronous
[ 32.195302] target0:0:0: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 63)
[ 32.206510] target0:0:0: Ending Domain Validation
[ 32.211699] scsi 0:0:1:0: Direct-Access FUJITSU MAH3182MP 0114 PQ: 0 ANSI: 4
[ 32.211707] scsi0:A:1:0: Tagged Queuing enabled. Depth 32
[ 32.211717] target0:0:1: Beginning Domain Validation
[ 32.213980] target0:0:1: wide asynchronous
[ 32.215682] target0:0:1: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 127)
[ 32.220205] target0:0:1: Ending Domain Validation

...

Thx James :)


Gabriel

2007-11-24 22:59:39

by Laurent Riffard

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1: I/O error, system hangs

[ 0.000000] Linux version 2.6.24-rc3-mm1 (laurent@calimero) (gcc version 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)) #122 PREEMPT Fri Nov 23 18:47:58 CET 2007
[ 0.000000] BIOS-provided physical RAM map:
[ 0.000000] BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
[ 0.000000] BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
[ 0.000000] BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
[ 0.000000] BIOS-e820: 0000000000100000 - 000000001ffec000 (usable)
[ 0.000000] BIOS-e820: 000000001ffec000 - 000000001ffef000 (ACPI data)
[ 0.000000] BIOS-e820: 000000001ffef000 - 000000001ffff000 (reserved)
[ 0.000000] BIOS-e820: 000000001ffff000 - 0000000020000000 (ACPI NVS)
[ 0.000000] BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
[ 0.000000] 511MB LOWMEM available.
[ 0.000000] Entering add_active_range(0, 0, 131052) 0 entries of 256 used
[ 0.000000] sizeof(struct page) = 32
[ 0.000000] Zone PFN ranges:
[ 0.000000] DMA 0 -> 4096
[ 0.000000] Normal 4096 -> 131052
[ 0.000000] Movable zone start PFN for each node
[ 0.000000] early_node_map[1] active PFN ranges
[ 0.000000] 0: 0 -> 131052
[ 0.000000] On node 0 totalpages: 131052
[ 0.000000] Node 0 memmap at 0xC1000000 size 4194304 first pfn 0xC1000000
[ 0.000000] DMA zone: 32 pages used for memmap
[ 0.000000] DMA zone: 0 pages reserved
[ 0.000000] DMA zone: 4064 pages, LIFO batch:0
[ 0.000000] Normal zone: 991 pages used for memmap
[ 0.000000] Normal zone: 125965 pages, LIFO batch:31
[ 0.000000] Movable zone: 0 pages used for memmap
[ 0.000000] DMI 2.3 present.
[ 0.000000] ACPI: RSDP 000F6A80, 0014 (r0 ASUS )
[ 0.000000] ACPI: RSDT 1FFEC000, 002C (r1 ASUS A7V133-C 30303031 MSFT 31313031)
[ 0.000000] ACPI: FACP 1FFEC080, 0074 (r1 ASUS A7V133-C 30303031 MSFT 31313031)
[ 0.000000] ACPI: DSDT 1FFEC100, 2CE1 (r1 ASUS A7V133-C 1000 MSFT 100000B)
[ 0.000000] ACPI: FACS 1FFFF000, 0040
[ 0.000000] ACPI: BOOT 1FFEC040, 0028 (r1 ASUS A7V133-C 30303031 MSFT 31313031)
[ 0.000000] ACPI: PM-Timer IO Port: 0xe408
[ 0.000000] Allocating PCI resources starting at 30000000 (gap: 20000000:dfff0000)
[ 0.000000] swsusp: Registered nosave memory region: 000000000009f000 - 00000000000a0000
[ 0.000000] swsusp: Registered nosave memory region: 00000000000a0000 - 00000000000f0000
[ 0.000000] swsusp: Registered nosave memory region: 00000000000f0000 - 0000000000100000
[ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 130029
[ 0.000000] Kernel command line: root=/dev/mapper/vglinux1-lv_ubuntu2 ro locale=fr_FR video=radeonfb:1280x1024@60 resume=/dev/mapper/vglinux1-lvswap
[ 0.000000] Local APIC disabled by BIOS -- you can enable it with "lapic"
[ 0.000000] mapped APIC to ffffb000 (01406000)
[ 0.000000] Enabling fast FPU save and restore... done.
[ 0.000000] Enabling unmasked SIMD FPU exception support... done.
[ 0.000000] Initializing CPU#0
[ 0.000000] CPU 0 irqstacks, hard=C03C2000 soft=C03C1000
[ 0.000000] PID hash table entries: 2048 (order: 11, 8192 bytes)
[ 0.000000] Detected 1410.216 MHz processor.
[ 22.884407] Console: colour VGA+ 80x25
[ 22.884416] console [tty0] enabled
[ 22.886762] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
[ 22.886826] ... MAX_LOCKDEP_SUBCLASSES: 8
[ 22.886874] ... MAX_LOCK_DEPTH: 30
[ 22.886923] ... MAX_LOCKDEP_KEYS: 2048
[ 22.886971] ... CLASSHASH_SIZE: 1024
[ 22.887020] ... MAX_LOCKDEP_ENTRIES: 8192
[ 22.887067] ... MAX_LOCKDEP_CHAINS: 16384
[ 22.887115] ... CHAINHASH_SIZE: 8192
[ 22.887164] memory used by lock dependency info: 992 kB
[ 22.887214] per task-struct memory footprint: 1200 bytes
[ 22.887265] ------------------------
[ 22.887312] | Locking API testsuite:
[ 22.887358] ----------------------------------------------------------------------------
[ 22.887422] | spin |wlock |rlock |mutex | wsem | rsem |
[ 22.887484] --------------------------------------------------------------------------
[ 22.887557] A-A deadlock: ok | ok | ok | ok | ok | ok |
[ 22.889187] A-B-B-A deadlock: ok | ok | ok | ok | ok | ok |
[ 22.890642] A-B-B-C-C-A deadlock: ok | ok | ok | ok | ok | ok |
[ 22.892120] A-B-C-A-B-C deadlock: ok | ok | ok | ok | ok | ok |
[ 22.893598] A-B-B-C-C-D-D-A deadlock: ok | ok | ok | ok | ok | ok |
[ 22.895101] A-B-C-D-B-D-D-A deadlock: ok | ok | ok | ok | ok | ok |
[ 22.896609] A-B-C-D-B-C-D-A deadlock: ok | ok | ok | ok | ok | ok |
[ 22.898121] double unlock: ok | ok | ok | ok | ok | ok |
[ 22.899557] initialize held: ok | ok | ok | ok | ok | ok |
[ 22.900996] bad unlock order: ok | ok | ok | ok | ok | ok |
[ 22.902460] --------------------------------------------------------------------------
[ 22.902523] recursive read-lock: | ok | | ok |
[ 22.903128] recursive read-lock #2: | ok | | ok |
[ 22.903732] mixed read-write-lock: | ok | | ok |
[ 22.904337] mixed write-read-lock: | ok | | ok |
[ 22.904945] --------------------------------------------------------------------------
[ 22.905009] hard-irqs-on + irq-safe-A/12: ok | ok | ok |
[ 22.905772] soft-irqs-on + irq-safe-A/12: ok | ok | ok |
[ 22.906532] hard-irqs-on + irq-safe-A/21: ok | ok | ok |
[ 22.907291] soft-irqs-on + irq-safe-A/21: ok | ok | ok |
[ 22.908049] sirq-safe-A => hirqs-on/12: ok | ok | ok |
[ 22.908809] sirq-safe-A => hirqs-on/21: ok | ok | ok |
[ 22.909568] hard-safe-A + irqs-on/12: ok | ok | ok |
[ 22.910327] soft-safe-A + irqs-on/12: ok | ok | ok |
[ 22.911086] hard-safe-A + irqs-on/21: ok | ok | ok |
[ 22.911846] soft-safe-A + irqs-on/21: ok | ok | ok |
[ 22.912605] hard-safe-A + unsafe-B #1/123: ok | ok | ok |
[ 22.913377] soft-safe-A + unsafe-B #1/123: ok | ok | ok |
[ 22.914148] hard-safe-A + unsafe-B #1/132: ok | ok | ok |
[ 22.914916] soft-safe-A + unsafe-B #1/132: ok | ok | ok |
[ 22.915686] hard-safe-A + unsafe-B #1/213: ok | ok | ok |
[ 22.916456] soft-safe-A + unsafe-B #1/213: ok | ok | ok |
[ 22.917227] hard-safe-A + unsafe-B #1/231: ok | ok | ok |
[ 22.917996] soft-safe-A + unsafe-B #1/231: ok | ok | ok |
[ 22.918766] hard-safe-A + unsafe-B #1/312: ok | ok | ok |
[ 22.919526] soft-safe-A + unsafe-B #1/312: ok | ok | ok |
[ 22.920290] hard-safe-A + unsafe-B #1/321: ok | ok | ok |
[ 22.921059] soft-safe-A + unsafe-B #1/321: ok | ok | ok |
[ 22.921827] hard-safe-A + unsafe-B #2/123: ok | ok | ok |
[ 22.922597] soft-safe-A + unsafe-B #2/123: ok | ok | ok |
[ 22.923368] hard-safe-A + unsafe-B #2/132: ok | ok | ok |
[ 22.924137] soft-safe-A + unsafe-B #2/132: ok | ok | ok |
[ 22.924907] hard-safe-A + unsafe-B #2/213: ok | ok | ok |
[ 22.925675] soft-safe-A + unsafe-B #2/213: ok | ok | ok |
[ 22.926446] hard-safe-A + unsafe-B #2/231: ok | ok | ok |
[ 22.927214] soft-safe-A + unsafe-B #2/231: ok | ok | ok |
[ 22.927984] hard-safe-A + unsafe-B #2/312: ok | ok | ok |
[ 22.928754] soft-safe-A + unsafe-B #2/312: ok | ok | ok |
[ 22.929525] hard-safe-A + unsafe-B #2/321: ok | ok | ok |
[ 22.930295] soft-safe-A + unsafe-B #2/321: ok | ok | ok |
[ 22.931066] hard-irq lock-inversion/123: ok | ok | ok |
[ 22.931839] soft-irq lock-inversion/123: ok | ok | ok |
[ 22.932615] hard-irq lock-inversion/132: ok | ok | ok |
[ 22.933389] soft-irq lock-inversion/132: ok | ok | ok |
[ 22.934162] hard-irq lock-inversion/213: ok | ok | ok |
[ 22.934934] soft-irq lock-inversion/213: ok | ok | ok |
[ 22.935709] hard-irq lock-inversion/231: ok | ok | ok |
[ 22.936479] soft-irq lock-inversion/231: ok | ok | ok |
[ 22.937251] hard-irq lock-inversion/312: ok | ok | ok |
[ 22.938021] soft-irq lock-inversion/312: ok | ok | ok |
[ 22.938796] hard-irq lock-inversion/321: ok | ok | ok |
[ 22.939568] soft-irq lock-inversion/321: ok | ok | ok |
[ 22.940341] hard-irq read-recursion/123: ok |
[ 22.940652] soft-irq read-recursion/123: ok |
[ 22.940963] hard-irq read-recursion/132: ok |
[ 22.941274] soft-irq read-recursion/132: ok |
[ 22.941587] hard-irq read-recursion/213: ok |
[ 22.941897] soft-irq read-recursion/213: ok |
[ 22.942208] hard-irq read-recursion/231: ok |
[ 22.942518] soft-irq read-recursion/231: ok |
[ 22.942829] hard-irq read-recursion/312: ok |
[ 22.943139] soft-irq read-recursion/312: ok |
[ 22.943450] hard-irq read-recursion/321: ok |
[ 22.943759] soft-irq read-recursion/321: ok |
[ 22.944071] -------------------------------------------------------
[ 22.944126] Good, all 218 testcases passed! |
[ 22.944174] ---------------------------------
[ 22.944870] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
[ 22.945989] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
[ 22.969934] Memory: 510792k/524208k available (1734k kernel code, 12768k reserved, 883k data, 184k init, 0k highmem)
[ 22.970014] virtual kernel memory layout:
[ 22.970016] fixmap : 0xfffb5000 - 0xfffff000 ( 296 kB)
[ 22.970019] vmalloc : 0xe0800000 - 0xfffb3000 ( 503 MB)
[ 22.970021] lowmem : 0xc0000000 - 0xdffec000 ( 511 MB)
[ 22.970023] .init : 0xc0390000 - 0xc03be000 ( 184 kB)
[ 22.970025] .data : 0xc02b18bc - 0xc038e504 ( 883 kB)
[ 22.970027] .text : 0xc0100000 - 0xc02b18bc (1734 kB)
[ 22.970368] Checking if this processor honours the WP bit even in supervisor mode... Ok.
[ 23.051065] Calibrating delay using timer specific routine.. 2824.37 BogoMIPS (lpj=5648753)
[ 23.051383] Mount-cache hash table entries: 512
[ 23.052131] CPU: After generic identify, caps: 0383f9ff c1cbf9ff 00000000 00000000 00000000 00000000 00000000 00000000
[ 23.052147] CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
[ 23.052205] CPU: L2 Cache: 256K (64 bytes/line)
[ 23.052255] CPU: After all inits, caps: 0383f9ff c1cbf9ff 00000000 00000420 00000000 00000000 00000000 00000000
[ 23.052267] Intel machine check architecture supported.
[ 23.052319] Intel machine check reporting enabled on CPU#0.
[ 23.052376] Compat vDSO mapped to ffffe000.
[ 23.052441] CPU: AMD Athlon(TM) XP 1600+ stepping 02
[ 23.052557] Checking 'hlt' instruction... OK.
[ 23.067300] Freeing SMP alternatives: 0k freed
[ 23.067349] ACPI: Core revision 20070126
[ 23.072552] Parsing all Control Methods:
[ 23.072681] Table [DSDT](id 0001) - 356 Objects with 38 Devices 115 Methods 24 Regions
[ 23.072782] tbxface-0598 [00] tb_load_namespace : ACPI Tables successfully acquired
[ 23.072914] ACPI: setting ELCR to 0200 (from 0820)
[ 23.073065] evxfevnt-0091 [00] enable : Transition to ACPI mode successful
[ 23.074112] khelper used greatest stack depth: 3172 bytes left
[ 23.074581] net_namespace: 76 bytes
[ 23.075809] NET: Registered protocol family 16
[ 23.077047] ACPI: bus type pci registered
[ 23.079899] PCI: PCI BIOS revision 2.10 entry at 0xf1180, last bus=1
[ 23.080300] PCI: Using configuration type 1
[ 23.080349] Setting up standard PCI resources
[ 23.089819] khelper used greatest stack depth: 3064 bytes left
[ 23.094177] evgpeblk-0956 [00] ev_create_gpe_block : GPE 00 to 0F [_GPE] 2 regs on int 0x9
[ 23.096633] evgpeblk-1052 [00] ev_initialize_gpe_bloc: Found 4 Wake, Enabled 0 Runtime GPEs in this block
[ 23.096774] ACPI: EC: Look up EC in DSDT
[ 23.100425] Completing Region/Field/Buffer/Package initialization:................................................
[ 23.107399] Initialized 16/24 Regions 2/2 Fields 19/19 Buffers 11/14 Packages (365 nodes)
[ 23.107501] Initializing Device/Processor/Thermal objects by executing _INI methods:
[ 23.107592] Executed 0 _INI methods requiring 0 _STA executions (examined 41 objects)
[ 23.107780] ACPI: Interpreter enabled
[ 23.107830] ACPI: (supports S0 S1 S3 S4 S5)
[ 23.108118] ACPI: Using PIC for interrupt routing
[ 23.134108] ACPI: PCI Root Bridge [PCI0] (0000:00)
[ 23.135036] PCI quirk: region e200-e27f claimed by vt82c686 HW-mon
[ 23.135123] PCI quirk: region e800-e80f claimed by vt82c686 SMB
[ 23.135717] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
[ 23.287800] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11 12 14 15)
[ 23.288493] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, disabled.
[ 23.289235] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, disabled.
[ 23.290017] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 *5 6 7 9 10 11 12 14 15)
[ 23.290844] Linux Plug and Play Support v0.97 (c) Adam Belay
[ 23.291166] pnp: PnP ACPI init
[ 23.291262] ACPI: bus type pnp registered
[ 23.300586] pnp: PnP ACPI: found 14 devices
[ 23.300648] ACPI: ACPI bus type pnp unregistered
[ 23.302100] PCI: Using ACPI for IRQ routing
[ 23.302153] PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report
[ 23.327027] Time: tsc clocksource has been installed.
[ 23.335311] system 00:00: iomem range 0x0-0x9ffff could not be reserved
[ 23.335371] system 00:00: iomem range 0xf0000-0xfffff could not be reserved
[ 23.335430] system 00:00: iomem range 0x100000-0x1fffffff could not be reserved
[ 23.335496] system 00:00: iomem range 0xfffe0000-0xffffffff could not be reserved
[ 23.335579] system 00:02: ioport range 0x3f0-0x3f1 has been reserved
[ 23.335636] system 00:02: ioport range 0x4d0-0x4d1 has been reserved
[ 23.335708] system 00:03: ioport range 0xe400-0xe47f has been reserved
[ 23.335765] system 00:03: ioport range 0xe800-0xe80f has been reserved
[ 23.368445] PCI: Bridge: 0000:00:01.0
[ 23.368500] IO window: d000-dfff
[ 23.368551] MEM window: b7000000-b7ffffff
[ 23.368602] PREFETCH window: b8000000-cfffffff
[ 23.368677] PCI: Setting latency timer of device 0000:00:01.0 to 64
[ 23.368757] NET: Registered protocol family 2
[ 23.403206] IP route cache hash table entries: 4096 (order: 2, 16384 bytes)
[ 23.404092] TCP established hash table entries: 16384 (order: 5, 131072 bytes)
[ 23.404621] TCP bind hash table entries: 16384 (order: 7, 524288 bytes)
[ 23.406957] TCP: Hash tables configured (established 16384 bind 16384)
[ 23.407128] TCP reno registered
[ 23.420600] checking if image is initramfs... it is
[ 23.870982] Switched to NOHz mode on CPU #0
[ 23.918866] Freeing initrd memory: 3197k freed
[ 23.919595] Simple Boot Flag at 0x3a set to 0x1
[ 23.923543] io scheduler noop registered
[ 23.923604] io scheduler anticipatory registered
[ 23.923654] io scheduler deadline registered
[ 23.923727] io scheduler cfq registered (default)
[ 23.923792] Applying VIA southbridge workaround.
[ 23.923845] PCI: VIA PCI bridge detected. Disabling DAC.
[ 23.923898] PCI: Disabling Via external APIC routing
[ 23.923989] Boot video device is 0000:01:00.0
[ 23.925776] ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 11
[ 23.925837] PCI: setting IRQ 11 as level-triggered
[ 23.925844] ACPI: PCI Interrupt 0000:01:00.0[A] -> Link [LNKA] -> GSI 11 (level, low) -> IRQ 11
[ 23.926143] radeonfb: Found Intel x86 BIOS ROM Image
[ 23.926200] radeonfb: Retrieved PLL infos from BIOS
[ 23.926252] radeonfb: Reference=27.00 MHz (RefDiv=12) Memory=250.00 Mhz, System=166.00 MHz
[ 23.926317] radeonfb: PLL min 20000 max 40000
[ 24.006702] i2c-adapter i2c-1: unable to read EDID block.
[ 24.130631] i2c-adapter i2c-1: unable to read EDID block.
[ 24.254602] i2c-adapter i2c-1: unable to read EDID block.
[ 24.378592] i2c-adapter i2c-3: unable to read EDID block.
[ 24.502559] i2c-adapter i2c-3: unable to read EDID block.
[ 24.626531] i2c-adapter i2c-3: unable to read EDID block.
[ 24.890696] radeonfb: Monitor 1 type CRT found
[ 24.890763] radeonfb: EDID probed
[ 24.890810] radeonfb: Monitor 2 type no found
[ 24.939657] Console: switching to colour frame buffer device 160x64
[ 24.978303] radeonfb (0000:01:00.0): ATI Radeon Ya
[ 24.979794] input: Power Button (FF) as /class/input/input0
[ 24.979882] ACPI: Power Button (FF) [PWRF]
[ 24.980293] input: Power Button (CM) as /class/input/input1
[ 24.980367] ACPI: Power Button (CM) [PWRB]
[ 24.981341] ACPI: CPU0 (power states: C1[C1] C2[C2])
[ 24.981457] ACPI: Processor [CPU0] (supports 16 throttling states)
[ 25.015443] RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
[ 25.016038] PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 0x60,0x64 irq 1,12
[ 25.016973] serio: i8042 KBD port at 0x60,0x64 irq 1
[ 25.017057] serio: i8042 AUX port at 0x60,0x64 irq 12
[ 25.018012] mice: PS/2 mouse device common for all mice
[ 25.029741] Marking TSC unstable due to: possible TSC halt in C2.
[ 25.030719] Time: acpi_pm clocksource has been installed.
[ 25.039605] input: AT Translated Set 2 keyboard as /class/input/input2
[ 25.054670] TCP cubic registered
[ 25.054759] NET: Registered protocol family 1
[ 25.054863] Using IPI Shortcut mode
[ 25.056562] BIOS EDD facility v0.16 2004-Jun-25, 6 devices found
[ 25.058363] Freeing unused kernel memory: 184k freed
[ 25.058540] Write protecting the kernel text: 1736k
[ 25.058606] Write protecting the kernel read-only data: 700k
[ 25.061832] busybox used greatest stack depth: 2900 bytes left
[ 25.072401] exe used greatest stack depth: 2864 bytes left
[ 25.175794] exe used greatest stack depth: 2652 bytes left
[ 25.240831] input: ImExPS/2 Generic Explorer Mouse as /class/input/input3
[ 25.261513] consolechars used greatest stack depth: 2556 bytes left
[ 25.483644] device-mapper: uevent: version 1.0.3
[ 25.484060] device-mapper: ioctl: 4.13.0-ioctl (2007-10-18) initialised: [email protected]
[ 25.506481] SCSI subsystem initialized
[ 25.517545] libata version 3.00 loaded.
[ 25.520583] pata_via 0000:00:04.1: version 0.3.3
[ 25.521256] scsi0 : pata_via
[ 25.521711] scsi1 : pata_via
[ 25.524089] ata1: PATA max UDMA/100 cmd 0x1f0 ctl 0x3f6 bmdma 0xb800 irq 14
[ 25.524176] ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xb808 irq 15
[ 25.683141] ata1.00: ATA-5: ST340016A, 3.75, max UDMA/100
[ 25.683208] ata1.00: 78165360 sectors, multi 16: LBA
[ 25.683475] ata1.01: ATA-7: Maxtor 6Y080L0, YAR41BW0, max UDMA/133
[ 25.684116] ata1.01: 160086528 sectors, multi 16: LBA
[ 25.691127] ata1.00: configured for UDMA/100
[ 25.699142] ata1.01: configured for UDMA/100
[ 26.170860] ata2.00: ATAPI: HL-DT-ST DVDRAM GSA-4165B, DL05, max UDMA/33
[ 26.171562] ata2.01: ATAPI: CD-950E/AKU, A4Q, max MWDMA2, CDB intr
[ 26.330839] ata2.00: configured for UDMA/33
[ 26.490828] ata2.01: configured for MWDMA2
[ 26.503014] scsi 0:0:0:0: Direct-Access ATA ST340016A 3.75 PQ: 0 ANSI: 5
[ 26.504670] scsi 0:0:1:0: Direct-Access ATA Maxtor 6Y080L0 YAR4 PQ: 0 ANSI: 5
[ 26.509842] scsi 1:0:0:0: CD-ROM HL-DT-ST DVDRAM GSA-4165B DL05 PQ: 0 ANSI: 5
[ 26.511673] scsi 1:0:1:0: CD-ROM E-IDE CD-950E/AKU A4Q PQ: 0 ANSI: 5
[ 26.513278] modprobe used greatest stack depth: 2152 bytes left
[ 26.527262] sd 0:0:0:0: [sda] 78165360 512-byte hardware sectors (40021 MB)
[ 26.528154] sd 0:0:0:0: [sda] Write Protect is off
[ 26.528961] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 26.529033] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 26.530146] sd 0:0:0:0: [sda] 78165360 512-byte hardware sectors (40021 MB)
[ 26.531224] sd 0:0:0:0: [sda] Write Protect is off
[ 26.532082] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 26.532151] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 26.533090] sda: sda1 sda2 sda3 < sda5 sda6 sda7 > sda4
[ 26.581919] sd 0:0:0:0: [sda] Attached SCSI disk
[ 26.583274] sd 0:0:1:0: [sdb] 160086528 512-byte hardware sectors (81964 MB)
[ 26.584268] sd 0:0:1:0: [sdb] Write Protect is off
[ 26.585211] sd 0:0:1:0: [sdb] Mode Sense: 00 3a 00 00
[ 26.585282] sd 0:0:1:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 26.586508] sd 0:0:1:0: [sdb] 160086528 512-byte hardware sectors (81964 MB)
[ 26.587530] sd 0:0:1:0: [sdb] Write Protect is off
[ 26.588492] sd 0:0:1:0: [sdb] Mode Sense: 00 3a 00 00
[ 26.588564] sd 0:0:1:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 26.589603] sdb: sdb1 sdb2 < sdb5 sdb6 sdb7 >
[ 26.639851] sd 0:0:1:0: [sdb] Attached SCSI disk
[ 26.641160] modprobe used greatest stack depth: 1964 bytes left
[ 29.780014] Attempting manual resume
[ 29.844555] ReiserFS: dm-10: found reiserfs format "3.6" with standard journal
[ 29.845623] ReiserFS: dm-10: using ordered data mode
[ 29.876338] ReiserFS: dm-10: journal params: device dm-10, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
[ 29.881733] ReiserFS: dm-10: checking transaction log (dm-10)
[ 29.994198] ReiserFS: dm-10: Using r5 hash to sort names
[ 29.995523] exe used greatest stack depth: 1620 bytes left
[ 41.338877] Linux agpgart interface v0.102
[ 41.365338] agpgart: Detected VIA Twister-K/KT133x/KM133 chipset
[ 41.455791] agpgart: AGP aperture is 256M @ 0xd0000000
[ 41.639237] parport_pc: VIA 686A/8231 detected
[ 41.639244] parport_pc: probing current configuration
[ 41.639266] parport_pc: Current parallel port base: 0x378
[ 41.639446] parport0: PC-style at 0x378 (0x778), irq 7 [PCSPP,TRISTATE]
[ 41.736002] parport_pc: VIA parallel port: io=0x378, irq=7
[ 41.826262] usbcore: registered new interface driver usbfs
[ 41.827814] usbcore: registered new interface driver hub
[ 41.838329] usbcore: registered new device driver usb
[ 41.842033] via686a 0000:00:04.4: Forcing ISA address 0xe200
[ 41.843094] via686a 0000:00:04.4: Enabling sensors
[ 41.857018] ACPI: I/O resource vt596_smbus [0xe800-0xe807] conflicts with ACPI region SM00 [0xe800-0xe806]
[ 41.858112] ACPI: Device needs an ACPI driver
[ 41.859147] vt596_smbus: probe of 0000:00:04.4 failed with error -16
[ 41.874600] PCI: Enabling device 0000:00:09.0 (0014 -> 0016)
[ 41.876608] ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 5
[ 41.877642] PCI: setting IRQ 5 as level-triggered
[ 41.877649] ACPI: PCI Interrupt 0000:00:09.0[A] -> Link [LNKD] -> GSI 5 (level, low) -> IRQ 5
[ 41.892852] input: PC Speaker as /class/input/input4
[ 41.941506] ne2k-pci.c:v1.03 9/22/2003 D. Becker/P. Gortmaker
[ 41.958451] USB Universal Host Controller Interface driver v3.0
[ 42.017891] sd 0:0:0:0: Attached scsi generic sg0 type 0
[ 42.032784] sd 0:0:1:0: Attached scsi generic sg1 type 0
[ 42.034064] scsi 1:0:0:0: Attached scsi generic sg2 type 5
[ 42.035203] scsi 1:0:1:0: Attached scsi generic sg3 type 5
[ 42.104236] sr0: scsi3-mmc drive: 48x/48x writer dvd-ram cd/rw xa/form2 cdda tray
[ 42.105276] Uniform CD-ROM driver Revision: 3.20
[ 42.123106] sr 1:0:0:0: Attached scsi CD-ROM sr0
[ 42.135665] sr1: scsi3-mmc drive: 0x/48x cd/rw xa/form2 cdda tray
[ 42.145075] Real Time Clock Driver v1.12ac
[ 42.155668] sr 1:0:1:0: Attached scsi CD-ROM sr1
[ 42.277609] Floppy drive(s): fd0 is 1.44M
[ 42.299599] FDC 0 is a post-1991 82077
[ 42.336396] ohci1394: fw-host0: OHCI-1394 1.0 (PCI): IRQ=[5] MMIO=[b6800000-b68007ff] Max Packet=[2048] IR/IT contexts=[8/8]
[ 42.376753] Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
[ 42.392166] serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[ 42.419779] serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
[ 42.467724] PCI: Enabling device 0000:00:0b.0 (0000 -> 0001)
[ 42.470235] ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 11
[ 42.471237] ACPI: PCI Interrupt 0000:00:0b.0[A] -> Link [LNKB] -> GSI 11 (level, low) -> IRQ 11
[ 42.474128] eth0: RealTek RTL-8029 found at 0x9400, IRQ 11, 00:40:95:46:6e:2d.
[ 42.475610] ACPI: PCI Interrupt 0000:00:04.2[D] -> Link [LNKD] -> GSI 5 (level, low) -> IRQ 5
[ 42.476711] uhci_hcd 0000:00:04.2: UHCI Host Controller
[ 42.478965] uhci_hcd 0000:00:04.2: new USB bus registered, assigned bus number 1
[ 42.480365] uhci_hcd 0000:00:04.2: irq 5, io base 0x0000b400
[ 42.482290] usb usb1: configuration #1 chosen from 1 choice
[ 42.483685] hub 1-0:1.0: USB hub found
[ 42.484993] hub 1-0:1.0: 2 ports detected
[ 42.552689] 00:0a: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[ 42.554316] 00:0b: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
[ 42.588475] usb usb1: new device found, idVendor=0000, idProduct=0000
[ 42.589655] usb usb1: new device strings: Mfr=3, Product=2, SerialNumber=1
[ 42.590616] usb usb1: Product: UHCI Host Controller
[ 42.592260] usb usb1: Manufacturer: Linux 2.6.24-rc3-mm1 uhci_hcd
[ 42.593218] usb usb1: SerialNumber: 0000:00:04.2
[ 42.594289] ACPI: PCI Interrupt 0000:00:04.3[D] -> Link [LNKD] -> GSI 5 (level, low) -> IRQ 5
[ 42.595339] uhci_hcd 0000:00:04.3: UHCI Host Controller
[ 42.596598] uhci_hcd 0000:00:04.3: new USB bus registered, assigned bus number 2
[ 42.597652] uhci_hcd 0000:00:04.3: irq 5, io base 0x0000b000
[ 42.599191] usb usb2: configuration #1 chosen from 1 choice
[ 42.600584] hub 2-0:1.0: USB hub found
[ 42.601596] hub 2-0:1.0: 2 ports detected
[ 42.704030] usb usb2: new device found, idVendor=0000, idProduct=0000
[ 42.705073] usb usb2: new device strings: Mfr=3, Product=2, SerialNumber=1
[ 42.706080] usb usb2: Product: UHCI Host Controller
[ 42.707068] usb usb2: Manufacturer: Linux 2.6.24-rc3-mm1 uhci_hcd
[ 42.708509] usb usb2: SerialNumber: 0000:00:04.3
[ 42.811540] usb 1-1: new full speed USB device using uhci_hcd and address 2
[ 42.974026] usb 1-1: configuration #1 chosen from 1 choice
[ 42.978609] hub 1-1:1.0: USB hub found
[ 42.981379] hub 1-1:1.0: 4 ports detected
[ 43.099312] usb 1-1: new device found, idVendor=05e3, idProduct=0606
[ 43.100430] usb 1-1: new device strings: Mfr=0, Product=1, SerialNumber=0
[ 43.101457] usb 1-1: Product: USB2.0 Hub
[ 43.467102] PCI: Enabling device 0000:00:0d.0 (0004 -> 0005)
[ 43.470645] ACPI: PCI Interrupt 0000:00:0d.0[A] -> Link [LNKD] -> GSI 5 (level, low) -> IRQ 5
[ 43.728051] ieee1394: Host added: ID:BUS[0-00:1023] GUID[00308d0120e085ca]
[ 59.341540] ReiserFS: dm-0: found reiserfs format "3.6" with standard journal
[ 59.341569] ReiserFS: dm-0: using ordered data mode
[ 59.346608] ReiserFS: dm-0: journal params: device dm-0, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
[ 59.349822] ReiserFS: dm-0: checking transaction log (dm-0)
[ 59.404729] ReiserFS: dm-0: Using r5 hash to sort names
[ 59.614980] Loading Reiser4. See http://www.namesys.com for a description of Reiser4.
[ 59.616355] modprobe used greatest stack depth: 1552 bytes left
[ 59.631731] reiser4: dm-5: found disk format 4.0.0.
[ 59.890236] reiser4: dm-4: found disk format 4.0.0.
[ 60.091592] EXT3-fs warning: maximal mount count reached, running e2fsck is recommended
[ 60.091681] kjournald starting. Commit interval 5 seconds
[ 60.091911] EXT3 FS on sda5, internal journal
[ 60.091989] EXT3-fs: mounted filesystem with ordered data mode.
[ 60.216113] sd 0:0:0:0: [sda] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK,SUGGEST_OK
[ 60.216124] end_request: I/O error, dev sda, sector 16460
[ 60.245789] ReiserFS: sda7: found reiserfs format "3.6" with standard journal
[ 60.245829] ReiserFS: sda7: using ordered data mode
[ 60.251474] ReiserFS: sda7: journal params: device sda7, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
[ 60.254845] ReiserFS: sda7: checking transaction log (sda7)
[ 60.297870] ReiserFS: sda7: Using r5 hash to sort names
[ 60.351096] sd 0:0:1:0: [sdb] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK,SUGGEST_OK
[ 60.351107] end_request: I/O error, dev sdb, sector 19632
[ 60.392984] sd 0:0:1:0: [sdb] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK,SUGGEST_OK
[ 60.392995] end_request: I/O error, dev sdb, sector 40037363
[ 60.611920] Adding 1048568k swap on /dev/mapper/vglinux1-lvswap. Priority:-1 extents:1 across:1048568k
[ 67.273626] lp0: using parport0 (interrupt-driven).
[ 67.991472] [drm] Initialized drm 1.1.0 20060810
[ 68.024210] [drm] Initialized radeon 1.28.0 20060524 on minor 0
[ 69.882699] agpgart: Found an AGP 2.0 compliant device at 0000:00:00.0.
[ 69.883411] agpgart: Putting AGP V2 device at 0000:00:00.0 into 4x mode
[ 69.883933] agpgart: Putting AGP V2 device at 0000:01:00.0 into 4x mode
[ 70.305388] [drm] Setting GART location based on new memory map
[ 70.305410] [drm] Loading R200 Microcode
[ 70.305452] [drm] writeback test succeeded in 1 usecs
[ 70.920327] warning: process `avahi-daemon' sets w/ old libcap
[ 70.927975] warning: process `avahi-daemon' sets w/ old libcap
[ 70.931271] warning: process `avahi-daemon' sets w/ old libcap
[ 70.945490] warning: process `avahi-daemon' sets w/ old libcap
[ 323.784537] agpgart: Found an AGP 2.0 compliant device at 0000:00:00.0.
[ 323.784574] agpgart: Putting AGP V2 device at 0000:00:00.0 into 4x mode
[ 323.784636] agpgart: Putting AGP V2 device at 0000:01:00.0 into 4x mode
[ 323.784658] [drm] Loading R200 Microcode
[ 334.964720] dmesg used greatest stack depth: 1292 bytes left


Attachments:
dmesg-2.6.24-rc3-mm1-patched (29.82 kB)

2007-11-25 07:38:10

by James Bottomley

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1: I/O error, system hangs

On Sat, 2007-11-24 at 23:59 +0100, Laurent Riffard wrote:
> Le 24.11.2007 14:26, James Bottomley a écrit :
> > OK, could you post dmesgs again, please. I actually tested this
> with an
> > aic79xx card, and for me it does cause Domain Validation to succeed
> > again.
>
> James,
>
> Here is a dmesg produced by 2.6.24-rc3-mm1 + your patch "separates
> the
> BLOCK and QUIESCE states
> correctly" (http://lkml.org/lkml/2007/11/24/8).
>
> How to reproduce :
> - boot
> - switch to a text console
> - capture dmesg in a file, sync, etc. There are 3 I/O errors, but the
> system does work.
> - switch to X console, log in the Gnome Desktop, the system partially
> hangs.
> - switch back to a text console: dmesg(1) still works, it shows some
> additonal I/O errors. At this point, any disk access makes the
> system
> completely hung.
>
> Additionnal data:
> - the I/O errors always happen on the same blocks.
>
> plain text document attachment (dmesg-2.6.24-rc3-mm1-patched)
[...]
> [ 25.521256] scsi0 : pata_via
> [ 25.521711] scsi1 : pata_via
> [ 25.524089] ata1: PATA max UDMA/100 cmd 0x1f0 ctl 0x3f6 bmdma
> 0xb800 irq 14
> [ 25.524176] ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma
> 0xb808 irq 15
> [ 25.683141] ata1.00: ATA-5: ST340016A, 3.75, max UDMA/100
> [ 25.683208] ata1.00: 78165360 sectors, multi 16: LBA
> [ 25.683475] ata1.01: ATA-7: Maxtor 6Y080L0, YAR41BW0, max UDMA/133
> [ 25.684116] ata1.01: 160086528 sectors, multi 16: LBA
> [ 25.691127] ata1.00: configured for UDMA/100
> [ 25.699142] ata1.01: configured for UDMA/100
> [ 26.170860] ata2.00: ATAPI: HL-DT-ST DVDRAM GSA-4165B, DL05, max
> UDMA/33
> [ 26.171562] ata2.01: ATAPI: CD-950E/AKU, A4Q, max MWDMA2, CDB intr
> [ 26.330839] ata2.00: configured for UDMA/33
> [ 26.490828] ata2.01: configured for MWDMA2
> [ 26.503014] scsi 0:0:0:0: Direct-Access ATA ST340016A
> 3.75 PQ: 0 ANSI: 5
> [ 26.504670] scsi 0:0:1:0: Direct-Access ATA Maxtor 6Y080L0
> YAR4 PQ: 0 ANSI: 5
> [ 26.509842] scsi 1:0:0:0: CD-ROM HL-DT-ST DVDRAM
> GSA-4165B DL05 PQ: 0 ANSI: 5
> [ 26.511673] scsi 1:0:1:0: CD-ROM E-IDE CD-950E/AKU
> A4Q PQ: 0 ANSI: 5
[...]
> [ 60.216113] sd 0:0:0:0: [sda] Result: hostbyte=DID_NO_CONNECT
> driverbyte=DRIVER_OK,SUGGEST_OK
> [ 60.216124] end_request: I/O error, dev sda, sector 16460

I think this one's quite easy: PATA devices in libata are queue depth 1
(since they don't do NCQ). Thus, they're peculiarly sensitive to the
bug where we fail over queue depth requests.

On the other hand, I don't see how a filesystem request is getting
REQ_FAILFAST ... unless there's a bio or readahead issue involved.
Anyway, could you try this patch:

http://marc.info/?l=linux-scsi&m=119592627425498

Which should fix the queue depth issue, and see if the errors go away?

Thanks,

James


2007-11-25 20:39:54

by Laurent Riffard

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1: I/O error, system hangs

Le 25.11.2007 08:37, James Bottomley a écrit :
> On Sat, 2007-11-24 at 23:59 +0100, Laurent Riffard wrote:
>> Le 24.11.2007 14:26, James Bottomley a écrit :
>>> OK, could you post dmesgs again, please. I actually tested this
>> with an
>>> aic79xx card, and for me it does cause Domain Validation to succeed
>>> again.
>> James,
>>
>> Here is a dmesg produced by 2.6.24-rc3-mm1 + your patch "separates
>> the
>> BLOCK and QUIESCE states
>> correctly" (http://lkml.org/lkml/2007/11/24/8).
>>
>> How to reproduce :
>> - boot
>> - switch to a text console
>> - capture dmesg in a file, sync, etc. There are 3 I/O errors, but the
>> system does work.
>> - switch to X console, log in the Gnome Desktop, the system partially
>> hangs.
>> - switch back to a text console: dmesg(1) still works, it shows some
>> additonal I/O errors. At this point, any disk access makes the system
>> completely hung.
>>
>> Additionnal data:
>> - the I/O errors always happen on the same blocks.
>>
>> plain text document attachment (dmesg-2.6.24-rc3-mm1-patched)
> [...]
>> [ 25.521256] scsi0 : pata_via
>> [ 25.521711] scsi1 : pata_via
>> [ 25.524089] ata1: PATA max UDMA/100 cmd 0x1f0 ctl 0x3f6 bmdma 0xb800 irq 14
>> [ 25.524176] ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xb808 irq 15
>> [ 25.683141] ata1.00: ATA-5: ST340016A, 3.75, max UDMA/100
>> [ 25.683208] ata1.00: 78165360 sectors, multi 16: LBA
>> [ 25.683475] ata1.01: ATA-7: Maxtor 6Y080L0, YAR41BW0, max UDMA/133
>> [ 25.684116] ata1.01: 160086528 sectors, multi 16: LBA
>> [ 25.691127] ata1.00: configured for UDMA/100
>> [ 25.699142] ata1.01: configured for UDMA/100
>> [ 26.170860] ata2.00: ATAPI: HL-DT-ST DVDRAM GSA-4165B, DL05, max UDMA/33
>> [ 26.171562] ata2.01: ATAPI: CD-950E/AKU, A4Q, max MWDMA2, CDB intr
>> [ 26.330839] ata2.00: configured for UDMA/33
>> [ 26.490828] ata2.01: configured for MWDMA2
>> [ 26.503014] scsi 0:0:0:0: Direct-Access ATA ST340016A 3.75 PQ: 0 ANSI: 5
>> [ 26.504670] scsi 0:0:1:0: Direct-Access ATA Maxtor 6Y080L0 YAR4 PQ: 0 ANSI: 5
>> [ 26.509842] scsi 1:0:0:0: CD-ROM HL-DT-ST DVDRAM GSA-4165B DL05 PQ: 0 ANSI: 5
>> [ 26.511673] scsi 1:0:1:0: CD-ROM E-IDE CD-950E/AKU A4Q PQ: 0 ANSI: 5
> [...]
>> [ 60.216113] sd 0:0:0:0: [sda] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK,SUGGEST_OK
>> [ 60.216124] end_request: I/O error, dev sda, sector 16460
>
> I think this one's quite easy: PATA devices in libata are queue depth 1
> (since they don't do NCQ). Thus, they're peculiarly sensitive to the
> bug where we fail over queue depth requests.
>
> On the other hand, I don't see how a filesystem request is getting
> REQ_FAILFAST ... unless there's a bio or readahead issue involved.
> Anyway, could you try this patch:
>
> http://marc.info/?l=linux-scsi&m=119592627425498
>
> Which should fix the queue depth issue, and see if the errors go away?

No, this one doesn't help...

--
laurent

2007-11-26 07:03:33

by Kamezawa Hiroyuki

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1 (sync is slow ?)

On Sat, 24 Nov 2007 19:04:34 +0100
Gabriel C <[email protected]> wrote:
> >> It seems OK here from a quick test (i386, ext3-on-IDE).
> >>
> >> Maybe device driver/block breakage?
>
> Try revert
>
> http://git.kernel.org/?p=linux/kernel/git/jejb/scsi-misc-2.6.git;a=commitdiff_plain;h=8655a546c83fc43f0a73416bbd126d02de7ad6c0;hp=5bc717b6bdaaf52edf365eb7d9d8c89fec79df5d
>
> See also :
> http://lkml.org/lkml/2007/11/23/5
>
> and search for '2.6.24-rc3-mm1: I/O error, system hangs' on LKML
>

Thank you!
The problem was fixed by reverting the patch you pointed out.

-Kame

2007-11-26 07:54:40

by Hannes Reinecke

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1: I/O error, system hangs

On Sat, Nov 24, 2007 at 07:44:13PM +0200, James Bottomley wrote:
> Probing intermittent failures in Domain Validation, even with the fixes
> applied leads me to the conclusion that there are further problems with
> this commit:
>
> commit fc5eb4facedbd6d7117905e775cee1975f894e79
> Author: Hannes Reinecke <[email protected]>
> Date: Tue Nov 6 09:23:40 2007 +0100
>
> [SCSI] Do not requeue requests if REQ_FAILFAST is set
>
> The essence of the problems is that you're causing REQ_FAILFAST to
> terminate commands with error on requeuing conditions, some of which are
> relatively common on most SCSI devices. While this may be the correct
> behaviour for multi-path, it's certainly wrong for the previously
> understood meaning of REQ_FAILFAST, which was don't retry on error,
> which is why domain validation and other applications use it to control
> error handling, but don't expect to get failures for a simple requeue
> are now spitting errors.
>
> I honestly can't see that, even for the multi-path case, returning an
> error when we're over queue depth is the correct thing to do (it may not
> matter to something like a symmetrix, but an array that has a non-zero
> cost associated with a path change, like a CPQ HSV or the AVT
> controllers, will show fairly large slow downs if you do this). Even if
> this is the desired behaviour (and I think that's a policy issue),
> DID_NO_CONNECT is almost certainly the wrong error to be sending back.
>
> This patch fixes up domain validation to work again correctly, however,
> I really think it's just a bandaid. Do you want to rethink the above
> commit?
>
Given the amounted error, yes, I'll have to.
But we still face the initial problem that requeued requests will be
stuck in the queue forever (ie until the timeout catches it), causing
failover to be painfully slow.

Anyway, I'll think it over.

Cheers,

Hannes
--
Dr. Hannes Reinecke zSeries & Storage
[email protected] +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N�rnberg
GF: Markus Rex, HRB 16746 (AG N�rnberg)

2007-11-26 18:48:46

by Rik van Riel

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1

On Wed, 21 Nov 2007 14:03:34 +0800
"Dave Young" <[email protected]> wrote:
> On Nov 21, 2007 2:00 PM, Andrew Morton <[email protected]> wrote:
> > On Wed, 21 Nov 2007 13:51:47 +0800 "Dave Young" <[email protected]> wrote:
> >
> > > Hi, andrew
> > >
> > > modpost failed for me:
> > > MODPOST 360 modules
> > > ERROR: "empty_zero_page" [drivers/kvm/kvm.ko] undefined!
> > > make[1]: *** [__modpost] Error 1
> > > make: *** [modules] Error 2
> > >
> >
> > You're a victim of the hasty unexporting fad. Which architecture?
> > x86_64 I guess?

> ia32 instead.

FYI, x86_64 has the exact same issue.

----
KVM needs the empty_zero_page export reinstated.

Signed-off-by: Rik van Riel <[email protected]>

diff -up linux-2.6.24-rc3-mm1/arch/x86/kernel/x8664_ksyms_64.c.export-empty-zero-page linux-2.6.24-rc3-mm1/arch/x86/kernel/x8664_ksyms_64.c
--- linux-2.6.24-rc3-mm1/arch/x86/kernel/x8664_ksyms_64.c.export-empty-zero-page 2007-11-26 13:47:53.000000000 -0500
+++ linux-2.6.24-rc3-mm1/arch/x86/kernel/x8664_ksyms_64.c 2007-11-26 13:41:32.000000000 -0500
@@ -33,6 +33,7 @@ EXPORT_SYMBOL(__copy_from_user_inatomic)

EXPORT_SYMBOL(copy_page);
EXPORT_SYMBOL(clear_page);
+EXPORT_SYMBOL(empty_zero_page);

/* Export string functions. We normally rely on gcc builtin for most of these,
but gcc sometimes decides not to inline them. */

2007-11-26 19:14:17

by Randy Dunlap

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1

On Tue, 20 Nov 2007 20:45:25 -0800 Andrew Morton wrote:

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

allnoconfig on x86_64 gives:

arch/x86/mm/init_64.c:84: error: implicit declaration of function 'pfn_valid'
mm/page_alloc.c:2533: error: implicit declaration of function 'pfn_valid'
mm/vmstat.c:518: error: implicit declaration of function 'pfn_valid'
mm/memory.c:400: error: implicit declaration of function 'pfn_valid'
drivers/char/mem.c:312: error: implicit declaration of function 'pfn_valid'


---
~Randy

2007-11-26 19:33:20

by Jiri Slaby

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1

On 11/26/2007 07:48 PM, Rik van Riel wrote:
>>>> ERROR: "empty_zero_page" [drivers/kvm/kvm.ko] undefined!
[...]
> FYI, x86_64 has the exact same issue.

yes:
hot-fixes/git-x86-dont-unexport-empty_zero_page.patch

regards,
--
Jiri Slaby ([email protected])
Faculty of Informatics, Masaryk University

2007-11-26 19:34:33

by Christoph Lameter

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1

On Mon, 26 Nov 2007, Randy Dunlap wrote:

> On Tue, 20 Nov 2007 20:45:25 -0800 Andrew Morton wrote:
>
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc3/2.6.24-rc3-mm1/
>
> allnoconfig on x86_64 gives:
>
> arch/x86/mm/init_64.c:84: error: implicit declaration of function 'pfn_valid'
> mm/page_alloc.c:2533: error: implicit declaration of function 'pfn_valid'
> mm/vmstat.c:518: error: implicit declaration of function 'pfn_valid'
> mm/memory.c:400: error: implicit declaration of function 'pfn_valid'
> drivers/char/mem.c:312: error: implicit declaration of function 'pfn_valid'

Hmmm... CONFIG_SPARSEMEM is not set if you do allnoconfig

config SPARSEMEM
def_bool y
depends on SPARSEMEM_MANUAL

So I guess we need to set SPARSEMEM_MANUAL

But arch/x86/Kconfig has

config SPARSEMEM_MANUAL
bool "Sparse Memory"
depends on ARCH_SPARSEMEM_ENABLE
help
This will be the only option for some systems, including
memory hotplug systems. This is normal.

It needs to be not deselectable for x86_64.

Inserting

def_bool y if X86_64

did not help....

Somehow make menuconfig did not give me an ability to even enable this
again.

2007-11-26 19:40:58

by Rik van Riel

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1 - Kernel Panic on IO-APIC

On Tue, 20 Nov 2007 22:18:39 -0800
Andrew Morton <[email protected]> wrote:

> > ..MP-BIOS bug: 8254 timer not connected to IO-APIC
> > Kernel panic - not syncing: IO-APIC + timer doesn't work! Try using the 'noapic' kernel parameter
>
> ACPI or x86 breakage, I guess.
>
> Did 'noapic' work?

I got the same bug as above, 'noapic' gets past that point and right to the
next oops. I'm posting it here because this one is different from the others
in the thread, yet looks vaguely related:

Unable to handle kernel NULL pointer dereference at 0000000000000021 RIP:
[<ffffffff8108382a>] refresh_zone_stat_thresholds+0x6d/0x90
PGD 0
Oops: 0002 [1] SMP
last sysfs file:
CPU 0
Modules linked in:
Pid: 1, comm: swapper Not tainted 2.6.24-rc3-mm1 #2
RIP: 0010:[<ffffffff8108382a>] [<ffffffff8108382a>] refresh_zone_stat_thresholds+0x6d/0x90
RSP: 0000:ffff81007fb59ec0 EFLAGS: 00010293
RAX: 0000000000000000 RBX: 0000000000000004 RCX: 0000000000000001
RDX: 0000000000000001 RSI: ffffffff8146fb38 RDI: 0000000000000001
RBP: ffff81000000c000 R08: 0000000000000000 R09: 0000000000000000
R10: ffff81007fb59e60 R11: 0000000000000028 R12: ffffffff814d4558
R13: 0000000000000000 R14: ffffffff814b62c0 R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffffffff813d9000(0000) knlGS:0000000000000000
CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: 0000000000000021 CR3: 0000000000201000 CR4: 00000000000006a0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process swapper (pid: 1, threadinfo FFFF81007FB58000, task FFFF81007FB56000)
Stack: 0000000000000000 0000000000000000 0000000000000000 ffffffff814a3839
0000000000000000 ffffffff8148e626 ffff81007fb56000 ffffffff8126d36a
0000000000000000 ffffffffffffffff ffffffff8105786b 0000000000000000
Call Trace:
[<ffffffff814a3839>] setup_vmstat+0x6/0x40
[<ffffffff8148e626>] kernel_init+0x169/0x2d8
[<ffffffff8126d36a>] trace_hardirqs_on_thunk+0x35/0x3a
[<ffffffff8105786b>] trace_hardirqs_on+0x115/0x138
[<ffffffff8100ce48>] child_rip+0xa/0x12
[<ffffffff8100c55f>] restore_args+0x0/0x30
[<ffffffff8148e4bd>] kernel_init+0x0/0x2d8
[<ffffffff8100ce3e>] child_rip+0x0/0x12

INFO: lockdep is turned off.

--
All Rights Reversed

2007-11-26 20:35:35

by Andrew Morton

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1 - Kernel Panic on IO-APIC

On Mon, 26 Nov 2007 14:39:43 -0500
Rik van Riel <[email protected]> wrote:

> On Tue, 20 Nov 2007 22:18:39 -0800
> Andrew Morton <[email protected]> wrote:
>
> > > ..MP-BIOS bug: 8254 timer not connected to IO-APIC
> > > Kernel panic - not syncing: IO-APIC + timer doesn't work! Try using the 'noapic' kernel parameter
> >
> > ACPI or x86 breakage, I guess.
> >
> > Did 'noapic' work?
>
> I got the same bug as above, 'noapic' gets past that point

We still don't know what caused this, afaik.

> and right to the
> next oops. I'm posting it here because this one is different from the others
> in the thread, yet looks vaguely related:
>
> Unable to handle kernel NULL pointer dereference at 0000000000000021 RIP:
> [<ffffffff8108382a>] refresh_zone_stat_thresholds+0x6d/0x90
> PGD 0
> Oops: 0002 [1] SMP
> last sysfs file:
> CPU 0
> Modules linked in:
> Pid: 1, comm: swapper Not tainted 2.6.24-rc3-mm1 #2
> RIP: 0010:[<ffffffff8108382a>] [<ffffffff8108382a>] refresh_zone_stat_thresholds+0x6d/0x90
> RSP: 0000:ffff81007fb59ec0 EFLAGS: 00010293
> RAX: 0000000000000000 RBX: 0000000000000004 RCX: 0000000000000001
> RDX: 0000000000000001 RSI: ffffffff8146fb38 RDI: 0000000000000001
> RBP: ffff81000000c000 R08: 0000000000000000 R09: 0000000000000000
> R10: ffff81007fb59e60 R11: 0000000000000028 R12: ffffffff814d4558
> R13: 0000000000000000 R14: ffffffff814b62c0 R15: 0000000000000000
> FS: 0000000000000000(0000) GS:ffffffff813d9000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
> CR2: 0000000000000021 CR3: 0000000000201000 CR4: 00000000000006a0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Process swapper (pid: 1, threadinfo FFFF81007FB58000, task FFFF81007FB56000)
> Stack: 0000000000000000 0000000000000000 0000000000000000 ffffffff814a3839
> 0000000000000000 ffffffff8148e626 ffff81007fb56000 ffffffff8126d36a
> 0000000000000000 ffffffffffffffff ffffffff8105786b 0000000000000000
> Call Trace:
> [<ffffffff814a3839>] setup_vmstat+0x6/0x40
> [<ffffffff8148e626>] kernel_init+0x169/0x2d8
> [<ffffffff8126d36a>] trace_hardirqs_on_thunk+0x35/0x3a
> [<ffffffff8105786b>] trace_hardirqs_on+0x115/0x138
> [<ffffffff8100ce48>] child_rip+0xa/0x12
> [<ffffffff8100c55f>] restore_args+0x0/0x30
> [<ffffffff8148e4bd>] kernel_init+0x0/0x2d8
> [<ffffffff8100ce3e>] child_rip+0x0/0x12
>
> INFO: lockdep is turned off.

hm. This smells like a startup ordering problem, but everything which
refresh_zone_stat_thresholds() should be set up by the time we run
initcalls. Maybe the zone lists are bad?

2007-11-26 20:42:44

by Randy Dunlap

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1

On Mon, 26 Nov 2007 11:34:15 -0800 (PST) Christoph Lameter wrote:

> On Mon, 26 Nov 2007, Randy Dunlap wrote:
>
> > On Tue, 20 Nov 2007 20:45:25 -0800 Andrew Morton wrote:
> >
> > >
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc3/2.6.24-rc3-mm1/
> >
> > allnoconfig on x86_64 gives:
> >
> > arch/x86/mm/init_64.c:84: error: implicit declaration of function 'pfn_valid'
> > mm/page_alloc.c:2533: error: implicit declaration of function 'pfn_valid'
> > mm/vmstat.c:518: error: implicit declaration of function 'pfn_valid'
> > mm/memory.c:400: error: implicit declaration of function 'pfn_valid'
> > drivers/char/mem.c:312: error: implicit declaration of function 'pfn_valid'
>
> Hmmm... CONFIG_SPARSEMEM is not set if you do allnoconfig
>
> config SPARSEMEM
> def_bool y
> depends on SPARSEMEM_MANUAL
>
> So I guess we need to set SPARSEMEM_MANUAL
>
> But arch/x86/Kconfig has
>
> config SPARSEMEM_MANUAL
> bool "Sparse Memory"
> depends on ARCH_SPARSEMEM_ENABLE
> help
> This will be the only option for some systems, including
> memory hotplug systems. This is normal.
>
> It needs to be not deselectable for x86_64.
>
> Inserting
>
> def_bool y if X86_64
>
> did not help....
>
> Somehow make menuconfig did not give me an ability to even enable this
> again.

Thanks for the hint.

ARCH_SELECT_MEMORY_MODEL depends on X86_32. Is that too restrictive?

config ARCH_SELECT_MEMORY_MODEL
def_bool y
depends on X86_32 && ARCH_SPARSEMEM_ENABLE

---
~Randy

2007-11-26 20:46:49

by Ingo Molnar

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1 - Kernel Panic on IO-APIC


* Andrew Morton <[email protected]> wrote:

> On Mon, 26 Nov 2007 14:39:43 -0500
> Rik van Riel <[email protected]> wrote:
>
> > On Tue, 20 Nov 2007 22:18:39 -0800
> > Andrew Morton <[email protected]> wrote:
> >
> > > > ..MP-BIOS bug: 8254 timer not connected to IO-APIC
> > > > Kernel panic - not syncing: IO-APIC + timer doesn't work! Try using the 'noapic' kernel parameter
> > >
> > > ACPI or x86 breakage, I guess.
> > >
> > > Did 'noapic' work?
> >
> > I got the same bug as above, 'noapic' gets past that point
>
> We still don't know what caused this, afaik.

yes. Is it a regression? If yes, could someone try to bisect it so that
we can fix it? If it's caused by x86.git then the 'mm' branch of the x86
git tree can be used for bisection:

git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86.git

it's supposed to build and boot fine at every bisection point. The
bisection run can be cut significantly by narrowing the bisection to the
arch/x86 changes only:

git-bisect start arch/x86 include/asm-x86/

(and if it finds a nonsensical commit, i.e. the breakage is not caused
by the x86 commits, save the "git-bisect log" output into a file,
restart the git bisection and use "git-bisect replay" to insert all the
test points into a fuller bisection run - this saves quite some time.)

Ingo

2007-11-26 20:48:47

by Randy Dunlap

[permalink] [raw]
Subject: [PATCH -mm] x86 allnoconfig memory model

This patch allows allnoconfig to build cleanly.

---

From: Randy Dunlap <[email protected]>

Make allnoconfig on x86_64 build by allowing ARCH_SELECT_MEMORY_MODEL
to be enabled on X86 32/64, not just X86_32.

Signed-off-by: Randy Dunlap <[email protected]>
---
arch/x86/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-2.6.24-rc3-mm1.orig/arch/x86/Kconfig
+++ linux-2.6.24-rc3-mm1/arch/x86/Kconfig
@@ -937,7 +937,7 @@ config ARCH_SPARSEMEM_ENABLE

config ARCH_SELECT_MEMORY_MODEL
def_bool y
- depends on X86_32 && ARCH_SPARSEMEM_ENABLE
+ depends on ARCH_SPARSEMEM_ENABLE

config ARCH_MEMORY_PROBE
def_bool X86_64

2007-11-26 20:55:28

by Rik van Riel

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1 - Kernel Panic on IO-APIC

On Mon, 26 Nov 2007 12:33:19 -0800
Andrew Morton <[email protected]> wrote:

> > Unable to handle kernel NULL pointer dereference at 0000000000000021 RIP:
> > [<ffffffff8108382a>] refresh_zone_stat_thresholds+0x6d/0x90
> > PGD 0
> > Oops: 0002 [1] SMP
> > last sysfs file:
> > CPU 0
> > Modules linked in:
> > Pid: 1, comm: swapper Not tainted 2.6.24-rc3-mm1 #2
> > RIP: 0010:[<ffffffff8108382a>] [<ffffffff8108382a>] refresh_zone_stat_thresholds+0x6d/0x90
> > RSP: 0000:ffff81007fb59ec0 EFLAGS: 00010293
> > RAX: 0000000000000000 RBX: 0000000000000004 RCX: 0000000000000001
> > RDX: 0000000000000001 RSI: ffffffff8146fb38 RDI: 0000000000000001
> > RBP: ffff81000000c000 R08: 0000000000000000 R09: 0000000000000000
> > R10: ffff81007fb59e60 R11: 0000000000000028 R12: ffffffff814d4558
> > R13: 0000000000000000 R14: ffffffff814b62c0 R15: 0000000000000000
> > FS: 0000000000000000(0000) GS:ffffffff813d9000(0000) knlGS:0000000000000000
> > CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
> > CR2: 0000000000000021 CR3: 0000000000201000 CR4: 00000000000006a0
> > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> > Process swapper (pid: 1, threadinfo FFFF81007FB58000, task FFFF81007FB56000)
> > Stack: 0000000000000000 0000000000000000 0000000000000000 ffffffff814a3839
> > 0000000000000000 ffffffff8148e626 ffff81007fb56000 ffffffff8126d36a
> > 0000000000000000 ffffffffffffffff ffffffff8105786b 0000000000000000
> > Call Trace:
> > [<ffffffff814a3839>] setup_vmstat+0x6/0x40
> > [<ffffffff8148e626>] kernel_init+0x169/0x2d8
> > [<ffffffff8126d36a>] trace_hardirqs_on_thunk+0x35/0x3a
> > [<ffffffff8105786b>] trace_hardirqs_on+0x115/0x138
> > [<ffffffff8100ce48>] child_rip+0xa/0x12
> > [<ffffffff8100c55f>] restore_args+0x0/0x30
> > [<ffffffff8148e4bd>] kernel_init+0x0/0x2d8
> > [<ffffffff8100ce3e>] child_rip+0x0/0x12
> >
> > INFO: lockdep is turned off.
>
> hm. This smells like a startup ordering problem, but everything which
> refresh_zone_stat_thresholds() should be set up by the time we run
> initcalls. Maybe the zone lists are bad?

Or the CPU array. Look at the oops Kamalesh got a few mails upthread...

I guess I'll have to start a bisect - can't port the VM code to a kernel
that doesn't boot...

--
All Rights Reversed

2007-11-26 20:56:19

by Christoph Lameter

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1 - Kernel Panic on IO-APIC

On Mon, 26 Nov 2007, Andrew Morton wrote:

> hm. This smells like a startup ordering problem, but everything which
> refresh_zone_stat_thresholds() should be set up by the time we run
> initcalls. Maybe the zone lists are bad?

refresh_zone_stat_thresholds goes through each zone and updates
the stat threshold for every per cpu structure in each zone.

So this could be a processor marked online where the pcp structures have
not been allocated or a zone NULL pointer.

2007-11-26 20:56:57

by Christoph Lameter

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1

On Mon, 26 Nov 2007, Randy Dunlap wrote:

> ARCH_SELECT_MEMORY_MODEL depends on X86_32. Is that too restrictive?

No. X86_64 only has one memory model.

2007-11-26 21:00:20

by Christoph Lameter

[permalink] [raw]
Subject: Re: [PATCH -mm] x86 allnoconfig memory model

On Mon, 26 Nov 2007, Randy Dunlap wrote:

> This patch allows allnoconfig to build cleanly.

Well this sortof works.

One can again select a memory model but there is only one to choose from.
It would be best if the memory model selection would not occur.

2007-11-26 21:19:36

by Randy Dunlap

[permalink] [raw]
Subject: Re: [PATCH -mm] x86 allnoconfig memory model

Christoph Lameter wrote:
> On Mon, 26 Nov 2007, Randy Dunlap wrote:
>
>> This patch allows allnoconfig to build cleanly.
>
> Well this sortof works.
>
> One can again select a memory model but there is only one to choose from.

At least the help text allows / explains that.

> It would be best if the memory model selection would not occur.

My attempt at that gave a warning from kconfig:

mm/Kconfig:70:warning: defaults for choice values not supported


Other than that, it seemed to work.
Maybe someone else can have a go at it.

--
~Randy

2007-11-26 21:21:44

by Andrew Morton

[permalink] [raw]
Subject: Re: [PATCH -mm] x86 allnoconfig memory model

On Mon, 26 Nov 2007 13:00:03 -0800 (PST)
Christoph Lameter <[email protected]> wrote:

> On Mon, 26 Nov 2007, Randy Dunlap wrote:
>
> > This patch allows allnoconfig to build cleanly.
>
> Well this sortof works.
>
> One can again select a memory model but there is only one to choose from.
> It would be best if the memory model selection would not occur.

Unfortunately I just dropped that patch because git-x86 has gone and
combined include/asm-x86/sparsemem_32.h and include/asm-x86/sparsemem_64.h
into the same file.

2007-11-26 21:52:39

by Christoph Lameter

[permalink] [raw]
Subject: Re: [PATCH -mm] x86 allnoconfig memory model

On Mon, 26 Nov 2007, Andrew Morton wrote:

> Unfortunately I just dropped that patch because git-x86 has gone and
> combined include/asm-x86/sparsemem_32.h and include/asm-x86/sparsemem_64.h
> into the same file.

git-x86 still contains separate sparsemem_32/64.h here.
git lag?

christoph@stapp:~/x86/linux-2.6-x86/.git$ cat config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "origin"]
url =
git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86.git
fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
remote = origin
merge = refs/heads/master

2007-11-26 21:58:41

by Andrew Morton

[permalink] [raw]
Subject: Re: [PATCH -mm] x86 allnoconfig memory model

On Mon, 26 Nov 2007 13:52:31 -0800 (PST)
Christoph Lameter <[email protected]> wrote:

> On Mon, 26 Nov 2007, Andrew Morton wrote:
>
> > Unfortunately I just dropped that patch because git-x86 has gone and
> > combined include/asm-x86/sparsemem_32.h and include/asm-x86/sparsemem_64.h
> > into the same file.
>
> git-x86 still contains separate sparsemem_32/64.h here.
> git lag?

yup

> christoph@stapp:~/x86/linux-2.6-x86/.git$ cat config
> [core]
> repositoryformatversion = 0
> filemode = true
> bare = false
> logallrefupdates = true
> [remote "origin"]
> url =
> git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86.git
> fetch = +refs/heads/*:refs/remotes/origin/*
> [branch "master"]
> remote = origin
> merge = refs/heads/master

git+ssh://master.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86.git#mm

a) I use the #mm branch

b) I go direct to master.kernel.org. Probably that's only worth five
minutes nowadays - it used to be worth hours, but kernel.org got better.

2007-11-26 22:08:50

by Jiri Slaby

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1 - Kernel Panic on IO-APIC

On 11/26/2007 09:45 PM, Ingo Molnar wrote:
> * Andrew Morton <[email protected]> wrote:
>
>> On Mon, 26 Nov 2007 14:39:43 -0500
>> Rik van Riel <[email protected]> wrote:
>>
>>> On Tue, 20 Nov 2007 22:18:39 -0800
>>> Andrew Morton <[email protected]> wrote:
>>>
>>>>> ..MP-BIOS bug: 8254 timer not connected to IO-APIC
>>>>> Kernel panic - not syncing: IO-APIC + timer doesn't work! Try using the 'noapic' kernel parameter
>>>> ACPI or x86 breakage, I guess.
>>>>
>>>> Did 'noapic' work?
>>> I got the same bug as above, 'noapic' gets past that point
>> We still don't know what caused this, afaik.
>
> yes. Is it a regression? If yes, could someone try to bisect it so that
> we can fix it? If it's caused by x86.git then the 'mm' branch of the x86
> git tree can be used for bisection:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86.git

I did, but it's hard, if you don't know the BAD point. HEAD boots fine and 'x86:
randomize brk' too (the top of git-x86.patch). Andrew, how do you pull it, git
#mm doesn't fit to the ids from the patch.

Maybe if you can emit a broken-out with the fresh pull to test?

regards,
--
Jiri Slaby ([email protected])
Faculty of Informatics, Masaryk University

2007-11-26 22:19:07

by Andrew Morton

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1 - Kernel Panic on IO-APIC

On Mon, 26 Nov 2007 23:08:33 +0100
Jiri Slaby <[email protected]> wrote:

> On 11/26/2007 09:45 PM, Ingo Molnar wrote:
> > * Andrew Morton <[email protected]> wrote:
> >
> >> On Mon, 26 Nov 2007 14:39:43 -0500
> >> Rik van Riel <[email protected]> wrote:
> >>
> >>> On Tue, 20 Nov 2007 22:18:39 -0800
> >>> Andrew Morton <[email protected]> wrote:
> >>>
> >>>>> ..MP-BIOS bug: 8254 timer not connected to IO-APIC
> >>>>> Kernel panic - not syncing: IO-APIC + timer doesn't work! Try using the 'noapic' kernel parameter
> >>>> ACPI or x86 breakage, I guess.
> >>>>
> >>>> Did 'noapic' work?
> >>> I got the same bug as above, 'noapic' gets past that point
> >> We still don't know what caused this, afaik.
> >
> > yes. Is it a regression? If yes, could someone try to bisect it so that
> > we can fix it? If it's caused by x86.git then the 'mm' branch of the x86
> > git tree can be used for bisection:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86.git
>
> I did, but it's hard, if you don't know the BAD point. HEAD boots fine and 'x86:
> randomize brk' too (the top of git-x86.patch).

So the bug wasn't in git-x86 in 2.6.24-rc3-mm1.

But it might be in there now, as some patches got moved over.

Or it could be git-acpi. Or lots of other things.

> Andrew, how do you pull it, git
> #mm doesn't fit to the ids from the patch.

The -mm git tree reimports the plain git-foo.patch files back into a new
git tree, so the commit IDs won't line up.

The way to find the culprit patch in 2.6.24-rc3-mm1 is
http://www.zip.com.au/~akpm/linux/patches/stuff/bisecting-mm-trees.txt. It
will be quite quick.

> Maybe if you can emit a broken-out with the fresh pull to test?

http://userweb.kernel.org/~akpm/mmotm/ is current. But it probably won't
compile. I'd suggest bisecting 2.6.24-rc3-mm1 would be easier.

2007-11-26 22:23:19

by Jiri Slaby

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1 - Kernel Panic on IO-APIC

On 11/26/2007 11:17 PM, Andrew Morton wrote:
> http://userweb.kernel.org/~akpm/mmotm/ is current. But it probably won't
> compile. I'd suggest bisecting 2.6.24-rc3-mm1 would be easier.

Yes, I've bisected this and it pointed to git-x86.patch + 2 pushed fixes from
series, Then tried x86 git, but its HEAD was OK.

2007-11-26 23:14:33

by Jiri Slaby

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1 - Kernel Panic on IO-APIC

On 11/26/2007 11:17 PM, Andrew Morton wrote:
>> Maybe if you can emit a broken-out with the fresh pull to test?
>
> http://userweb.kernel.org/~akpm/mmotm/ is current. But it probably won't
> compile.

Yes it did :). And it worked. Both in qemu and on my desktop...

qemu output at:
http://www.fi.muni.cz/~xslaby/sklad/qemu-output.txt

thanks,
--
Jiri Slaby ([email protected])
Faculty of Informatics, Masaryk University

2007-11-26 23:20:44

by Christoph Lameter

[permalink] [raw]
Subject: Re: [PATCH -mm] x86 allnoconfig memory model

On Mon, 26 Nov 2007, Andrew Morton wrote:

> b) I go direct to master.kernel.org. Probably that's only worth five
> minutes nowadays - it used to be worth hours, but kernel.org got better.

Updated patch (including Randy's fix) against git-x86 mm.



x86_64: Make sparsemem/vmemmap the only memory model V3

V2->V3:
- Rediff against mm git-x86

V1->V2:
- Rediff against new upstream x86 code that unifies the Kconfig files.

Use sparsemem as the only memory model for UP, SMP and NUMA.
Measurements indicate that DISCONTIGMEM has a higher overhead
than sparsemem. And FLATMEMs benefits are minimal. So I think its
best to simply standardize on sparsemem.

Results of page allocator tests (test can be had via git from slab git
tree branch tests)

Measurements in cycle counts. 1000 allocations were performed and then the
average cycle count was calculated.

Order FlatMem Discontig SparseMem
0 639 665 641
1 567 647 593
2 679 774 692
3 763 967 781
4 961 1501 962
5 1356 2344 1392
6 2224 3982 2336
7 4869 7225 5074
8 12500 14048 12732
9 27926 28223 28165
10 58578 58714 58682

(Note that FlatMem is an SMP config and the rest NUMA configurations)

Memory use:

SMP Sparsemem
-------------

Kernel size:

text data bss dec hex filename
3849268 397739 1264856 5511863 541ab7 vmlinux

total used free shared buffers cached
Mem: 8242252 41164 8201088 0 352 11512
-/+ buffers/cache: 29300 8212952
Swap: 9775512 0 9775512

SMP Flatmem
-----------

Kernel size:

text data bss dec hex filename
3844612 397739 1264536 5506887 540747 vmlinux

So 4.5k growth in text size vs. FLATMEM.

total used free shared buffers cached
Mem: 8244052 40544 8203508 0 352 11484
-/+ buffers/cache: 28708 8215344

2k growth in overall memory use after boot.



NUMA discontig:

text data bss dec hex filename
3888124 470659 1276504 5635287 55fcd7 vmlinux

total used free shared buffers cached
Mem: 8256256 56908 8199348 0 352 11496
-/+ buffers/cache: 45060 8211196
Swap: 9775512 0 9775512

NUMA sparse:

text data bss dec hex filename
3896428 470659 1276824 5643911 561e87 vmlinux


8k text growth. Given that we fully inline virt_to_page and friends now
that is rather good.

total used free shared buffers cached
Mem: 8264720 57240 8207480 0 352 11516
-/+ buffers/cache: 45372 8219348
Swap: 9775512 0 9775512

The total available memory is increased by 8k.


This patch makes sparsemem the default and removes discontig and
flatmem support from x86.

Acked-by: Andi Kleen <[email protected]>
Signed-off-by: Christoph Lameter <[email protected]>

---
arch/x86/Kconfig | 22 +++++---------
arch/x86/configs/x86_64_defconfig | 9 -----
arch/x86/kernel/machine_kexec_64.c | 5 ---
arch/x86/mm/init_64.c | 30 -------------------
arch/x86/mm/ioremap_64.c | 17 -----------
arch/x86/mm/numa_64.c | 21 -------------
arch/x86/mm/srat_64.c | 57 -------------------------------------
include/asm-x86/mmzone_64.h | 6 ---
include/asm-x86/page_64.h | 3 -
9 files changed, 9 insertions(+), 161 deletions(-)

Index: linux-2.6-x86/arch/x86/configs/x86_64_defconfig
===================================================================
--- linux-2.6-x86.orig/arch/x86/configs/x86_64_defconfig 2007-11-26 13:53:18.927361771 -0800
+++ linux-2.6-x86/arch/x86/configs/x86_64_defconfig 2007-11-26 15:15:41.430361615 -0800
@@ -145,15 +145,6 @@ CONFIG_K8_NUMA=y
CONFIG_NODES_SHIFT=6
CONFIG_X86_64_ACPI_NUMA=y
CONFIG_NUMA_EMU=y
-CONFIG_ARCH_DISCONTIGMEM_ENABLE=y
-CONFIG_ARCH_DISCONTIGMEM_DEFAULT=y
-CONFIG_ARCH_SPARSEMEM_ENABLE=y
-CONFIG_SELECT_MEMORY_MODEL=y
-# CONFIG_FLATMEM_MANUAL is not set
-CONFIG_DISCONTIGMEM_MANUAL=y
-# CONFIG_SPARSEMEM_MANUAL is not set
-CONFIG_DISCONTIGMEM=y
-CONFIG_FLAT_NODE_MEM_MAP=y
CONFIG_NEED_MULTIPLE_NODES=y
# CONFIG_SPARSEMEM_STATIC is not set
CONFIG_SPLIT_PTLOCK_CPUS=4
Index: linux-2.6-x86/arch/x86/kernel/machine_kexec_64.c
===================================================================
--- linux-2.6-x86.orig/arch/x86/kernel/machine_kexec_64.c 2007-11-26 13:53:18.939362118 -0800
+++ linux-2.6-x86/arch/x86/kernel/machine_kexec_64.c 2007-11-26 15:15:41.430361615 -0800
@@ -234,10 +234,5 @@ NORET_TYPE void machine_kexec(struct kim
void arch_crash_save_vmcoreinfo(void)
{
VMCOREINFO_SYMBOL(init_level4_pgt);
-
-#ifdef CONFIG_ARCH_DISCONTIGMEM_ENABLE
- VMCOREINFO_SYMBOL(node_data);
- VMCOREINFO_LENGTH(node_data, MAX_NUMNODES);
-#endif
}

Index: linux-2.6-x86/arch/x86/mm/ioremap_64.c
===================================================================
--- linux-2.6-x86.orig/arch/x86/mm/ioremap_64.c 2007-11-26 13:53:18.951362033 -0800
+++ linux-2.6-x86/arch/x86/mm/ioremap_64.c 2007-11-26 15:15:41.430361615 -0800
@@ -86,23 +86,6 @@ void __iomem * __ioremap(unsigned long p
if (phys_addr >= ISA_START_ADDRESS && last_addr < ISA_END_ADDRESS)
return (__force void __iomem *)phys_to_virt(phys_addr);

-#ifdef CONFIG_FLATMEM
- /*
- * Don't allow anybody to remap normal RAM that we're using..
- */
- if (last_addr < virt_to_phys(high_memory)) {
- char *t_addr, *t_end;
- struct page *page;
-
- t_addr = __va(phys_addr);
- t_end = t_addr + (size - 1);
-
- for(page = virt_to_page(t_addr); page <= virt_to_page(t_end); page++)
- if(!PageReserved(page))
- return NULL;
- }
-#endif
-
pgprot = __pgprot(_PAGE_PRESENT | _PAGE_RW | _PAGE_GLOBAL
| _PAGE_DIRTY | _PAGE_ACCESSED | flags);
/*
Index: linux-2.6-x86/arch/x86/mm/numa_64.c
===================================================================
--- linux-2.6-x86.orig/arch/x86/mm/numa_64.c 2007-11-26 15:15:26.130611458 -0800
+++ linux-2.6-x86/arch/x86/mm/numa_64.c 2007-11-26 15:15:41.430361615 -0800
@@ -153,12 +153,10 @@ int __init compute_hash_shift(struct boo
return shift;
}

-#ifdef CONFIG_SPARSEMEM
int early_pfn_to_nid(unsigned long pfn)
{
return phys_to_nid(pfn << PAGE_SHIFT);
}
-#endif

static void * __init early_node_mem(int nodeid, unsigned long start,
unsigned long end, unsigned long size)
@@ -635,23 +633,4 @@ void __init init_cpu_to_node(void)
}
}

-#ifdef CONFIG_DISCONTIGMEM
-/*
- * Functions to convert PFNs from/to per node page addresses.
- * These are out of line because they are quite big.
- * They could be all tuned by pre caching more state.
- * Should do that.
- */

-int pfn_valid(unsigned long pfn)
-{
- unsigned nid;
- if (pfn >= num_physpages)
- return 0;
- nid = pfn_to_nid(pfn);
- if (nid == 0xff)
- return 0;
- return pfn >= node_start_pfn(nid) && (pfn) < node_end_pfn(nid);
-}
-EXPORT_SYMBOL(pfn_valid);
-#endif
Index: linux-2.6-x86/include/asm-x86/mmzone_64.h
===================================================================
--- linux-2.6-x86.orig/include/asm-x86/mmzone_64.h 2007-11-26 15:15:26.471361483 -0800
+++ linux-2.6-x86/include/asm-x86/mmzone_64.h 2007-11-26 15:15:41.430361615 -0800
@@ -43,12 +43,6 @@ static inline __attribute__((pure)) int

extern int early_pfn_to_nid(unsigned long pfn);

-#ifdef CONFIG_DISCONTIGMEM
-#define pfn_to_nid(pfn) phys_to_nid((unsigned long)(pfn) << PAGE_SHIFT)
-
-extern int pfn_valid(unsigned long pfn);
-#endif
-
#ifdef CONFIG_NUMA_EMU
#define FAKE_NODE_MIN_SIZE (64*1024*1024)
#define FAKE_NODE_MIN_HASH_MASK (~(FAKE_NODE_MIN_SIZE - 1uL))
Index: linux-2.6-x86/include/asm-x86/page_64.h
===================================================================
--- linux-2.6-x86.orig/include/asm-x86/page_64.h 2007-11-26 15:15:26.475361591 -0800
+++ linux-2.6-x86/include/asm-x86/page_64.h 2007-11-26 15:15:41.430361615 -0800
@@ -127,9 +127,6 @@ extern unsigned long __phys_addr(unsigne
#define __va(x) ((void *)((unsigned long)(x)+PAGE_OFFSET))
#define __boot_va(x) __va(x)
#define __boot_pa(x) __pa(x)
-#ifdef CONFIG_FLATMEM
-#define pfn_valid(pfn) ((pfn) < end_pfn)
-#endif

#define virt_to_page(kaddr) pfn_to_page(__pa(kaddr) >> PAGE_SHIFT)
#define virt_addr_valid(kaddr) pfn_valid(__pa(kaddr) >> PAGE_SHIFT)
Index: linux-2.6-x86/arch/x86/mm/init_64.c
===================================================================
--- linux-2.6-x86.orig/arch/x86/mm/init_64.c 2007-11-26 15:15:26.122611468 -0800
+++ linux-2.6-x86/arch/x86/mm/init_64.c 2007-11-26 15:15:41.430361615 -0800
@@ -486,34 +486,6 @@ EXPORT_SYMBOL_GPL(memory_add_physaddr_to

#endif /* CONFIG_MEMORY_HOTPLUG */

-#ifdef CONFIG_MEMORY_HOTPLUG_RESERVE
-/*
- * Memory Hotadd without sparsemem. The mem_maps have been allocated in advance,
- * just online the pages.
- */
-int __add_pages(struct zone *z, unsigned long start_pfn, unsigned long nr_pages)
-{
- int err = -EIO;
- unsigned long pfn;
- unsigned long total = 0, mem = 0;
- for (pfn = start_pfn; pfn < start_pfn + nr_pages; pfn++) {
- if (pfn_valid(pfn)) {
- online_page(pfn_to_page(pfn));
- err = 0;
- mem++;
- }
- total++;
- }
- if (!err) {
- z->spanned_pages += total;
- z->present_pages += mem;
- z->zone_pgdat->node_spanned_pages += total;
- z->zone_pgdat->node_present_pages += mem;
- }
- return err;
-}
-#endif
-
static struct kcore_list kcore_mem, kcore_vmalloc, kcore_kernel, kcore_modules,
kcore_vsyscall;

@@ -739,7 +711,6 @@ const char *arch_vma_name(struct vm_area
return NULL;
}

-#ifdef CONFIG_SPARSEMEM_VMEMMAP
/*
* Initialise the sparsemem vmemmap using huge-pages at the PMD level.
*/
@@ -782,4 +753,3 @@ int __meminit vmemmap_populate(struct pa

return 0;
}
-#endif
Index: linux-2.6-x86/arch/x86/mm/srat_64.c
===================================================================
--- linux-2.6-x86.orig/arch/x86/mm/srat_64.c 2007-11-26 13:53:18.983361973 -0800
+++ linux-2.6-x86/arch/x86/mm/srat_64.c 2007-11-26 15:15:41.434361980 -0800
@@ -151,62 +151,6 @@ acpi_numa_processor_affinity_init(struct
pxm, pa->apic_id, node);
}

-#ifdef CONFIG_MEMORY_HOTPLUG_RESERVE
-/*
- * Protect against too large hotadd areas that would fill up memory.
- */
-static int hotadd_enough_memory(struct bootnode *nd)
-{
- static unsigned long allocated;
- static unsigned long last_area_end;
- unsigned long pages = (nd->end - nd->start) >> PAGE_SHIFT;
- long mem = pages * sizeof(struct page);
- unsigned long addr;
- unsigned long allowed;
- unsigned long oldpages = pages;
-
- if (mem < 0)
- return 0;
- allowed = (end_pfn - absent_pages_in_range(0, end_pfn)) * PAGE_SIZE;
- allowed = (allowed / 100) * hotadd_percent;
- if (allocated + mem > allowed) {
- unsigned long range;
- /* Give them at least part of their hotadd memory upto hotadd_percent
- It would be better to spread the limit out
- over multiple hotplug areas, but that is too complicated
- right now */
- if (allocated >= allowed)
- return 0;
- range = allowed - allocated;
- pages = (range / PAGE_SIZE);
- mem = pages * sizeof(struct page);
- nd->end = nd->start + range;
- }
- /* Not completely fool proof, but a good sanity check */
- addr = find_e820_area(last_area_end, end_pfn<<PAGE_SHIFT, mem);
- if (addr == -1UL)
- return 0;
- if (pages != oldpages)
- printk(KERN_NOTICE "SRAT: Hotadd area limited to %lu bytes\n",
- pages << PAGE_SHIFT);
- last_area_end = addr + mem;
- allocated += mem;
- return 1;
-}
-
-static int update_end_of_memory(unsigned long end)
-{
- found_add_area = 1;
- if ((end >> PAGE_SHIFT) > end_pfn)
- end_pfn = end >> PAGE_SHIFT;
- return 1;
-}
-
-static inline int save_add_info(void)
-{
- return hotadd_percent > 0;
-}
-#else
int update_end_of_memory(unsigned long end) {return -1;}
static int hotadd_enough_memory(struct bootnode *nd) {return 1;}
#ifdef CONFIG_MEMORY_HOTPLUG_SPARSE
@@ -214,7 +158,6 @@ static inline int save_add_info(void) {r
#else
static inline int save_add_info(void) {return 0;}
#endif
-#endif
/*
* Update nodes_add and decide if to include add are in the zone.
* Both SPARSE and RESERVE need nodes_add infomation.
Index: linux-2.6-x86/arch/x86/Kconfig
===================================================================
--- linux-2.6-x86.orig/arch/x86/Kconfig 2007-11-26 15:15:25.194361726 -0800
+++ linux-2.6-x86/arch/x86/Kconfig 2007-11-26 15:17:40.310569645 -0800
@@ -912,25 +912,29 @@ config HAVE_ARCH_ALLOC_REMAP

config ARCH_FLATMEM_ENABLE
def_bool y
- depends on (X86_32 && ARCH_SELECT_MEMORY_MODEL && X86_PC) || (X86_64 && !NUMA)
+ depends on X86_32 && ARCH_SELECT_MEMORY_MODEL && X86_PC

config ARCH_DISCONTIGMEM_ENABLE
def_bool y
- depends on NUMA
+ depends on NUMA && X86_32

config ARCH_DISCONTIGMEM_DEFAULT
def_bool y
- depends on NUMA
+ depends on NUMA && X86_32
+
+config ARCH_SPARSEMEM_DEFAULT
+ def_bool y
+ depends on X86_64

config ARCH_SPARSEMEM_ENABLE
def_bool y
- depends on NUMA || (EXPERIMENTAL && (X86_PC || X86_64))
+ depends on X86_64 || NUMA || (EXPERIMENTAL && X86_PC)
select SPARSEMEM_STATIC if X86_32
select SPARSEMEM_VMEMMAP_ENABLE if X86_64

config ARCH_SELECT_MEMORY_MODEL
def_bool y
- depends on X86_32 && ARCH_SPARSEMEM_ENABLE
+ depends on ARCH_SPARSEMEM_ENABLE

config ARCH_MEMORY_PROBE
def_bool X86_64
@@ -1228,18 +1232,10 @@ config ARCH_ENABLE_MEMORY_HOTPLUG
def_bool y
depends on X86_64 || (X86_32 && HIGHMEM)

-config MEMORY_HOTPLUG_RESERVE
- def_bool X86_64
- depends on (MEMORY_HOTPLUG && DISCONTIGMEM)
-
config HAVE_ARCH_EARLY_PFN_TO_NID
def_bool X86_64
depends on NUMA

-config OUT_OF_LINE_PFN_TO_PAGE
- def_bool X86_64
- depends on DISCONTIGMEM
-
menu "Power management options"
depends on !X86_VOYAGER


2007-11-26 23:30:51

by Andrew Morton

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1 - Kernel Panic on IO-APIC

On Tue, 27 Nov 2007 00:14:17 +0100
Jiri Slaby <[email protected]> wrote:

> On 11/26/2007 11:17 PM, Andrew Morton wrote:
> >> Maybe if you can emit a broken-out with the fresh pull to test?
> >
> > http://userweb.kernel.org/~akpm/mmotm/ is current. But it probably won't
> > compile.
>
> Yes it did :). And it worked. Both in qemu and on my desktop...

boggle. Let's slap 2.6.25 on it and take the rest of the year off.

> qemu output at:
> http://www.fi.muni.cz/~xslaby/sklad/qemu-output.txt

Thanks for testing.

2007-11-27 06:15:31

by Andrew Morton

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1

On Fri, 23 Nov 2007 06:55:41 +0100 Gabriel C <[email protected]> wrote:

> Andrew Morton wrote:
> > On Fri, 23 Nov 2007 02:39:08 +0100 Gabriel C <[email protected]> wrote:
> >
> >> I have some warnings on each SCSI disc:
> >>
> >>
> >> ...
> >>
> >> [ 30.724410] scsi 0:0:0:0: Direct-Access SEAGATE ST318406LW 0109 PQ: 0 ANSI: 3
> >> [ 30.724419] scsi0:A:0:0: Tagged Queuing enabled. Depth 32
> >> [ 30.724435] target0:0:0: Beginning Domain Validation
> >> [ 30.724446] target0:0:0: Domain Validation Initial Inquiry Failed <--
> >> [ 30.724572] target0:0:0: Ending Domain Validation
> >> [ 30.729747] scsi 0:0:1:0: Direct-Access FUJITSU MAH3182MP 0114 PQ: 0 ANSI: 4
> >> [ 30.729754] scsi0:A:1:0: Tagged Queuing enabled. Depth 32
> >> [ 30.729771] target0:0:1: Beginning Domain Validation
> >> [ 30.729780] target0:0:1: Domain Validation Initial Inquiry Failed <--
> >> [ 30.729908] target0:0:1: Ending Domain Validation
> >>
> >
> > Don't know what would have caused that. But yes, something is wrong in
> > scsi land.
>
> Actually I'm lucky the author didn't fix that FIXME in scsi_transport_spi.c and I still can boot ;)
>
> >
> >> no idea whatever this is related but buffered disk reads are 2.XX MB/sec and the box is somewhat laggy.
> >>
> >> hdparm -t on sda and sdb reports :
> >>
> >> /dev/sda:
> >> Timing buffered disk reads: 8 MB in 3.26 seconds = 2.46 MB/sec
> >>
> >> /dev/sdb:
> >> Timing buffered disk reads: 8 MB in 3.56 seconds = 2.25 MB/sec
> >>
> >> My IDE discs are fine.
> >>
> >> Please let me know if you need my config or any other informations.
> >>
> >
> > And you're the second to report very slow scsi throughput in 2.6.24-rc3-mm1.
> >
>
> I found the commit which cause these problems , it is in git-scsi-misc patch and reverting it fixes both problems for me.
>
> http://git.kernel.org/?p=linux/kernel/git/jejb/scsi-misc-2.6.git;a=commitdiff_plain;h=8655a546c83fc43f0a73416bbd126d02de7ad6c0;hp=5bc717b6bdaaf52edf365eb7d9d8c89fec79df5d
>

OK, thanks. I'll assume that James and Hannes have this in hand (or will
have, by mid-week) and I won't do anything here.

2007-11-27 07:16:38

by Valdis Klētnieks

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1 - brick my Dell Latitude D820

On Tue, 20 Nov 2007 20:45:25 PST, Andrew Morton said:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc3/2.6.24-rc3-mm1/

Finally got both time and motivation to at least start a bisect..

2.6.23-mm1 works on my D820 (x86_64 kernel, Core2 Duo T7200)

24-rc3-mm1 (plus 3 patches from hotfixes/) bricks *instantly* at boot - grub
prints its 3 or 4 lines saying what it loaded, the screen clears, and *blam*
dead. No serial console output, no pair of penguins on the monitor, no
netconsole, no earlyprintk=vga output, no alt-sysrq, only thing that does
*anything* is "hold the power button for 5 seconds". Whatever it is, it
happens *very* early (before we get as far as the 'Linux version 2.6.mumble'
banner), and happens *hard*.

I've bisected it down this far:

git-ipwireless_cs.patch GOOD
git-x86.patch
git-x86-fixup.patch
git-x86-thread_order-borkage.patch
git-x86-thread_order-borkage-fix.patch
git-x86-identify_cpu-fix.patch
git-x86-memory_add_physaddr_to_nid-export-for-acpi-memhotplugko.patch
git-x86-memory_add_physaddr_to_nid-export-for-acpi-memhotplugko-checkpatch-fixes.patch
git-x86-inlining-borkage.patch
x86_64-set-cpu_index-to-nr_cpus-instead-of-0.patch
x86_64-make-sparsemem-vmemmap-the-default-memory-model-v2.patch BAD

Anybody got any good debugging ideas before I go through and do the final
3 or 4 bisects? I suspect I'll need them once I find the offending patch
to tell *why* said patch dies on my box - I've seen enough traffic regarding
-rc3-mm1 dying *later* to know it's probably a subtle issue and not one
that will be obvious once I finger a specific patch. For example, it's
probably not the IO-APIC panic that people are seeing, because their kernels
live long enough to panic. ;)


Attachments:
(No filename) (226.00 B)

2007-11-27 07:27:19

by Andrew Morton

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1 - brick my Dell Latitude D820

On Tue, 27 Nov 2007 02:16:26 -0500 [email protected] wrote:

> On Tue, 20 Nov 2007 20:45:25 PST, Andrew Morton said:
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc3/2.6.24-rc3-mm1/
>
> Finally got both time and motivation to at least start a bisect..
>
> 2.6.23-mm1 works on my D820 (x86_64 kernel, Core2 Duo T7200)
>
> 24-rc3-mm1 (plus 3 patches from hotfixes/) bricks *instantly* at boot - grub
> prints its 3 or 4 lines saying what it loaded, the screen clears, and *blam*
> dead. No serial console output, no pair of penguins on the monitor, no
> netconsole, no earlyprintk=vga output, no alt-sysrq, only thing that does
> *anything* is "hold the power button for 5 seconds". Whatever it is, it
> happens *very* early (before we get as far as the 'Linux version 2.6.mumble'
> banner), and happens *hard*.
>
> I've bisected it down this far:
>
> git-ipwireless_cs.patch GOOD
> git-x86.patch
> git-x86-fixup.patch
> git-x86-thread_order-borkage.patch
> git-x86-thread_order-borkage-fix.patch
> git-x86-identify_cpu-fix.patch
> git-x86-memory_add_physaddr_to_nid-export-for-acpi-memhotplugko.patch
> git-x86-memory_add_physaddr_to_nid-export-for-acpi-memhotplugko-checkpatch-fixes.patch
> git-x86-inlining-borkage.patch
> x86_64-set-cpu_index-to-nr_cpus-instead-of-0.patch
> x86_64-make-sparsemem-vmemmap-the-default-memory-model-v2.patch BAD
>
> Anybody got any good debugging ideas before I go through and do the final
> 3 or 4 bisects? I suspect I'll need them once I find the offending patch
> to tell *why* said patch dies on my box - I've seen enough traffic regarding
> -rc3-mm1 dying *later* to know it's probably a subtle issue and not one
> that will be obvious once I finger a specific patch. For example, it's
> probably not the IO-APIC panic that people are seeing, because their kernels
> live long enough to panic. ;)
>

You could try http://userweb.kernel.org/~akpm/mmotm/ - we might have already
fixed it.

Otherwise, please proceed to work out which diff I need to drop and hope like
hell that it isn't git-x86..

2007-11-27 07:55:17

by Valdis Klētnieks

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1 - brick my Dell Latitude D820

On Mon, 26 Nov 2007 23:27:03 PST, Andrew Morton said:

> > git-x86.patch
> > git-x86-fixup.patch
> > git-x86-thread_order-borkage.patch
> > git-x86-thread_order-borkage-fix.patch
> > git-x86-identify_cpu-fix.patch
> > git-x86-memory_add_physaddr_to_nid-export-for-acpi-memhotplugko.patch
> > git-x86-memory_add_physaddr_to_nid-export-for-acpi-memhotplugko-checkpatch-fixes.patch
> > git-x86-inlining-borkage.patch
> > x86_64-set-cpu_index-to-nr_cpus-instead-of-0.patch
> > x86_64-make-sparsemem-vmemmap-the-default-memory-model-v2.patch BAD

> You could try http://userweb.kernel.org/~akpm/mmotm/ - we might have already
> fixed it.

I suspect that trying -rc3-mm1 but refreshing just the 10 patches above
from -mmotm would be far less likely to pull in other heartburn?

> Otherwise, please proceed to work out which diff I need to drop and hope like
> hell that it isn't git-x86..

That's a 41,240 line diff, the rest *total* to about 400 lines. I don't have
warm-n-fuzzies about my odds here. ;)

I'm a git-idiot, but *do* know how to git-bisect through Linus tree - what
would I need to do to git-bisect through git-x86.patch? (I do *not* know how
to deal with more than 1 source git tree, so if the magic is just 'get a
linus tree, merge git-x86, then bisect as usual", I'm stuck on "merge git-x86")..


Attachments:
(No filename) (226.00 B)

2007-11-27 08:17:17

by Andrew Morton

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1 - brick my Dell Latitude D820

On Tue, 27 Nov 2007 02:54:56 -0500 [email protected] wrote:

> On Mon, 26 Nov 2007 23:27:03 PST, Andrew Morton said:
>
> > > git-x86.patch
> > > git-x86-fixup.patch
> > > git-x86-thread_order-borkage.patch
> > > git-x86-thread_order-borkage-fix.patch
> > > git-x86-identify_cpu-fix.patch
> > > git-x86-memory_add_physaddr_to_nid-export-for-acpi-memhotplugko.patch
> > > git-x86-memory_add_physaddr_to_nid-export-for-acpi-memhotplugko-checkpatch-fixes.patch
> > > git-x86-inlining-borkage.patch
> > > x86_64-set-cpu_index-to-nr_cpus-instead-of-0.patch
> > > x86_64-make-sparsemem-vmemmap-the-default-memory-model-v2.patch BAD
>
> > You could try http://userweb.kernel.org/~akpm/mmotm/ - we might have already
> > fixed it.
>
> I suspect that trying -rc3-mm1 but refreshing just the 10 patches above
> from -mmotm would be far less likely to pull in other heartburn?

All the above are no longer in -mm. They got merged, dropped,
otherwise-fixed, etc.

> > Otherwise, please proceed to work out which diff I need to drop and hope like
> > hell that it isn't git-x86..
>
> That's a 41,240 line diff, the rest *total* to about 400 lines. I don't have
> warm-n-fuzzies about my odds here. ;)

No.

> I'm a git-idiot, but *do* know how to git-bisect through Linus tree - what
> would I need to do to git-bisect through git-x86.patch? (I do *not* know how
> to deal with more than 1 source git tree, so if the magic is just 'get a
> linus tree, merge git-x86, then bisect as usual", I'm stuck on "merge git-x86")..

umm, I'm minimally git-afflicted hence am the wrong person to ask.
Something like:


- checkout Linus's tree

- echo 'git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86.git#mm' > .git/branches/git-x86

- git-fetch git-x86

- git-checkout git-x86

- start bisecting.

2007-11-27 08:25:32

by Dave Young

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1 - brick my Dell Latitude D820

On Nov 27, 2007 3:16 PM, <[email protected]> wrote:
> On Tue, 20 Nov 2007 20:45:25 PST, Andrew Morton said:
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc3/2.6.24-rc3-mm1/
>
> Finally got both time and motivation to at least start a bisect..
>
> 2.6.23-mm1 works on my D820 (x86_64 kernel, Core2 Duo T7200)
>
> 24-rc3-mm1 (plus 3 patches from hotfixes/) bricks *instantly* at boot - grub
> prints its 3 or 4 lines saying what it loaded, the screen clears, and *blam*
> dead. No serial console output, no pair of penguins on the monitor, no
> netconsole, no earlyprintk=vga output, no alt-sysrq, only thing that does
> *anything* is "hold the power button for 5 seconds". Whatever it is, it
> happens *very* early (before we get as far as the 'Linux version 2.6.mumble'
> banner), and happens *hard*.
>
> I've bisected it down this far:
>
> git-ipwireless_cs.patch GOOD
> git-x86.patch
> git-x86-fixup.patch
> git-x86-thread_order-borkage.patch
> git-x86-thread_order-borkage-fix.patch
> git-x86-identify_cpu-fix.patch
> git-x86-memory_add_physaddr_to_nid-export-for-acpi-memhotplugko.patch
> git-x86-memory_add_physaddr_to_nid-export-for-acpi-memhotplugko-checkpatch-fixes.patch
> git-x86-inlining-borkage.patch
> x86_64-set-cpu_index-to-nr_cpus-instead-of-0.patch
> x86_64-make-sparsemem-vmemmap-the-default-memory-model-v2.patch BAD
>
> Anybody got any good debugging ideas before I go through and do the final
> 3 or 4 bisects? I suspect I'll need them once I find the offending patch
> to tell *why* said patch dies on my box - I've seen enough traffic regarding
> -rc3-mm1 dying *later* to know it's probably a subtle issue and not one
> that will be obvious once I finger a specific patch. For example, it's
> probably not the IO-APIC panic that people are seeing, because their kernels
> live long enough to panic. ;)

Hi,
does boot_delay helps?

Regards
dave

2007-11-27 08:46:48

by Valdis Klētnieks

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1 - brick my Dell Latitude D820

On Tue, 27 Nov 2007 16:25:22 +0800, Dave Young said:

> does boot_delay helps?

It might, if the kernel lived long enough to output a first printk for
us to delay after. :)

Shooting this one would be *easy* if the problem was an boot-time oops that
would otherwise scroll off the screen without a boot_delay...


Attachments:
(No filename) (226.00 B)

2007-11-27 10:26:17

by Ingo Molnar

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1 - brick my Dell Latitude D820


* Andrew Morton <[email protected]> wrote:

> Otherwise, please proceed to work out which diff I need to drop and
> hope like hell that it isn't git-x86..

hm? x86.git is fully bisectable - so a more accurate statement would be
"and hope that it's x86.git, so that it can be properly bisected" :-)
For x86.git bisection, pull the 'mm' branch from:

git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86.git

Ingo

2007-11-27 17:59:57

by Rik van Riel

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1 - Kernel Panic on IO-APIC

On Mon, 26 Nov 2007 15:28:32 -0800
Andrew Morton <[email protected]> wrote:

> On Tue, 27 Nov 2007 00:14:17 +0100
> Jiri Slaby <[email protected]> wrote:
>
> > On 11/26/2007 11:17 PM, Andrew Morton wrote:
> > >> Maybe if you can emit a broken-out with the fresh pull to test?
> > >
> > > http://userweb.kernel.org/~akpm/mmotm/ is current. But it probably won't
> > > compile.
> >
> > Yes it did :). And it worked. Both in qemu and on my desktop...
>
> boggle. Let's slap 2.6.25 on it and take the rest of the year off.

No worries, the mmotm compiling issue seems to have been fixed:

CC [M] drivers/scsi/libsas/sas_ata.o
drivers/scsi/libsas/sas_ata.c:39: error: field ‘rphy’ has incomplete type
drivers/scsi/libsas/sas_ata.c: In function ‘sas_discover_sata’:
drivers/scsi/libsas/sas_ata.c:773: error: implicit declaration of function ‘ata_sas_rphy_alloc’
drivers/scsi/libsas/sas_ata.c:775: error: dereferencing pointer to incomplete type
drivers/scsi/libsas/sas_ata.c:775: warning: assignment makes pointer from integer without a cast
drivers/scsi/libsas/sas_ata.c:781: error: dereferencing pointer to incomplete type
drivers/scsi/libsas/sas_ata.c:782: error: dereferencing pointer to incomplete type
drivers/scsi/libsas/sas_ata.c:784: warning: type defaults to ‘int’ in declaration of ‘__mptr’
drivers/scsi/libsas/sas_ata.c:784: warning: initialization from incompatible pointer type
drivers/scsi/libsas/sas_ata.c:791: error: implicit declaration of function ‘ata_sas_rphy_add’
drivers/scsi/libsas/sas_ata.c:807: error: implicit declaration of function ‘ata_sas_rphy_delete’
drivers/scsi/libsas/sas_ata.c:809: error: implicit declaration of function ‘ata_sas_rphy_free’
make[3]: *** [drivers/scsi/libsas/sas_ata.o] Error 1
make[2]: *** [drivers/scsi/libsas] Error 2
make[1]: *** [drivers/scsi] Error 2
make: *** [drivers] Error 2

So much for continuing the bisect with that tree, to find the
cause of the second bug :)

Guess I'll extract an x86 tree changeset first, to place into
the 2.6.23-rc3-mm1 broken out tree and work from there...

--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

2007-11-28 05:03:43

by Andrew Morton

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1 make headers_check fails

On Wed, 21 Nov 2007 12:17:14 +0200 Avi Kivity <[email protected]> wrote:

> Avi Kivity wrote:
> >>>>>
> >>>>>> The make headers_check fails,
> >>>>>>
> >>>>>> CHECK include/linux/usb/gadgetfs.h
> >>>>>> CHECK include/linux/usb/ch9.h
> >>>>>> CHECK include/linux/usb/cdc.h
> >>>>>> CHECK include/linux/usb/audio.h
> >>>>>> CHECK include/linux/kvm.h
> >>>>>> /root/kernels/linux-2.6.24-rc3/usr/include/linux/kvm.h requires
> >>>>>> asm/kvm.h, which does not exist in exported headers
> >>>>>>
> >>>>> hm, works for me, on i386 and x86_64. What's different over there?
> >>>>>
> >>>> Hi Andrew,
> >>>>
> >>>> It fails on the powerpc box, with allyesconfig option.
> >>>>
> >>>>
> >>>>
> >>> How do we fix this? Export linux/kvm.h only on x86? Seems ugly.
> >>>
> >>
> >> Is kvm x86 specific? Then move the .h file to asm-x86.
> >> Otherwise no good idea...
> >>
> >>
> >
> > kvm.h is x86 specific today, but will be s390, ppc, ia64, and x86
> > specific tomorrow.
> >
> > What about having a asm-generic/kvm.h with a nice #error? would
> > that suit?
> >
>
> headers_check continues to complain. Is the only recourse to add
> asm/kvm.h for all archs?
>

That would work.

Meanwhile my recourse is to drop the kvm tree ;)

2007-11-28 21:38:56

by Laurent Riffard

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1: I/O error, system hangs

Le 25.11.2007 21:39, Laurent Riffard a écrit :
> Le 25.11.2007 08:37, James Bottomley a écrit :
>> On Sat, 2007-11-24 at 23:59 +0100, Laurent Riffard wrote:
>>> Le 24.11.2007 14:26, James Bottomley a écrit :
>>>> OK, could you post dmesgs again, please. I actually tested this
>>> with an
>>>> aic79xx card, and for me it does cause Domain Validation to succeed
>>>> again.
>>> James,
>>>
>>> Here is a dmesg produced by 2.6.24-rc3-mm1 + your patch "separates
>>> the
>>> BLOCK and QUIESCE states
>>> correctly" (http://lkml.org/lkml/2007/11/24/8).
>>>
[...]
>>> [ 25.521256] scsi0 : pata_via
>>> [ 25.521711] scsi1 : pata_via
>>> [ 25.524089] ata1: PATA max UDMA/100 cmd 0x1f0 ctl 0x3f6 bmdma 0xb800 irq 14
>>> [ 25.524176] ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xb808 irq 15
>>> [ 25.683141] ata1.00: ATA-5: ST340016A, 3.75, max UDMA/100
>>> [ 25.683208] ata1.00: 78165360 sectors, multi 16: LBA
>>> [ 25.683475] ata1.01: ATA-7: Maxtor 6Y080L0, YAR41BW0, max UDMA/133
>>> [ 25.684116] ata1.01: 160086528 sectors, multi 16: LBA
>>> [ 25.691127] ata1.00: configured for UDMA/100
>>> [ 25.699142] ata1.01: configured for UDMA/100
>>> [ 26.170860] ata2.00: ATAPI: HL-DT-ST DVDRAM GSA-4165B, DL05, max UDMA/33
>>> [ 26.171562] ata2.01: ATAPI: CD-950E/AKU, A4Q, max MWDMA2, CDB intr
>>> [ 26.330839] ata2.00: configured for UDMA/33
>>> [ 26.490828] ata2.01: configured for MWDMA2
>>> [ 26.503014] scsi 0:0:0:0: Direct-Access ATA ST340016A 3.75 PQ: 0 ANSI: 5
>>> [ 26.504670] scsi 0:0:1:0: Direct-Access ATA Maxtor 6Y080L0 YAR4 PQ: 0 ANSI: 5
>>> [ 26.509842] scsi 1:0:0:0: CD-ROM HL-DT-ST DVDRAM GSA-4165B DL05 PQ: 0 ANSI: 5
>>> [ 26.511673] scsi 1:0:1:0: CD-ROM E-IDE CD-950E/AKU A4Q PQ: 0 ANSI: 5
>> [...]
>>> [ 60.216113] sd 0:0:0:0: [sda] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK,SUGGEST_OK
>>> [ 60.216124] end_request: I/O error, dev sda, sector 16460
>> I think this one's quite easy: PATA devices in libata are queue depth 1
>> (since they don't do NCQ). Thus, they're peculiarly sensitive to the
>> bug where we fail over queue depth requests.
>>
>> On the other hand, I don't see how a filesystem request is getting
>> REQ_FAILFAST ... unless there's a bio or readahead issue involved.
>> Anyway, could you try this patch:
>>
>> http://marc.info/?l=linux-scsi&m=119592627425498
>>
>> Which should fix the queue depth issue, and see if the errors go away?
>
> No, this one doesn't help...

still happens with 2.6.24-rc3-mm2...
--
laurent

2007-12-02 08:53:50

by Avi Kivity

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1 make headers_check fails

Andrew Morton wrote:
> On Wed, 21 Nov 2007 12:17:14 +0200 Avi Kivity <[email protected]> wrote:
>
>
>> Avi Kivity wrote:
>>
>>>>>>>
>>>>>>>
>>>>>>>> The make headers_check fails,
>>>>>>>>
>>>>>>>> CHECK include/linux/usb/gadgetfs.h
>>>>>>>> CHECK include/linux/usb/ch9.h
>>>>>>>> CHECK include/linux/usb/cdc.h
>>>>>>>> CHECK include/linux/usb/audio.h
>>>>>>>> CHECK include/linux/kvm.h
>>>>>>>> /root/kernels/linux-2.6.24-rc3/usr/include/linux/kvm.h requires
>>>>>>>> asm/kvm.h, which does not exist in exported headers
>>>>>>>>
>>>>>>>>
>>>>>>> hm, works for me, on i386 and x86_64. What's different over there?
>>>>>>>
>>>>>>>
>>>>>> Hi Andrew,
>>>>>>
>>>>>> It fails on the powerpc box, with allyesconfig option.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> How do we fix this? Export linux/kvm.h only on x86? Seems ugly.
>>>>>
>>>>>
>>>> Is kvm x86 specific? Then move the .h file to asm-x86.
>>>> Otherwise no good idea...
>>>>
>>>>
>>>>
>>> kvm.h is x86 specific today, but will be s390, ppc, ia64, and x86
>>> specific tomorrow.
>>>
>>> What about having a asm-generic/kvm.h with a nice #error? would
>>> that suit?
>>>
>>>
>> headers_check continues to complain. Is the only recourse to add
>> asm/kvm.h for all archs?
>>
>>
>
> That would work.
>
> Meanwhile my recourse is to drop the kvm tree ;)
>

Since you put it this way...

I committed the attached (sorry) patch to kvm.git. Rather than
touching 2*($NARCH - 1) file, I changed include/linux/Kbuild to only
export kvm.h if the arch actually supports it. Currently that's just x86.


--
error compiling committee.c: too many arguments to function


Attachments:
0001-KVM-Export-include-linux-kvm.h-only-if-ARCH-actual.patch (1.83 kB)

2007-12-11 18:08:35

by James Bottomley

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1


On Mon, 2007-11-26 at 22:15 -0800, Andrew Morton wrote:
> OK, thanks. I'll assume that James and Hannes have this in hand (or will
> have, by mid-week) and I won't do anything here.

Just to confirm what I think I'm going to be doing: rebasing the
scsi-misc tree to remove this commit:

commit 8655a546c83fc43f0a73416bbd126d02de7ad6c0
Author: Hannes Reinecke <[email protected]>
Date: Tue Nov 6 09:23:40 2007 +0100

[SCSI] Do not requeue requests if REQ_FAILFAST is set

And its allied fix ups:

commit 983289045faa96fba8841d3c51b98bb8623d9504
Author: James Bottomley <[email protected]>
Date: Sat Nov 24 19:47:25 2007 +0200

[SCSI] fix up REQ_FASTFAIL not to fail when state is QUIESCE

commit 9dd15a13b332e9f5c8ee752b1ccd9b84cb5bdf17
Author: James Bottomley <[email protected]>
Date: Sat Nov 24 19:55:53 2007 +0200

[SCSI] fix domain validation to work again

James

2007-12-12 10:09:19

by Boaz Harrosh

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1

On Tue, Dec 11 2007 at 18:33 +0200, James Bottomley <[email protected]> wrote:
> On Mon, 2007-11-26 at 22:15 -0800, Andrew Morton wrote:
>> OK, thanks. I'll assume that James and Hannes have this in hand (or will
>> have, by mid-week) and I won't do anything here.
>
> Just to confirm what I think I'm going to be doing: rebasing the
> scsi-misc tree to remove this commit:
>
> commit 8655a546c83fc43f0a73416bbd126d02de7ad6c0
> Author: Hannes Reinecke <[email protected]>
> Date: Tue Nov 6 09:23:40 2007 +0100
>
> [SCSI] Do not requeue requests if REQ_FAILFAST is set
>
> And its allied fix ups:
>
> commit 983289045faa96fba8841d3c51b98bb8623d9504
> Author: James Bottomley <[email protected]>
> Date: Sat Nov 24 19:47:25 2007 +0200
>
> [SCSI] fix up REQ_FASTFAIL not to fail when state is QUIESCE
>
> commit 9dd15a13b332e9f5c8ee752b1ccd9b84cb5bdf17
> Author: James Bottomley <[email protected]>
> Date: Sat Nov 24 19:55:53 2007 +0200
>
> [SCSI] fix domain validation to work again
>
> James
>

The problems caused by this patch where nagging me at the back of my head
from the begging. Why should we fail on a check of FAIL_FAST in all kind
of weird places like boots, when the only place that should ever set the
flag should be one of the multi-path drivers. finally it struck me:

It might be a bug in ll_rw_blk at blk_rq_bio_prep() there is this:

static void blk_rq_bio_prep(struct request_queue *q, struct request *rq,
struct bio *bio)
{
/* first two bits are identical in rq->cmd_flags and bio->bi_rw */
rq->cmd_flags |= (bio->bi_rw & 3);
...

Now this is no longer true and is a bug.
Second bit of bio->bi_rw defined in bio.h is:
#define BIO_RW_AHEAD 1
but
Second bit of rq->cmd_flags is __REQ_FAILFAST

so maybe we are getting FAILFAST in the wrong places?

(I will look for an old patch I sent a year ago that fixes
this bug)

Boaz

2007-12-12 11:03:56

by Boaz Harrosh

[permalink] [raw]
Subject: [PATCH] REQ-flags to/from BIO-flags bugfix


- BIO flags bio->bi_rw and REQ flags req->cmd_flags no longer match.
Remove comments and do a proper translation between the 2 systems.

(Please look in ll_rw_blk.c/blk_rq_bio_prep() below if we need more flags)

Signed-off-by: Boaz Harrosh <[email protected]>
---
block/ll_rw_blk.c | 23 +++++++++++++++++------
include/linux/blktrace_api.h | 8 +++++++-
2 files changed, 24 insertions(+), 7 deletions(-)

diff --git a/block/ll_rw_blk.c b/block/ll_rw_blk.c
index 8b91994..c6a84bb 100644
--- a/block/ll_rw_blk.c
+++ b/block/ll_rw_blk.c
@@ -1990,10 +1990,6 @@ blk_alloc_request(struct request_queue *q, int rw, int priv, gfp_t gfp_mask)
if (!rq)
return NULL;

- /*
- * first three bits are identical in rq->cmd_flags and bio->bi_rw,
- * see bio.h and blkdev.h
- */
rq->cmd_flags = rw | REQ_ALLOCED;

if (priv) {
@@ -3772,8 +3768,23 @@ EXPORT_SYMBOL(end_request);
static void blk_rq_bio_prep(struct request_queue *q, struct request *rq,
struct bio *bio)
{
- /* first two bits are identical in rq->cmd_flags and bio->bi_rw */
- rq->cmd_flags |= (bio->bi_rw & 3);
+ if (bio_data_dir(bio))
+ rq->cmd_flags |= REQ_RW;
+ else
+ rq->cmd_flags &= ~REQ_RW;
+
+ if (bio->bi_rw & (1<<BIO_RW_SYNC))
+ rq->cmd_flags |= REQ_RW_SYNC;
+ else
+ rq->cmd_flags &= ~REQ_RW_SYNC;
+ /* FIXME: what about other flags, should we sync these too? */
+ /*
+ BIO_RW_AHEAD ==> ??
+ BIO_RW_BARRIER ==> REQ_SOFTBARRIER/REQ_HARDBARRIER
+ BIO_RW_FAILFAST ==> REQ_FAILFAST
+ BIO_RW_SYNC ==> REQ_RW_SYNC
+ BIO_RW_META ==> REQ_RW_META
+ */

rq->nr_phys_segments = bio_phys_segments(q, bio);
rq->nr_hw_segments = bio_hw_segments(q, bio);
diff --git a/include/linux/blktrace_api.h b/include/linux/blktrace_api.h
index 7e11d23..9e7ce65 100644
--- a/include/linux/blktrace_api.h
+++ b/include/linux/blktrace_api.h
@@ -165,7 +165,13 @@ static inline void blk_add_trace_rq(struct request_queue *q, struct request *rq,
u32 what)
{
struct blk_trace *bt = q->blk_trace;
- int rw = rq->cmd_flags & 0x03;
+ /* blktrace.c prints them according to bio flags */
+ int rw = (((rq_rw_dir(rq) == WRITE) << BIO_RW) |
+ (((rq->cmd_flags & (REQ_SOFTBARRIER|REQ_HARDBARRIER)) != 0) <<
+ BIO_RW_BARRIER) |
+ (((rq->cmd_flags & REQ_FAILFAST) != 0) << BIO_RW_FAILFAST) |
+ (((rq->cmd_flags & REQ_RW_SYNC) != 0) << BIO_RW_SYNC) |
+ (((rq->cmd_flags & REQ_RW_META) != 0) << BIO_RW_META));

if (likely(!bt))
return;
--
1.5.3.3

2007-12-12 11:40:06

by Jens Axboe

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1

On Wed, Dec 12 2007, Boaz Harrosh wrote:
> On Tue, Dec 11 2007 at 18:33 +0200, James Bottomley <[email protected]> wrote:
> > On Mon, 2007-11-26 at 22:15 -0800, Andrew Morton wrote:
> >> OK, thanks. I'll assume that James and Hannes have this in hand (or will
> >> have, by mid-week) and I won't do anything here.
> >
> > Just to confirm what I think I'm going to be doing: rebasing the
> > scsi-misc tree to remove this commit:
> >
> > commit 8655a546c83fc43f0a73416bbd126d02de7ad6c0
> > Author: Hannes Reinecke <[email protected]>
> > Date: Tue Nov 6 09:23:40 2007 +0100
> >
> > [SCSI] Do not requeue requests if REQ_FAILFAST is set
> >
> > And its allied fix ups:
> >
> > commit 983289045faa96fba8841d3c51b98bb8623d9504
> > Author: James Bottomley <[email protected]>
> > Date: Sat Nov 24 19:47:25 2007 +0200
> >
> > [SCSI] fix up REQ_FASTFAIL not to fail when state is QUIESCE
> >
> > commit 9dd15a13b332e9f5c8ee752b1ccd9b84cb5bdf17
> > Author: James Bottomley <[email protected]>
> > Date: Sat Nov 24 19:55:53 2007 +0200
> >
> > [SCSI] fix domain validation to work again
> >
> > James
> >
>
> The problems caused by this patch where nagging me at the back of my head
> from the begging. Why should we fail on a check of FAIL_FAST in all kind
> of weird places like boots, when the only place that should ever set the
> flag should be one of the multi-path drivers. finally it struck me:
>
> It might be a bug in ll_rw_blk at blk_rq_bio_prep() there is this:
>
> static void blk_rq_bio_prep(struct request_queue *q, struct request *rq,
> struct bio *bio)
> {
> /* first two bits are identical in rq->cmd_flags and bio->bi_rw */
> rq->cmd_flags |= (bio->bi_rw & 3);
> ...
>
> Now this is no longer true and is a bug.
> Second bit of bio->bi_rw defined in bio.h is:
> #define BIO_RW_AHEAD 1
> but
> Second bit of rq->cmd_flags is __REQ_FAILFAST
>
> so maybe we are getting FAILFAST in the wrong places?

But that's actually on purpose, though the comment is pretty much crap.
We don't want to be retrying readahead requests, those should always
just be tossable.

--
Jens Axboe

2007-12-12 15:18:25

by Matthew Wilcox

[permalink] [raw]
Subject: Re: [PATCH] REQ-flags to/from BIO-flags bugfix

On Wed, Dec 12, 2007 at 01:03:10PM +0200, Boaz Harrosh wrote:
> - BIO flags bio->bi_rw and REQ flags req->cmd_flags no longer match.
> Remove comments and do a proper translation between the 2 systems.

I'd rather see them resynchronised ... in a way that makes it obvious
that they should be desynced again:

I don't know whether BIO_RW_BARRIER is __REQ_SOFTBARRIER or
__REQ_HARDBARRIER, so I didn't include that in this patch. There also
doesn't seem to be a __REQ equivalent to BIO_RW_AHEAD, but we can do
the other four bits (and leave gaps for those two).

diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index d18ee67..6aef34b 100644
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@ -167,11 +167,13 @@ enum {
};

/*
- * request type modified bits. first three bits match BIO_RW* bits, important
+ * request type modified bits. Don't change without looking at bi_rw flags
*/
enum rq_flag_bits {
- __REQ_RW, /* not set, read. set, write */
- __REQ_FAILFAST, /* no low level driver retries */
+ __REQ_RW = BIO_RW, /* not set, read. set, write */
+ __REQ_FAILFAST = BIO_RW_FAILFAST, /* no low level driver retries */
+ __REQ_RW_SYNC = BIO_RW_SYNC, /* request is sync (O_DIRECT) */
+ __REQ_RW_META = BIO_RW_META, /* metadata io request */
__REQ_SORTED, /* elevator knows about this request */
__REQ_SOFTBARRIER, /* may not be passed by ioscheduler */
__REQ_HARDBARRIER, /* may not be passed by drive either */
@@ -185,9 +187,7 @@ enum rq_flag_bits {
__REQ_QUIET, /* don't worry about errors */
__REQ_PREEMPT, /* set for "ide_preempt" requests */
__REQ_ORDERED_COLOR, /* is before or after barrier */
- __REQ_RW_SYNC, /* request is sync (O_DIRECT) */
__REQ_ALLOCED, /* request came from our alloc pool */
- __REQ_RW_META, /* metadata io request */
__REQ_NR_BITS, /* stops here */
};


--
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."

2007-12-12 15:54:29

by Matthew Wilcox

[permalink] [raw]
Subject: Re: [PATCH] REQ-flags to/from BIO-flags bugfix

On Wed, Dec 12, 2007 at 08:18:14AM -0700, Matthew Wilcox wrote:
> I don't know whether BIO_RW_BARRIER is __REQ_SOFTBARRIER or
> __REQ_HARDBARRIER, so I didn't include that in this patch. There also
> doesn't seem to be a __REQ equivalent to BIO_RW_AHEAD, but we can do
> the other four bits (and leave gaps for those two).

Hm. BIO_RW_AHEAD seems unused:

willy@honeydew:~/kernel/linux-2.6$ grep -r BIO_RW_AHEAD *
block/blktrace.c: (((rw) & (1 << BIO_RW_AHEAD)) << (2 - BIO_RW_AHEAD))
include/linux/bio.h:#define BIO_RW_AHEAD 1
include/linux/bio.h:#define bio_rw_ahead(bio) ((bio)->bi_rw & (1 << BIO_RW_AHEAD))
willy@honeydew:~/kernel/linux-2.6$ grep -r bio_rw_ahead *
block/ll_rw_blk.c: if (bio_rw_ahead(bio) || bio_failfast(bio))
drivers/md/dm-mpath.c: if ((error == -EWOULDBLOCK) && bio_rw_ahead(bio))
drivers/md/multipath.c: else if (!bio_rw_ahead(bio)) {
include/linux/bio.h:#define bio_rw_ahead(bio) ((bio)->bi_rw & (1 << BIO_RW_AHEAD))

BIO_RW_BARRIER seems to be __REQ_HARDBARRIER, but we set it
explicitly in init_request_from_bio(). We could probably simplify
init_request_from_bio() with the patch in the previous message.

--
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."

2007-12-12 16:08:24

by Boaz Harrosh

[permalink] [raw]
Subject: Re: [PATCH] REQ-flags to/from BIO-flags bugfix

On Wed, Dec 12 2007 at 17:18 +0200, Matthew Wilcox <[email protected]> wrote:
> On Wed, Dec 12, 2007 at 01:03:10PM +0200, Boaz Harrosh wrote:
>> - BIO flags bio->bi_rw and REQ flags req->cmd_flags no longer match.
>> Remove comments and do a proper translation between the 2 systems.
>
> I'd rather see them resynchronised ... in a way that makes it obvious
> that they should be desynced again:
>
> I don't know whether BIO_RW_BARRIER is __REQ_SOFTBARRIER or
> __REQ_HARDBARRIER, so I didn't include that in this patch. There also
> doesn't seem to be a __REQ equivalent to BIO_RW_AHEAD, but we can do
> the other four bits (and leave gaps for those two).
>
> diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
> index d18ee67..6aef34b 100644
> --- a/include/linux/blkdev.h
> +++ b/include/linux/blkdev.h
> @@ -167,11 +167,13 @@ enum {
> };
>
> /*
> - * request type modified bits. first three bits match BIO_RW* bits, important
> + * request type modified bits. Don't change without looking at bi_rw flags
> */
> enum rq_flag_bits {
> - __REQ_RW, /* not set, read. set, write */
> - __REQ_FAILFAST, /* no low level driver retries */
> + __REQ_RW = BIO_RW, /* not set, read. set, write */
> + __REQ_FAILFAST = BIO_RW_FAILFAST, /* no low level driver retries */
> + __REQ_RW_SYNC = BIO_RW_SYNC, /* request is sync (O_DIRECT) */
> + __REQ_RW_META = BIO_RW_META, /* metadata io request */
> __REQ_SORTED, /* elevator knows about this request */
> __REQ_SOFTBARRIER, /* may not be passed by ioscheduler */
> __REQ_HARDBARRIER, /* may not be passed by drive either */
> @@ -185,9 +187,7 @@ enum rq_flag_bits {
> __REQ_QUIET, /* don't worry about errors */
> __REQ_PREEMPT, /* set for "ide_preempt" requests */
> __REQ_ORDERED_COLOR, /* is before or after barrier */
> - __REQ_RW_SYNC, /* request is sync (O_DIRECT) */
> __REQ_ALLOCED, /* request came from our alloc pool */
> - __REQ_RW_META, /* metadata io request */
> __REQ_NR_BITS, /* stops here */
> };
>
>
Thats not enough You still need to fix code in ll_rw_blk(), I would
define a rq_flags_bio_match_mask = 0xf for that.
(and also add what Jens called "needed" with the
BIO_RW_AHEAD selects REQ_FAILFAST.)

And I still don't understand why, for example, "Domain Validation" fails
with the original patch. What sets BIO_RW_FAILFAST and than panics
on Errors?
(All I see is this flag set in dm/multipath.c & dm-mpath.c)

Boaz

2007-12-12 16:33:52

by Matthew Wilcox

[permalink] [raw]
Subject: Re: [PATCH] REQ-flags to/from BIO-flags bugfix

On Wed, Dec 12, 2007 at 06:06:45PM +0200, Boaz Harrosh wrote:
> Thats not enough You still need to fix code in ll_rw_blk(), I would
> define a rq_flags_bio_match_mask = 0xf for that.
> (and also add what Jens called "needed" with the
> BIO_RW_AHEAD selects REQ_FAILFAST.)

Yes, I appreciate it's not enough; that's why I didn't sign-off on it.

Nobody currently sets BIO_RW_AHEAD, so I don't understand why we need to
do anything ;-)

> And I still don't understand why, for example, "Domain Validation" fails
> with the original patch. What sets BIO_RW_FAILFAST and than panics
> on Errors?
> (All I see is this flag set in dm/multipath.c & dm-mpath.c)

No idea ...

--
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."

2007-12-13 05:46:20

by David Chinner

[permalink] [raw]
Subject: Re: [PATCH] REQ-flags to/from BIO-flags bugfix

On Wed, Dec 12, 2007 at 08:54:07AM -0700, Matthew Wilcox wrote:
> On Wed, Dec 12, 2007 at 08:18:14AM -0700, Matthew Wilcox wrote:
> > I don't know whether BIO_RW_BARRIER is __REQ_SOFTBARRIER or
> > __REQ_HARDBARRIER, so I didn't include that in this patch. There also
> > doesn't seem to be a __REQ equivalent to BIO_RW_AHEAD, but we can do
> > the other four bits (and leave gaps for those two).
>
> Hm. BIO_RW_AHEAD seems unused:
>
> willy@honeydew:~/kernel/linux-2.6$ grep -r BIO_RW_AHEAD *
> block/blktrace.c: (((rw) & (1 << BIO_RW_AHEAD)) << (2 - BIO_RW_AHEAD))
> include/linux/bio.h:#define BIO_RW_AHEAD 1
> include/linux/bio.h:#define bio_rw_ahead(bio) ((bio)->bi_rw & (1 << BIO_RW_AHEAD))
> willy@honeydew:~/kernel/linux-2.6$ grep -r bio_rw_ahead *
> block/ll_rw_blk.c: if (bio_rw_ahead(bio) || bio_failfast(bio))
> drivers/md/dm-mpath.c: if ((error == -EWOULDBLOCK) && bio_rw_ahead(bio))
> drivers/md/multipath.c: else if (!bio_rw_ahead(bio)) {
> include/linux/bio.h:#define bio_rw_ahead(bio) ((bio)->bi_rw & (1 << BIO_RW_AHEAD))

That would say to me that READA is not hooked up correctly. i.e:

#define READ 0
#define WRITE 1
#define READA 2 /* read-ahead - don't block if no resources */
#define SWRITE 3 /* for ll_rw_block() - wait for buffer lock */
#define READ_SYNC (READ | (1 << BIO_RW_SYNC))
#define READ_META (READ | (1 << BIO_RW_META))
#define WRITE_SYNC (WRITE | (1 << BIO_RW_SYNC))
#define WRITE_BARRIER ((1 << BIO_RW) | (1 << BIO_RW_BARRIER))

i.e. it should be:

#define READA (1 << BIO_RW_AHEAD)

Right?

FWIW, dm does this:

if (bio_rw(bio) != READA)

Which really should be if (bio_rw_ahead(bio)).....

Cheers,

Dave.
--
Dave Chinner
Principal Engineer
SGI Australian Software Group

2007-12-14 09:01:18

by Hannes Reinecke

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1

James Bottomley wrote:
> On Mon, 2007-11-26 at 22:15 -0800, Andrew Morton wrote:
>> OK, thanks. I'll assume that James and Hannes have this in hand (or will
>> have, by mid-week) and I won't do anything here.
>
> Just to confirm what I think I'm going to be doing: rebasing the
> scsi-misc tree to remove this commit:
>
> commit 8655a546c83fc43f0a73416bbd126d02de7ad6c0
> Author: Hannes Reinecke <[email protected]>
> Date: Tue Nov 6 09:23:40 2007 +0100
>
> [SCSI] Do not requeue requests if REQ_FAILFAST is set
>
> And its allied fix ups:
>
> commit 983289045faa96fba8841d3c51b98bb8623d9504
> Author: James Bottomley <[email protected]>
> Date: Sat Nov 24 19:47:25 2007 +0200
>
> [SCSI] fix up REQ_FASTFAIL not to fail when state is QUIESCE
>
> commit 9dd15a13b332e9f5c8ee752b1ccd9b84cb5bdf17
> Author: James Bottomley <[email protected]>
> Date: Sat Nov 24 19:55:53 2007 +0200
>
> [SCSI] fix domain validation to work again
>
> James
>
>
Or just apply my latest patch (cf Undo __scsi_kill_request).
The main point is that we shouldn't retry requests
with FAILFAST set when the queue is blocked. AFAICS
only FC and iSCSI transports set the queue to blocked,
and use this to indicate a loss of connection. So any
retry with queue blocked is futile.

Cheers,

Hannes

--
Dr. Hannes Reinecke zSeries & Storage
[email protected] +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N?rnberg
GF: Markus Rex, HRB 16746 (AG N?rnberg)

2007-12-14 14:27:11

by James Bottomley

[permalink] [raw]
Subject: Re: 2.6.24-rc3-mm1


On Fri, 2007-12-14 at 10:00 +0100, Hannes Reinecke wrote:
> James Bottomley wrote:
> > On Mon, 2007-11-26 at 22:15 -0800, Andrew Morton wrote:
> >> OK, thanks. I'll assume that James and Hannes have this in hand (or will
> >> have, by mid-week) and I won't do anything here.
> >
> > Just to confirm what I think I'm going to be doing: rebasing the
> > scsi-misc tree to remove this commit:
> >
> > commit 8655a546c83fc43f0a73416bbd126d02de7ad6c0
> > Author: Hannes Reinecke <[email protected]>
> > Date: Tue Nov 6 09:23:40 2007 +0100
> >
> > [SCSI] Do not requeue requests if REQ_FAILFAST is set
> >
> > And its allied fix ups:
> >
> > commit 983289045faa96fba8841d3c51b98bb8623d9504
> > Author: James Bottomley <[email protected]>
> > Date: Sat Nov 24 19:47:25 2007 +0200
> >
> > [SCSI] fix up REQ_FASTFAIL not to fail when state is QUIESCE
> >
> > commit 9dd15a13b332e9f5c8ee752b1ccd9b84cb5bdf17
> > Author: James Bottomley <[email protected]>
> > Date: Sat Nov 24 19:55:53 2007 +0200
> >
> > [SCSI] fix domain validation to work again
> >
> > James
> >
> >
> Or just apply my latest patch (cf Undo __scsi_kill_request).
> The main point is that we shouldn't retry requests
> with FAILFAST set when the queue is blocked. AFAICS
> only FC and iSCSI transports set the queue to blocked,
> and use this to indicate a loss of connection. So any
> retry with queue blocked is futile.

I still don't think this is the right approach.

For link up/down events, those are direct pathing events and should be
signalled along a kernel notifier, not by mucking with the SCSI state
machine. However, there's still devloss_tmo to consider ... even in
multipath, I don't think you want to signal path failure until
devloss_tmo has fired otherwise you'll get too many transient up/down
events which damage performance if the array has an expensive failover
model.

The other problem is what to do with in-flight commands at the time the
link went down. With your current patch, they're still stuck until they
time out ... surely there needs to be some type of recovery mechanism
for these?

James

2007-12-31 21:06:36

by Alan Stern

[permalink] [raw]
Subject: Re: [linux-usb-devel] 2.6.24-rc3-mm1: usb mouse doesn't work

On Fri, 23 Nov 2007, Kirill A. Shutemov wrote:

> On [Thu, 22.11.2007 21:51], Alan Stern wrote:
> > On Thu, 22 Nov 2007, Marin Mitov wrote:
> >
> > > > > > I've had some strangenesses with USB lately. Sometimes running `lsusb'
> > > > > > makes the USB system notice a newly attached device.
> > > > >
> > > > > No. But I have new messages in dmesg:
> > > > >
> > > > > uhci_hcd 0000:00:1d.3: FGR not stopped yet!
> > > > > uhci_hcd 0000:00:1d.2: FGR not stopped yet!
> > > > > uhci_hcd 0000:00:1d.1: FGR not stopped yet!
> > > > > uhci_hcd 0000:00:1d.0: FGR not stopped yet!
> > > > >
> > > > > > Is that "FGR not stopped yet!" messgae new behaviour?
> > > > >
> > > > > It is a new message since 2.6.24-rc3. I have never try -mm tree before.
> > > >
> > > > These messages could indicate a timing problem. You can see the code
> > > > that writes the messages near the end of wakeup_rh() in
> > > > drivers/usb/host/uhci-hcd.c.
> > > >
> > > > The message gets written if the controller hardware hasn't turned off a
> > > > particular bit after a 4-us delay. If the udelay() function wasn't
> > > > working right, it could cause this problem.
> > >
> > > udelay() _is_ OK for 2.6.24-rc3, so it is not the cause of the problem
> >
> > But is it OK for 2.6.24-rc3-mm1? Kirill said specifically that
> > 2.6.24-rc3 does not display the message but 2.6.24-rc3-mm1 does.
>
> How can I test it?

Any progress? How about more recent kernels?

Alan Stern

2008-01-07 14:05:55

by Hannes Reinecke

[permalink] [raw]
Subject: Multipath failover handling (Was: Re: 2.6.24-rc3-mm1)

James Bottomley wrote:
> On Fri, 2007-12-14 at 10:00 +0100, Hannes Reinecke wrote:
>> James Bottomley wrote:
>>> On Mon, 2007-11-26 at 22:15 -0800, Andrew Morton wrote:
>>>> OK, thanks. I'll assume that James and Hannes have this in hand (or will
>>>> have, by mid-week) and I won't do anything here.
>>> Just to confirm what I think I'm going to be doing: rebasing the
>>> scsi-misc tree to remove this commit:
>>>
>>> commit 8655a546c83fc43f0a73416bbd126d02de7ad6c0
>>> Author: Hannes Reinecke <[email protected]>
>>> Date: Tue Nov 6 09:23:40 2007 +0100
>>>
>>> [SCSI] Do not requeue requests if REQ_FAILFAST is set
>>>
>>> And its allied fix ups:
>>>
>>> commit 983289045faa96fba8841d3c51b98bb8623d9504
>>> Author: James Bottomley <[email protected]>
>>> Date: Sat Nov 24 19:47:25 2007 +0200
>>>
>>> [SCSI] fix up REQ_FASTFAIL not to fail when state is QUIESCE
>>>
>>> commit 9dd15a13b332e9f5c8ee752b1ccd9b84cb5bdf17
>>> Author: James Bottomley <[email protected]>
>>> Date: Sat Nov 24 19:55:53 2007 +0200
>>>
>>> [SCSI] fix domain validation to work again
>>>
>>> James
>>>
>>>
>> Or just apply my latest patch (cf Undo __scsi_kill_request).
>> The main point is that we shouldn't retry requests
>> with FAILFAST set when the queue is blocked. AFAICS
>> only FC and iSCSI transports set the queue to blocked,
>> and use this to indicate a loss of connection. So any
>> retry with queue blocked is futile.
>
> I still don't think this is the right approach.
>
> For link up/down events, those are direct pathing events and should be
> signalled along a kernel notifier, not by mucking with the SCSI state
> machine.
Of course they will be signalled. And eventually we should patch up
mutltipath-tools to read the exising events from the uevent socket.
But even with that patch there is a quite largish window during
which IOs will be sent to the blocked device, and hence will be
stuck in the request queue until the timer expires.

> However, there's still devloss_tmo to consider ... even in
> multipath, I don't think you want to signal path failure until
> devloss_tmo has fired otherwise you'll get too many transient up/down
> events which damage performance if the array has an expensive failover
> model.
>
Yes. But currently we have a very high failover latency as we always have
to wait for the requeued commands to time-out.
Hence we're damaging performance on arrays with inexpensive failover.

> The other problem is what to do with in-flight commands at the time the
> link went down. With your current patch, they're still stuck until they
> time out ... surely there needs to be some type of recovery mechanism
> for these?
>
Well, the in-flight commands are owned by the HBA driver, which should
have the proper code to terminate / return those commands with the
appriopriate codes. They will then be rescheduled and will be caught
like 'normal' IO requests.

Cheers,

Hannes
--
Dr. Hannes Reinecke zSeries & Storage
[email protected] +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N?rnberg
GF: Markus Rex, HRB 16746 (AG N?rnberg)

2008-01-07 17:58:09

by James Bottomley

[permalink] [raw]
Subject: Re: Multipath failover handling (Was: Re: 2.6.24-rc3-mm1)

On Mon, 2008-01-07 at 15:05 +0100, Hannes Reinecke wrote:
> James Bottomley wrote:
> > On Fri, 2007-12-14 at 10:00 +0100, Hannes Reinecke wrote:
> >> James Bottomley wrote:
> >>> On Mon, 2007-11-26 at 22:15 -0800, Andrew Morton wrote:
> >>>> OK, thanks. I'll assume that James and Hannes have this in hand (or will
> >>>> have, by mid-week) and I won't do anything here.
> >>> Just to confirm what I think I'm going to be doing: rebasing the
> >>> scsi-misc tree to remove this commit:
> >>>
> >>> commit 8655a546c83fc43f0a73416bbd126d02de7ad6c0
> >>> Author: Hannes Reinecke <[email protected]>
> >>> Date: Tue Nov 6 09:23:40 2007 +0100
> >>>
> >>> [SCSI] Do not requeue requests if REQ_FAILFAST is set
> >>>
> >>> And its allied fix ups:
> >>>
> >>> commit 983289045faa96fba8841d3c51b98bb8623d9504
> >>> Author: James Bottomley <[email protected]>
> >>> Date: Sat Nov 24 19:47:25 2007 +0200
> >>>
> >>> [SCSI] fix up REQ_FASTFAIL not to fail when state is QUIESCE
> >>>
> >>> commit 9dd15a13b332e9f5c8ee752b1ccd9b84cb5bdf17
> >>> Author: James Bottomley <[email protected]>
> >>> Date: Sat Nov 24 19:55:53 2007 +0200
> >>>
> >>> [SCSI] fix domain validation to work again
> >>>
> >>> James
> >>>
> >>>
> >> Or just apply my latest patch (cf Undo __scsi_kill_request).
> >> The main point is that we shouldn't retry requests
> >> with FAILFAST set when the queue is blocked. AFAICS
> >> only FC and iSCSI transports set the queue to blocked,
> >> and use this to indicate a loss of connection. So any
> >> retry with queue blocked is futile.
> >
> > I still don't think this is the right approach.
> >
> > For link up/down events, those are direct pathing events and should be
> > signalled along a kernel notifier, not by mucking with the SCSI state
> > machine.
> Of course they will be signalled. And eventually we should patch up
> mutltipath-tools to read the exising events from the uevent socket.
> But even with that patch there is a quite largish window during
> which IOs will be sent to the blocked device, and hence will be
> stuck in the request queue until the timer expires.

But the assumption your code makes is that if REQ_FAILFAST is set then
it's a dm request ... and that's not true. The code in question
negatively impacts other users of REQ_FAILFAST. For every user other
than dm, the right thing to do is to wait out the block.

> > However, there's still devloss_tmo to consider ... even in
> > multipath, I don't think you want to signal path failure until
> > devloss_tmo has fired otherwise you'll get too many transient up/down
> > events which damage performance if the array has an expensive failover
> > model.
> >
> Yes. But currently we have a very high failover latency as we always have
> to wait for the requeued commands to time-out.
> Hence we're damaging performance on arrays with inexpensive failover.

If it's a either/or choice between the two that's showing our current
approach to multi-path is broken.

> > The other problem is what to do with in-flight commands at the time the
> > link went down. With your current patch, they're still stuck until they
> > time out ... surely there needs to be some type of recovery mechanism
> > for these?
> >
> Well, the in-flight commands are owned by the HBA driver, which should
> have the proper code to terminate / return those commands with the
> appriopriate codes. They will then be rescheduled and will be caught
> like 'normal' IO requests.

But my point is that if a driver goes blocked, those commands will be
forced to wait the blocked timeout anyway, so your proposed patch does
nothing to improve the case for dm anyway ... you only avoid commands
stuck when a device goes blocked if by chance its request queue was
empty.

James

2008-01-07 18:25:21

by Mike Christie

[permalink] [raw]
Subject: Re: Multipath failover handling (Was: Re: 2.6.24-rc3-mm1)

James Bottomley wrote:
>>> However, there's still devloss_tmo to consider ... even in
>>> multipath, I don't think you want to signal path failure until
>>> devloss_tmo has fired otherwise you'll get too many transient up/down
>>> events which damage performance if the array has an expensive failover
>>> model.
>>>
>> Yes. But currently we have a very high failover latency as we always have
>> to wait for the requeued commands to time-out.
>> Hence we're damaging performance on arrays with inexpensive failover.
>
> If it's a either/or choice between the two that's showing our current
> approach to multi-path is broken.
>
>>> The other problem is what to do with in-flight commands at the time the
>>> link went down. With your current patch, they're still stuck until they
>>> time out ... surely there needs to be some type of recovery mechanism
>>> for these?
>>>
>> Well, the in-flight commands are owned by the HBA driver, which should
>> have the proper code to terminate / return those commands with the
>> appriopriate codes. They will then be rescheduled and will be caught
>> like 'normal' IO requests.
>
> But my point is that if a driver goes blocked, those commands will be
> forced to wait the blocked timeout anyway, so your proposed patch does
> nothing to improve the case for dm anyway ... you only avoid commands
> stuck when a device goes blocked if by chance its request queue was
> empty.


How about my patches to use new transport error values and make the
iscsi and fc behave the same.

The problem I think Hannes and I are both trying to solve is this:

1. We do not want to wait for dev_loss_tmo seconds for failover.

2. The FC drivers can hook into fast_io_fail_tmo related callouts and
with that set that tmo to a very low value like a couple of seconds if
they are using multipath, so failovers are fast. However, there is a bug
with where when the fast_io_fail_tmo fires requests that made it to the
driver get failed and returned to the multipath layer, but commands in
the blocked request queue are stuck in there until dev_loss_tmo fires.

With my patches here (need to be rediffed and for FC I need to handle
JamesS's comments about not using a new field for the fast_fail_timeout
state bit):

http://marc.info/?l=linux-scsi&m=117399843216280&w=2
http://marc.info/?l=linux-scsi&m=117399544112073&w=2
http://marc.info/?l=linux-scsi&m=117399844316771&w=2
http://marc.info/?l=linux-scsi&m=117400203324693&w=2
http://marc.info/?l=linux-scsi&m=117400203324690&w=2

For FC we can use the fast_io_fail_tmo for fast failovers, and commands
will not get stuck in a blocked queue for dev_loss_tmo seconds because
when the fast_io_fail_tmo fires the target's queues are unblocked and
fc_remote_port_chkready() ready kicks in (iSCSI does the same with the
patches in the links). And with the patches if multipath-tools is
sending its path testing IO it will get a DID_TRANSPORT_* error code
that it can use to make a decent path failing decision with.