ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc1/2.6.19-rc1-mm1/
- Added the ext4 filesystem. Quick usage instructions:
- Grab updated e2fsprogs from
ftp://ftp.kernel.org/pub/linux/kernel/people/tytso/e2fsprogs-interim/
- It's still mke2fs -j /dev/hda1
- mount /dev/hda1 /wherever -t ext4dev
- To enable extents,
mount /dev/hda1 /wherever -t ext4dev -o extents
- The filesystem is compatible with the ext3 driver until you add a file
which has extents (ie: `mount -o extents', then create a file).
- When comparing performance with other filesystems, remember that
ext3/4 by default offers higher data integrity guarantees than most. So
when comparing with a metadata-only journalling filesystem, use `mount -o
data=writeback'. (Although this doesn't seem to make much difference with
ext3).
And you might as well use `mount -o nobh' too.
Making the journal larger than the mke2fs default often helps
performance with metadata-intensive workloads.
- Added the high-resolution timers and dynamic-ticks code. Please be sure
to cc [email protected]>, [email protected] and [email protected] if it blows
up.
Boilerplate:
- See the `hot-fixes' directory for any important updates to this patchset.
- To fetch an -mm tree using git, use (for example)
git fetch git://git.kernel.org/pub/scm/linux/kernel/git/smurf/linux-trees.git v2.6.16-rc2-mm1
- -mm kernel commit activity can be reviewed by subscribing to the
mm-commits mailing list.
echo "subscribe mm-commits" | mail [email protected]
- If you hit a bug in -mm and it 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.
- Semi-daily 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.
Changes since 2.6.18-mm3:
origin.patch
git-acpi.patch
git-cifs.patch
git-dvb.patch
git-geode.patch
git-ia64.patch
git-ieee1394.patch
git-infiniband.patch
git-libata-all.patch
git-mtd.patch
git-netdev-all.patch
git-ocfs2.patch
git-pcmcia.patch
git-selinux.patch
git-pciseg.patch
git-s390.patch
git-sh.patch
git-scsi-target.patch
git-qla3xxx.patch
git-watchdog.patch
git-gccbug.patch
git trees.
-pidh-cleanup.patch
-vfs-make-filldir_t-and-struct-kstat-deal-in-64-bit-inode-numbers.patch
-revert-insert-ioapics-and-local-apic-into-resource-map.patch
-acpi-cast-removal.patch
-dereference-after-free-in-snd_hwdep_release.patch
-kauditd_thread-warning-fix.patch
-hdrcheck-permission-fix.patch
-docs-small-kbuild-cleanup.patch
-kthread-update-arch-mips-kernel-apmc.patch
-mmc-driver-for-ti-flashmedia-card-reader-source.patch
-mmc-driver-for-ti-flashmedia-card-reader-kconfig-makefile.patch
-forcedeth-hardirq-lockdep-warning.patch
-hp100-fix-conditional-compilation-mess.patch
-zatm-always-clear-pcr-in-alloc_shaper.patch
-atm-ambassador-fix-return-code-bug.patch
-tipc-fix-printk-warning.patch
-git-powerpc-wrapper-dont-require-execute-permissions.patch
-powerpc-xmon-fix.patch
-pcie_portdrv_restore_config-undefined-without-config_pm.patch
-pci-optionally-sort-device-lists-breadth-first.patch
-scsi-convertion-to-struct-scsi_cmnd-in-ips-driver.patch
-scsi-scsi_cmnd-convertion-in-arm-subtree.patch
-gregkh-usb-usb-storage-unusual_devs.h-entry-for-sony-ericsson-p990i.patch
-usb-serial-mos7840-fix-cast.patch
-x86_64-mm-defconfig-update.patch
-x86_64-mm-i386-defconfig-update.patch
-x86_64-mm-calgary-init.patch
-x86_64-mm-calgary-off-by-one.patch
-x86_64-mm-calgary-jon-contact.patch
-x86_64-mm-calgary-hex-bus.patch
-x86_64-mm-pci-bios-fix.patch
-x86_64-mm-kernel-stack-termination.patch
-fix-x86_64-mm-kernel-stack-termination.patch
-mm-micro-optimise-zone_watermark_ok.patch
-slab-clean-up-leak-tracking-ifdefs-a-little-bit.patch
-kmemdup-introduce-vs-slab-clean-up-leak-tracking-ifdefs-a-little-bit.patch
-slab-reduce-numa-text-size.patch
-slab-reduce-numa-text-size-tidy.patch
-create-kallsyms_lookup_size_offset.patch
-low-performance-of-lib-sortc.patch
-char-kill-unneeded-memsets.patch
-char-serial167-remove-useless-tty-check.patch
-kernel-doc-for-kernel-dmac.patch
-kernel-doc-for-kernel-resourcec.patch
-fs-eventpoll-error-handling-micro-cleanup.patch
-ipmi-fix-uninitd-data-bug.patch
-drivers-char-ip2-kill-unused-code-label.patch
-schedule-ftape-removal.patch
-isdn-warning-fixes.patch
-restore-parport_pc-probing-on-powermac.patch
-add-pekka-to-credits.patch
-ipmi-allow-user-to-override-the-kernel-ipmi-daemon-enable.patch
-ipmi-allow-user-to-override-the-kernel-ipmi-daemon-enable-tidy.patch
-ia64-note-requirement-for-8250_pnp-now-that-8250_acpi-is-gone.patch
-maintainers-removes-duplicated-entry.patch
-pktcdvd-replace-pktcdvd-strings-with-macro-driver_name.patch
-pktcdvd-rename-a-variable-for-better-readability.patch
-remove-unnecessary-check-in-fs-reiserfs-inodec.patch
-add-unifdef-to-gitignore.patch
-fix-spurious-error-on-tags-target-when-missing-defconfig.patch
-pata_hpt366-fix-typo.patch
-hisax-niccy-cleanup.patch
-knfsd-nfsd-lockdep-annotation-fix.patch
-knfsd-call-lockd_down-when-closing-a-socket-via-a-write-to-nfsd-portlist.patch
-knfsd-protect-update-to-sn_nrthreads-with-lock_kernel.patch
-knfsd-fixed-handling-of-lockd-fail-when-adding-nfsd-socket.patch
-knfsd-replace-two-page-lists-in-struct-svc_rqst-with-one.patch
-knfsd-replace-two-page-lists-in-struct-svc_rqst-with-one-fix.patch
-knfsd-avoid-excess-stack-usage-in-svc_tcp_recvfrom.patch
-knfsd-prepare-knfsd-for-support-of-rsize-wsize-of-up-to-1mb-over-tcp.patch
-knfsd-allow-max-size-of-nfsd-payload-to-be-configured.patch
-knfsd-make-nfsd-readahead-params-cache-smp-friendly.patch
-knfsd-knfsd-cache-ipmap-per-tcp-socket.patch
-knfsd-hide-use-of-lockds-h_monitored-flag.patch
-knfsd-consolidate-common-code-for-statd-lockd-notification.patch
-knfsd-when-looking-up-a-lockd-host-pass-hostname-length.patch
-knfsd-lockd-introduce-nsm_handle.patch
-knfsd-lockd-introduce-nsm_handle-fix.patch
-knfsd-misc-minor-fixes-indentation-changes.patch
-knfsd-lockd-make-nlm_host_rebooted-use-the-nsm_handle.patch
-knfsd-lockd-make-the-nsm-upcalls-use-the-nsm_handle.patch
-knfsd-lockd-make-the-hash-chains-use-a-hlist_node.patch
-knfsd-lockd-change-list-of-blocked-list-to-list_node.patch
-knfsd-change-nlm_file-to-use-a-hlist.patch
-knfsd-lockd-make-nlm_traverse_-more-flexible.patch
-knfsd-lockd-add-nlm_destroy_host.patch
-knfsd-simplify-nlmsvc_invalidate_all.patch
-knfsd-lockd-optionally-use-hostnames-for-identifying-peers.patch
-knfsd-make-nlmclnt_next_cookie-smp-safe.patch
-knfsd-match-granted_res-replies-using-cookies.patch
-knfsd-export-nsm_local_state-to-user-space-via-sysctl.patch
-knfsd-lockd-fix-use-of-h_nextrebind.patch
-knfsd-register-all-rpc-programs-with-portmapper-by-default.patch
-knfsd-lockd-introduce-nsm_handle-sem2mutex.patch
-knfsd-svcrpc-gss-factor-out-some-common-wrapping-code.patch
-knfsd-svcrpc-gss-fix-failure-on-svc_denied-in-integrity-case.patch
-knfsd-svcrpc-use-consistent-variable-name-for-the-reply-state.patch
-knfsd-nfsd4-refactor-exp_pseudoroot.patch
-knfsd-nfsd4-clean-up-exp_pseudoroot.patch
-knfsd-nfsd4-acls-relax-the-nfsv4-posix-mapping.patch
-knfsd-nfsd4-acls-fix-inheritance.patch
-knfsd-nfsd4-acls-simplify-nfs4_acl_nfsv4_to_posix-interface.patch
-knfsd-nfsd4-acls-fix-handling-of-zero-length-acls.patch
-knfsd-lockd-fix-refount-on-nsm.patch
-knfsd-fix-auto-sizing-of-nfsd-request-reply-buffers.patch
-knfsd-close-a-race-opportunity-in-d_splice_alias.patch
-knfsd-nfsd-store-export-path-in-export.patch
-knfsd-nfsd4-fslocations-data-structures.patch
-knfsd-nfsd4-fslocations-data-structures-nfsd4-fix-fs-locations-bounds-checking.patch
-knfsd-nfsd4-fslocations-data-structures-nfsd4-fslocs-fix-compile-in-non-config_nfsd_v4-case.patch
-knfsd-nfsd4-xdr-encoding-for-fs_locations.patch
-knfsd-nfsd4-actually-use-all-the-pieces-to-implement-referrals.patch
-sched-force-sbin-init-off-isolated-cpus.patch
-sched-remove-unnecessary-sched-group-allocations.patch
-sched-dont-print-migration-cost-when-only-1-cpu.patch
-sched-introduce-child-field-in-sched_domain.patch
-sched-cleanup-sched_group-cpu_power-setup.patch
-sched-fixing-wrong-comment-for-find_idlest_cpu.patch
-scheduler-numa-aware-placement-of-sched_group_allnodes.patch
-ecryptfs-fs-makefile-and-fs-kconfig.patch
-ecryptfs-fs-makefile-and-fs-kconfig-kconfig-help-update.patch
-ecryptfs-documentation.patch
-ecryptfs-makefile.patch
-ecryptfs-main-module-functions.patch
-ecryptfs-header-declarations.patch
-ecryptfs-superblock-operations.patch
-ecryptfs-dentry-operations.patch
-ecryptfs-file-operations.patch
-ecryptfs-file-operations-readdir-fix-for-seeking-in-directory-streams.patch
-ecryptfs-inode-operations.patch
-ecryptfs-mmap-operations.patch
-ecryptfs-mmap-operations-fix.patch
-ecryptfs-keystore.patch
-ecryptfs-crypto-functions.patch
-ecryptfs-crypto-functions-mutex-fixes.patch
-fs-ecryptfs-possible-cleanups.patch
-ecryptfs-debug-functions.patch
-ecryptfs-alpha-build-fix.patch
-ecryptfs-convert-assert-to-bug_on.patch
-ecryptfs-remove-pointless-bug_ons.patch
-ecryptfs-remove-unnecessary-null-checks.patch
-ecryptfs-rewrite-ecryptfs_fsync.patch
-ecryptfs-overhaul-file-locking.patch
-ecryptfs-remove-lock-propagation.patch
-ecryptfs-dont-muck-with-the-existing-nameidata-structures.patch
-ecryptfs-asm-scatterlisth-linux-scatterlisth.patch
-ecryptfs-support-for-larger-maximum-key-size.patch
-ecryptfs-add-codes-for-additional-ciphers.patch
-ecryptfs-unencrypted-key-size-based-on-encrypted-key-size.patch
-ecryptfs-packet-and-key-management-update-for-variable-key-size.patch
-ecryptfs-add-ecryptfs_-prefix-to-mount-options-key-size-parameter.patch
-ecryptfs-set-the-key-size-from-the-default-for-the-mount.patch
-ecryptfs-check-for-weak-keys.patch
-ecryptfs-add-define-values-for-cipher-codes-from-rfc2440-openpgp.patch
-ecryptfs-convert-bits-to-bytes.patch
-ecryptfs-more-elegant-aes-key-size-manipulation.patch
-ecryptfs-more-intelligent-use-of-tfm-objects.patch
-ecryptfs-remove-debugging-cruft.patch
-ecryptfs-get_sb_dev-fix.patch
-ecryptfs-validate-minimum-header-extent-size.patch
-ecryptfs-validate-body-size.patch
-ecryptfs-validate-packet-length-prior-to-parsing-add-comments.patch
-ecryptfs-use-the-passed-in-max-value-as-the-upper-bound.patch
-ecryptfs-change-the-maximum-size-check-when-writing-header.patch
-ecryptfs-print-the-actual-option-that-is-problematic.patch
-ecryptfs-add-a-maintainers-entry.patch
-ecryptfs-partial-signed-integer-to-size_t-conversion-updated-ii.patch
-ecryptfs-graceful-handling-of-mount-error.patch
-inode-diet-move-i_pipe-into-a-union-ecryptfs.patch
-inode-diet-eliminate-i_blksize-and-use-a-per-superblock-default-ecryptfs.patch
-streamline-generic_file_-interfaces-and-filemap-ecryptfs.patch
-ecryptfs-fix-printk-format-warnings.patch
-ecryptfs-associate-vfsmount-with-dentry-rather-than-superblock.patch
-ecryptfs-mntput-lower-mount-on-umount_begin.patch
-vfs-make-filldir_t-and-struct-kstat-deal-in-64-bit-inode-numbers-ecryptfs.patch
-make-kmem_cache_destroy-return-void-ecryptfs.patch
-ecryptfs-inode-numbering-fixes.patch
-ecryptfs-versioning-fixes.patch
-ecryptfs-versioning-fixes-tidy.patch
-ecryptfs-grab-lock-on-lower_page-in-ecryptfs_sync_page.patch
-ecryptfs-enable-plaintext-passthrough.patch
-non-libata-driver-for-jmicron-devices.patch
-ide-claim-extra-dma-ports-regardless-of-channel.patch
-ide-always-release-dma-engine.patch
-ide-error-handling-fixes.patch
-make-number-of-ide-interfaces-configurable.patch
-ide_dma_speed-fixes.patch
-enable-cdrom-dma-access-with-pdc20265_old.patch
-ide-fix-revision-comparison-in-ide_in_drive_list.patch
-ide-backport-piix-fixes-from-libata-into-the-legacy-driver.patch
-move-ide-to-unmaintained-drop-reference-to-old-git-tree.patch
-ide-core-must_check-fixes.patch
-drivers-ide-cleanups.patch
-ide-remove-dma_base2-field-from-ide_hwif_t.patch
-ide-reprogram-disk-pio-timings-on-resume.patch
-pcmcia-add-few-ids-into-ide-cs.patch
-config_pm=n-slim-drivers-ide-pci-sc1200c.patch
-ide-fix-crash-on-repeated-reset.patch
-ide-fix-crash-on-repeated-reset-tidy.patch
-allow-ide_generic_all-to-be-used-modular-and-built-in.patch
-ide-more-pci_find-cleanup.patch
-ide-cs-compactflash-driver-rm-irq-warning.patch
-au1100fb-add-option-to-enable-disable-the-cursor.patch
-intelfb-documentation-update.patch
-rivafb-use-constants-instead-of-magic-values.patch
-vfb-document-option-to-enable-the-driver.patch
-fbdev-add-generic-ddc-read-functionality.patch
-nvidiafb-use-generic-ddc-reading.patch
-rivafb-use-generic-ddc-reading.patch
-i810fb-use-generic-ddc-reading.patch
-savagefb-use-generic-ddc-reading.patch
-savagefb-use-generic-ddc-reading-fix.patch
-radeonfb-use-generic-ddc-reading.patch
-fbcon-use-persistent-allocation-for-cursor-blinking.patch
-fbcon-remove-cursor-timer-if-unused.patch
-vt-honor-the-return-value-of-device_create_file.patch
-fbdev-honor-the-return-value-of-device_create_file.patch
-fbcon-honor-the-return-value-of-device_create_file.patch
-atyfb-honor-the-return-value-of-pci_register_driver.patch
-matroxfb-honor-the-return-value-of-pci_register_driver.patch
-nvidiafb-honor-the-return-value-of-pci_enable_device.patch
-i810fb-honor-the-return-value-of-pci_enable_device.patch
-drivers-video-sis-init301h-removal-of-old.patch
-drivers-video-sis-initextlfbc-removal-of.patch
-drivers-video-sis-inith-removal-of-old-code.patch
-drivers-video-sis-osdefh-removal-of-old-code.patch
-drivers-video-sis-sis_accelc-removal-of-old.patch
-drivers-video-sis-sis_accelh-removal-of-old.patch
-drivers-video-sis-sis_mainc-removal-of-old.patch
-drivers-video-sis-sis_mainc-removal-of-old-2.patch
-drivers-video-sis-vgatypesh-removal-of-old.patch
-drivers-video-sis-sis_mainh-removal-of-old.patch
-atyfb-possible-cleanups.patch
-mbxfb-fix-a-chip-bug-resulting-in-wrong-pixclock.patch
-mbxfb-fix-framebuffer-size-smaller-than-requested.patch
-fbcon-make-3-functions-static.patch
-vt-proper-prototypes-for-some-console-functions.patch
-sstfb-clean-ups.patch
-documentation-fixes-in-intel810txt.patch
-radeonfb-supend-resume-support-for-acer-aspire-2010.patch
-fbdev-correct-buffer-size-limit-in-fbmem_read_proc.patch
-dm-support-ioctls-on-mapped-devices.patch
-dm-linear-support-ioctls.patch
-dm-mpath-support-ioctls.patch
-dm-export-blkdev_driver_ioctl.patch
-dm-support-ioctls-on-mapped-devices-fix-with-fake-file.patch
-dm-fix-alloc_dev-error-path.patch
-dm-snapshot-fix-invalidation-enomem.patch
-dm-snapshot-allow-zero-chunk_size.patch
-dm-snapshot-fix-metadata-error-handling.patch
-dm-snapshot-make-read-and-write-exception-functions-void.patch
-dm-snapshot-fix-metadata-writing-when-suspending.patch
-dm-snapshot-tidy-snapshot_map.patch
-dm-snapshot-tidy-pending_complete.patch
-dm-snapshot-add-workqueue.patch
-dm-snapshot-tidy-pe-ref-counting.patch
-dm-snapshot-fix-freeing-pending-exception.patch
-dm-mirror-remove-trailing-space-from-table.patch
-dm-mpath-tidy-ctr.patch
-dm-mpath-use-kzalloc.patch
-dm-add-uevent-change-event-on-resume.patch
-dm-add-debug-macro.patch
-dm-table-add-target-preresume.patch
-dm-crypt-add-key-msg.patch
-dm-crypt-restructure-for-workqueue-change.patch
-dm-crypt-restructure-write-processing.patch
-dm-crypt-move-io-to-workqueue.patch
-dm-crypt-use-private-biosets.patch
-dm-use-private-biosets.patch
-dm-extract-device-limit-setting.patch
-dm-table-add-target-flush.patch
-md-the-scheduled-removal-of-the-start_array-ioctl-for-md.patch
-md-fix-a-comment-that-is-wrong-in-raid5h.patch
-md-factor-out-part-of-raid10d-into-a-separate-function.patch
-md-replace-magic-numbers-in-sb_dirty-with-well-defined-bit-flags.patch
-md-remove-the-working_disks-and-failed_disks-from-raid5-state-data.patch
-md-remove-working_disks-from-raid10-state.patch
-md-new-sysfs-interface-for-setting-bits-in-the-write-intent-bitmap.patch
-md-remove-unnecessary-variable-x-in-stripe_to_pdidx.patch
-md-factor-out-part-of-raid1d-into-a-separate-function.patch
-md-remove-working_disks-from-raid1-state-data.patch
-md-improve-locking-around-error-handling.patch
-md-define-backing_dev_infocongested_fn-for-raid0-and-linear.patch
-md-define-congested_fn-for-raid1-raid10-and-multipath.patch
-md-add-a-congested_fn-function-for-raid5-6.patch
-md-make-messages-about-resync-recovery-etc-more-specific.patch
-md-fix-duplicity-of-levels-in-mdtxt.patch
-md-remove-max_md_devs-which-is-an-arbitrary-limit.patch
-md-remove-experimental-classification-from-raid5-reshape.patch
-md-use-ffz-instead-of-find_first_set-to-convert-multiplier-to-shift.patch
-md-allow-set_bitmap_file-to-work-on-64bit-kernel-with-32bit-userspace.patch
-md-add-error-reporting-to-superblock-write-failure.patch
-genirq-convert-the-x86_64-architecture-to-irq-chips.patch
-genirq-convert-the-i386-architecture-to-irq-chips.patch
-genirq-irq-convert-the-move_irq-flag-from-a-32bit-word-to-a-single-bit.patch
-genirq-irq-add-moved_masked_irq.patch
-genirq-x86_64-irq-reenable-migrating-irqs-to-other-cpus.patch
-genirq-msi-simplify-msi-enable-and-disable.patch
-genirq-msi-make-the-msi-boolean-tests-return-either-0-or-1.patch
-genirq-msi-implement-helper-functions-read_msi_msg-and-write_msi_msg.patch
-genirq-msi-refactor-the-msi_ops.patch
-genirq-msi-simplify-the-msi-irq-limit-policy.patch
-genirq-irq-add-a-dynamic-irq-creation-api.patch
-genirq-ia64-irq-dynamic-irq-support.patch
-genirq-i386-irq-dynamic-irq-support.patch
-genirq-x86_64-irq-dynamic-irq-support.patch
-genirq-msi-make-the-msi-code-irq-based-and-not-vector-based.patch
-genirq-x86_64-irq-move-msi-message-composition-into-io_apicc.patch
-genirq-i386-irq-move-msi-message-composition-into-io_apicc.patch
-genirq-msi-only-build-msi-apicc-on-ia64.patch
-genirq-msi-only-build-msi-apicc-on-ia64-fix.patch
-genirq-x86_64-irq-remove-the-msi-assumption-that-irq-==-vector.patch
-genirq-i386-irq-remove-the-msi-assumption-that-irq-==-vector.patch
-genirq-irq-remove-msi-hacks.patch
-genirq-irq-generalize-the-check-for-hardirq_bits.patch
-genirq-x86_64-irq-make-the-external-irq-handlers-report-their-vector-not-the-irq-number.patch
-genirq-x86_64-irq-make-vector_irq-per-cpu.patch
-genirq-x86_64-irq-make-vector_irq-per-cpu-fix.patch
-genirq-x86_64-irq-make-vector_irq-per-cpu-warning-fix.patch
-genirq-x86_64-irq-kill-gsi_irq_sharing.patch
-genirq-x86_64-irq-kill-irq-compression.patch
-add-hypertransport-capability-defines.patch
-add-hypertransport-capability-defines-fix.patch
-initial-generic-hypertransport-interrupt-support.patch
-initial-generic-hypertransport-interrupt-support-Kconfig-fix.patch
-msi-simplify-msi-sanity-checks-by-adding-with-generic-irq-code.patch
-msi-only-use-a-single-irq_chip-for-msi-interrupts.patch
-msi-refactor-and-move-the-msi-irq_chip-into-the-arch-code.patch
-msi-move-the-ia64-code-into-arch-ia64.patch
-htirq-tidy-up-the-htirq-code.patch
-genirq-clean-up-irq-flow-type-naming.patch
-srcu-3-rcu-variant-permitting-read-side-blocking.patch
-srcu-3-rcu-variant-permitting-read-side-blocking-fix.patch
-srcu-3-rcu-variant-permitting-read-side-blocking-srcu-add-lock-annotations.patch
-srcu-3-rcu-variant-permitting-read-side-blocking-comments.patch
-srcu-3-add-srcu-operations-to-rcutorture.patch
-srcu-3-add-srcu-operations-to-rcutorture-fix.patch
-add-srcu-based-notifier-chains.patch
-add-srcu-based-notifier-chains-cleanup.patch
-srcu-report-out-of-memory-errors.patch
-srcu-report-out-of-memory-errors-fixlet.patch
-cpufreq-make-the-transition_notifier-chain-use-srcu.patch
-rcu-add-module_author-to-rcutorture-module.patch
-rcu-fix-incorrect-description-of-default-for-rcutorture.patch
-rcu-mention-rcu_bh-in-description-of-rcutortures.patch
-rcu-avoid-kthread_stop-on-invalid-pointer-if-rcutorture.patch
-rcu-fix-sign-bug-making-rcu_random-always-return-the-same.patch
-rcu-add-fake-writers-to-rcutorture.patch
-rcu-add-fake-writers-to-rcutorture-tidy.patch
-rcu-refactor-srcu_torture_deferred_free-to-work-for.patch
-rcu-add-rcu_sync-torture-type-to-rcutorture.patch
-rcu-add-rcu_bh_sync-torture-type-to-rcutorture.patch
-rcu-add-sched-torture-type-to-rcutorture.patch
-rcu-simplify-improve-batch-tuning.patch
-rcu-credits-and-maintainers.patch
-the-scheduled-removal-of-some-oss-drivers.patch
-the-scheduled-removal-of-some-oss-drivers-fix.patch
-the-scheduled-removal-of-some-oss-drivers-fix-fix.patch
-kill-sound-oss-_symsc.patch
-kill-include-linux-configh.patch
-pci_module_init-convertion-in-ata_genericc.patch
-pci_module_init-convertion-in-ata_genericc-fix.patch
-pci_module_init-convertion-in-amso1100-driver.patch
-pci_module_init-convertion-for-k8_edacc.patch
-pci_module_init-convertion-in-the-legacy-megaraid-driver.patch
-pci_module_init-convertion-in-olympicc.patch
-pci_module_init-conversion-for-pata_pdc2027x.patch
-pci_module_init-convertion-in-tmscsimc.patch
-pr_debug-aio-use-size_t-length-modifier-in-pr_debug-format-arguments.patch
-pr_debug-configfs-use-size_t-length-modifier-in-pr_debug-format-argument.patch
-pr_debug-sysfs-use-size_t-length-modifier-in-pr_debug-format-arguments.patch
-pr_debug-umem-repair-nonexistant-bh-pr_debug-reference.patch
-pr_debug-tipar-repair-nonexistant-pr_debug-argument-use.patch
-pr_debug-dell_rbu-fix-pr_debug-argument-warnings.patch
-pr_debug-ifb-replace-missing-comma-to-separate-pr_debug-arguments.patch
-pr_debug-trident-use-size_t-length-modifier-in-pr_debug-format-arguments.patch
-pr_debug-check-pr_debug-arguments-arm-fix.patch
-isdn-debug-build-fix.patch
-isdn-more-pr_debug-fixes.patch
-pr_debug-check-pr_debug-arguments.patch
-squash-tcp-warnings.patch
Merged into mainline or a subsystem tree.
+null-dereference-in-fs-jbd-journalc.patch
+irq-fix-avr32-breakage.patch
+mm-use-symbolic-names-instead-of-indices-for-zone-initialisation.patch
+mm-remove-memmap_zone_idx.patch
+fix-menuconfig-build-failure-due-to-missing-stdboolh.patch
+user-struct-irq_chip-instead-of-struct-hw_interrupt_type.patch
+disable-detect_softlockup-for-s390.patch
2.6.19 queue.
+revert-pci-quirk-for-ibm-dock-ii-cardbus-controllers.patch
+revert-nvidiafb-use-generic-ddc-reading.patch
Will be 2.6.19 queue soon if we don't look like fixing a few things.
+ext4-copy.patch
+ext4-rename.patch
+ext4-enable.patch
+jbd2-copy.patch
+jbd2-rename.patch
+jbd2-rename-slab.patch
+jbd2-enable.patch
+jbd2-cleanup.patch
+ext4-extents.patch
+ext4_fsblk_sector_t.patch
+ext4-extents-48bit.patch
+ext4-unitialized-extent-handling.patch
+extents_comment_fix.patch
+64bit_jbd2_core.patch
+sector_t-jbd2.patch
+ext4_48bit_i_file_acl.patch
+64bit-metadata.patch
+ext4_blk_type_from_sector_t_to_ulonglong.patch
+ext4_blk_type_from_sector_t_to_ulonglong-fix.patch
+ext4_remove_sector_t_bits_check.patch
+jbd2_blks_type_from_sector_t_to_ull.patch
+ext4_allow_larger_descriptor_size.patch
+ext4_move_block_number_hi_bits.patch
+ext4-uninline-ext4_get_group_no_and_offset.patch
+ext4-64-bit-divide-fix.patch
+ext4-64-bit-divide-fix-fix.patch
+ext4-rename-logic_sb_block.patch
+ext4-errors-behaviour-fix.patch
+ext4-whitespace-cleanups.patch
ext4
+i386-acpi-build-fix.patch
ACPI fix
+cifs-kconfig-dont-select-connector.patch
CIFS Kconfig sanity
+gregkh-driver-documentation-feature-removal-schedule-typo.patch
+gregkh-driver-driver-core-don-t-ignore-error-returns-from-probing.patch
+gregkh-driver-driver-core-bus-remove-indentation-level.patch
+gregkh-driver-aoe-eliminate-isbusy-message.patch
+gregkh-driver-aoe-update-copyright-date.patch
+gregkh-driver-aoe-remove-unused-nargs-enum.patch
+gregkh-driver-aoe-zero-copy-write-1-of-2.patch
+gregkh-driver-aoe-jumbo-frame-support-1-of-2.patch
+gregkh-driver-aoe-clean-up-printks-via-macros.patch
+gregkh-driver-aoe-jumbo-frame-support-2-of-2.patch
+gregkh-driver-aoe-improve-retransmission-heuristics.patch
+gregkh-driver-aoe-zero-copy-write-2-of-2.patch
+gregkh-driver-aoe-module-parameter-for-device-timeout.patch
+gregkh-driver-aoe-use-bio-bi_idx.patch
+gregkh-driver-aoe-remove-sysfs-comment.patch
+gregkh-driver-aoe-update-driver-version.patch
+gregkh-driver-aoe-revert-printk-macros.patch
+gregkh-driver-aoe-fix-sysfs-warnings.patch
+gregkh-driver-driver-link-sysfs-timing.patch
Driver tree updates.
+w1-kconfig-fix.patch
+fs-partitions-check-add-sysfs-error-handling.patch
+char-nozomi-use-tty_wakeup.patch
Misc fixes agaisnt driver tree.
+drm-fix-error-returns-sysfs-error-handling.patch
DRM sysfs fix.
+git-dvb-build-fix.patch
Fix rejects in git-dvb.patch
+gregkh-i2c-w1-ioremap-balanced-with-iounmap.patch
I2C tree update.
+kill-include-linux-configh-ia64.patch
ia64 cleanup.
-revert-input-make-input_openclose_device-more-robust.patch
Dropped.
+pci_module_init-convertion-in-amso1100-driver.patch
+drivers-infiniband-hw-amso1100-c2_rnicc-fix-a-null-dereference.patch
infiniband things.
+git-input-fixup.patch
Fix rejects in git-input.patch (which isn't here. But it compiles. hrm)
+ata-must-depend-on-block.patch
+pci_module_init-convertion-in-ata_genericc.patch
+pci_module_init-convertion-in-ata_genericc-fix.patch
+pci_module_init-conversion-for-pata_pdc2027x.patch
sata/pata things.
+mtd-maps-add-parameter-to-amd76xrom-to-override-rom-window-size-if-set-incorrectly-by-bios.patch
+mtd-maps-add-parameter-to-amd76xrom-to-override-rom-window-size-if-set-incorrectly-by-bios-tweak.patch
+mtd-chips-support-for-sst-49lf040b-flash-chip.patch
+mtd-maps-support-for-bios-flash-chips-on-intel-esb2-southbridge.patch
+mtd-maps-support-for-bios-flash-chips-on-intel-esb2-southbridge-tidy.patch
+mtd-maps-support-for-bios-flash-chips-on-intel-esb2-southbridge-fix.patch
MTD updates.
+libphy-dont-do-that.patch
netdev build fix (allegedly deadlocks).
-powerpc-cell-spidernet-burst-alignment-patch.patch
-powerpc-cell-spidernet-low-watermark-patch.patch
-powerpc-cell-spidernet-stop-error-printing-patch.patch
-powerpc-cell-spidernet-ethtool-i-version-number-info.patch
-powerpc-cell-spidernet-ethtool-i-version-number.patch
-powerpc-cell-spidernet-refine-locking.patch
Dropped.
+pci_module_init-convertion-in-olympicc.patch
+ibmveth-irq-fix.patch
netdev fixes.
+drivers-atm-no-need-to-return-void.patch
Driver cleanup.
-git-parisc-powerpc-fix.patch
Dropped.
+git-serial-fixup.patch
Actually a pcmcia fix.
+ioremap-balanced-with-iounmap-for-drivers-pcmcia.patch
+export-soc_common_drv_pcmcia_remove-to-allow-modular-pcmcia.patch
pcmcia fixes.
-git-serial-fixup.patch
Dropped.
-serial-fix-uart_bug_txen-test.patch
Unneeded, dropped.
+gregkh-pci-acpipnp-dma-resource-setup-fix.patch
+gregkh-pci-pci-fix-pcie_portdrv_restore_config-undefined-without-config_pm-error.patch
+gregkh-pci-pci-stamp-out-pci_find_-usage-in-fakephp.patch
+gregkh-pci-shpchp-fix-command-completion-check.patch
+gregkh-pci-shpchp-remove-unnecessary-cmd_busy-member-from-struct.patch
+gregkh-pci-pci-hotplug-ioremap-balanced-with-iounmap.patch
+gregkh-pci-pci-improve-pci_msi_supported-comments.patch
+gregkh-pci-pci-update-msi-howto.txt-according-to-pci_msi_supported.patch
+gregkh-pci-change-pci-hotplug-subsystem-maintainer-to-kristen.patch
+gregkh-pci-pci-optionally-sort-device-lists-breadth-first.patch
+gregkh-pci-pci-quirks-fix-the-festering-mess-that-claims-to-handle-ide-quirks.patch
-gregkh-pci-altix-rom-shadowing.patch
+gregkh-pci-altix-initial-acpi-support-rom-shadowing.patch
PCI tree updates.
-revert-gregkh-pci-altix-rom-shadowing.patch
-revert-gregkh-pci-altix-sn-acpi-hotplug-support.patch
-revert-gregkh-pci-altix-add-initial-acpi-io-support.patch
Dropped.
-revert-pci-assign-ioapic-resource-at-hotplug.patch
Dropped.
+quirks-switch-quirks-code-offender-to-use-pci_get-api.patch
PCI fix.
+scsi-scsi_cmnd-convertion-in-sun3-driver.patch
+scsi-scsi_cmnd-conversion-in-qlogicfas408-driver.patch
+scsi-scsi_cmnd-convertion-in-psi240i-driver.patch
+pci_module_init-convertion-in-the-legacy-megaraid-driver.patch
+pci_module_init-convertion-in-tmscsimc.patch
+aic94xx-sata-tag-mask-not-set-correctly.patch
+maintain-module-parameter-name-consistency-with-qla2xxx-qla4xxx.patch
+scsi_libc-use-build_bug_on.patch
+drivers-scsi-dpt_i2oc-remove-dead-code.patch
SCSI fixes.
+gregkh-usb-usb-fix-use-after-free-in-wacom_sys.c.patch
+gregkh-usb-airprime-new-device-id.patch
+gregkh-usb-usb-support-for-bt-on-air-usb-modem-in-cdc-acm.c.patch
+gregkh-usb-usb-suspend-resume-support-for-kaweth.patch
+gregkh-usb-usb-ohci-pnx4008-build-fixes.patch
+gregkh-usb-ueagle-be-suspend-friendly.patch
+gregkh-usb-ueagle-use-interruptible-sleep.patch
+gregkh-usb-ueagle-comestic-changes.patch
+gregkh-usb-usb-fix-cdc-acm-problems-with-hard-irq.patch
+gregkh-usb-usb-unusual_devs-entry-for-nokia-6131.patch
+gregkh-usb-usbatm-fix-tiny-race.patch
+gregkh-usb-speedtch-extended-reach.patch
+gregkh-usb-cxacru-add-the-zte-zxdsl-852.patch
+gregkh-usb-usb-fix-suspend-support-for-usblp.patch
+gregkh-usb-usb-ftdi-elan-fix-sparse-warnings.patch
+gregkh-usb-usb-ehci-hcd-make-ehci_iso_stream-instances-more-persistent.patch
+gregkh-usb-usb-ehci-hcd-periodic-startup-shutdown-centralization-and-hysteresis.patch
+gregkh-usb-usb-ehci-hcd-group-interrupt-endpoint-code-into-one-place.patch
+gregkh-usb-usb-ehci-hcd-group-ehci_iso_sched-functions-into-one-place.patch
+gregkh-usb-usb-ehci-hcd-group-ehci_iso_sched-and-ehci_itd-code.patch
+gregkh-usb-usb-ehci-hcd-group-ehci_sitd-code-in-one-place.patch
+gregkh-usb-usb-ehci-hcd-refactor-sitd-link-patch-code-for-easier-frame-spanning.patch
+gregkh-usb-usb-ehci-hcd-split-scan_periodic-to-reuse-code-for-spanned-completions.patch
+gregkh-usb-usb-ehci-hcd-unify-interval-granularity-and-limit-depth-of-interrupt-tree.patch
+gregkh-usb-usb-ehci-hcd-add-shadow-budget-code.patch
+gregkh-usb-usb-ehci-hcd-activate-shadow-budget-tracking.patch
+gregkh-usb-usb-ehci-hcd-activate-use-of-shadow-budget-for-scheduling-decisions.patch
+gregkh-usb-usb-ehci-hcd-add-fstn-support.patch
+gregkh-usb-usb-ehci-hcd-add-sitd-frame-spanning-support.patch
+gregkh-usb-ehci-hcd-fix-budget_pool-allocation-for-machines-with-multiple-ehci-controllers.patch
+gregkh-usb-usb-usbaudio-correct-bug-caused-by-harmless-underrun-during-playback-setup.patch
USB tree updates.
+fix-gregkh-usb-usbatm-fix-tiny-race.patch
+memory-leak-in-drivers-usb-serial-airprimec.patch
+extract-and-implement-are-bit-field-manipulation-routines.patch
+drivers-usb-net-use-build_bug_on.patch
+drivers-usb-misc-ftdi-elanc-remove-dead-code.patch
+drivers-usb-serial-mos7840c-fix-a-check-after-dereference.patch
USB updates.
-git-watchdog-fixup.patch
Dropped.
+airo-suspend-fix.patch
+prism54-use-build_bug_on.patch
Wireless driver fixes.
+x86_64-overlapping-program-headers-in-physical-addr-space-fix.patch
+sleazy-fpu-feature-i386-support.patch
+add-seccomp_disable_tsc-config-option.patch
+i386-fix-recursive-faults-during-oops-when-current.patch
+x86-remove-default_ldt-and-simplify-ldt-setting.patch
+fix-buggy-mtrr-address-checks.patch
+i386-espfix-cleanup.patch
+x86_64-hot-add-memroy-sratc-fix.patch
+x86_64-add-missing-enter_idle-calls.patch
+x86_64-rename-x86_feature_dtes-to-x86_feature_ds.patch
+add-x86_feature_pebs-and-detection.patch
+i386-rename-x86_feature_dtes-to-x86_feature_ds.patch
+i386-add-x86_feature_pebs-and-detection.patch
+remove-pointless-printk-from-i386-oops-output.patch
+compress-stack-unwinder-output.patch
+x86_64-use-build_bug_on-in-fpu-code.patch
+fix-for-arch-x86_64-pci-makefile-cflags.patch
+i386-math-emu-fix-must_checks.patch
x86 and x86_64 updates.
+touchkit-ps-2-touchscreen-driver-configh.patch
+touchkit-ps-2-touchscreen-driver-regs-fix.patch
Fix touchkit-ps-2-touchscreen-driver.patch
+direct-io-sync-and-invalidate-file-region-when-falling-back-to-buffered-write.patch
+direct-io-sync-and-invalidate-file-region-when-falling-back-to-buffered-write-fixes.patch
Make direct-io fallback-to-buffered work more like direct-io normally does.
+mm-kevent-threads-use-mpol_default.patch
+move-rmap-bug_on-outside-debug_vm.patch
+fix-do_mbind-warning-with-config_migration=n.patch
+memory-page-alloc-minor-cleanups.patch
MM updates
-get-rid-of-zone_table-fix.patch
-get-rid-of-zone_table-fix-2.patch
-get-rid-of-zone_table-fix-4.patch
Folded into get-rid-of-zone_table.patch
-deal-with-cases-of-zone_dma-meaning-the-first-zone-fix.patch
Folded into deal-with-cases-of-zone_dma-meaning-the-first-zone.patch
-optional-zone_dma-in-the-vm-tidy.patch
Folded into optional-zone_dma-in-the-vm.patch
+zoneid-fix-up-calculations-for-zoneid_pgshift.patch
Fix zone rework patches in -mm.
-swap-token-try-to-grab-swap-token-before-the-vm-selects-pages-for-eviction.patch
-swap-token-new-scheme-to-preempt-token.patch
-swap-token-new-scheme-to-preempt-token-tidy.patch
+grab-swap-token-reordered.patch
+new-scheme-to-preempt-swap-token.patch
+new-scheme-to-preempt-swap-token-tidy.patch
+shared-page-table-for-hugetlb-page-v4.patch
+htlb-forget-rss-with-pt-sharing.patch
+mm-arch_free_page-fix.patch
+mm-locks_freed-fix.patch
+mm-add-arch_alloc_page.patch
More MM updates.
-fix-tiacx-on-alpha.patch
-tiacx-fix-attribute-packed-warnings.patch
-tiacx-fix-attribute-packed-warnings-fix.patch
-tiacx-pci-build-fix.patch
-tiacx-ia64-fix.patch
-tiacx-build-fix.patch
-tiacx-sparse-cleanups.patch
Folded into acx1xx-wireless-driver.patch
-swsusp-add-resume_offset-command-line-parameter-rev-2-fix.patch
Folded into swsusp-add-resume_offset-command-line-parameter-rev-2.patch
-swsusp-add-ioctl-for-swap-files-support-fix.patch
Folded into swsusp-add-ioctl-for-swap-files-support.patch
+uml-revert-wrong-patch.patch
+uml-correct-removal-of-pte_mkexec.patch
+uml-readd-forgot-prototype.patch
+uml-make-tt-mode-compile-after-setjmp-related-changes.patch
+uml-make-uml_setjmp-always-safe.patch
+uml-fix-processor-selection-to-exclude-unsupported-processors-and-features.patch
+uml-fix-uname-under-setarch-i386.patch
+uml-declare-in-kconfig-our-partial-lockdep-support.patch
+uml-allow-using-again-x86-x86_64-crypto-code.patch
+uml-asm-offsets-duplication-removal.patch
+uml-remove-duplicate-export.patch
+uml-deprecate-config_mode_tt.patch
+uml-allow-finer-tuning-for-host-vmsplit-setting.patch
UML updates
-edac-new-opteron-athlon64-memory-controller-driver-tidy.patch
Folded into edac-new-opteron-athlon64-memory-controller-driver.patch
-add-address_space_operationsbatch_write-fix.patch
Folded into add-address_space_operationsbatch_write.patch
+pci_module_init-convertion-for-k8_edacc.patch
+kbuild-dont-put-temp-files-in-the-source-tree.patch
+grow_buffers-infinite-loop-fix.patch
+ide-generic-jmicron-fix.patch
+fix-rescan_partitions-to-return-errors-properly.patch
+fix-check_partition-routines.patch
+fix-module-taint-flags-listing-in-oops-panic.patch
+ext3-errors-behaviour-fix.patch
+ext2-errors-behaviour-fix.patch
+tpm-fix-error-handling.patch
+sched-likely-profiling.patch
+serial-uartlite-driver.patch
+serial-uartlite-driver-fix.patch
+invalidate_inode_pages2_range-debug.patch
+x86-microcode-handle-sysfs-error.patch
+apm-share-apm-emulator-between-architectures.patch
+32-bit-compatibility-hdio-ioctls.patch
+pktcdvd-reusability-of-procfs-functions.patch
+pktcdvd-make-procfs-interface-optional.patch
+bitmap-parse-input-from-kernel-and-user-buffers-2.patch
+# drivers-add-lcd-support.patch: Pavel says use fbcon
+drivers-add-lcd-support.patch
+drivers-add-lcd-support-update.patch
+ioremap-balanced-with-iounmap-for-drivers-char-rio-rio_linuxc.patch
+ioremap-balanced-with-iounmap-for-drivers-char-moxac.patch
+ioremap-balanced-with-iounmap-for-drivers-char-istallionc.patch
+sound-oss-btaudioc-ioremap-balanced-with-iounmap.patch
+document-the-core-dump-to-a-pipe-patch.patch
+lockdep-annotate-nfs-nfsd-in-kernel-sockets.patch
+lockdep-annotate-nfs-nfsd-in-kernel-sockets-tidy.patch
+honour-mnt_noexec-for-access.patch
+vm-fix-the-gfp_mask-in-invalidate_complete_page2.patch
+posix-cpu-timers-prevent-signal-delivery-starvation.patch
+remove-unnecessary-check-in-fs-fat-inodec.patch
+d-cache-aliasing-issue-in-__block_prepare_write.patch
+use-linux-ioh-instead-of-asm-ioh.patch
+consolidate-check_signature.patch
+fix-typos-in-mm-shmem_aclc.patch
+ht_irq-must-depend-on-pci.patch
+fs-use-build_bug_on.patch
+dac960-use-memmove-for-overlapping-areas.patch
+lockdep-use-build_bug_on.patch
+fix-lockdep-designtxt.patch
+lockdep-fix-printk-recursion-logic.patch
+kernel-doc-fix-function-name-in-usercopyc.patch
+uaccessh-match-kernel-doc-and-function-names.patch
+kernel-doc-drop-various-inline-qualifiers.patch
+include-linux-typesh-in-linux-nbdh.patch
+kernel-doc-make-parameter-description-indentation-uniform.patch
+dell_rbu-printk-warning-fix.patch
misc.
-generic-bug-handling.patch
-use-generic-bug-for-i386.patch
-use-generic-bug-for-x86-64.patch
-use-generic-bug-for-powerpc.patch
-use-generic-bug-for-powerpc-fix-2.patch
-bug-test-1.patch
+generic-implementatation-of-bug.patch
+generic-implementatation-of-bug-fix.patch
+generic-bug-for-i386.patch
+generic-bug-for-x86-64.patch
+uml-add-generic-bug-support.patch
+use-generic-bug-for-ppc.patch
+bug-test-1.patch
Updated generic-bug implementation.
+log2-implement-a-general-integer-log2-facility-in-the-kernel.patch
+log2-implement-a-general-integer-log2-facility-in-the-kernel-fix.patch
+log2-alter-roundup_pow_of_two-so-that-it-can-use-a-ilog2-on-a-constant.patch
+log2-alter-get_order-so-that-it-can-make-use-of-ilog2-on-a-constant.patch
+log2-provide-ilog2-fallbacks-for-powerpc.patch
generic log2() implementation.
+fs-cache-provide-a-filesystem-specific-syncable-page-bit-ext4.patch
Fix ext4 for fs-cache-provide-a-filesystem-specific-syncable-page-bit.patch
+nfs-use-local-caching-configh.patch
Clean up nfs-use-local-caching.patch
+fs-cache-cachefiles-a-cache-that-backs-onto-a-mounted-filesystem-log2-fix.patch
log2() fix.
+char-mxser_new-revert-spin_lock-changes.patch
+char-mxser_new-remove-request-for-testers-line.patch
+char-mxser_new-debug-printk-dependent-on-debug.patch
+char-mxser_new-alter-license-terms.patch
+char-mxser_new-code-upside-down.patch
+char-mxser_new-cmspar-is-defined.patch
+char-remove-unneded-termbits-redefinitions-mxser_new.patch
+char-mxser_new-eliminate-tty-ldisc-deref.patch
+char-mxser_new-testbit-for-bit-testing.patch
+char-mxser_new-correct-fail-paths.patch
+char-mxser_new-dont-check-tty_unregister-retval.patch
+char-mxser_new-compress-isa-finding.patch
+char-mxser_new-register-tty-devices-on-the-fly.patch
+char-mxser_new-compact-structures-round2.patch
+char-mxser_new-reverse-if-else-paths-patch.patch
+char-mxser_new-comments-cleanup.patch
More updates to the updated mxser driver.
-readahead-sysctl-parameters-fix.patch
Folded into readahead-sysctl-parameters.patch
-readahead-state-based-method-aging-accounting-apply-type-enum-zone_type-readahead.patch
Folded into readahead-state-based-method-aging-accounting.patch
-readahead-call-scheme-fix.patch
Folded into readahead-call-scheme.patch
+reiser4-configh.patch
reiser4 cleanup
+reiser4-format-subversion-numbers-heir-set-and-file-conversion.patch
+reiser4-cleanups-in-lzo-compression-library.patch
reiser4 updates.
+ioremap-balanced-with-iounmap-for-drivers-video-virgefb.patch
+ioremap-balanced-with-iounmap-for-drivers-video-vesafb.patch
+ioremap-balanced-with-iounmap-for-drivers-video-tridentfb.patch
+ioremap-balanced-with-iounmap-for-drivers-video-tgafb.patch
+ioremap-balanced-with-iounmap-for-drivers-video-stifb.patch
+ioremap-balanced-with-iounmap-for-drivers-video-retz3fb.patch
+ioremap-balanced-with-iounmap-for-drivers-video-pvr2fb.patch
+ioremap-balanced-with-iounmap-for-drivers-video-platinumfb.patch
+ioremap-balanced-with-iounmap-for-drivers-video-offb.patch
+ioremap-balanced-with-iounmap-for-drivers-video-macfb.patch
+ioremap-balanced-with-iounmap-for-drivers-video-hpfb.patch
+ioremap-balanced-with-iounmap-for-drivers-video-fm2fb.patch
+ioremap-balanced-with-iounmap-for-drivers-video-ffb.patch
+ioremap-balanced-with-iounmap-for-drivers-video-cyberfb.patch
+ioremap-balanced-with-iounmap-for-drivers-video-cirrusfb.patch
+ioremap-balanced-with-iounmap-for-drivers-video-atyfb_base.patch
+ioremap-balanced-with-iounmap-for-drivers-video-atafb.patch
+ioremap-balanced-with-iounmap-for-drivers-video-amifb.patch
+ioremap-balanced-with-iounmap-for-drivers-video-S3triofb.patch
ioremap() fixes in fbdev drivers.
-statistics-infrastructure-prerequisite-timestamp-fix.patch
Folded into statistics-infrastructure-prerequisite-timestamp.patch
-statistics-infrastructure-update-9.patch
Folded into statistics-infrastructure.patch
-statistics-infrastructure-exploitation-zfcp-sched_clock-fix.patch
Folded into statistics-infrastructure-exploitation-zfcp.patch
+dio-centralize-completion-in-dio_complete.patch
+dio-call-blk_run_address_space-once-per-op.patch
+dio-formalize-bio-counters-as-a-dio-reference-count.patch
+dio-remove-duplicate-bio-wait-code.patch
+dio-only-call-aio_complete-after-returning-eiocbqueued.patch
drirect-io cleanups and fixes
+fdtable-delete-pointless-code-in-dup_fd.patch
+fdtable-make-fdarray-and-fdsets-equal-in-size.patch
+fdtable-remove-the-free_files-field.patch
+fdtable-implement-new-pagesize-based-fdtable-allocator.patch
Redo the fdtable code.
+gtod-exponential-update_wall_time.patch
+gtod-persistent-clock-support-core.patch
+gtod-persistent-clock-support-i386.patch
+time-uninline-jiffiesh.patch
+time-fix-msecs_to_jiffies-bug.patch
+time-fix-timeout-overflow.patch
+cleanup-uninline-irq_enter-and-move-it-into-a-function.patch
+dynticks-extend-next_timer_interrupt-to-use-a-reference-jiffie.patch
+hrtimers-namespace-and-enum-cleanup.patch
+hrtimers-clean-up-locking.patch
+hrtimers-state-tracking.patch
+hrtimers-clean-up-callback-tracking.patch
+hrtimers-move-and-add-documentation.patch
+clockevents-core.patch
+clockevents-drivers-for-i386.patch
+high-res-timers-core.patch
+gtod-mark-tsc-unusable-for-highres-timers.patch
+dynticks-core.patch
+dynticks-add-nohz-stats-to-proc-stat.patch
+dynticks-i386-arch-code.patch
+high-res-timers-dynticks-enable-i386-support.patch
+debugging-feature-timer-stats.patch
hrtimers and dynamic ticks.
+kevent-timer-notifications-fix.patch
+kevent-fix-socket-notifications.patch
+kevent-remove-mmap-interface.patch
kevent updates
All 766 patches:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc1/2.6.19-rc1-mm1/patch-list
On Tue, 2006-10-10 at 00:09 -0700, Andrew Morton wrote:
> +htlb-forget-rss-with-pt-sharing.patch
if it's ok to ignore RSS, can we consider the shared pagetables for
normal pages patch? It saves quite a bit of memory on even desktop
workloads as well as avoiding several (soft) pagefaults.
So.. what does RSS actually mean? Can we ignore it somewhat for
shared-readonly mappings ?
--
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
On 10/10/06, Andrew Morton <[email protected]> wrote:
>
> +# drivers-add-lcd-support.patch: Pavel says use fbcon
> +drivers-add-lcd-support.patch
> +drivers-add-lcd-support-update.patch
>
Has the # a special meaning?
I'm going to work on offering the fbcon feature as Pavel requested. We
suggested 2 ways.
Pavel's idea: Change the driver so the cfag12864b module will be just
a framebuffer device, removing access through /dev/cfag12864b.
My idea: Code a new module called "fbcfag12864b", which will depend on
cfag12864b and will be the framebuffer device. This way we have both
devices, and they doesn't affect each other as they are different
things. So the ks0108 and cfag12864b can stay without any changes.
Also, if we finally decide we don't want the raw cfag12864b module, it
is easy to remove it from the cfag12864b and the fbcafg12864b will
continue working.
Is there anyone who can decide which idea is better? If not, I will
code it my way. Also, if the Pavel's idea will be the chosen one, it
will be easier to put the fbcfag12864b code into the cfag12864b rather
than the opposite.
On Tue, 10 Oct 2006 09:20:00 +0200
Arjan van de Ven <[email protected]> wrote:
> On Tue, 2006-10-10 at 00:09 -0700, Andrew Morton wrote:
> > +htlb-forget-rss-with-pt-sharing.patch
Which I didn't write. cc's added.
> if it's ok to ignore RSS,
We'd prefer not to. But what's the alternative?
> can we consider the shared pagetables for
> normal pages patch?
Has been repeatedly considered, but Hugh keeps finding bugs in it.
> It saves quite a bit of memory on even desktop
> workloads as well as avoiding several (soft) pagefaults.
>
> So.. what does RSS actually mean? Can we ignore it somewhat for
> shared-readonly mappings ?
We'd prefer to go the other way, and implement RLIMIT_RSS wouldn't we?
On Tue, 2006-10-10 at 00:45 -0700, Andrew Morton wrote:
> > if it's ok to ignore RSS,
>
> We'd prefer not to. But what's the alternative?
it's a good question; today (2.6.18) we have some defacto behavior of
RSS; 2.6.19-rc1-mm1 has a somewhat different one. Either can be entirely
valid; and we can obviously implement either. We can go even further and
remove more from RSS to help save memory and pagefaults (both help
desktop performance) by going the shared pagetable road
>
> > can we consider the shared pagetables for
> > normal pages patch?
>
> Has been repeatedly considered, but Hugh keeps finding bugs in it.
the latest one I tried looked relatively simple (earlier ones were very
complex) so maybe Hugh can find time to give it another lookover?
>
> > It saves quite a bit of memory on even desktop
> > workloads as well as avoiding several (soft) pagefaults.
> >
> > So.. what does RSS actually mean? Can we ignore it somewhat for
> > shared-readonly mappings ?
>
> We'd prefer to go the other way, and implement RLIMIT_RSS wouldn't we?
Well... that again depends on how we define RSS. implementing the rlimit
doesn't mean we can't NOT count certain things (like the hugetlb pages
in the patch above, or shared read only pagecache pages) to be part of
it. It's a fundamental "what does it mean" thing.
You can argue that RSS means "all memory that the application has in
it's address space", you can argue "all such memory except a few cases",
you can argue "all memory that is private/exclusive to the
application"...
This is not a pointless piss-in-the-wind discussion; unless we define
rather specific what it really means, the RLIMIT doesn't mean anything
either.
We need to consider at least if any of the following are part of rss:
* VM_IO io mmaped device stuff
* Non-linear mappings
* Shared hugetlb memory that shares pagetables
* Shared hugetlb memory
* Hugetlb memory in general
* Shared normal memory that shares pagetables
* Shared normal memory (file backed; eg pagecache)
* Shared normal memory (anonymous/non-file-backed)
* Sysv/ipc shared memory
* Not shared normal memory
I don't think posix or anything else helps us here so we can vote or
otherwise reason which make sense and which don't. I hope the outcome is
reasonably consistent ;)
I know the desktop guys at least consider RSS useless as measure of "how
much memory does my desktop app take"; especially since they have many
shared libraries and they consider it unfair that each app pays the full
price in terms of RSS for those. So personally I'm not unhappy with a
definition that comes down to "all memory that's private to the app";
although it is a change from what 2.6.18 does.
--
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
On Tue, 10 Oct 2006 07:31:23 +0000
"Miguel Ojeda" <[email protected]> wrote:
> On 10/10/06, Andrew Morton <[email protected]> wrote:
> >
> > +# drivers-add-lcd-support.patch: Pavel says use fbcon
> > +drivers-add-lcd-support.patch
> > +drivers-add-lcd-support-update.patch
> >
>
> Has the # a special meaning?
It's a comment separator ;)
> I'm going to work on offering the fbcon feature as Pavel requested.
Thanks. It does sound like making the thing an fbdev is the right way to go.
> suggested 2 ways.
>
> Pavel's idea: Change the driver so the cfag12864b module will be just
> a framebuffer device, removing access through /dev/cfag12864b.
>
> My idea: Code a new module called "fbcfag12864b", which will depend on
> cfag12864b and will be the framebuffer device. This way we have both
> devices, and they doesn't affect each other as they are different
> things. So the ks0108 and cfag12864b can stay without any changes.
> Also, if we finally decide we don't want the raw cfag12864b module, it
> is easy to remove it from the cfag12864b and the fbcafg12864b will
> continue working.
>
> Is there anyone who can decide which idea is better? If not, I will
> code it my way. Also, if the Pavel's idea will be the chosen one, it
> will be easier to put the fbcfag12864b code into the cfag12864b rather
> than the opposite.
I'd have thought that once the device is accessible as an fbdev, there's so
much other software and kernel infrastructure to support that, there's
little point in offering an alternative way of presenting the device to
userspace.
On 10/10/06, Andrew Morton <[email protected]> wrote:
> On Tue, 10 Oct 2006 07:31:23 +0000
> "Miguel Ojeda" <[email protected]> wrote:
>
> > On 10/10/06, Andrew Morton <[email protected]> wrote:
> > >
> > > +# drivers-add-lcd-support.patch: Pavel says use fbcon
> > > +drivers-add-lcd-support.patch
> > > +drivers-add-lcd-support-update.patch
> > >
> >
> > Has the # a special meaning?
>
> It's a comment separator ;)
>
Ouch. Right.
>
> > I'm going to work on offering the fbcon feature as Pavel requested.
>
> Thanks. It does sound like making the thing an fbdev is the right way to go.
>
Yep, such way will let us to run a xgl server through some ascii video
lib and display it on the 128x64 LCD fb device ;)
> > suggested 2 ways.
> >
> > Pavel's idea: Change the driver so the cfag12864b module will be just
> > a framebuffer device, removing access through /dev/cfag12864b.
> >
> > My idea: Code a new module called "fbcfag12864b", which will depend on
> > cfag12864b and will be the framebuffer device. This way we have both
> > devices, and they doesn't affect each other as they are different
> > things. So the ks0108 and cfag12864b can stay without any changes.
> > Also, if we finally decide we don't want the raw cfag12864b module, it
> > is easy to remove it from the cfag12864b and the fbcafg12864b will
> > continue working.
> >
> > Is there anyone who can decide which idea is better? If not, I will
> > code it my way. Also, if the Pavel's idea will be the chosen one, it
> > will be easier to put the fbcfag12864b code into the cfag12864b rather
> > than the opposite.
>
> I'd have thought that once the device is accessible as an fbdev, there's so
> much other software and kernel infrastructure to support that, there's
> little point in offering an alternative way of presenting the device to
> userspace.
>
Allright, I will code it as the fbcfag12864b module, and when it will
be working fine, I will remove the raw device of the cfag12864b and if
the code of fbcfag12864b results really small/trivial, I will put it
in the cfag12864b module. Then I will send you the "update patch 2".
Give me a couple of days or so :)
Thanks you,
Miguel Ojeda
On Tue, Oct 10, 2006 at 12:09:28AM -0700, Andrew Morton wrote:
>
> - Added the ext4 filesystem. Quick usage instructions:
>
> - Grab updated e2fsprogs from
> ftp://ftp.kernel.org/pub/linux/kernel/people/tytso/e2fsprogs-interim/
>
> - It's still mke2fs -j /dev/hda1
>
> - mount /dev/hda1 /wherever -t ext4dev
>
> - To enable extents,
>
> mount /dev/hda1 /wherever -t ext4dev -o extents
Looks like you didn't take the updated patch from Shaggy which
requires that you use tune2fs -O extents first? (This requires the
e2fsprogs-interim patches.)
The plan is that mount -o extents is not going to be the long-term way
that extents will be enabled. I can imagine a -o noextents option,
which might be used with remount to do an on-line rollback from
extents to non-extents, but normally you shouldn't need to use a mount
option to enable a feature that are filesystem format-related. Those
should be implied by the appropriate flags in the superblock.
Mount -o nobh is a different story, since that's just a implementation
detail --- although for ext4, maybe we should just make nobh a
default, since that way more people will test it and hopefully,
eventually nobh will be the only way of doing things, right?
> Making the journal larger than the mke2fs default often helps
> performance with metadata-intensive workloads.
The default was increased significantly in e2fsprogs 1.40; if someone
who has their favorite metadata-intesive benchmark could test and see
if we should be using even larger defaults for certain "mke2fs -T
<workload-type>" configurations, I'd really appreciate it.
- Ted
> Mount -o nobh is a different story, since that's just a implementation
> detail --- although for ext4, maybe we should just make nobh a
> default, since that way more people will test it and hopefully,
> eventually nobh will be the only way of doing things, right?
imo it should be that even for ext3!
Hi,
On 10/10/06, Andrew Morton <[email protected]> wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc1/2.6.19-rc1-mm1/
>
Kernel 2.6.19-rc1-mm1 + Neil's avoid_lockdep_warning_in_md.patch
(http://www.ussg.iu.edu/hypermail/linux/kernel/0610.1/0642.html)
(I'll try to reproduce this without Neil's patch).
echo shutdown > /sys/power/disk; echo disk > /sys/power/state
=======================================================
[ INFO: possible circular locking dependency detected ]
2.6.19-rc1-mm1 #4
-------------------------------------------------------
bash/2404 is trying to acquire lock:
((cpu_chain).rwsem){..--}, at: [<c012e6a0>]
blocking_notifier_call_chain+0x11/0x2d
but task is already holding lock:
(workqueue_mutex){--..}, at: [<c0313dea>] mutex_lock+0x1c/0x1f
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (workqueue_mutex){--..}:
[<c013a4d0>] add_lock_to_list+0x5c/0x7a
[<c013c5f5>] __lock_acquire+0x9f3/0xaef
[<c013ca5b>] lock_acquire+0x71/0x91
[<c0313baf>] __mutex_lock_slowpath+0xd2/0x2f1
[<c0313dea>] mutex_lock+0x1c/0x1f
[<c0131767>] workqueue_cpu_callback+0x109/0x1ff
[<c012e30f>] notifier_call_chain+0x20/0x31
[<c012e6ac>] blocking_notifier_call_chain+0x1d/0x2d
[<c014126b>] _cpu_down+0x48/0x1ff
[<c01415fc>] disable_nonboot_cpus+0x9b/0x12f
[<c0146bd3>] prepare_processes+0xf/0x73
[<c0146e78>] pm_suspend_disk+0xa/0x11c
[<c01460d4>] enter_state+0x5a/0x185
[<c0146285>] state_store+0x86/0x9c
[<c01ad6dc>] subsys_attr_store+0x20/0x25
[<c01ad7df>] sysfs_write_file+0xaa/0xd3
[<c0177189>] vfs_write+0xcd/0x179
[<c0177834>] sys_write+0x3b/0x71
[<c0103241>] sysenter_past_esp+0x56/0x8d
[<ffffffff>] 0xffffffff
-> #0 ((cpu_chain).rwsem){..--}:
[<c013bbce>] print_circular_bug_tail+0x30/0x64
[<c013c52c>] __lock_acquire+0x92a/0xaef
[<c013ca5b>] lock_acquire+0x71/0x91
[<c0138202>] down_read+0x28/0x3c
[<c012e6a0>] blocking_notifier_call_chain+0x11/0x2d
[<c014138b>] _cpu_down+0x168/0x1ff
[<c01415fc>] disable_nonboot_cpus+0x9b/0x12f
[<c0146bd3>] prepare_processes+0xf/0x73
[<c0146e78>] pm_suspend_disk+0xa/0x11c
[<c01460d4>] enter_state+0x5a/0x185
[<c0146285>] state_store+0x86/0x9c
[<c01ad6dc>] subsys_attr_store+0x20/0x25
[<c01ad7df>] sysfs_write_file+0xaa/0xd3
[<c0177189>] vfs_write+0xcd/0x179
[<c0177834>] sys_write+0x3b/0x71
[<c0103241>] sysenter_past_esp+0x56/0x8d
[<ffffffff>] 0xffffffff
other info that might help us debug this:
2 locks held by bash/2404:
#0: (cpu_add_remove_lock){--..}, at: [<c0313dea>] mutex_lock+0x1c/0x1f
#1: (workqueue_mutex){--..}, at: [<c0313dea>] mutex_lock+0x1c/0x1f
stack backtrace:
[<c01042e6>] dump_trace+0x64/0x1cd
[<c0104461>] show_trace_log_lvl+0x12/0x25
[<c0104a08>] show_trace+0xd/0x10
[<c0104a4f>] dump_stack+0x19/0x1b
[<c013bbf7>] print_circular_bug_tail+0x59/0x64
[<c013c52c>] __lock_acquire+0x92a/0xaef
[<c013ca5b>] lock_acquire+0x71/0x91
[<c0138202>] down_read+0x28/0x3c
[<c012e6a0>] blocking_notifier_call_chain+0x11/0x2d
[<c014138b>] _cpu_down+0x168/0x1ff
[<c01415fc>] disable_nonboot_cpus+0x9b/0x12f
[<c0146bd3>] prepare_processes+0xf/0x73
[<c0146e78>] pm_suspend_disk+0xa/0x11c
[<c01460d4>] enter_state+0x5a/0x185
[<c0146285>] state_store+0x86/0x9c
[<c01ad6dc>] subsys_attr_store+0x20/0x25
[<c01ad7df>] sysfs_write_file+0xaa/0xd3
[<c0177189>] vfs_write+0xcd/0x179
[<c0177834>] sys_write+0x3b/0x71
[<c0103241>] sysenter_past_esp+0x56/0x8d
DWARF2 unwinder stuck at sysenter_past_esp+0x56/0x8d
Leftover inexact backtrace:
=======================
config & dmesg http://www.stardust.webpages.pl/files/tbf/euridica/2.6.19-rc1-mm1/
Regards,
Michal
--
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/)
On Tue, 2006-10-10 at 10:03 +0200, Arjan van de Ven wrote:
> On Tue, 2006-10-10 at 00:45 -0700, Andrew Morton wrote:
>
> > > if it's ok to ignore RSS,
> >
> > We'd prefer not to. But what's the alternative?
>
> it's a good question; today (2.6.18) we have some defacto behavior of
> RSS; 2.6.19-rc1-mm1 has a somewhat different one. Either can be entirely
> valid; and we can obviously implement either. We can go even further and
> remove more from RSS to help save memory and pagefaults (both help
> desktop performance) by going the shared pagetable road
> > > So.. what does RSS actually mean? Can we ignore it somewhat for
> > > shared-readonly mappings ?
> >
> > We'd prefer to go the other way, and implement RLIMIT_RSS wouldn't we?
>
> Well... that again depends on how we define RSS. implementing the rlimit
> doesn't mean we can't NOT count certain things (like the hugetlb pages
> in the patch above, or shared read only pagecache pages) to be part of
> it. It's a fundamental "what does it mean" thing.
> You can argue that RSS means "all memory that the application has in
> it's address space", you can argue "all such memory except a few cases",
> you can argue "all memory that is private/exclusive to the
> application"...
> This is not a pointless piss-in-the-wind discussion; unless we define
> rather specific what it really means, the RLIMIT doesn't mean anything
> either.
>
> We need to consider at least if any of the following are part of rss:
> * VM_IO io mmaped device stuff
> * Non-linear mappings
> * Shared hugetlb memory that shares pagetables
> * Shared hugetlb memory
> * Hugetlb memory in general
> * Shared normal memory that shares pagetables
> * Shared normal memory (file backed; eg pagecache)
> * Shared normal memory (anonymous/non-file-backed)
> * Sysv/ipc shared memory
> * Not shared normal memory
>
> I don't think posix or anything else helps us here so we can vote or
> otherwise reason which make sense and which don't. I hope the outcome is
> reasonably consistent ;)
>
> I know the desktop guys at least consider RSS useless as measure of "how
> much memory does my desktop app take"; especially since they have many
> shared libraries and they consider it unfair that each app pays the full
> price in terms of RSS for those. So personally I'm not unhappy with a
> definition that comes down to "all memory that's private to the app";
> although it is a change from what 2.6.18 does.
So we have three cases where RSS matters besides presenting a number to
user-space;
- shared page tables
- containers
- rlimit
Preferably they will all share a common definition of what RSS is; since
containers must account shared pages somehow (not doing so would open up
a large hole to DoS the other containers) and the container case can be
argued to be an extension of the rlimit case we cannot just ignore them.
As then what to do with them, I've yet to figure out. Some random bit
floating in my brain;
- VM_IO can be discarted, its not actual memory
- hugetlb is memory too, so I'd not special case this (other than the
different unit of accounting)
- shared mapped pages could be accounted on vma level, since both
containers have access to the same file, there is already an imbalance,
so I'd not worry about the 1%-99% usage scenario here.
- regular, non mapped, pagecache pages however have no owner - what to
do. (fake vma - which would result in each container paying equally for
all these pages?)
Anyway, I'd rather not break RSS twice, once now because we don't quite
know what to do, and later when we do get an acceptable mm container and
have to include shared memory in one way or the other.
On 10/10/06, Michal Piotrowski <[email protected]> wrote:
> Hi,
>
> On 10/10/06, Andrew Morton <[email protected]> wrote:
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc1/2.6.19-rc1-mm1/
> >
>
> Kernel 2.6.19-rc1-mm1 + Neil's avoid_lockdep_warning_in_md.patch
> (http://www.ussg.iu.edu/hypermail/linux/kernel/0610.1/0642.html)
>
> (I'll try to reproduce this without Neil's patch).
I can't reproduce this without Neil's patch.
>
> echo shutdown > /sys/power/disk; echo disk > /sys/power/state
>
> =======================================================
> [ INFO: possible circular locking dependency detected ]
> 2.6.19-rc1-mm1 #4
> -------------------------------------------------------
> bash/2404 is trying to acquire lock:
> ((cpu_chain).rwsem){..--}, at: [<c012e6a0>]
> blocking_notifier_call_chain+0x11/0x2d
>
> but task is already holding lock:
> (workqueue_mutex){--..}, at: [<c0313dea>] mutex_lock+0x1c/0x1f
>
> which lock already depends on the new lock.
>
> the existing dependency chain (in reverse order) is:
>
> -> #1 (workqueue_mutex){--..}:
> [<c013a4d0>] add_lock_to_list+0x5c/0x7a
> [<c013c5f5>] __lock_acquire+0x9f3/0xaef
> [<c013ca5b>] lock_acquire+0x71/0x91
> [<c0313baf>] __mutex_lock_slowpath+0xd2/0x2f1
> [<c0313dea>] mutex_lock+0x1c/0x1f
> [<c0131767>] workqueue_cpu_callback+0x109/0x1ff
> [<c012e30f>] notifier_call_chain+0x20/0x31
> [<c012e6ac>] blocking_notifier_call_chain+0x1d/0x2d
> [<c014126b>] _cpu_down+0x48/0x1ff
> [<c01415fc>] disable_nonboot_cpus+0x9b/0x12f
> [<c0146bd3>] prepare_processes+0xf/0x73
> [<c0146e78>] pm_suspend_disk+0xa/0x11c
> [<c01460d4>] enter_state+0x5a/0x185
> [<c0146285>] state_store+0x86/0x9c
> [<c01ad6dc>] subsys_attr_store+0x20/0x25
> [<c01ad7df>] sysfs_write_file+0xaa/0xd3
> [<c0177189>] vfs_write+0xcd/0x179
> [<c0177834>] sys_write+0x3b/0x71
> [<c0103241>] sysenter_past_esp+0x56/0x8d
> [<ffffffff>] 0xffffffff
>
> -> #0 ((cpu_chain).rwsem){..--}:
> [<c013bbce>] print_circular_bug_tail+0x30/0x64
> [<c013c52c>] __lock_acquire+0x92a/0xaef
> [<c013ca5b>] lock_acquire+0x71/0x91
> [<c0138202>] down_read+0x28/0x3c
> [<c012e6a0>] blocking_notifier_call_chain+0x11/0x2d
> [<c014138b>] _cpu_down+0x168/0x1ff
> [<c01415fc>] disable_nonboot_cpus+0x9b/0x12f
> [<c0146bd3>] prepare_processes+0xf/0x73
> [<c0146e78>] pm_suspend_disk+0xa/0x11c
> [<c01460d4>] enter_state+0x5a/0x185
> [<c0146285>] state_store+0x86/0x9c
> [<c01ad6dc>] subsys_attr_store+0x20/0x25
> [<c01ad7df>] sysfs_write_file+0xaa/0xd3
> [<c0177189>] vfs_write+0xcd/0x179
> [<c0177834>] sys_write+0x3b/0x71
> [<c0103241>] sysenter_past_esp+0x56/0x8d
> [<ffffffff>] 0xffffffff
>
> other info that might help us debug this:
>
> 2 locks held by bash/2404:
> #0: (cpu_add_remove_lock){--..}, at: [<c0313dea>] mutex_lock+0x1c/0x1f
> #1: (workqueue_mutex){--..}, at: [<c0313dea>] mutex_lock+0x1c/0x1f
>
> stack backtrace:
> [<c01042e6>] dump_trace+0x64/0x1cd
> [<c0104461>] show_trace_log_lvl+0x12/0x25
> [<c0104a08>] show_trace+0xd/0x10
> [<c0104a4f>] dump_stack+0x19/0x1b
> [<c013bbf7>] print_circular_bug_tail+0x59/0x64
> [<c013c52c>] __lock_acquire+0x92a/0xaef
> [<c013ca5b>] lock_acquire+0x71/0x91
> [<c0138202>] down_read+0x28/0x3c
> [<c012e6a0>] blocking_notifier_call_chain+0x11/0x2d
> [<c014138b>] _cpu_down+0x168/0x1ff
> [<c01415fc>] disable_nonboot_cpus+0x9b/0x12f
> [<c0146bd3>] prepare_processes+0xf/0x73
> [<c0146e78>] pm_suspend_disk+0xa/0x11c
> [<c01460d4>] enter_state+0x5a/0x185
> [<c0146285>] state_store+0x86/0x9c
> [<c01ad6dc>] subsys_attr_store+0x20/0x25
> [<c01ad7df>] sysfs_write_file+0xaa/0xd3
> [<c0177189>] vfs_write+0xcd/0x179
> [<c0177834>] sys_write+0x3b/0x71
> [<c0103241>] sysenter_past_esp+0x56/0x8d
> DWARF2 unwinder stuck at sysenter_past_esp+0x56/0x8d
> Leftover inexact backtrace:
> =======================
>
> config & dmesg http://www.stardust.webpages.pl/files/tbf/euridica/2.6.19-rc1-mm1/
Regards,
Michal
--
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/)
On Tue, 2006-10-10 at 00:09 -0700, Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc1/2.6.19-rc1-mm1/
I'm seeing an exception in filp_close(), called from sys_dup2(). I have
only seen it when I try to start up a java application (Lotus
Workplace).
I suspect that it may be related to the fdtable work, but I haven't
investigated it too closely.
> +fdtable-delete-pointless-code-in-dup_fd.patch
> +fdtable-make-fdarray-and-fdsets-equal-in-size.patch
> +fdtable-remove-the-free_files-field.patch
> +fdtable-implement-new-pagesize-based-fdtable-allocator.patch
>
> Redo the fdtable code.
BUG: unable to handle kernel paging request at virtual address 3237304a
printing eip:
c015636f
*pde = 00000000
Oops: 0000 [#1]
PREEMPT
last sysfs file: /block/hda/hda5/stat
Modules linked in: irda crc_ccitt tun airo e1000 pcmcia yenta_socket rsrc_nonstatic pcmcia_core radeon rtc ntfs jfs
CPU: 0
EIP: 0060:[<c015636f>] Not tainted VLI
EFLAGS: 00010206 (2.6.19-rc1-mm1 #1)
EIP is at filp_close+0xc/0x5e
eax: 00000000 ebx: 32373036 ecx: cbc66000 edx: 00000000
esi: 00000001 edi: dff0cc80 ebp: cbc67f8c esp: cbc67f80
ds: 007b es: 007b ss: 0068
Process java (pid: 12945, ti=cbc66000 task=ce9d6b00 task.ti=cbc66000)
Stack: 0000020c 00000001 cef765c0 cbc67fb4 c01623ed 32373036 dff0cc80 dff0cca4
32373036 dff0cc80 00000007 00000000 fffffff4 cbc66000 c0102e05 00000007
0000020c 00000000 00000000 fffffff4 bf966c14 0000003f 0000007b c03b007b
Call Trace:
[<c01623ed>] sys_dup2+0xdb/0x10f
[<c0102e05>] sysenter_past_esp+0x56/0x79
DWARF2 unwinder stuck at sysenter_past_esp+0x56/0x79
Leftover inexact backtrace:
=======================
Code: 26 00 8b 43 04 8b 40 0c 0f b3 30 3b 73 4c 73 03 89 73 4c 89 f8 e8 c0 51 26 00 5b 5e 5f 5d c3 55 89 e5 57 8b 7d 0c 56 53 8b 5d 08 <8b> 43 14 85 c0 75 0f 68 a1 e8 3f c0 31 f6 e8 54 35 fc ff 59 eb
EIP: [<c015636f>] filp_close+0xc/0x5e SS:ESP 0068:cbc67f80
<1>BUG: unable to handle kernel paging request at virtual address 02404e7c
printing eip:
c015636f
*pde = 00000000
Oops: 0000 [#2]
PREEMPT
last sysfs file: /block/hda/hda5/stat
Modules linked in: irda crc_ccitt tun airo e1000 pcmcia yenta_socket rsrc_nonstatic pcmcia_core radeon rtc ntfs jfs
CPU: 0
EIP: 0060:[<c015636f>] Not tainted VLI
EFLAGS: 00010202 (2.6.19-rc1-mm1 #1)
EIP is at filp_close+0xc/0x5e
eax: 00000000 ebx: 02404e68 ecx: cc636000 edx: 00000000
esi: 00000001 edi: dfcfecc0 ebp: cc637f8c esp: cc637f80
ds: 007b es: 007b ss: 0068
Process java (pid: 13593, ti=cc636000 task=ce97f550 task.ti=cc636000)
Stack: 0000020c 00000001 cbc56b80 cc637fb4 c01623ed 02404e68 dfcfecc0 dfcfece4
02404e68 dfcfecc0 00000007 00000000 fffffff4 cc636000 c0102e05 00000007
0000020c 00000000 00000000 fffffff4 bfc5f704 0000003f 0000007b c03b007b
Call Trace:
[<c01623ed>] sys_dup2+0xdb/0x10f
[<c0102e05>] sysenter_past_esp+0x56/0x79
DWARF2 unwinder stuck at sysenter_past_esp+0x56/0x79
Leftover inexact backtrace:
=======================
Code: 26 00 8b 43 04 8b 40 0c 0f b3 30 3b 73 4c 73 03 89 73 4c 89 f8 e8 c0 51 26 00 5b 5e 5f 5d c3 55 89 e5 57 8b 7d 0c 56 53 8b 5d 08 <8b> 43 14 85 c0 75 0f 68 a1 e8 3f c0 31 f6 e8 54 35 fc ff 59 eb
EIP: [<c015636f>] filp_close+0xc/0x5e SS:ESP 0068:cc637f80
<1>BUG: unable to handle kernel NULL pointer dereference at virtual address 00000127
printing eip:
c01874ca
*pde = 00000000
Oops: 0000 [#3]
PREEMPT
last sysfs file: /block/hda/hda5/stat
Modules linked in: irda crc_ccitt tun airo e1000 pcmcia yenta_socket rsrc_nonstatic pcmcia_core radeon rtc ntfs jfs
CPU: 0
EIP: 0060:[<c01874ca>] Not tainted VLI
EFLAGS: 00210246 (2.6.19-rc1-mm1 #1)
EIP is at dnotify_flush+0xf/0x73
eax: c8892c4b ebx: b7f96e4a ecx: cab2c000 edx: b7f96e4a
esi: 000000ff edi: c148a280 ebp: cab2df70 esp: cab2df64
ds: 007b es: 007b ss: 0068
Process java (pid: 13942, ti=cab2c000 task=d572d4d0 task.ti=cab2c000)
Stack: b7f96e4a 00000000 c148a280 cab2df8c c01563a6 b7f96e4a c148a280 0000020c
00000001 cef5dec0 cab2dfb4 c01623ed b7f96e4a c148a280 c148a2a4 b7f96e4a
c148a280 00000007 00000000 fffffff4 cab2c000 c0102e05 00000007 0000020c
Call Trace:
[<c01563a6>] filp_close+0x43/0x5e
[<c01623ed>] sys_dup2+0xdb/0x10f
[<c0102e05>] sysenter_past_esp+0x56/0x79
DWARF2 unwinder stuck at sysenter_past_esp+0x56/0x79
Leftover inexact backtrace:
=======================
Code: ff ff 53 e8 d3 00 fe ff 83 c4 0c eb 07 89 f0 e8 6b 40 23 00 8d 65 f4 5b 5e 5f 5d c3 55 89 e5 8b 55 08 57 56 53 8b 42 08 8b 70 30 <0f> b7 46 28 25 00 f0 00 00 3d 00 40 00 00 75 4c 8d 7e 70 89 f8
EIP: [<c01874ca>] dnotify_flush+0xf/0x73 SS:ESP 0068:cab2df64
--
David Kleikamp
IBM Linux Technology Center
On 10/10/06, Andrew Morton <[email protected]> wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc1/2.6.19-rc1-mm1/
>
This looks strange
ps aux | grep t3
root 4305 81.6 0.1 5952 2596 pts/7 R+ 17:54 2:44
python ./rt-tester.py t3-l1-pi-steal.tst
michal 4351 0.0 0.0 3908 760 pts/5 R+ 17:58 0:00 grep t3
[michal@euridica ~]$ ps aux | grep creat
root 3934 87.3 0.0 1652 496 pts/4 R 17:25 28:37 creat05
michal 4353 0.0 0.0 3912 772 pts/5 S+ 17:58 0:00 grep creat
python ./rt-tester.py t3-l1-pi-steal.tst and creat05 (from LTP) are
always in running state (creat05 since 28 minutes). I don't have any
idea why this happens.
Regards,
Michal
--
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/)
On Tue, 2006-10-10 at 15:14 +0200, Peter Zijlstra wrote:
> >
> > We need to consider at least if any of the following are part of rss:
> > * VM_IO io mmaped device stuff
> > * Non-linear mappings
> > * Shared hugetlb memory that shares pagetables
> > * Shared hugetlb memory
> > * Hugetlb memory in general
> > * Shared normal memory that shares pagetables
> > * Shared normal memory (file backed; eg pagecache)
> > * Shared normal memory (anonymous/non-file-backed)
> > * Sysv/ipc shared memory
> > * Not shared normal memory
> So we have three cases where RSS matters besides presenting a number to
> user-space;
> - shared page tables
> - containers
> - rlimit
>
> Preferably they will all share a common definition of what RSS is; since
> containers must account shared pages somehow (not doing so would open up
> a large hole to DoS the other containers) and the container case can be
> argued to be an extension of the rlimit case we cannot just ignore them.
>
> As then what to do with them, I've yet to figure out. Some random bit
> floating in my brain;
> - VM_IO can be discarted, its not actual memory
agreed (although I think we do count it today; this is half of what
makes X look so bloated, next to firefox ;)
>
> - hugetlb is memory too, so I'd not special case this (other than the
> different unit of accounting)
agreed again; personally I don't think hugetlb memory should be special;
especially with all the libhugetlbfs work on making it real easy for
apps to use; the more it's used the more people would notice something
funky with it.
> - shared mapped pages could be accounted on vma level, since both
> containers have access to the same file, there is already an imbalance,
> so I'd not worry about the 1%-99% usage scenario here.
or one level below; if you count it in the actual PTE page then the
sharing case will "just work". It's a trick question; do you count it as
100% or do you count it as 100% / number of sharers.
> - regular, non mapped, pagecache pages however have no owner - what to
> do. (fake vma - which would result in each container paying equally for
> all these pages?)
if they're clean I wouldn't count them to anything actually
> Anyway, I'd rather not break RSS twice, once now because we don't quite
> know what to do, and later when we do get an acceptable mm container and
> have to include shared memory in one way or the other.
RSS of a container versus RSS of a process is an interesting question
for sure ;)
On Tue, 10 Oct 2006 08:19:50 -0400
Theodore Tso <[email protected]> wrote:
> On Tue, Oct 10, 2006 at 12:09:28AM -0700, Andrew Morton wrote:
> >
> > - Added the ext4 filesystem. Quick usage instructions:
> >
> > - Grab updated e2fsprogs from
> > ftp://ftp.kernel.org/pub/linux/kernel/people/tytso/e2fsprogs-interim/
> >
> > - It's still mke2fs -j /dev/hda1
> >
> > - mount /dev/hda1 /wherever -t ext4dev
> >
> > - To enable extents,
> >
> > mount /dev/hda1 /wherever -t ext4dev -o extents
>
> Looks like you didn't take the updated patch from Shaggy which
> requires that you use tune2fs -O extents first?
Nope. That would have made extents inaccessible with the e2fsprogs I was
using and I didn't have time to test e2fsprogs-interim.
> (This requires the
> e2fsprogs-interim patches.)
OK.
> The plan is that mount -o extents is not going to be the long-term way
> that extents will be enabled. I can imagine a -o noextents option,
> which might be used with remount to do an on-line rollback from
> extents to non-extents, but normally you shouldn't need to use a mount
> option to enable a feature that are filesystem format-related. Those
> should be implied by the appropriate flags in the superblock.
>
> Mount -o nobh is a different story, since that's just a implementation
> detail --- although for ext4, maybe we should just make nobh a
> default, since that way more people will test it and hopefully,
> eventually nobh will be the only way of doing things, right?
nobh might be inefficient with large PAGE_SIZE and small files (or just
small writes).
> > Making the journal larger than the mke2fs default often helps
> > performance with metadata-intensive workloads.
>
> The default was increased significantly in e2fsprogs 1.40; if someone
> who has their favorite metadata-intesive benchmark could test and see
> if we should be using even larger defaults for certain "mke2fs -T
> <workload-type>" configurations, I'd really appreciate it.
>
> - Ted
I keep hitting this on -rc1-mm1. The system comes up but I can't login
since login hits it.
Bisect says that fdtable-implement-new-pagesize-based-fdtable-allocator.patch is at fault.
CONFIG_PPC_64K_PAGES=y is required for it to fail, with 4K pages it's fine.
(Hardware is a Quad G5, 1GB RAM, g5_defconfig + CONFIG_PPC_64K_PAGES, defaults
on all new options)
kernel BUG in copy_fdtable at fs/file.c:138!
Oops: Exception in kernel mode, sig: 5 [#1]
SMP NR_CPUS=4
Modules linked in: snd_pcm_oss snd_mixer_oss joydev snd_pcm snd_page_alloc snd_timer snd soundcore
NIP: C0000000000B926C LR: C0000000000B9210 CTR: C0000000000ADA34
REGS: c00000000f80ba60 TRAP: 0700 Not tainted (2.6.19-rc1-mm1)
MSR: 9000000000029032 <EE,ME,IR,DR> CR: 22002428 XER: 200FFFFF
TASK = c00000000fe38ba0[2022] 'dhclient-script' THREAD: c00000000f808000 CPU: 2
GPR00: 0000000000000001 C00000000F80BCE0 C0000000006CDCC8 C00000003F8CF880
GPR04: 00000000000000D0 0000000042002428 0000000000004000 000000000FEC1950
GPR08: C000000000585480 0000000000000000 C00000003FFD0480 C000000001E04200
GPR12: 100000000000F032 C000000000585480 0000000010000000 0000000010010000
GPR16: 0000000010002790 000000001001819D 00000000FCCDF818 0000000000000000
GPR20: 0000000000000000 00000000FCCDF828 0000000010018790 0000000010018760
GPR24: 00000000F7FDE6F0 C00000003F8CF800 0000000000000000 C00000003F8CF810
GPR28: 0000000000000040 0000000000000000 C0000000005B4B00 C00000000FB511C0
NIP [C0000000000B926C] .expand_files+0x1d4/0x34c
LR [C0000000000B9210] .expand_files+0x178/0x34c
Call Trace:
[C00000000F80BCE0] [C0000000000B91D0] .expand_files+0x138/0x34c (unreliable)
[C00000000F80BD90] [C0000000000ADAD8] .sys_dup2+0xa4/0x1ec
[C00000000F80BE30] [C00000000000871C] syscall_exit+0x0/0x40
Instruction dump:
60000000 4800000c 4bfd3609 60000000 7fe3fb78 4bfdf125 60000000 48000150
835f0000 7f9ae040 7c101026 5400effe <0b000000> 2fbc0000 419e00a4 7b9d1828
-Olof
Andrew Morton wrote:
> +generic-implementatation-of-bug.patch
> +generic-implementatation-of-bug-fix.patch
> +generic-bug-for-i386.patch
> +generic-bug-for-x86-64.patch
> +uml-add-generic-bug-support.patch
> +use-generic-bug-for-ppc.patch
> +bug-test-1.patch
>
No generic-bug for powerpc? Still broken?
J
Miguel Ojeda wrote:
> Allright, I will code it as the fbcfag12864b module, and when it will
> be working fine, I will remove the raw device of the cfag12864b and if
> the code of fbcfag12864b results really small/trivial, I will put it
> in the cfag12864b module. Then I will send you the "update patch 2".
>
> Give me a couple of days or so :)
Just as an aside, would it be possible to give this module a name which
doesn't look like a changeset ID? It's only the 'g' which gives it away...
J
On Tue, 10 Oct 2006 18:09:31 +0200
"Michal Piotrowski" <[email protected]> wrote:
> On 10/10/06, Andrew Morton <[email protected]> wrote:
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc1/2.6.19-rc1-mm1/
> >
>
> This looks strange
> ps aux | grep t3
> root 4305 81.6 0.1 5952 2596 pts/7 R+ 17:54 2:44
> python ./rt-tester.py t3-l1-pi-steal.tst
> michal 4351 0.0 0.0 3908 760 pts/5 R+ 17:58 0:00 grep t3
> [michal@euridica ~]$ ps aux | grep creat
> root 3934 87.3 0.0 1652 496 pts/4 R 17:25 28:37 creat05
> michal 4353 0.0 0.0 3912 772 pts/5 S+ 17:58 0:00 grep creat
>
> python ./rt-tester.py t3-l1-pi-steal.tst and creat05 (from LTP) are
> always in running state (creat05 since 28 minutes). I don't have any
> idea why this happens.
>
The fdtable patches might have some problems.
http://userweb.kernel.org/~akpm/mp.bz2 is 2.6.19-rc1-mm1 without those
patches. Does it work better?
Thanks.
On Tue, 10 Oct 2006 11:09:32 -0700
Jeremy Fitzhardinge <[email protected]> wrote:
> Andrew Morton wrote:
> > +generic-implementatation-of-bug.patch
> > +generic-implementatation-of-bug-fix.patch
> > +generic-bug-for-i386.patch
> > +generic-bug-for-x86-64.patch
> > +uml-add-generic-bug-support.patch
> > +use-generic-bug-for-ppc.patch
> > +bug-test-1.patch
> >
>
> No generic-bug for powerpc? Still broken?
>
I didn't do anything to fix it. But I haven't tested it recently - it
might have repaired itself ;)
My plan was to pathetically spam the powerpc guys with it once all the
above is merged up. I took a close look and couldn't see why it was
failing.
On Tue, 10 Oct 2006 12:15:19 -0500
Olof Johansson <[email protected]> wrote:
> I keep hitting this on -rc1-mm1. The system comes up but I can't login
> since login hits it.
>
> Bisect says that fdtable-implement-new-pagesize-based-fdtable-allocator.patch is at fault.
>
> CONFIG_PPC_64K_PAGES=y is required for it to fail, with 4K pages it's fine.
>
> (Hardware is a Quad G5, 1GB RAM, g5_defconfig + CONFIG_PPC_64K_PAGES, defaults
> on all new options)
>
>
>
> kernel BUG in copy_fdtable at fs/file.c:138!
OK, thanks. I put the revert patch into
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc1/2.6.19-rc1-mm1/hot-fixes/
Andrew Morton wrote:
> I didn't do anything to fix it. But I haven't tested it recently - it
> might have repaired itself ;)
>
Surely the way to check it just throw it in and see who screams...
> My plan was to pathetically spam the powerpc guys with it once all the
> above is merged up. I took a close look and couldn't see why it was
> failing.
>
Oh, I thought it turned out to be some other problem. Er, something
about numa memory stuff?
J
On Tue, Oct 10, 2006 at 12:15:19PM -0500, Olof Johansson wrote:
> I keep hitting this on -rc1-mm1. The system comes up but I can't login
> since login hits it.
>
> Bisect says that fdtable-implement-new-pagesize-based-fdtable-allocator.patch is at fault.
>
> CONFIG_PPC_64K_PAGES=y is required for it to fail, with 4K pages it's fine.
>
> (Hardware is a Quad G5, 1GB RAM, g5_defconfig + CONFIG_PPC_64K_PAGES, defaults
> on all new options)
>
>
>
> kernel BUG in copy_fdtable at fs/file.c:138!
FWIW, I too was hitting this bug, during init:
[ 41.659823] Freeing unused kernel memory: 320k freed
INIT: version 2.86 bootin[ 42.509322] kernel BUG in copy_fdtable at fs/file.c:138!
and of course systm does not come up.
--linas
On Tuesday 10 October 2006 13:20, Linas Vepstas wrote:
> On Tue, Oct 10, 2006 at 12:15:19PM -0500, Olof Johansson wrote:
> > I keep hitting this on -rc1-mm1. The system comes up but I can't login
> > since login hits it.
> >
> > Bisect says that
> > fdtable-implement-new-pagesize-based-fdtable-allocator.patch is at fault.
> >
> > CONFIG_PPC_64K_PAGES=y is required for it to fail, with 4K pages it's
> > fine.
> >
> > (Hardware is a Quad G5, 1GB RAM, g5_defconfig + CONFIG_PPC_64K_PAGES,
> > defaults on all new options)
> >
> >
> >
> > kernel BUG in copy_fdtable at fs/file.c:138!
>
> FWIW, I too was hitting this bug, during init:
>
> [ 41.659823] Freeing unused kernel memory: 320k freed
> INIT: version 2.86 bootin[ 42.509322] kernel BUG in copy_fdtable at
> fs/file.c:138!
>
> and of course systm does not come up.
>
> --linas
I'm digging through this right now, trying to figure out exactly what went
wrong (and why some people are seeing this, while others are not). All the
code seems correct; another pair of eyes is always welcome though.
-- Vadim Lobanov
On 10/10/06, Andrew Morton <[email protected]> wrote:
> On Tue, 10 Oct 2006 18:09:31 +0200
> "Michal Piotrowski" <[email protected]> wrote:
>
> > On 10/10/06, Andrew Morton <[email protected]> wrote:
> > >
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc1/2.6.19-rc1-mm1/
> > >
> >
> > This looks strange
> > ps aux | grep t3
> > root 4305 81.6 0.1 5952 2596 pts/7 R+ 17:54 2:44
> > python ./rt-tester.py t3-l1-pi-steal.tst
> > michal 4351 0.0 0.0 3908 760 pts/5 R+ 17:58 0:00 grep t3
> > [michal@euridica ~]$ ps aux | grep creat
> > root 3934 87.3 0.0 1652 496 pts/4 R 17:25 28:37 creat05
> > michal 4353 0.0 0.0 3912 772 pts/5 S+ 17:58 0:00 grep creat
> >
> > python ./rt-tester.py t3-l1-pi-steal.tst and creat05 (from LTP) are
> > always in running state (creat05 since 28 minutes). I don't have any
> > idea why this happens.
> >
>
> The fdtable patches might have some problems.
>
> http://userweb.kernel.org/~akpm/mp.bz2 is 2.6.19-rc1-mm1 without those
> patches. Does it work better?
Yes, it does. Thanks.
BTW. Kernel hangs while running Cyclictest
(http://rt.wiki.kernel.org/index.php/Cyclictest)
cyclictest -t 10 -l 100000
(or "bin/autotest tests/cyclictest/control" in autotest). I don't see
nothing special on tty (currently my sysklogd is broken, FC6
problem..)
Regards,
Michal
--
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/)
On Tue, 10 Oct 2006 23:44:04 +0200
"Michal Piotrowski" <[email protected]> wrote:
> BTW. Kernel hangs while running Cyclictest
> (http://rt.wiki.kernel.org/index.php/Cyclictest)
> cyclictest -t 10 -l 100000
> (or "bin/autotest tests/cyclictest/control" in autotest). I don't see
> nothing special on tty (currently my sysklogd is broken, FC6
> problem..)
cc added.
On Tue, 2006-10-10 at 10:47 -0500, Dave Kleikamp wrote:
> On Tue, 2006-10-10 at 00:09 -0700, Andrew Morton wrote:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc1/2.6.19-rc1-mm1/
>
> I'm seeing an exception in filp_close(), called from sys_dup2(). I have
> only seen it when I try to start up a java application (Lotus
> Workplace).
>
> I suspect that it may be related to the fdtable work, but I haven't
> investigated it too closely.
Still don't know exactly what's going on here. In case it helps, this
is the call to dup2() from strace output:
1419 open("/dev/null", O_RDWR) = 7
1419 getrlimit(RLIMIT_NOFILE, {rlim_cur=1024, rlim_max=1024}) = 0
1419 dup2(7, 524) = 524
1419 dup2(7, 525 <unfinished ...>
>
> > +fdtable-delete-pointless-code-in-dup_fd.patch
> > +fdtable-make-fdarray-and-fdsets-equal-in-size.patch
> > +fdtable-remove-the-free_files-field.patch
> > +fdtable-implement-new-pagesize-based-fdtable-allocator.patch
> >
> > Redo the fdtable code.
>
> BUG: unable to handle kernel paging request at virtual address 3237304a
> printing eip:
> c015636f
> *pde = 00000000
> Oops: 0000 [#1]
> PREEMPT
> last sysfs file: /block/hda/hda5/stat
> Modules linked in: irda crc_ccitt tun airo e1000 pcmcia yenta_socket rsrc_nonstatic pcmcia_core radeon rtc ntfs jfs
> CPU: 0
> EIP: 0060:[<c015636f>] Not tainted VLI
> EFLAGS: 00010206 (2.6.19-rc1-mm1 #1)
> EIP is at filp_close+0xc/0x5e
> eax: 00000000 ebx: 32373036 ecx: cbc66000 edx: 00000000
> esi: 00000001 edi: dff0cc80 ebp: cbc67f8c esp: cbc67f80
> ds: 007b es: 007b ss: 0068
> Process java (pid: 12945, ti=cbc66000 task=ce9d6b00 task.ti=cbc66000)
> Stack: 0000020c 00000001 cef765c0 cbc67fb4 c01623ed 32373036 dff0cc80 dff0cca4
> 32373036 dff0cc80 00000007 00000000 fffffff4 cbc66000 c0102e05 00000007
> 0000020c 00000000 00000000 fffffff4 bf966c14 0000003f 0000007b c03b007b
> Call Trace:
> [<c01623ed>] sys_dup2+0xdb/0x10f
> [<c0102e05>] sysenter_past_esp+0x56/0x79
> DWARF2 unwinder stuck at sysenter_past_esp+0x56/0x79
> Leftover inexact backtrace:
> =======================
> Code: 26 00 8b 43 04 8b 40 0c 0f b3 30 3b 73 4c 73 03 89 73 4c 89 f8 e8 c0 51 26 00 5b 5e 5f 5d c3 55 89 e5 57 8b 7d 0c 56 53 8b 5d 08 <8b> 43 14 85 c0 75 0f 68 a1 e8 3f c0 31 f6 e8 54 35 fc ff 59 eb
> EIP: [<c015636f>] filp_close+0xc/0x5e SS:ESP 0068:cbc67f80
> <1>BUG: unable to handle kernel paging request at virtual address 02404e7c
> printing eip:
> c015636f
> *pde = 00000000
> Oops: 0000 [#2]
> PREEMPT
> last sysfs file: /block/hda/hda5/stat
> Modules linked in: irda crc_ccitt tun airo e1000 pcmcia yenta_socket rsrc_nonstatic pcmcia_core radeon rtc ntfs jfs
> CPU: 0
> EIP: 0060:[<c015636f>] Not tainted VLI
> EFLAGS: 00010202 (2.6.19-rc1-mm1 #1)
> EIP is at filp_close+0xc/0x5e
> eax: 00000000 ebx: 02404e68 ecx: cc636000 edx: 00000000
> esi: 00000001 edi: dfcfecc0 ebp: cc637f8c esp: cc637f80
> ds: 007b es: 007b ss: 0068
> Process java (pid: 13593, ti=cc636000 task=ce97f550 task.ti=cc636000)
> Stack: 0000020c 00000001 cbc56b80 cc637fb4 c01623ed 02404e68 dfcfecc0 dfcfece4
> 02404e68 dfcfecc0 00000007 00000000 fffffff4 cc636000 c0102e05 00000007
> 0000020c 00000000 00000000 fffffff4 bfc5f704 0000003f 0000007b c03b007b
> Call Trace:
> [<c01623ed>] sys_dup2+0xdb/0x10f
> [<c0102e05>] sysenter_past_esp+0x56/0x79
> DWARF2 unwinder stuck at sysenter_past_esp+0x56/0x79
> Leftover inexact backtrace:
> =======================
> Code: 26 00 8b 43 04 8b 40 0c 0f b3 30 3b 73 4c 73 03 89 73 4c 89 f8 e8 c0 51 26 00 5b 5e 5f 5d c3 55 89 e5 57 8b 7d 0c 56 53 8b 5d 08 <8b> 43 14 85 c0 75 0f 68 a1 e8 3f c0 31 f6 e8 54 35 fc ff 59 eb
> EIP: [<c015636f>] filp_close+0xc/0x5e SS:ESP 0068:cc637f80
> <1>BUG: unable to handle kernel NULL pointer dereference at virtual address 00000127
> printing eip:
> c01874ca
> *pde = 00000000
> Oops: 0000 [#3]
> PREEMPT
> last sysfs file: /block/hda/hda5/stat
> Modules linked in: irda crc_ccitt tun airo e1000 pcmcia yenta_socket rsrc_nonstatic pcmcia_core radeon rtc ntfs jfs
> CPU: 0
> EIP: 0060:[<c01874ca>] Not tainted VLI
> EFLAGS: 00210246 (2.6.19-rc1-mm1 #1)
> EIP is at dnotify_flush+0xf/0x73
> eax: c8892c4b ebx: b7f96e4a ecx: cab2c000 edx: b7f96e4a
> esi: 000000ff edi: c148a280 ebp: cab2df70 esp: cab2df64
> ds: 007b es: 007b ss: 0068
> Process java (pid: 13942, ti=cab2c000 task=d572d4d0 task.ti=cab2c000)
> Stack: b7f96e4a 00000000 c148a280 cab2df8c c01563a6 b7f96e4a c148a280 0000020c
> 00000001 cef5dec0 cab2dfb4 c01623ed b7f96e4a c148a280 c148a2a4 b7f96e4a
> c148a280 00000007 00000000 fffffff4 cab2c000 c0102e05 00000007 0000020c
> Call Trace:
> [<c01563a6>] filp_close+0x43/0x5e
> [<c01623ed>] sys_dup2+0xdb/0x10f
> [<c0102e05>] sysenter_past_esp+0x56/0x79
> DWARF2 unwinder stuck at sysenter_past_esp+0x56/0x79
> Leftover inexact backtrace:
> =======================
> Code: ff ff 53 e8 d3 00 fe ff 83 c4 0c eb 07 89 f0 e8 6b 40 23 00 8d 65 f4 5b 5e 5f 5d c3 55 89 e5 8b 55 08 57 56 53 8b 42 08 8b 70 30 <0f> b7 46 28 25 00 f0 00 00 3d 00 40 00 00 75 4c 8d 7e 70 89 f8
> EIP: [<c01874ca>] dnotify_flush+0xf/0x73 SS:ESP 0068:cab2df64
>
>
--
David Kleikamp
IBM Linux Technology Center
On Tuesday 10 October 2006 15:07, Dave Kleikamp wrote:
> Still don't know exactly what's going on here. In case it helps, this
> is the call to dup2() from strace output:
>
> 1419 open("/dev/null", O_RDWR) = 7
> 1419 getrlimit(RLIMIT_NOFILE, {rlim_cur=1024, rlim_max=1024}) = 0
> 1419 dup2(7, 524) = 524
> 1419 dup2(7, 525 <unfinished ...>
Thanks for the data point.
Hmmm... looks as if the likely sequence of events was:
create embedded fdtable
extend fdtable, allocate external data to handle fd = 524
try to extend fdtable again, crash.
Seems as if alloc_fdtable() or copy_fdtable() are to blame, but the code logic
seems to be identical. Hmmmm.
-- Vadim Lobanov
On Tue, 2006-10-10 at 00:09 -0700, Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc1/2.6.19-rc1-mm1/
I hate to report always failures, I hope you don't hate me
for that :)
My EM64T box doesn't boot -mm1. Seems like IRQ problem ?
Thanks,
Badari
Linux version 2.6.19-rc1-mm1-smp (root@elm3a241) (gcc version 4.1.1 20060612 (Red Hat 4.1.1-3)) #2 SMP Tue Oct 10 10:37:46 PDT 2006
Command line: ro root=/dev/VolGroup00/LogVol00 console=tty0 console=ttyS0,38400 rhgb verbose
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009dc00 (usable)
BIOS-e820: 000000000009dc00 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 00000000d7fcca80 (usable)
BIOS-e820: 00000000d7fcca80 - 00000000d7fd0000 (ACPI data)
BIOS-e820: 00000000d7fd0000 - 00000000d8000000 (reserved)
BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved)
BIOS-e820: 0000000100000000 - 0000000128000000 (usable)
end_pfn_map = 1212416
DMI 2.3 present.
>>> ERROR: Invalid checksum
No NUMA configuration found
Faking a node at 0000000000000000-0000000128000000
Bootmem setup node 0 0000000000000000-0000000128000000
Zone PFN ranges:
DMA 0 -> 4096
DMA32 4096 -> 1048576
Normal 1048576 -> 1212416
early_node_map[3] active PFN ranges
0: 0 -> 157
0: 256 -> 884684
0: 1048576 -> 1212416
Intel MultiProcessor Specification v1.4
MPTABLE: OEM ID: IBM ENSW MPTABLE: Product ID: x346 SMP MPTABLE: APIC at: 0xFEE00000
Processor #0 (Bootup-CPU)
Processor #6
I/O APIC #14 at 0xFEC00000.
I/O APIC #13 at 0xFEC84000.
I/O APIC #12 at 0xFEC84400.
I/O APIC #11 at 0xFEC80000.
I/O APIC #10 at 0xFEC80400.
Setting APIC routing to physical flat
Processors: 2
Nosave address range: 000000000009d000 - 000000000009e000
Nosave address range: 000000000009e000 - 00000000000a0000
Nosave address range: 00000000000a0000 - 00000000000e0000
Nosave address range: 00000000000e0000 - 0000000000100000
Nosave address range: 00000000d7fcc000 - 00000000d7fcd000
Nosave address range: 00000000d7fcd000 - 00000000d7fd0000
Nosave address range: 00000000d7fd0000 - 00000000d8000000
Nosave address range: 00000000d8000000 - 00000000fec00000
Nosave address range: 00000000fec00000 - 0000000100000000
Allocating PCI resources starting at dc000000 (gap: d8000000:26c00000)
SMP: Allowing 2 CPUs, 0 hotplug CPUs
PERCPU: Allocating 50432 bytes of per cpu data
Built 1 zonelists. Total pages: 1019681
Kernel command line: ro root=/dev/VolGroup00/LogVol00 console=tty0 console=ttyS0,38400 rhgb verbose
Initializing CPU#0
PID hash table entries: 4096 (order: 12, 32768 bytes)
Console: colour VGA+ 80x25
Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
... MAX_LOCKDEP_SUBCLASSES: 8
... MAX_LOCK_DEPTH: 30
... MAX_LOCKDEP_KEYS: 2048
... CLASSHASH_SIZE: 1024
... MAX_LOCKDEP_ENTRIES: 8192
... MAX_LOCKDEP_CHAINS: 8192
... CHAINHASH_SIZE: 4096
memory used by lock dependency info: 1328 kB
per task-struct memory footprint: 1680 bytes
Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes)
Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes)
Checking aperture...
PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
Placing software IO TLB between 0x1675000 - 0x5675000
Memory: 4004408k/4849664k available (2714k kernel code, 189292k reserved, 2094k data, 328k init)
Calibrating delay using timer specific routine.. 6014.59 BogoMIPS (lpj=12029192)
Security Framework v1.0.0 initialized
Mount-cache hash table entries: 256
CPU: Trace cache: 12K uops, L1 D cache: 16K
CPU: L2 cache: 2048K
CPU 0/0 -> Node 0
using mwait in idle threads.
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 0
CPU0: Thermal monitoring enabled (TM1)
lockdep: not fixing up alternatives.
Using local APIC timer interrupts.
result 12500678
Detected 12.500 MHz APIC timer.
lockdep: not fixing up alternatives.
Booting processor 1/2 APIC 0x6
Initializing CPU#1
Calibrating delay using timer specific routine.. 6000.53 BogoMIPS (lpj=12001079)
CPU: Trace cache: 12K uops, L1 D cache: 16K
CPU: L2 cache: 2048K
CPU 1/6 -> Node 0
CPU: Physical Processor ID: 3
CPU: Processor Core ID: 0
CPU1: Thermal monitoring enabled (TM1)
Intel(R) Xeon(TM) CPU 3.00GHz stepping 03
Brought up 2 CPUs
testing NMI watchdog ... OK.
time.c: Using 1.193182 MHz WALL PIT GTOD PIT/TSC timer.
time.c: Detected 3000.178 MHz processor.
migration_cost=1820
checking if image is initramfs... it is
Freeing initrd memory: 1743k freed
NET: Registered protocol family 16
PCI: Using configuration type 1
ACPI: Interpreter disabled.
SCSI subsystem initialized
PCI: Probing PCI hardware
PCI quirk: region 0580-05ff claimed by ICH4 ACPI/GPIO/TCO
PCI quirk: region 0400-043f claimed by ICH4 GPIO
PCI: PXH quirk detected, disabling MSI for SHPC device
PCI: PXH quirk detected, disabling MSI for SHPC device
PCI: Transparent bridge - 0000:00:1e.0
PCI->APIC IRQ transform: 0000:00:1d.0[A] -> IRQ 16
PCI->APIC IRQ transform: 0000:00:1d.1[B] -> IRQ 19
PCI->APIC IRQ transform: 0000:00:1d.7[D] -> IRQ 23
PCI->APIC IRQ transform: 0000:00:1f.1[A] -> IRQ 17
PCI->APIC IRQ transform: 0000:00:1f.3[B] -> IRQ 17
PCI->APIC IRQ transform: 0000:05:00.0[A] -> IRQ 16
PCI->APIC IRQ transform: 0000:06:00.0[A] -> IRQ 16
PCI->APIC IRQ transform: 0000:08:07.0[A] -> IRQ 27
PCI->APIC IRQ transform: 0000:08:07.1[B] -> IRQ 24
PCI->APIC IRQ transform: 0000:01:06.0[A] -> IRQ 20
PCI-GART: No AMD northbridge found.
PCI: Bridge: 0000:02:00.0
IO window: disabled.
MEM window: disabled.
PREFETCH window: disabled.
PCI: Bridge: 0000:02:00.2
IO window: disabled.
MEM window: disabled.
PREFETCH window: disabled.
PCI: Bridge: 0000:00:02.0
IO window: disabled.
MEM window: disabled.
PREFETCH window: disabled.
PCI: Bridge: 0000:00:04.0
IO window: disabled.
MEM window: dd000000-deffffff
PREFETCH window: disabled.
PCI: Bridge: 0000:00:05.0
IO window: disabled.
MEM window: db000000-dcffffff
PREFETCH window: disabled.
PCI: Bridge: 0000:07:00.0
IO window: 4000-4fff
MEM window: d9000000-daffffff
PREFETCH window: df000000-df0fffff
PCI: Bridge: 0000:07:00.2
IO window: 5000-ffff
MEM window: disabled.
PREFETCH window: disabled.
PCI: Bridge: 0000:00:06.0
IO window: 4000-ffff
MEM window: d9000000-daffffff
PREFETCH window: df000000-df0fffff
PCI: Bridge: 0000:00:1e.0
IO window: 3000-3fff
MEM window: f8000000-f8ffffff
PREFETCH window: f0000000-f7ffffff
PCI: No IRQ known for interrupt pin A of device 0000:00:02.0. Probably buggy MP table.
PCI: No IRQ known for interrupt pin A of device 0000:00:04.0. Probably buggy MP table.
PCI: No IRQ known for interrupt pin A of device 0000:00:05.0. Probably buggy MP table.
PCI: No IRQ known for interrupt pin A of device 0000:00:06.0. Probably buggy MP table.
NET: Registered protocol family 2
IP route cache hash table entries: 131072 (order: 8, 1048576 bytes)
TCP established hash table entries: 65536 (order: 9, 3670016 bytes)
TCP bind hash table entries: 32768 (order: 8, 1835008 bytes)
TCP: Hash tables configured (established 65536 bind 32768)
TCP reno registered
audit: initializing netlink socket (disabled)
audit(1160515309.208:1): initialized
Total HugeTLB memory allocated, 0
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
pcie_portdrv_probe->Dev[3595:8086] has invalid IRQ. Check vendor BIOS
pcie_portdrv_probe->Dev[3597:8086] has invalid IRQ. Check vendor BIOS
pcie_portdrv_probe->Dev[3598:8086] has invalid IRQ. Check vendor BIOS
pcie_portdrv_probe->Dev[3599:8086] has invalid IRQ. Check vendor BIOS
Real Time Clock Driver v1.12ac
Non-volatile memory driver v1.2
Linux agpgart interface v0.101 (c) Dave Jones
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
RAMDISK driver initialized: 16 RAM disks of 128000K size 1024 blocksize
tg3.c:v3.66 (September 23, 2006)
eth0: Tigon3 [partno(BCM95721) rev 4101 PHY(5750)] (PCI Express) 10/100/1000BaseT Ethernet 00:11:25:8f:60:06
eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[1] Split[0] WireSpeed[1] TSOcap[1]
eth0: dma_rwctrl[76180000] dma_mask[64-bit]
eth1: Tigon3 [partno(BCM95721) rev 4101 PHY(5750)] (PCI Express) 10/100/1000BaseT Ethernet 00:11:25:8f:60:07
eth1: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[1] Split[0] WireSpeed[1] TSOcap[1]
eth1: dma_rwctrl[76180000] dma_mask[64-bit]
scsi0 : Adaptec AIC79XX PCI-X SCSI HBA DRIVER, Rev 3.0
<Adaptec AIC7902 Ultra320 SCSI adapter>
aic7902: Ultra320 Wide Channel A, SCSI Id=7, PCI-X 101-133Mhz, 512 SCBs
scsi1 : Adaptec AIC79XX PCI-X SCSI HBA DRIVER, Rev 3.0
<Adaptec AIC7902 Ultra320 SCSI adapter>
aic7902: Ultra320 Wide Channel B, SCSI Id=7, PCI-X 101-133Mhz, 512 SCBs
scsi 1:0:0:0: Direct-Access IBM-ESXS MAP3367NC FN C101 PQ: 0 ANSI: 3
target1:0:0: asynchronous
scsi1:A:0:0: Tagged Queuing enabled. Depth 32
target1:0:0: Beginning Domain Validation
target1:0:0: wide asynchronous
target1:0:0: FAST-160 WIDE SCSI 320.0 MB/s DT IU RTI PCOMP (6.25 ns, offset 127)
target1:0:0: Ending Domain Validation
scsi 1:0:2:0: Direct-Access IBM-ESXS MAP3367NC FN C101 PQ: 0 ANSI: 3
target1:0:2: asynchronous
scsi1:A:2:0: Tagged Queuing enabled. Depth 32
target1:0:2: Beginning Domain Validation
target1:0:2: wide asynchronous
target1:0:2: FAST-160 WIDE SCSI 320.0 MB/s DT IU RTI PCOMP (6.25 ns, offset 127)
target1:0:2: Ending Domain Validation
scsi 1:0:8:0: Processor IBM 25R5170a S320 0 1 PQ: 0 ANSI: 2
target1:0:8: asynchronous
target1:0:8: Beginning Domain Validation
target1:0:8: Ending Domain Validation
SCSI device sda: 71096640 512-byte hdwr sectors (36401 MB)
sda: Write Protect is off
SCSI device sda: drive cache: write through
SCSI device sda: 71096640 512-byte hdwr sectors (36401 MB)
sda: Write Protect is off
SCSI device sda: drive cache: write through
sda: sda1 sda2
sd 1:0:0:0: Attached scsi disk sda
SCSI device sdb: 71096640 512-byte hdwr sectors (36401 MB)
sdb: Write Protect is off
SCSI device sdb: drive cache: write through
SCSI device sdb: 71096640 512-byte hdwr sectors (36401 MB)
sdb: Write Protect is off
SCSI device sdb: drive cache: write through
sdb: sdb1 sdb2
sd 1:0:2:0: Attached scsi disk sdb
sd 1:0:0:0: Attached scsi generic sg0 type 0
sd 1:0:2:0: Attached scsi generic sg1 type 0
scsi 1:0:8:0: Attached scsi generic sg2 type 3
serio: i8042 KBD port at 0x60,0x64 irq 1
serio: i8042 AUX port at 0x60,0x64 irq 12
mice: PS/2 mouse device common for all mice
input: PC Speaker as /class/input/input0
NET: Registered protocol family 1
Freeing unused kernel memory: 328k freed
Write protecting the kernel read-only data: 565k
input: AT Translated Set 2 keyboard as /class/input/input1
Red Hat nash version 5.0.41 starting
Mounting proc filesystem
Mounting sysfs filesystem
Creating /dev
Creating initial device nodes
Setting up hotplug.
input: PS/2 Generic Mouse as /class/input/input2
Creating block device nodes.
Loading ide-core.ko module
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
Loading ide-disk.ko module
Loading dm-mod.ko module
device-mapper: ioctl: 4.10.0-ioctl (2006-09-14) initialised: [email protected]
Loading dm-mirror.ko module
Loading dm-zero.ko module
Loading dm-snapshot.ko module
Making device-mapper control node
Scanning logical volumes
Reading all physical volumes. This may take a while...
Found volume group "VolGroup00" using metadata type lvm2
Activating logical volumes
2 logical volume(s) in volume group "VolGroup00" now active
Creating root device.
Mounting root filesystem.
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
Setting up other filesystems.
Setting up new root fs
no fstab.sys, mounting internal defaults
Switching to new root and running init.
unmounting old /dev
unmounting old /proc
unmounting old /proc/bus/usb
ERROR unmounting old /proc/bus/usb: No such file or directory
forcing unmount of /proc/bus/usb
unmounting old /sys
INIT: version 2.86 booting
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
Welcome to Red Hat Enterprise Linux
Press 'I' to enter interactive startup.
warning: process `date' used the removed sysctl system call
Setting clock (utc): Tue Oct 10 14:22:36 PDT 2006 [ OK ]
Starting udev: udevd[539]: add_to_rules: unknown key 'MODALIAS'
udevd[539]: add_to_rules: unknown key 'MODALIAS'
udevd[539]: add_to_rules: unknown key 'MODALIAS'
[ OK ]
Setting hostname elm3a241: [ OK ]
Setting up Logical Volume Management: 2 logical volume(s) in volume group "VolGroup00" now active
[ OK ]
Checking filesystems
Checking all file systems.
[/sbin/fsck.ext3 (1) -- /] fsck.ext3 -a /dev/VolGroup00/LogVol00
/dev/VolGroup00/LogVol00: clean, 454331/8339520 files, 6170765/8339456 blocks
[/sbin/fsck.ext3 (1) -- /boot] fsck.ext3 -a /dev/sda1
/boot: clean, 67/26104 files, 101516/104388 blocks
[ OK ]
Remounting root filesystem in read-write mode: [ OK ]
Mounting local filesystems: [ OK ]
Enabling local filesystem quotas: [ OK ]
Enabling local swap partitions: swapon: /dev/dm-1: Device or resource busy
[FAILED]
Enabling /etc/fstab swaps: [ OK ]
INIT: Entering runlevel: 3
Entering non-interactive startup
Starting readahead_early: Starting background readahead: [ OK ]
[ OK ]
FATAL: Error inserting acpi_cpufreq (/lib/modules/2.6.19-rc1-mm1-smp/kernel/arch/x86_64/kernel/cpufreq/acpi-cpufreq.ko): No such device
Applying ip6tables firewall rules: [ OK ]
Bringing up loopback interface: [ OK ]
Bringing up interface eth0: [ OK ]
Starting system logger: [ OK ]
Starting kernel logger: [ OK ]
Starting irqbalance: [ OK ]
Starting portmap: [ OK ]
Starting NFS statd: [ OK ]
Starting RPC idmapd: [ OK ]
Starting system message bus: [ OK ]
[ OK ] Bluetooth services:[ OK ]
Mounting other filesystems: [ OK ]
Starting hidd: [ OK ]
Loading autofs4: [ OK ]
Starting automount: [ OK ]
Starting smartd: [ OK ]
Starting hpiod: [ OK ]
Starting hpssd: [ OK ]
Starting cups: [ OK ]
Starting sshd: [ OK ]
Starting sendmail: [ OK ]
Starting sm-client: [ OK ]
Starting console mouse services: [ OK ]
Starting crond: [ OK ]
Starting xfs: [ OK ]
Starting anacron: [ OK ]
Starting atd: [ OK ]
Starting yum-updatesd: [ OK ]
Starting Avahi daemon: do_IRQ: 0.57 No irq handler for vector
On Tuesday 10 October 2006 15:07, Dave Kleikamp wrote:
> On Tue, 2006-10-10 at 10:47 -0500, Dave Kleikamp wrote:
> > On Tue, 2006-10-10 at 00:09 -0700, Andrew Morton wrote:
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc
> > >1/2.6.19-rc1-mm1/
> >
> > I'm seeing an exception in filp_close(), called from sys_dup2(). I have
> > only seen it when I try to start up a java application (Lotus
> > Workplace).
> >
> > I suspect that it may be related to the fdtable work, but I haven't
> > investigated it too closely.
>
> Still don't know exactly what's going on here. In case it helps, this
> is the call to dup2() from strace output:
>
> 1419 open("/dev/null", O_RDWR) = 7
> 1419 getrlimit(RLIMIT_NOFILE, {rlim_cur=1024, rlim_max=1024}) = 0
> 1419 dup2(7, 524) = 524
> 1419 dup2(7, 525 <unfinished ...>
>
> > > +fdtable-delete-pointless-code-in-dup_fd.patch
> > > +fdtable-make-fdarray-and-fdsets-equal-in-size.patch
> > > +fdtable-remove-the-free_files-field.patch
> > > +fdtable-implement-new-pagesize-based-fdtable-allocator.patch
> > >
> > > Redo the fdtable code.
D'oh!!! Everybody who hit this bug can feel free to call me a moron now! (And
Andrew will probably take me up on that offer, for all the residual flak he
caught. :)) The problem is in the following logic:
+ nr++;
+ nr /= (PAGE_SIZE / 4 / sizeof(struct file *));
+ nr = roundup_pow_of_two(nr);
+ nr *= (PAGE_SIZE / 4 / sizeof(struct file *));
+ if (nr > NR_OPEN)
+ nr = NR_OPEN;
The problem is that roundup_pow_of_two() will not necessarily bring the array
up to the necessary size, and we get an array overflow. This is clearly
visible in the example above: dup2(..., 524) with a PAGE_SIZE of 4K. (Thanks
for sending that in, Dave.) Let me think about the best way to fix this
computation, and I'll send out a patch for you folks to test to see if it
fixes your problem, if you'll oblige.
-- Vadim Lobanov, idiot of the day
On Tue, Oct 10, 2006 at 01:31:11PM -0700, Vadim Lobanov wrote:
> On Tuesday 10 October 2006 13:20, Linas Vepstas wrote:
> > On Tue, Oct 10, 2006 at 12:15:19PM -0500, Olof Johansson wrote:
> > > I keep hitting this on -rc1-mm1. The system comes up but I can't login
> > > since login hits it.
> > >
> > > Bisect says that
> > > fdtable-implement-new-pagesize-based-fdtable-allocator.patch is at fault.
> > >
> > > CONFIG_PPC_64K_PAGES=y is required for it to fail, with 4K pages it's
> > > fine.
> > >
> > > (Hardware is a Quad G5, 1GB RAM, g5_defconfig + CONFIG_PPC_64K_PAGES,
> > > defaults on all new options)
> > >
> > > kernel BUG in copy_fdtable at fs/file.c:138!
> >
> > FWIW, I too was hitting this bug, during init:
> >
> > [ 41.659823] Freeing unused kernel memory: 320k freed
> > INIT: version 2.86 bootin[ 42.509322] kernel BUG in copy_fdtable at
> > fs/file.c:138!
> >
> > and of course systm does not come up.
I forgot to mention my h/w was completely different (a cell)
> I'm digging through this right now, trying to figure out exactly what went
> wrong (and why some people are seeing this, while others are not). All the
> code seems correct; another pair of eyes is always welcome though.
The patch that AKPM just posted at
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc1/2.6.19-rc1-mm1/hot-fixes/revert-fdtable-implement-new-pagesize-based-fdtable-allocator.patch
boots for me.
Thanks Andrew!
--linas
Andrew Morton writes:
> My plan was to pathetically spam the powerpc guys with it once all the
> above is merged up. I took a close look and couldn't see why it was
> failing.
What was the failure?
Paul.
Paul Mackerras wrote:
> Andrew Morton writes:
>
>
>> My plan was to pathetically spam the powerpc guys with it once all the
>> above is merged up. I took a close look and couldn't see why it was
>> failing.
>>
>
> What was the failure?
>
I've included it below. But Michael Ellerman said it worked OK for him
when applied to the plain Linus tree, and Andrew said that
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18/2.6.18-mm3/hot-fixes/slab-reduce-numa-text-size-tidy-fix.patch
fixed it. So I thought it was OK.
J
> On Wed, 04 Oct 2006 00:22:33 -0600
> [email protected] wrote:
>
>> > Subject: generic-implementatation-of-bug-fix
>
> x86_64 works OK. powerpc compiles now, but hangs after "returning from
> prom_init". I can't see why. The quickest way to fix this is to merge it
> into mainline as-is then whistle innocently.
>
> Can any of the powerpc guys spot-the-bug??
>
> Thanks.
>
>
> From: Jeremy Fitzhardinge <[email protected]>
>
> This makes powerpc use the generic BUG machinery. The biggest reports the
> function name, since it is redundant with kallsyms, and not needed in general.
>
> There is an overall reduction of code, since module_32/64 duplicated several
> functions.
>
> Unfortunately there's no way to tell gcc that BUG won't return, so the BUG
> macro includes a goto loop. This will generate a real jmp instruction, which
> is never used.
>
> BTW, powerpc doesn't seem to be using BUG_OPCODE or BUG_ILLEGAL_INSTRUCTION
> for actual BUGs any more (I presume they were once used). There are still a
> couple of uses of those macros elsewhere (kernel/prom_init.c and
> kernel/head_64.S); should be converted to "twi 31,0,0" as well?
>
> [[email protected]: build fixes]
> Signed-off-by: Jeremy Fitzhardinge <[email protected]>
> Cc: Andi Kleen <[email protected]>
> Cc: Hugh Dickens <[email protected]>
> Cc: Michael Ellerman <[email protected]>
> Cc: Paul Mackerras <[email protected]>
> Cc: Benjamin Herrenschmidt <[email protected]>
> Cc: Rusty Russell <[email protected]>
> Signed-off-by: Andrew Morton <[email protected]>
> ---
>
> arch/powerpc/Kconfig | 5 +
> arch/powerpc/kernel/module_32.c | 43 +-------------
> arch/powerpc/kernel/module_64.c | 43 +-------------
> arch/powerpc/kernel/traps.c | 54 ++----------------
> arch/powerpc/kernel/vmlinux.lds.S | 6 --
> arch/powerpc/xmon/xmon.c | 10 +--
> include/asm-powerpc/bug.h | 83 ++++++++++++++--------------
> include/asm-powerpc/module.h | 2
> 8 files changed, 65 insertions(+), 181 deletions(-)
>
> diff -puN arch/powerpc/Kconfig~generic-bug-for-powerpc arch/powerpc/Kconfig
> --- a/arch/powerpc/Kconfig~generic-bug-for-powerpc
> +++ a/arch/powerpc/Kconfig
> @@ -99,6 +99,11 @@ config AUDIT_ARCH
> bool
> default y
>
> +config GENERIC_BUG
> + bool
> + default y
> + depends on BUG
> +
> config DEFAULT_UIMAGE
> bool
> help
> diff -puN arch/powerpc/kernel/module_32.c~generic-bug-for-powerpc arch/powerpc/kernel/module_32.c
> --- a/arch/powerpc/kernel/module_32.c~generic-bug-for-powerpc
> +++ a/arch/powerpc/kernel/module_32.c
> @@ -23,6 +23,7 @@
> #include <linux/string.h>
> #include <linux/kernel.h>
> #include <linux/cache.h>
> +#include <linux/bug.h>
>
> #if 0
> #define DEBUGP printk
> @@ -273,48 +274,10 @@ int module_finalize(const Elf_Ehdr *hdr,
> const Elf_Shdr *sechdrs,
> struct module *me)
> {
> - char *secstrings;
> - unsigned int i;
> -
> - me->arch.bug_table = NULL;
> - me->arch.num_bugs = 0;
> -
> - /* Find the __bug_table section, if present */
> - secstrings = (char *)hdr + sechdrs[hdr->e_shstrndx].sh_offset;
> - for (i = 1; i < hdr->e_shnum; i++) {
> - if (strcmp(secstrings+sechdrs[i].sh_name, "__bug_table"))
> - continue;
> - me->arch.bug_table = (void *) sechdrs[i].sh_addr;
> - me->arch.num_bugs = sechdrs[i].sh_size / sizeof(struct bug_entry);
> - break;
> - }
> -
> - /*
> - * Strictly speaking this should have a spinlock to protect against
> - * traversals, but since we only traverse on BUG()s, a spinlock
> - * could potentially lead to deadlock and thus be counter-productive.
> - */
> - list_add(&me->arch.bug_list, &module_bug_list);
> -
> - return 0;
> + return module_bug_finalize(hdr, sechdrs, me);
> }
>
> void module_arch_cleanup(struct module *mod)
> {
> - list_del(&mod->arch.bug_list);
> -}
> -
> -struct bug_entry *module_find_bug(unsigned long bugaddr)
> -{
> - struct mod_arch_specific *mod;
> - unsigned int i;
> - struct bug_entry *bug;
> -
> - list_for_each_entry(mod, &module_bug_list, bug_list) {
> - bug = mod->bug_table;
> - for (i = 0; i < mod->num_bugs; ++i, ++bug)
> - if (bugaddr == bug->bug_addr)
> - return bug;
> - }
> - return NULL;
> + module_bug_cleanup(mod);
> }
> diff -puN arch/powerpc/kernel/module_64.c~generic-bug-for-powerpc arch/powerpc/kernel/module_64.c
> --- a/arch/powerpc/kernel/module_64.c~generic-bug-for-powerpc
> +++ a/arch/powerpc/kernel/module_64.c
> @@ -20,6 +20,7 @@
> #include <linux/moduleloader.h>
> #include <linux/err.h>
> #include <linux/vmalloc.h>
> +#include <linux/bug.h>
> #include <asm/module.h>
> #include <asm/uaccess.h>
>
> @@ -416,48 +417,10 @@ LIST_HEAD(module_bug_list);
> int module_finalize(const Elf_Ehdr *hdr,
> const Elf_Shdr *sechdrs, struct module *me)
> {
> - char *secstrings;
> - unsigned int i;
> -
> - me->arch.bug_table = NULL;
> - me->arch.num_bugs = 0;
> -
> - /* Find the __bug_table section, if present */
> - secstrings = (char *)hdr + sechdrs[hdr->e_shstrndx].sh_offset;
> - for (i = 1; i < hdr->e_shnum; i++) {
> - if (strcmp(secstrings+sechdrs[i].sh_name, "__bug_table"))
> - continue;
> - me->arch.bug_table = (void *) sechdrs[i].sh_addr;
> - me->arch.num_bugs = sechdrs[i].sh_size / sizeof(struct bug_entry);
> - break;
> - }
> -
> - /*
> - * Strictly speaking this should have a spinlock to protect against
> - * traversals, but since we only traverse on BUG()s, a spinlock
> - * could potentially lead to deadlock and thus be counter-productive.
> - */
> - list_add(&me->arch.bug_list, &module_bug_list);
> -
> - return 0;
> + return module_bug_finalize(hdr, sechdrs, me);
> }
>
> void module_arch_cleanup(struct module *mod)
> {
> - list_del(&mod->arch.bug_list);
> -}
> -
> -struct bug_entry *module_find_bug(unsigned long bugaddr)
> -{
> - struct mod_arch_specific *mod;
> - unsigned int i;
> - struct bug_entry *bug;
> -
> - list_for_each_entry(mod, &module_bug_list, bug_list) {
> - bug = mod->bug_table;
> - for (i = 0; i < mod->num_bugs; ++i, ++bug)
> - if (bugaddr == bug->bug_addr)
> - return bug;
> - }
> - return NULL;
> + module_bug_cleanup(mod);
> }
> diff -puN arch/powerpc/kernel/traps.c~generic-bug-for-powerpc arch/powerpc/kernel/traps.c
> --- a/arch/powerpc/kernel/traps.c~generic-bug-for-powerpc
> +++ a/arch/powerpc/kernel/traps.c
> @@ -32,6 +32,7 @@
> #include <linux/kprobes.h>
> #include <linux/kexec.h>
> #include <linux/backlight.h>
> +#include <linux/bug.h>
>
> #include <asm/kdebug.h>
> #include <asm/pgtable.h>
> @@ -731,54 +732,9 @@ static int emulate_instruction(struct pt
> return -EINVAL;
> }
>
> -/*
> - * Look through the list of trap instructions that are used for BUG(),
> - * BUG_ON() and WARN_ON() and see if we hit one. At this point we know
> - * that the exception was caused by a trap instruction of some kind.
> - * Returns 1 if we should continue (i.e. it was a WARN_ON) or 0
> - * otherwise.
> - */
> -extern struct bug_entry __start___bug_table[], __stop___bug_table[];
> -
> -#ifndef CONFIG_MODULES
> -#define module_find_bug(x) NULL
> -#endif
> -
> -struct bug_entry *find_bug(unsigned long bugaddr)
> +int is_valid_bugaddr(unsigned long addr)
> {
> - struct bug_entry *bug;
> -
> - for (bug = __start___bug_table; bug < __stop___bug_table; ++bug)
> - if (bugaddr == bug->bug_addr)
> - return bug;
> - return module_find_bug(bugaddr);
> -}
> -
> -static int check_bug_trap(struct pt_regs *regs)
> -{
> - struct bug_entry *bug;
> - unsigned long addr;
> -
> - if (regs->msr & MSR_PR)
> - return 0; /* not in kernel */
> - addr = regs->nip; /* address of trap instruction */
> - if (addr < PAGE_OFFSET)
> - return 0;
> - bug = find_bug(regs->nip);
> - if (bug == NULL)
> - return 0;
> - if (bug->line & BUG_WARNING_TRAP) {
> - /* this is a WARN_ON rather than BUG/BUG_ON */
> - printk(KERN_ERR "Badness in %s at %s:%ld\n",
> - bug->function, bug->file,
> - bug->line & ~BUG_WARNING_TRAP);
> - dump_stack();
> - return 1;
> - }
> - printk(KERN_CRIT "kernel BUG in %s at %s:%ld!\n",
> - bug->function, bug->file, bug->line);
> -
> - return 0;
> + return is_kernel_addr(addr);
> }
>
> void __kprobes program_check_exception(struct pt_regs *regs)
> @@ -812,7 +768,9 @@ void __kprobes program_check_exception(s
> return;
> if (debugger_bpt(regs))
> return;
> - if (check_bug_trap(regs)) {
> +
> + if (!(regs->msr & MSR_PR) && /* not user-mode */
> + report_bug(regs->nip) == BUG_TRAP_TYPE_WARN) {
> regs->nip += 4;
> return;
> }
> diff -puN arch/powerpc/kernel/vmlinux.lds.S~generic-bug-for-powerpc arch/powerpc/kernel/vmlinux.lds.S
> --- a/arch/powerpc/kernel/vmlinux.lds.S~generic-bug-for-powerpc
> +++ a/arch/powerpc/kernel/vmlinux.lds.S
> @@ -62,11 +62,7 @@ SECTIONS
> __stop___ex_table = .;
> }
>
> - __bug_table : {
> - __start___bug_table = .;
> - *(__bug_table)
> - __stop___bug_table = .;
> - }
> + BUG_TABLE
>
> /*
> * Init sections discarded at runtime
> diff -puN arch/powerpc/xmon/xmon.c~generic-bug-for-powerpc arch/powerpc/xmon/xmon.c
> --- a/arch/powerpc/xmon/xmon.c~generic-bug-for-powerpc
> +++ a/arch/powerpc/xmon/xmon.c
> @@ -19,6 +19,7 @@
> #include <linux/module.h>
> #include <linux/sysrq.h>
> #include <linux/interrupt.h>
> +#include <linux/bug.h>
>
> #include <asm/ptrace.h>
> #include <asm/string.h>
> @@ -32,7 +33,6 @@
> #include <asm/cputable.h>
> #include <asm/rtas.h>
> #include <asm/sstep.h>
> -#include <asm/bug.h>
>
> #ifdef CONFIG_PPC64
> #include <asm/hvcall.h>
> @@ -1329,7 +1329,7 @@ static void backtrace(struct pt_regs *ex
>
> static void print_bug_trap(struct pt_regs *regs)
> {
> - struct bug_entry *bug;
> + const struct bug_entry *bug;
> unsigned long addr;
>
> if (regs->msr & MSR_PR)
> @@ -1340,11 +1340,11 @@ static void print_bug_trap(struct pt_reg
> bug = find_bug(regs->nip);
> if (bug == NULL)
> return;
> - if (bug->line & BUG_WARNING_TRAP)
> + if (is_warning_bug(bug))
> return;
>
> - printf("kernel BUG in %s at %s:%d!\n",
> - bug->function, bug->file, (unsigned int)bug->line);
> + printf("kernel BUG at %s:%u!\n",
> + bug->file, bug->line);
> }
>
> void excprint(struct pt_regs *fp)
> diff -puN include/asm-powerpc/bug.h~generic-bug-for-powerpc include/asm-powerpc/bug.h
> --- a/include/asm-powerpc/bug.h~generic-bug-for-powerpc
> +++ a/include/asm-powerpc/bug.h
> @@ -13,37 +13,40 @@
>
> #ifndef __ASSEMBLY__
>
> -struct bug_entry {
> - unsigned long bug_addr;
> - long line;
> - const char *file;
> - const char *function;
> -};
> -
> -struct bug_entry *find_bug(unsigned long bugaddr);
> -
> -/*
> - * If this bit is set in the line number it means that the trap
> - * is for WARN_ON rather than BUG or BUG_ON.
> - */
> -#define BUG_WARNING_TRAP 0x1000000
> -
> #ifdef CONFIG_BUG
>
> +/* _EMIT_BUG_ENTRY expects args %0,%1,%2,%3 to be FILE, LINE, flags and
> + sizeof(struct bug_entry), respectively */
> +#ifdef CONFIG_DEBUG_BUGVERBOSE
> +#define _EMIT_BUG_ENTRY \
> + ".section __bug_table,\"a\"\n" \
> + "2:\t" PPC_LONG "1b, %0\n" \
> + "\t.short %1, %2\n" \
> + ".org 2b+%3\n" \
> + ".previous\n"
> +#else
> +#define _EMIT_BUG_ENTRY \
> + ".section __bug_table,\"a\"\n" \
> + "2:\t" PPC_LONG "1b\n" \
> + "\t.short %2\n" \
> + ".org 2b+%3\n" \
> + ".previous\n"
> +#endif
> +
> /*
> * BUG_ON() and WARN_ON() do their best to cooperate with compile-time
> * optimisations. However depending on the complexity of the condition
> * some compiler versions may not produce optimal results.
> */
>
> -#define BUG() do { \
> - __asm__ __volatile__( \
> - "1: twi 31,0,0\n" \
> - ".section __bug_table,\"a\"\n" \
> - "\t"PPC_LONG" 1b,%0,%1,%2\n" \
> - ".previous" \
> - : : "i" (__LINE__), "i" (__FILE__), "i" (__FUNCTION__)); \
> -} while (0)
> +#define BUG() do { \
> + __asm__ __volatile__( \
> + "1: twi 31,0,0\n" \
> + _EMIT_BUG_ENTRY \
> + : : "i" (__FILE__), "i" (__LINE__), \
> + "i" (0), "i" (sizeof(struct bug_entry))); \
> + for(;;) ; \
> + } while (0)
>
> #define BUG_ON(x) do { \
> if (__builtin_constant_p(x)) { \
> @@ -51,23 +54,22 @@ struct bug_entry *find_bug(unsigned long
> BUG(); \
> } else { \
> __asm__ __volatile__( \
> - "1: "PPC_TLNEI" %0,0\n" \
> - ".section __bug_table,\"a\"\n" \
> - "\t"PPC_LONG" 1b,%1,%2,%3\n" \
> - ".previous" \
> - : : "r" ((long)(x)), "i" (__LINE__), \
> - "i" (__FILE__), "i" (__FUNCTION__)); \
> + "1: "PPC_TLNEI" %4,0\n" \
> + _EMIT_BUG_ENTRY \
> + : : "i" (__FILE__), "i" (__LINE__), "i" (0), \
> + "i" (sizeof(struct bug_entry)), \
> + "r" ((long)(x))); \
> + for(;;) ; \
> } \
> } while (0)
>
> #define __WARN() do { \
> __asm__ __volatile__( \
> "1: twi 31,0,0\n" \
> - ".section __bug_table,\"a\"\n" \
> - "\t"PPC_LONG" 1b,%0,%1,%2\n" \
> - ".previous" \
> - : : "i" (__LINE__ + BUG_WARNING_TRAP), \
> - "i" (__FILE__), "i" (__FUNCTION__)); \
> + _EMIT_BUG_ENTRY \
> + : : "i" (__FILE__), "i" (__LINE__), \
> + "i" (BUGFLAG_WARNING), \
> + "i" (sizeof(struct bug_entry))); \
> } while (0)
>
> #define WARN_ON(x) ({ \
> @@ -77,13 +79,12 @@ struct bug_entry *find_bug(unsigned long
> __WARN(); \
> } else { \
> __asm__ __volatile__( \
> - "1: "PPC_TLNEI" %0,0\n" \
> - ".section __bug_table,\"a\"\n" \
> - "\t"PPC_LONG" 1b,%1,%2,%3\n" \
> - ".previous" \
> - : : "r" (__ret_warn_on), \
> - "i" (__LINE__ + BUG_WARNING_TRAP), \
> - "i" (__FILE__), "i" (__FUNCTION__)); \
> + "1: "PPC_TLNEI" %4,0\n" \
> + _EMIT_BUG_ENTRY \
> + : : "i" (__FILE__), "i" (__LINE__), \
> + "i" (BUGFLAG_WARNING), \
> + "i" (sizeof(struct bug_entry)), \
> + "r" (__ret_warn_on)); \
> } \
> unlikely(__ret_warn_on); \
> })
> diff -puN include/asm-powerpc/module.h~generic-bug-for-powerpc include/asm-powerpc/module.h
> --- a/include/asm-powerpc/module.h~generic-bug-for-powerpc
> +++ a/include/asm-powerpc/module.h
> @@ -46,8 +46,6 @@ struct mod_arch_specific {
> unsigned int num_bugs;
> };
>
> -extern struct bug_entry *module_find_bug(unsigned long bugaddr);
> -
> /*
> * Select ELF headers.
> * Make empty section for module_frob_arch_sections to expand.
> _
>
On Wed, 11 Oct 2006 09:10:23 +1000
Paul Mackerras <[email protected]> wrote:
> Andrew Morton writes:
>
> > My plan was to pathetically spam the powerpc guys with it once all the
> > above is merged up. I took a close look and couldn't see why it was
> > failing.
>
> What was the failure?
>
White-screen hang after "returning from prom_init".
I'll merge Jeremy's latest patches and retest this evening.
Arjan van de Ven <[email protected]> writes:
> On Tue, 2006-10-10 at 15:14 +0200, Peter Zijlstra wrote:
>> >
>> > We need to consider at least if any of the following are part of rss:
>> > * VM_IO io mmaped device stuff
>> > * Non-linear mappings
>> > * Shared hugetlb memory that shares pagetables
>> > * Shared hugetlb memory
>> > * Hugetlb memory in general
>> > * Shared normal memory that shares pagetables
>> > * Shared normal memory (file backed; eg pagecache)
>> > * Shared normal memory (anonymous/non-file-backed)
>> > * Sysv/ipc shared memory
>> > * Not shared normal memory
There is a concept related to RSS that is very interesting. The
minimum RSS that a process needs to keep from thrashing.
It can be shown that if your RSS rlimit is greater that your minimum
RSS your process will never thrash.
One thing that older paging algorithms would try and do when there
was memory pressure was to dynamically discover an applications
minimum RSS, and if they couldn't meet it swap that process out,
because the program can't make progress anyway.
A per process not a per application RSS fails to model multiple
process applications but the concepts are sound.
So since VM_IO does not have any effect on paging it should not
be counted but if you were a stickler the page tables from the
VM_IO should be counted.
The other thing to note is even if you RSS is just above your minimum
RSS that will only result in your process having pages bounce in and
out of the page cache (not necessarily to disk). So while it will
increase minor faults a restrictive RSS is not a problem when
you have excess resources.
>> - shared mapped pages could be accounted on vma level, since both
>> containers have access to the same file, there is already an imbalance,
>> so I'd not worry about the 1%-99% usage scenario here.
>
> or one level below; if you count it in the actual PTE page then the
> sharing case will "just work". It's a trick question; do you count it as
> 100% or do you count it as 100% / number of sharers.
I'm not certain I even want to follow the logic here. The answer is
clear.
For processes shared pages are not special.
For computing a container RSS shared pages need to be counted the
first time they are mapped by any process in a container, and
uncounted the last time they are unmapped by a process in a container.
With rmap we have the data structures necessary to do the accounting,
although it might be a bit of a pain.
>> - regular, non mapped, pagecache pages however have no owner - what to
>> do. (fake vma - which would result in each container paying equally for
>> all these pages?)
>
> if they're clean I wouldn't count them to anything actually
If the pages aren't mapped they aren't part of the resident set size.
At least not until we start worrying about per container or per
process splits of the page cache, and there are clearly good reasons
to avoid that.
>> Anyway, I'd rather not break RSS twice, once now because we don't quite
>> know what to do, and later when we do get an acceptable mm container and
>> have to include shared memory in one way or the other.
>
>
> RSS of a container versus RSS of a process is an interesting question
> for sure ;)
Agreed. Historically it was much more interesting because we didn't
have rmap so telling if your set of processes had mapped the page
already is a challenge. At this point unless the performance of
the accounting is to much it should just be a simple counting problem.
The real challenge is doing a decent job of picking the appropriate
page to unmap when a new mapping by a process would exceed the rss
limit. That is the one piece of the puzzle we have never implemented
:(
You can declare success when you can push one container into heavy
swapping and the rest of the containers are still running fine.
Eric
Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc1/2.6.19-rc1-mm1/
>
>
> - Added the ext4 filesystem. Quick usage instructions:
>
> - Grab updated e2fsprogs from
> ftp://ftp.kernel.org/pub/linux/kernel/people/tytso/e2fsprogs-interim/
>
Hi Ted,
e2fsprogs-1.39-tyt1-rollup.patch doesn't compile. (seems to be missing
percent.c). Can
you role up new version ? I had to apply individual patches to get it
working ..
Thanks,
Badari
On Tue, 10 Oct 2006 20:13:49 -0700
Badari Pulavarty <[email protected]> wrote:
> Andrew Morton wrote:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc1/2.6.19-rc1-mm1/
> >
> >
> > - Added the ext4 filesystem. Quick usage instructions:
> >
> > - Grab updated e2fsprogs from
> > ftp://ftp.kernel.org/pub/linux/kernel/people/tytso/e2fsprogs-interim/
> >
>
> Hi Ted,
>
> e2fsprogs-1.39-tyt1-rollup.patch doesn't compile. (seems to be missing
> percent.c). Can
> you role up new version ? I had to apply individual patches to get it
> working ..
>
http://userweb.kernel.org/~akpm/e2fsprogs-akpm.tar.gz is the version I
used. That's e2fsprogs-1.39 plus patches from
http://www.bullopensource.org/ext4/20060926/
On Tuesday October 10, [email protected] wrote:
> On 10/10/06, Michal Piotrowski <[email protected]> wrote:
> > Hi,
> >
> > On 10/10/06, Andrew Morton <[email protected]> wrote:
> > >
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc1/2.6.19-rc1-mm1/
> > >
> >
> > Kernel 2.6.19-rc1-mm1 + Neil's avoid_lockdep_warning_in_md.patch
> > (http://www.ussg.iu.edu/hypermail/linux/kernel/0610.1/0642.html)
> >
> > (I'll try to reproduce this without Neil's patch).
>
> I can't reproduce this without Neil's patch.
>
Despite this circumstantial evidence, I don't see how my patch could
possible have an effect here....
Looking at the code, starting at _cpu_down in the CONFIG_HOTPLUG_CPU
case, the call notifier chain 'cpu_chain' contains
workqueue_cpu_callback which does 'mutex_lock(&workqueue_mutex)' in
the "DOWN_PREPARE" case and mutex_unlock(&workqueue_mutex) in the
DOWN_FAILED and DEAD cases.
blocking_notifier_call_chain is
down_read(&nh->rwsem);
ret = notifier_call_chain(&nh->head, val, v);
up_read(&nh->rwsem);
and so holds ->rwsem while calling the callback.
So the locking sequence ends up as:
down_read(&cpu_chain.rwsem);
mutex_lock(&workqueue_mutex);
up_read(&cpu_chain.rwsem);
down_read(&cpu_chain.rwsem);
mutex_unlock(&workqueue_mutex);
up_read(&workqueue_mutex);
and lockdep doesn't seem to like this. It sees workqueue_mutex
claimed while cpu_chain.rwsem is held. and then it sees
cpu_chain.rwsem claimed while workqueue_mutex is held, which looks a
bit like a class ABBA deadlock.
Of course because it is a 'down_read' rather than a 'down', it isn't
really a dead lock.
I don't know how to tell lockdep to do the right thing, but I'll leave
that up to Ingo et al.
Why it didn't trigger without my patch I cannot imagine. Are you sure
the config was identical (you didn't remove CONFIG_HOTPLUG_CPU or
anything did you?).
NeilBrown
> >
> > echo shutdown > /sys/power/disk; echo disk > /sys/power/state
> >
> > =======================================================
> > [ INFO: possible circular locking dependency detected ]
> > 2.6.19-rc1-mm1 #4
> > -------------------------------------------------------
On Tue, 2006-10-10 at 15:17 -0700, Badari Pulavarty wrote:
> On Tue, 2006-10-10 at 00:09 -0700, Andrew Morton wrote:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc1/2.6.19-rc1-mm1/
>
>
> I hate to report always failures, I hope you don't hate me
> for that :)
>
> My EM64T box doesn't boot -mm1. Seems like IRQ problem ?
> Starting Avahi daemon: do_IRQ: 0.57 No irq handler for vector
I'm seeing something simliar (different number though) a few minutes
after boot with yesterdays git snapshot... something is sick in irq
land...
--
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
On Tue, 2006-10-10 at 17:54 -0600, Eric W. Biederman wrote:
> For processes shared pages are not special.
depends on what question you want to answer with RSS.
If the question is "workload working set size" then you are right. If
the question is "how much ram does my application cause to be used" the
answer is FAR less clear....
You seem to have an implicit definition on what RSS should mean; but
it's implicit. Mind making an explicit definition of what RSS should be
in your opinion? I think that's the biggest problem we have right now;
several people have different ideas about what it should/could be, and
as such we're not talking about the same thing. Lets first agree/specify
what it SHOULD mean, and then we can figure out what gets counted for
that ;)
On 11/10/06, Neil Brown <[email protected]> wrote:
> On Tuesday October 10, [email protected] wrote:
> > On 10/10/06, Michal Piotrowski <[email protected]> wrote:
> > > Hi,
> > >
> > > On 10/10/06, Andrew Morton <[email protected]> wrote:
> > > >
> > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc1/2.6.19-rc1-mm1/
> > > >
> > >
> > > Kernel 2.6.19-rc1-mm1 + Neil's avoid_lockdep_warning_in_md.patch
> > > (http://www.ussg.iu.edu/hypermail/linux/kernel/0610.1/0642.html)
> > >
> > > (I'll try to reproduce this without Neil's patch).
> >
> > I can't reproduce this without Neil's patch.
> >
>
> Despite this circumstantial evidence, I don't see how my patch could
> possible have an effect here....
>
> Looking at the code, starting at _cpu_down in the CONFIG_HOTPLUG_CPU
> case, the call notifier chain 'cpu_chain' contains
> workqueue_cpu_callback which does 'mutex_lock(&workqueue_mutex)' in
> the "DOWN_PREPARE" case and mutex_unlock(&workqueue_mutex) in the
> DOWN_FAILED and DEAD cases.
>
> blocking_notifier_call_chain is
> down_read(&nh->rwsem);
> ret = notifier_call_chain(&nh->head, val, v);
> up_read(&nh->rwsem);
>
> and so holds ->rwsem while calling the callback.
> So the locking sequence ends up as:
>
> down_read(&cpu_chain.rwsem);
> mutex_lock(&workqueue_mutex);
> up_read(&cpu_chain.rwsem);
>
> down_read(&cpu_chain.rwsem);
> mutex_unlock(&workqueue_mutex);
> up_read(&workqueue_mutex);
>
> and lockdep doesn't seem to like this. It sees workqueue_mutex
> claimed while cpu_chain.rwsem is held. and then it sees
> cpu_chain.rwsem claimed while workqueue_mutex is held, which looks a
> bit like a class ABBA deadlock.
> Of course because it is a 'down_read' rather than a 'down', it isn't
> really a dead lock.
>
> I don't know how to tell lockdep to do the right thing, but I'll leave
> that up to Ingo et al.
>
> Why it didn't trigger without my patch I cannot imagine. Are you sure
> the config was identical (you didn't remove CONFIG_HOTPLUG_CPU or
> anything did you?).
No, I didn't remove CONFIG_HOTPLUG_CPU or anything else.
I didn't do enough testing - only a few hibernatins.
>
> NeilBrown
>
Regards,
Michal
--
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/)
> > blocking_notifier_call_chain is
> > down_read(&nh->rwsem);
> > ret = notifier_call_chain(&nh->head, val, v);
> > up_read(&nh->rwsem);
> >
> > and so holds ->rwsem while calling the callback.
> > So the locking sequence ends up as:
> >
> > down_read(&cpu_chain.rwsem);
> > mutex_lock(&workqueue_mutex);
> > up_read(&cpu_chain.rwsem);
> >
> > down_read(&cpu_chain.rwsem);
> > mutex_unlock(&workqueue_mutex);
> > up_read(&workqueue_mutex);
> >
> > and lockdep doesn't seem to like this. It sees workqueue_mutex
> > claimed while cpu_chain.rwsem is held. and then it sees
> > cpu_chain.rwsem claimed while workqueue_mutex is held, which looks a
> > bit like a class ABBA deadlock.
> > Of course because it is a 'down_read' rather than a 'down', it isn't
> > really a dead lock.
ok can you explain to me why "down_read" doesn't make this a deadlock
while "down" would make it a deadlock? I have trouble following your
reasoning.....
(remember that rwsems are strictly fair)
Arjan van de Ven <[email protected]> writes:
> On Tue, 2006-10-10 at 17:54 -0600, Eric W. Biederman wrote:
>
>> For processes shared pages are not special.
Actually the above is not quite true you can map a shared page twice
into the same process but in practice it rarely happens.
> depends on what question you want to answer with RSS.
> If the question is "workload working set size" then you are right. If
> the question is "how much ram does my application cause to be used" the
> answer is FAR less clear....
There are two basic concerns. How do you keep an application from
going crazy and trashing the rest of your system? A question on what
number do you need to implement a resource limit.
The other question is how do I get good information so I can
effectively understand what kind of resources a given
application is using and hopefully predict what kind of
resources that application will use in the future.
The last time I tried to answer the question "how much ram does my
application cause to be used" I had to slowly start up additional
copies and watch how much free memory decreased.
Having a couple of additional counts in addition to RSS would probably
be the most help in understanding resource usage. Counting the number
of private dirty resident pages would be interesting. As would
counting the number of pages that are resident in the process but not
resident in any other process.
It might also help to have a per page report on which file it backs
and how many user it has. Unfortunately that is totally overwhelming
detail and the act of reporting it would quite likely change the
result as it would take so much memory to store the result.
> You seem to have an implicit definition on what RSS should mean; but
> it's implicit. Mind making an explicit definition of what RSS should be
> in your opinion? I think that's the biggest problem we have right now;
> several people have different ideas about what it should/could be, and
> as such we're not talking about the same thing. Lets first agree/specify
> what it SHOULD mean, and then we can figure out what gets counted for
> that ;)
Well I tried to defined it in terms of what you can use it for.
I would define the resident set size as the total number of bytes
of physical RAM that a process (or set of processes) is using,
irrespective of the rest of the system.
By physical RAM I mean that if a single page (if shared) is used twice
by a single process it will be counted only once. This definition
works well for shared and private pages.
COW pages are probably the most subtle. They are both shared and not
shared. Since that sharing is application visible and at application
discretion I would count COW pages as shared until they that sharing
is broken, and then I would count them as private pages.
The principle is that you don't find the ``owner'' of a page and
charge the page to the ``owner''. Instead you find the users
of a page and charge all of them for the page exactly once.
By and large most of that usage comes from pages in the page tables
so they are the most interesting items to count.
Things like file descriptors, inodes, page tables and other kernel
memory are interesting but are generally overshadowed by the page
table users, and generally kernel data structures don't have reverse
maps which makes it difficult to charge all of the users.
So I think the counting should be primarily about what is mapped into
the page tables. But other things can be added as is appropriate or
easy.
The practical effect should be that an application that needs more
pages than it's specified RSS to avoid thrashing should thrash but
it shouldn't take the rest of the system with it.
The biggest instance of system memory that an application does not
seem to have true control over is the page cache. Some kind of limit
that prevents one application from destroying everything another
application doing seems interesting. But I expect the solution there
are I/O limits and not memory limits.
Eric
On Tue, Oct 10, 2006 at 08:13:49PM -0700, Badari Pulavarty wrote:
> Hi Ted,
>
> e2fsprogs-1.39-tyt1-rollup.patch doesn't compile. (seems to be missing
> percent.c). Can
> you role up new version ? I had to apply individual patches to get it
> working ..
OK, fixed. I've also created a slightly new structure in:
ftp://ftp.kernel.org/pub/linux/kernel/people/tytso/e2fsprogs-interim
Each new version will be its own directory, i.e., e2fsprogs-1.39-tyt1,
with a symlink LATEST pointing at the most recent directory.
Within each directory, there will be a tarball of the complete
sources, as requested by akpm, as well a broken-out tar.gz file and a
single file that has all of the patches rolled up. I've regenerated
the rollup patches this time with feeling (and the -N diff option :-),
so once the new structure gets mirrored out from master.kernel.org to
ftp.kernel.org, you should be able to get the fixed rollup patch, as
well as a pre-patched tarball.
Regards,
- Ted
On Wed, 2006-10-11 at 06:07 -0600, Eric W. Biederman wrote:
> Arjan van de Ven <[email protected]> writes:
>
> > On Tue, 2006-10-10 at 17:54 -0600, Eric W. Biederman wrote:
> >
> >> For processes shared pages are not special.
>
> Actually the above is not quite true you can map a shared page twice
> into the same process but in practice it rarely happens.
yeah I'm entirely fine with ignoring that case (or making the person who
does it pay for it :)
>
> > depends on what question you want to answer with RSS.
> > If the question is "workload working set size" then you are right. If
> > the question is "how much ram does my application cause to be used" the
> > answer is FAR less clear....
>
> There are two basic concerns. How do you keep an application from
> going crazy and trashing the rest of your system? A question on what
> number do you need to implement a resource limit.
yet at the same time if 2 apps mmap a shared file, and app 1 keeps it in
pagecache, it doesn't cause app2 to trash, or rather, it's not like if
app 2 did NOT have the page from that file, the system wouldn't trash.
> > You seem to have an implicit definition on what RSS should mean; but
> > it's implicit. Mind making an explicit definition of what RSS should be
> > in your opinion? I think that's the biggest problem we have right now;
> > several people have different ideas about what it should/could be, and
> > as such we're not talking about the same thing. Lets first agree/specify
> > what it SHOULD mean, and then we can figure out what gets counted for
> > that ;)
>
> Well I tried to defined it in terms of what you can use it for.
>
> I would define the resident set size as the total number of bytes
> of physical RAM that a process (or set of processes) is using,
> irrespective of the rest of the system.
>
>
> So I think the counting should be primarily about what is mapped into
> the page tables. But other things can be added as is appropriate or
> easy.
>
> The practical effect should be that an application that needs more
> pages than it's specified RSS to avoid thrashing should thrash but
> it shouldn't take the rest of the system with it.
so by your definition, hugepages are part of RSS.
Ken: what is your definition of RSS ?
Arjan van de Ven wrote on Wednesday, October 11, 2006 6:55 AM
> > Well I tried to defined it in terms of what you can use it for.
> >
> > I would define the resident set size as the total number of bytes
> > of physical RAM that a process (or set of processes) is using,
> > irrespective of the rest of the system.
> >
> > So I think the counting should be primarily about what is mapped into
> > the page tables. But other things can be added as is appropriate or
> > easy.
> >
> > The practical effect should be that an application that needs more
> > pages than it's specified RSS to avoid thrashing should thrash but
> > it shouldn't take the rest of the system with it.
>
>
> so by your definition, hugepages are part of RSS.
>
> Ken: what is your definition of RSS ?
I'm more inclined to define RSS as "how much ram does my application
cause to be used". To monitor process's working set size, We already
have /proc/<pid>/smaps. Whether we can use working set size in an
intelligent way in mm is an interesting question. Though, so far such
accounting is not utilized at all.
- Ken
Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc1/2.6.19-rc1-mm1/
>
>
>
>
fsx seems to fail now, across several different machines.
http://test.kernel.org/functional/index.html
and drill down under "regression" on the failing ones.
eg, see end of
http://test.kernel.org/abat/54516/debug/test.log.1 (i386)
and
http://test.kernel.org/abat/54503/debug/test.log.1 (x86_64)
-rc1 is OK (as is -rc1-git7)
Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc1/2.6.19-rc1-mm1/
>
>
> -
>
Oh, and hangs in LTP.
x86_64 just hangs.
http://test.kernel.org/abat/54544/debug/test.log.1 (in something io-ish)
http://test.kernel.org/abat/54541/debug/test.log.1 (ppc64)
craps itself with
Modules linked in:
NIP: C0000000000CC520 LR: C0000000000CC4EC CTR: 0000000000000FF5
REGS: c00000069ae83940 TRAP: 0700 Not tainted (2.6.19-rc1-mm1-autokern1)
MSR: 8000000000029032 <EE,ME,IR,DR> CR: 28002424 XER: 20000000
TASK = c000000768026660[32160] 'openfile' THREAD: c00000069ae80000 CPU: 2
GPR00: 0000000000000001 C00000069AE83BC0 C00000000065E548 FFFFFFFFFFFFFFF4
GPR04: 00000000000000D0 0000000000000040 C0000006DF1D200A 0000000000000008
GPR08: 0000000000000001 0000000000000000 C00000003FFA3000 0000000000000000
GPR12: 000000000000F032 C00000000053E480 0000000000000000 0000000000000000
GPR16: 00000000100D5D40 00000000100CCFF8 00000000FF8352E0 00000000F800F7E0
GPR20: 00000000FF8352D0 0000000010000D38 0000000000000001 0000000000000003
GPR24: 00000000F67C9F80 FFFFFFFFFFFFFF9C C0000007750C4680 C0000007750C4690
GPR28: 0000000000000040 C000000775AF9CC0 C000000000570348 C000000775AF9CC0
NIP [C0000000000CC520] .expand_files+0x1f4/0x354
LR [C0000000000CC4EC] .expand_files+0x1c0/0x354
Call Trace:
[C00000069AE83BC0] [C0000000000CC470] .expand_files+0x144/0x354 (unreliable)
[C00000069AE83C60] [C0000000000AE148] .get_unused_fd+0x80/0x170
[C00000069AE83D00] [C0000000000AE6EC] .do_sys_open+0x5c/0x140
[C00000069AE83DB0] [C0000000000ED574] .compat_sys_open+0x24/0x38
[C00000069AE83E30] [C00000000000871C] syscall_exit+0x0/0x40
and another one from another ppc64 box
gekko-lp1 login:-- 0:conmux-control -- time-stamp -- Oct/10/06 9:38:14 --
cpu 0x3: Vector: 700 (Program Check) at [c0000000e9a43960]
pc: c0000000000f1454: .expand_files+0x1f4/0x354
lr: c0000000000f1420: .expand_files+0x1c0/0x354
sp: c0000000e9a43be0
msr: 8000000000029032
current = 0xc0000000e8b4a810
paca = 0xc000000000482b80
pid = 26003, comm = creat05
kernel BUG in copy_fdtable at fs/file.c:138!
enter ? for help
[c0000000e9a43c80] c0000000000d0af8 .get_unused_fd+0x80/0x170
[c0000000e9a43d20] c0000000000d1094 .do_sys_open+0x54/0x12c
[c0000000e9a43dc0] c0000000000161b8 .compat_sys_creat+0x14/0x28
[c0000000e9a43e30] c00000000000871c syscall_exit+0x0/0x40
--- Exception: c01 (System Call) at 000000000ff6e3b0
SP (ff9cf310) is in userspace
3:mon>-- 0:conmux-control -- time-stamp -- Oct/10/06 9:40:19 --
-- 0:conmux-control -- time-stamp -- Oct/10/06 9:48:51 --
On 11/10/06, Martin J. Bligh <[email protected]> wrote:
> Andrew Morton wrote:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc1/2.6.19-rc1-mm1/
> >
> >
> > -
> >
>
> Oh, and hangs in LTP.
It's probably a problem with fdtable patches
http://www.ussg.iu.edu/hypermail/linux/kernel/0610.1/0925.html
Regards,
Michal
--
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/)
On 10/10/06, Andrew Morton <[email protected]> wrote:
>
>
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc1/2.6.19-rc1-mm1/
>
>
> git-libata-all.patch
>
>
>
Hi
I think I've found a regression in the pata-via module. My cdrom drive isn't
detected I have compiled in and also tried as modules pata-via and the SCSI
CDROM device driver
I think the problem may be due to my cdrom not having a jumper setting
either master or slave (or even cable select for that matter) as I lost the
wee jumper.
Even if this is the case I'd still call this a regression as the old code
finds it no problem
My dmesg states:
pata_via 0000:00:0f.1: version 0.1.14
ata3: PATA max UDMA/133 cmd 0x1F0 ctl 0x3F6 bmdma 0xA400 irq 14
ata4: PATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0xA408 irq 15
scsi2 : pata_via
ata3.00: ATAPI, max UDMA/33
EXT3-fs: mounted filesystem with ordered data mode.
ata3.00: qc timeout (cmd 0xa1)
ata3.00: failed to IDENTIFY (I/O error, err_mask=0x4)
ata3.00: revalidation failed (errno=-5)
ata3.00: limiting speed to UDMA/25
ata3: failed to recover some devices, retrying in 5 secs
ata3.00: qc timeout (cmd 0xa1)
ata3.00: failed to IDENTIFY (I/O error, err_mask=0x4)
ata3.00: revalidation failed (errno=-5)
ata3: failed to recover some devices, retrying in 5 secs
ata3.00: qc timeout (cmd 0xa1)
ata3.00: failed to IDENTIFY (I/O error, err_mask=0x4)
ata3.00: revalidation failed (errno=-5)
ata3.00: disabled
scsi3 : pata_via
ATA: abnormal status 0x8 on port 0x177
Does anyone have any ideas on why this is the case?
Cheers for any help you can offer
Mike
PS Apologies for the 3rd time your receiving this andrew
On Wed, 11 Oct 2006 12:59:19 -0700
"Martin J. Bligh" <[email protected]> wrote:
> Andrew Morton wrote:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc1/2.6.19-rc1-mm1/
> >
> >
> > -
> >
>
> Oh, and hangs in LTP.
>
> x86_64 just hangs.
> http://test.kernel.org/abat/54544/debug/test.log.1 (in something io-ish)
>
What makes you thing it was something io-ish?
>
> http://test.kernel.org/abat/54541/debug/test.log.1 (ppc64)
> craps itself with
There's been a fix for this in hot-fixes/ for 24 hours. It'd be good if you
could tinkle the scripts to pull that directory in.
Or just suck the -mm git tree. That incorprates additions to hot-fixes/ within
five minutes.
Martin J. Bligh wrote:
> Andrew Morton wrote:
>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc1/2.6.19-rc1-mm1/
>>
>>
>>
>>
>>
> fsx seems to fail now, across several different machines.
>
> http://test.kernel.org/functional/index.html
>
>
> and drill down under "regression" on the failing ones.
>
> eg, see end of
> http://test.kernel.org/abat/54516/debug/test.log.1 (i386)
> and
> http://test.kernel.org/abat/54503/debug/test.log.1 (x86_64)
>
I am seeing fsx failures on 1k/2k ext3 filesystems, but not on 4k.
Do you know the filesystem type & blocksize ?
Thanks,
Badari
On Wed, Oct 11, 2006 at 10:15:39AM -0700, Chen, Kenneth W wrote:
> I'm more inclined to define RSS as "how much ram does my application
> cause to be used". To monitor process's working set size, We already
> have /proc/<pid>/smaps. Whether we can use working set size in an
> intelligent way in mm is an interesting question. Though, so far such
> accounting is not utilized at all.
If that is the case, it would make sense to account such things as page
tables and other kernel allocations against the RSS, which would be useful.
That said, it's possible to keep semantics fairly close to those currently
implemented by tracking RSS differently for shared vs private areas --
those vmas which are shared could be placed on a list and then summed when
RSS is read. That said, I'm not sure it is a good idea, as the cost of
obtaining RSS for tools like top is exactly why we have the current
counters maintained to provide O(1) semantics.
All of the old semantics are covered by smaps, though, so I'd agree with
any changes to make RSS reflect allocations incurred by this process.
-ben
--
"Time is of no importance, Mr. President, only life is important."
Don't Email: <[email protected]>.
Andrew Morton wrote:
> On Wed, 11 Oct 2006 12:59:19 -0700
> "Martin J. Bligh" <[email protected]> wrote:
>
>> Andrew Morton wrote:
>>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc1/2.6.19-rc1-mm1/
>>>
>>>
>>> -
>>>
>> Oh, and hangs in LTP.
>>
>> x86_64 just hangs.
>> http://test.kernel.org/abat/54544/debug/test.log.1 (in something io-ish)
>>
>
> What makes you thing it was something io-ish?
>
>> http://test.kernel.org/abat/54541/debug/test.log.1 (ppc64)
>> craps itself with
>
> There's been a fix for this in hot-fixes/ for 24 hours. It'd be good if you
> could tinkle the scripts to pull that directory in.
>
> Or just suck the -mm git tree. That incorprates additions to hot-fixes/ within
> five minutes.
I have to say I always forget its there, debug and fix it only to find
its in hotfixes, grr. So having the test system notice and fire new
jobs off with these too is the Right Thing (tm).
I've hopefully modified the test system to take hot-fixes into account.
I do wonder if there should be a series file in this directory, as we
have no ordering otherwise and it would simplify the detection and
application of these patches at my end for sure.
Anyhow, hopefully we'll get some results in the next 4 hours out to TKO
and see how it looks ... assuming they don't all go "what patch, boom,
crash".
-apw
I found an easy way to hang the kernel when copying a SD-card:
dd if=/dev/sdc of=file bs=1048576
I.e. copy the entire 256MB card in 1MB chunks. I got about
160MB before the kernel hung. Not even sysrq+B worked, I needed
the reset button. The pc has a total of 512MB memory if that matters.
Using bs=4096 instead let me copy the entire card with no problems,
but that seems to progress slower.
The above 'dd' command hangs my office pc every time. So I can repeat
it for debugging purposes.
Helge Hafting
On Wed, 2006-10-11 at 14:47 -0700, Andrew Morton wrote:
> On Wed, 11 Oct 2006 12:59:19 -0700
> "Martin J. Bligh" <[email protected]> wrote:
>
> > Andrew Morton wrote:
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc1/2.6.19-rc1-mm1/
> > >
> > >
> > > -
> > >
> >
> > Oh, and hangs in LTP.
> >
> > x86_64 just hangs.
> > http://test.kernel.org/abat/54544/debug/test.log.1 (in something io-ish)
> >
>
> What makes you thing it was something io-ish?
create05 test hang goes away with hot-fix (revert-fd-table stuff).
FYI.
Thanks,
Badari
On Thu, 12 Oct 2006 14:18:04 +0200
Helge Hafting <[email protected]> wrote:
> I found an easy way to hang the kernel when copying a SD-card:
>
> dd if=/dev/sdc of=file bs=1048576
>
> I.e. copy the entire 256MB card in 1MB chunks. I got about
> 160MB before the kernel hung. Not even sysrq+B worked, I needed
> the reset button. The pc has a total of 512MB memory if that matters.
>
> Using bs=4096 instead let me copy the entire card with no problems,
> but that seems to progress slower.
>
> The above 'dd' command hangs my office pc every time. So I can repeat
> it for debugging purposes.
>
What device driver is providing /dev/sdc?
Did any previous kernels work correctly? If so, which?
On Tue, 10 Oct 2006 00:09:28 PDT, Andrew Morton said:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc1/2.6.19-rc1-mm1/
> - Added the high-resolution timers and dynamic-ticks code. Please be sure
> to cc [email protected]>, [email protected] and [email protected] if it blows
> up.
Compiles, boots, and behaves on my Dell Latitude C840 that previously had
indigestion. It selected the ACPI-PM timesource right off the bat (for reasons
I don't understand, previous dynticks used the tsc timesource), so I'm not
seeing the huge clock drift issues I had with previous dyntick patches when
running 'cpuspeed' - it drops from 1.6Ghz to 1.2Ghz and back without a problem.
On Thursday 12 October 2006 11:09, Badari Pulavarty wrote:
> create05 test hang goes away with hot-fix (revert-fd-table stuff).
> FYI.
Does it also go away with the "Eradicate fdarray overflow" patch instead of
the hot-fix?
> Thanks,
> Badari
-- Vadim Lobanov
On Thu, 2006-10-12 at 11:52 -0700, Vadim Lobanov wrote:
> On Thursday 12 October 2006 11:09, Badari Pulavarty wrote:
> > create05 test hang goes away with hot-fix (revert-fd-table stuff).
> > FYI.
>
> Does it also go away with the "Eradicate fdarray overflow" patch instead of
> the hot-fix?
I just verified. Test hang goes away with your overflow fix.
Thanks,
Badari
Andrew Morton wrote:
> On Thu, 12 Oct 2006 14:18:04 +0200
> Helge Hafting <[email protected]> wrote:
>
>
>> I found an easy way to hang the kernel when copying a SD-card:
>>
>> dd if=/dev/sdc of=file bs=1048576
>>
>> I.e. copy the entire 256MB card in 1MB chunks. I got about
>> 160MB before the kernel hung. Not even sysrq+B worked, I needed
>> the reset button. The pc has a total of 512MB memory if that matters.
>>
>> Using bs=4096 instead let me copy the entire card with no problems,
>> but that seems to progress slower.
>>
>> The above 'dd' command hangs my office pc every time. So I can repeat
>> it for debugging purposes.
>>
>>
>
> What device driver is providing /dev/sdc?
>
It is an usb card reader, so it is "usb mass storage"
and "scsi disk".
> Did any previous kernels work correctly? If so, which?
>
I just got that card reader, so I haven't tested any earlier kernels.
I have another machine with a card reader, which I have used for
a long time. But I only ever copy files with "cp" on that one.
This time I used "dd" to get an image of the entire card, and got trouble
when using 1M chunks.
I can try with verbose scsi debug messages if that might help?
Helge Hafting
On Fri, 13 Oct 2006 15:11:11 +0200
Helge Hafting <[email protected]> wrote:
> Andrew Morton wrote:
> > On Thu, 12 Oct 2006 14:18:04 +0200
> > Helge Hafting <[email protected]> wrote:
> >
> >
> >> I found an easy way to hang the kernel when copying a SD-card:
> >>
> >> dd if=/dev/sdc of=file bs=1048576
> >>
> >> I.e. copy the entire 256MB card in 1MB chunks. I got about
> >> 160MB before the kernel hung. Not even sysrq+B worked, I needed
> >> the reset button. The pc has a total of 512MB memory if that matters.
> >>
> >> Using bs=4096 instead let me copy the entire card with no problems,
> >> but that seems to progress slower.
> >>
> >> The above 'dd' command hangs my office pc every time. So I can repeat
> >> it for debugging purposes.
> >>
> >>
> >
> > What device driver is providing /dev/sdc?
> >
> It is an usb card reader, so it is "usb mass storage"
> and "scsi disk".
> > Did any previous kernels work correctly? If so, which?
> >
>
> I just got that card reader, so I haven't tested any earlier kernels.
> I have another machine with a card reader, which I have used for
> a long time. But I only ever copy files with "cp" on that one.
>
> This time I used "dd" to get an image of the entire card, and got trouble
> when using 1M chunks.
>
> I can try with verbose scsi debug messages if that might help?
>
Maybe. The first step is to tell the developers. (adds cc).
On Fri, 13 Oct 2006, Andrew Morton wrote:
> On Fri, 13 Oct 2006 15:11:11 +0200
> Helge Hafting <[email protected]> wrote:
>
> > Andrew Morton wrote:
> > > On Thu, 12 Oct 2006 14:18:04 +0200
> > > Helge Hafting <[email protected]> wrote:
> > >
> > >
> > >> I found an easy way to hang the kernel when copying a SD-card:
> > >>
> > >> dd if=/dev/sdc of=file bs=1048576
> > >>
> > >> I.e. copy the entire 256MB card in 1MB chunks. I got about
> > >> 160MB before the kernel hung. Not even sysrq+B worked, I needed
> > >> the reset button. The pc has a total of 512MB memory if that matters.
> > >>
> > >> Using bs=4096 instead let me copy the entire card with no problems,
> > >> but that seems to progress slower.
> > >>
> > >> The above 'dd' command hangs my office pc every time. So I can repeat
> > >> it for debugging purposes.
> > >>
> > >>
> > >
> > > What device driver is providing /dev/sdc?
> > >
> > It is an usb card reader, so it is "usb mass storage"
> > and "scsi disk".
> > > Did any previous kernels work correctly? If so, which?
> > >
> >
> > I just got that card reader, so I haven't tested any earlier kernels.
> > I have another machine with a card reader, which I have used for
> > a long time. But I only ever copy files with "cp" on that one.
> >
> > This time I used "dd" to get an image of the entire card, and got trouble
> > when using 1M chunks.
> >
> > I can try with verbose scsi debug messages if that might help?
Verbose usb-storage debugging messages would help more
(CONFIG_USB_STORAGE_DEBUG and CONFIG_USB_DEBUG). If the kernel hangs very
badly you might need to use a serial console to capture all the logging
information.
Alan Stern
Badari Pulavarty wrote:
> Martin J. Bligh wrote:
>> Andrew Morton wrote:
>>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc1/2.6.19-rc1-mm1/
>>>
>>>
>>>
>>>
>>>
>> fsx seems to fail now, across several different machines.
>>
>> http://test.kernel.org/functional/index.html
>>
>>
>> and drill down under "regression" on the failing ones.
>>
>> eg, see end of
>> http://test.kernel.org/abat/54516/debug/test.log.1 (i386)
>> and
>> http://test.kernel.org/abat/54503/debug/test.log.1 (x86_64)
>>
>
> I am seeing fsx failures on 1k/2k ext3 filesystems, but not on 4k.
> Do you know the filesystem type & blocksize ?
Ok. I've been poking at these results to try and get you these answers.
In the process I noted that the benchmark was recently reviewed and
overhauled. Looking at the changes it looks like we are now reporting
the results from some tests which are backgrounded for additional load,
which would not have previously been reported. So this might not be a
new phenomenon. We have some stable tests coming through now, so I
should be able to use them as a reference to be sure.
Here are the ones which are failing currently, note that the 139 at the
start is the exit status as reported by the shell, so SIGSEGV:
bl6-13: x86_64 ext3
-------------------
139 ./fsx-linux -l 500000 -r 4096 -t 2048 -w 2048 -Z -R -W -N 10000
test/junkfile
139 ./fsx-linux -N 10000 -o 128000 -A -l 500000 -r 512 -t 4096 -w 1024
-Z -R -W test/junkfile
elm3b239: x86_64 reiserfs
-------------------------
139 ./fsx-linux -N 10000 -o 8192 -A -l 500000 -r 1024 -t 2048 -w 2048 -Z
-R -W test/junkfile
139 ./fsx-linux -N 10000 -o 128000 -r 2048 -w 4096 -Z -R -W test/junkfile
139 ./fsx-linux -N 10000 -o 8192 -A -l 500000 -r 1024 -t 2048 -w 1024 -Z
-R -W test/junkfile
I have also seen the following style messages on 19-rc1-mm1:
short write: 0x15000 bytes instead of 0xf000
Note that this really does mean a _long_ write!
-apw
Alan Stern wrote:
> Verbose usb-storage debugging messages would help more
> (CONFIG_USB_STORAGE_DEBUG and CONFIG_USB_DEBUG). If the kernel hangs very
> badly you might need to use a serial console to capture all the logging
> information.
>
Version information first: This is 2.6.19-rc1, not mm1. I apparently
forgot to apply the mm1 patch before compiling it.
I got a BUG, which I could write down by getting X out of the way first.
It is repeatable, just ask if I omitted something cruical. On bootup,
the verbose debugging complains about read errors on sdc,
I guess the kernel tries to get the partition table. I have no idea
why there is read errors - that shouldn't hang anything though.
To bring it down:
dd if=/dev/sdc of=sdc.dump bs=1M
sd 0:0:0:2 ioctl_internal_command return code: 8000002
:Current: Sense key: Hardware Error
Additional Sense: End_of_data detected
cut here----
Kernel BUG at [Verbose debugging unavailable]
invalid opcode: 0000 [#1]
cpu:0
EIP: 0060:[<c031f823>] Not tainted VLI
Eflags: 00010002 (2.6.16-rc1 #16)
EIP is at start_unlink_async
eax:00000000 ebx:dfe69180 ecx:e0832020 edx:00000005
esi:dffdb6bc edi:00010021 ebp:dffdb6bc esp:c0664d58
ds:007b es:007b ss:0068
Process swapper . . .
stack . . .
Call trace
ehci_urb_dequeue
unlink1
usb_hcd_unlink_urb
sg_complete
usb_hcd_giveback_urb
qh_completions
ehci_work
ehci_irq
usb_hcd_irq
handle_IRQ_event
handle_fasteoi_irq
do_IRQ
Code 5d e9 8e 31 ff ff f6 43 28 01 75 b8 c7 43 24 00 00 00 00 eb af . . .
<0>Kernel Panic - not syncing fatal exception in interrupt
<0>Rebooting in 300 seconds
It did reboot in 300 seconds, I had to crash twice to get this much written down.
I checked that stuff written down the first time was identical.
Invalid opcode suggest a compiler bug or memory scribble, or possibly
calling a bad function pointer. The crash is trivial to reproduce,
just ask me.
In case it matters:
$ lspci
00:00.0 Host bridge: Silicon Integrated Systems [SiS] SiS645DX Host & Memory & AGP Controller
00:01.0 PCI bridge: Silicon Integrated Systems [SiS] Virtual PCI-to-PCI bridge (AGP)
00:02.0 ISA bridge: Silicon Integrated Systems [SiS] SiS962 [MuTIOL Media IO] (rev 04)
00:02.1 SMBus: Silicon Integrated Systems [SiS] SiS961/2 SMBus Controller
00:02.5 IDE interface: Silicon Integrated Systems [SiS] 5513 [IDE]
00:02.7 Multimedia audio controller: Silicon Integrated Systems [SiS] AC'97 Sound Controller (rev a0)
00:03.0 USB Controller: Silicon Integrated Systems [SiS] USB 1.0 Controller (rev 0f)
00:03.1 USB Controller: Silicon Integrated Systems [SiS] USB 1.0 Controller (rev 0f)
00:03.2 USB Controller: Silicon Integrated Systems [SiS] USB 1.0 Controller (rev 0f)
00:03.3 USB Controller: Silicon Integrated Systems [SiS] USB 2.0 Controller
00:0b.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado] (rev 78)
00:0c.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
01:00.0 VGA compatible controller: ATI Technologies Inc Radeon RV100 QY [Radeon 7000/VE]
Helge
On Wed, 18 Oct 2006, Helge Hafting wrote:
> Alan Stern wrote:
> > Verbose usb-storage debugging messages would help more
> > (CONFIG_USB_STORAGE_DEBUG and CONFIG_USB_DEBUG). If the kernel hangs very
> > badly you might need to use a serial console to capture all the logging
> > information.
> >
> Version information first: This is 2.6.19-rc1, not mm1. I apparently
> forgot to apply the mm1 patch before compiling it.
>
> I got a BUG, which I could write down by getting X out of the way first.
> It is repeatable, just ask if I omitted something cruical. On bootup,
> the verbose debugging complains about read errors on sdc,
> I guess the kernel tries to get the partition table. I have no idea
> why there is read errors - that shouldn't hang anything though.
That's why I asked for the USB debugging logs (which you forgot to include
here).
> To bring it down:
>
> dd if=/dev/sdc of=sdc.dump bs=1M
>
> sd 0:0:0:2 ioctl_internal_command return code: 8000002
> :Current: Sense key: Hardware Error
> Additional Sense: End_of_data detected
> cut here----
> Kernel BUG at [Verbose debugging unavailable]
> invalid opcode: 0000 [#1]
> cpu:0
> EIP: 0060:[<c031f823>] Not tainted VLI
> Eflags: 00010002 (2.6.16-rc1 #16)
Hmmm. Well, a recent patch affecting that area was just reverted because
it added some problems. Maybe you're seeing those same problems.
Although I don't think they involved invalid opcode errors...
You're the second person I've seen report invalid opcode errors in the
recent kernels. The other report involved uhci-hcd, not ehci-hcd. See
here:
http://marc.theaimsgroup.com/?l=linux-usb-users&m=115942141207661&w=2
It's possible that both of these are caused by something unrelated
overwriting kernel memory.
By the way, what happens if you add a "skip=" argument to dd so that the
copy begins near the end of the device? Does the oops then occur that
much sooner?
Oh, and the next time this happens, could you copy down all of the code
bytes from the oops message? And also provide the section from "objdump
-d drivers/usb/host/ehci-hcd.o" for the start_unlink_async routine?
Alan Stern
00000fed <start_unlink_async>:
fed: 57 push %edi
fee: 56 push %esi
fef: 53 push %ebx
ff0: 83 ec 10 sub $0x10,%esp
ff3: 89 c6 mov %eax,%esi
ff5: 89 d3 mov %edx,%ebx
ff7: 8b 48 04 mov 0x4(%eax),%ecx
ffa: 8b 39 mov (%ecx),%edi
ffc: 8b 40 14 mov 0x14(%eax),%eax
fff: 85 c0 test %eax,%eax
1001: 74 6f je 1072 <start_unlink_async+0x85>
1003: 0f 0b ud2a
1005: 39 5e 10 cmp %ebx,0x10(%esi)
1008: 74 78 je 1082 <start_unlink_async+0x95>
100a: c6 43 68 02 movb $0x2,0x68(%ebx)
100e: 8d 43 60 lea 0x60(%ebx),%eax
1011: e8 fc ff ff ff call 1012 <start_unlink_async+0x25>
1016: 89 5e 14 mov %ebx,0x14(%esi)
1019: 8b 4e 10 mov 0x10(%esi),%ecx
101c: 8b 41 48 mov 0x48(%ecx),%eax
101f: 39 c3 cmp %eax,%ebx
1021: 74 09 je 102c <start_unlink_async+0x3f>
1023: 89 c1 mov %eax,%ecx
1025: 8b 40 48 mov 0x48(%eax),%eax
1028: 39 c3 cmp %eax,%ebx
102a: 75 f7 jne 1023 <start_unlink_async+0x36>
102c: 8b 03 mov (%ebx),%eax
102e: 89 01 mov %eax,(%ecx)
1030: 8b 43 48 mov 0x48(%ebx),%eax
1033: 89 41 48 mov %eax,0x48(%ecx)
1036: 8b 46 fc mov 0xfffffffc(%esi),%eax
1039: 85 c0 test %eax,%eax
103b: 0f 84 83 00 00 00 je 10c4 <start_unlink_async+0xd7>
1041: 8b 46 04 mov 0x4(%esi),%eax
1044: 83 cf 40 or $0x40,%edi
1047: 89 38 mov %edi,(%eax)
1049: 8b 46 04 mov 0x4(%esi),%eax
104c: 8b 00 mov (%eax),%eax
104e: 8b 86 84 00 00 00 mov 0x84(%esi),%eax
1054: 85 c0 test %eax,%eax
1056: 75 41 jne 1099 <start_unlink_async+0xac>
1058: 8b 15 00 00 00 00 mov 0x0,%edx
105e: 8d 86 84 00 00 00 lea 0x84(%esi),%eax
1064: 83 c2 0a add $0xa,%edx
1067: 83 c4 10 add $0x10,%esp
106a: 5b pop %ebx
106b: 5e pop %esi
106c: 5f pop %edi
106d: e9 fc ff ff ff jmp 106e <start_unlink_async+0x81>
1072: 0f b6 52 68 movzbl 0x68(%edx),%edx
1076: 80 fa 01 cmp $0x1,%dl
1079: 74 8a je 1005 <start_unlink_async+0x18>
107b: 80 fa 04 cmp $0x4,%dl
107e: 75 83 jne 1003 <start_unlink_async+0x16>
1080: eb 83 jmp 1005 <start_unlink_async+0x18>
1082: 8b 56 fc mov 0xfffffffc(%esi),%edx
1085: 85 d2 test %edx,%edx
1087: 74 09 je 1092 <start_unlink_async+0xa5>
1089: 85 c0 test %eax,%eax
108b: 90 nop
108c: 8d 74 26 00 lea 0x0(%esi),%esi
1090: 74 3e je 10d0 <start_unlink_async+0xe3>
1092: 83 c4 10 add $0x10,%esp
1095: 5b pop %ebx
1096: 5e pop %esi
1097: 5f pop %edi
1098: c3 ret
1099: c7 44 24 0c 65 00 00 movl $0x65,0xc(%esp)
10a0: 00
10a1: c7 44 24 08 78 00 00 movl $0x78,0x8(%esp)
10a8: 00
10a9: c7 44 24 04 00 00 00 movl $0x0,0x4(%esp)
10b0: 00
10b1: c7 04 24 18 00 00 00 movl $0x18,(%esp)
10b8: e8 fc ff ff ff call 10b9 <start_unlink_async+0xcc>
10bd: e8 fc ff ff ff call 10be <start_unlink_async+0xd1>
10c2: eb 94 jmp 1058 <start_unlink_async+0x6b>
10c4: 31 d2 xor %edx,%edx
10c6: 89 f0 mov %esi,%eax
10c8: 83 c4 10 add $0x10,%esp
10cb: 5b pop %ebx
10cc: 5e pop %esi
10cd: 5f pop %edi
10ce: eb 0f jmp 10df <end_unlink_async>
10d0: 83 e7 df and $0xffffffdf,%edi
10d3: 89 39 mov %edi,(%ecx)
10d5: 0f ba b6 b4 00 00 00 btrl $0x2,0xb4(%esi)
10dc: 02
10dd: eb b3 jmp 1092 <start_unlink_async+0xa5>
On Thu, 19 Oct 2006, Helge Hafting wrote:
> Alan Stern wrote:
> > On Wed, 18 Oct 2006, Helge Hafting wrote:
> >
> [...]
> > That's why I asked for the USB debugging logs (which you forgot to include
> > here).
> >
> Attached dmesg.gz with lots of usb messages.
But no messages from the time just before the BUG occurred. :-(
> >> To bring it down:
> >>
> >> dd if=/dev/sdc of=sdc.dump bs=1M
> >>
> This time, it seems to have crashed on the first megabyte.
> I mounted the filesystem synchronously, and still I had 0 bytes
> in the dumpfile. The crash also came with no delay after
> pressing enter.
>
> > It's possible that both of these are caused by something unrelated
> > overwriting kernel memory.
> >
> something like a function pointer mistaken for a data pointer?
After looking at the debugging output, no. That "invalid opcode" is a red
herring. What you encountered this time was a BUG() in the source code of
start_unlink_async() in drivers/usb/host/ehci-q.c:
#ifdef DEBUG
assert_spin_locked(&ehci->lock);
if (ehci->reclaim
|| (qh->qh_state != QH_STATE_LINKED
&& qh->qh_state != QH_STATE_UNLINK_WAIT)
)
BUG ();
#endif
You could try putting a printk() just before the BUG() to display the
values of ehci->reclaim and qh->qh_state. Maybe also change the BUG() to
WARN(), which might help prevent your system from crashing so badly.
Monty has been making changes to this driver recently; maybe he has some
ideas about the problem.
Alan Stern
On 10/19/06, Alan Stern <[email protected]> wrote:
> Monty has been making changes to this driver recently; maybe he has some
> ideas about the problem.
I have been watching the thread worried that this is due to a change
I've made. However, I should not have done anything to change
handling on the async queue-- at least, I've not made any changes
intentionally, which is not the same thing as not making any changes.
I'll also be interested to see the result of the additional debug message.
Monty
Alan Stern wrote:
[...]
> After looking at the debugging output, no. That "invalid opcode" is a red
> herring. What you encountered this time was a BUG() in the source code of
> start_unlink_async() in drivers/usb/host/ehci-q.c:
>
> #ifdef DEBUG
> assert_spin_locked(&ehci->lock);
> if (ehci->reclaim
> || (qh->qh_state != QH_STATE_LINKED
> && qh->qh_state != QH_STATE_UNLINK_WAIT)
> )
> BUG ();
> #endif
>
> You could try putting a printk() just before the BUG() to display the
> values of ehci->reclaim and qh->qh_state. Maybe also change the BUG() to
>
ehci->reclaim=0
qh->qh_state=5
> WARN(), which might help prevent your system from crashing so badly.
>
WARN didn't help much. I then got the warning twice, followed by
another BUG:
process klogd
ehci_irq
usb_hcd_irq
handle_IRQ_event
handle_fasteio_irq
do_IRQ
So I set it back to BUG. Crashing hard isn't so bad when I
know what is coming - I simply remount everything synchronously
before trying.
I hope these printk's help. I can add more of them too, if needed.
Big transfers seems to bring out the worst - I always get the
crash on the first megabyte now.
During boot I get lots of those "Hardware error, end-of-data detected"
messages, but I've never seen it crash during bootup.
Helge Hafting
On Fri, 20 Oct 2006, Helge Hafting wrote:
> Alan Stern wrote:
> [...]
> > After looking at the debugging output, no. That "invalid opcode" is a red
> > herring. What you encountered this time was a BUG() in the source code of
> > start_unlink_async() in drivers/usb/host/ehci-q.c:
> >
> > #ifdef DEBUG
> > assert_spin_locked(&ehci->lock);
> > if (ehci->reclaim
> > || (qh->qh_state != QH_STATE_LINKED
> > && qh->qh_state != QH_STATE_UNLINK_WAIT)
> > )
> > BUG ();
> > #endif
> >
> > You could try putting a printk() just before the BUG() to display the
> > values of ehci->reclaim and qh->qh_state. Maybe also change the BUG() to
> >
> ehci->reclaim=0
> qh->qh_state=5
5 is QH_STATE_COMPLETING. That explains why the BUG() fires.
At this point it's beyond me. Monty will have to take it from here.
> During boot I get lots of those "Hardware error, end-of-data detected"
> messages, but I've never seen it crash during bootup.
Those messages are from the card reader. It doesn't seem to be working
right. It returns the "end-of-data" error in response to a PREVENT MEDIUM
REMOVAL command and it returns a phase error in response to a READ
command. In spite of the fact that it claims to have a 256 MB card
present.
Alan Stern
On Tue, 2006-10-10 at 14:52 -0700, Andrew Morton wrote:
> On Tue, 10 Oct 2006 23:44:04 +0200
> "Michal Piotrowski" <[email protected]> wrote:
>
> > BTW. Kernel hangs while running Cyclictest
> > (http://rt.wiki.kernel.org/index.php/Cyclictest)
> > cyclictest -t 10 -l 100000
> > (or "bin/autotest tests/cyclictest/control" in autotest). I don't see
> > nothing special on tty (currently my sysklogd is broken, FC6
> > problem..)
Michal,
is this on a SMP box ?
tglx
Alan Stern wrote:
>>> You could try putting a printk() just before the BUG() to display the
>>> values of ehci->reclaim and qh->qh_state. Maybe also change the BUG() to
>>>
>>>
>> ehci->reclaim=0
>> qh->qh_state=5
>>
>
> 5 is QH_STATE_COMPLETING. That explains why the BUG() fires.
>
> At this point it's beyond me. Monty will have to take it from here.
>
>
>> During boot I get lots of those "Hardware error, end-of-data detected"
>> messages, but I've never seen it crash during bootup.
>>
>
> Those messages are from the card reader. It doesn't seem to be working
> right. It returns the "end-of-data" error in response to a PREVENT MEDIUM
> REMOVAL command
Unlike a cdrom, it doesn't have the means to prevent media removal. :-)
> and it returns a phase error in response to a READ
> command. In spite of the fact that it claims to have a 256 MB card
> present.
>
It has slots for several different cards, all the other
slots are empty.
Perhaps it is broken, but interesting as a "stress-test".
Linux should not crash because of a bad usb thing, just complain.
Helge Hafting
On Mon, 23 Oct 2006, Helge Hafting wrote:
> >> During boot I get lots of those "Hardware error, end-of-data detected"
> >> messages, but I've never seen it crash during bootup.
> >>
> >
> > Those messages are from the card reader. It doesn't seem to be working
> > right. It returns the "end-of-data" error in response to a PREVENT MEDIUM
> > REMOVAL command
> Unlike a cdrom, it doesn't have the means to prevent media removal. :-)
There's nothing wrong with that; lots of devices don't have the means to
prevent media removal. The proper response is "Invalid Command", not "End
of Data". If the device sent the proper reply you wouldn't get all those
"Hardware error, end-of-data detected" messages in the log.
> > and it returns a phase error in response to a READ
> > command. In spite of the fact that it claims to have a 256 MB card
> > present.
> >
> It has slots for several different cards, all the other
> slots are empty.
Were all the slots empty? If yes, the reader should not have indicated a
card was present in that slot. If no, the reader should have returned the
data from the card instead of a phase error. Either way, it misbehaved.
> Perhaps it is broken, but interesting as a "stress-test".
> Linux should not crash because of a bad usb thing, just complain.
Linux did not crash because of the bad reader; it crashed because of an
unrelated bug in ehci-hcd. (Although it's possible that the bug was
triggered by the error-recovery for the bad reader.)
Alan Stern
On 10/20/06, Alan Stern <[email protected]> wrote:
> At this point it's beyond me. Monty will have to take it from here.
I will look more closely at what might have changed there. Despite
the code refactoring (and a hand-resolved patch collision at that
point) the async disable handling *should* have been functionally
unchanged from 2.6.18. I will revisit that closely.
Has it actually been demonstrated that this does not crash 2.6.18
(pre-my-patches) kernels? If it crashes earlier, that doesn't mean
I'm uninterested in fixing it, I just want to know. I don't think
that had been explicitly answered earlier in the thread.
Monty
Christopher "Monty" Montgomery wrote:
> On 10/20/06, Alan Stern <[email protected]> wrote:
>> At this point it's beyond me. Monty will have to take it from here.
>
> I will look more closely at what might have changed there. Despite
> the code refactoring (and a hand-resolved patch collision at that
> point) the async disable handling *should* have been functionally
> unchanged from 2.6.18. I will revisit that closely.
>
> Has it actually been demonstrated that this does not crash 2.6.18
> (pre-my-patches) kernels?
I just tested this. 2.6.18 does not crash. I still get tons of errors,
and no data. Copying using 1MB chunks or 4kB chunks
don't matter, it doesn't work. So card, reader or driver must be faulty.
The card works in a windows machine though.
2.6.19-rc1 gets data with 4kB chunks, and BUGs with 1M chunks.
> If it crashes earlier, that doesn't mean
> I'm uninterested in fixing it, I just want to know. I don't think
> that had been explicitly answered earlier in the thread.
2.6.18 wasn't tried before, the reason being I did not have this
card reader when 2.6.18 was current.
dmesg output for 2.6.18 (after the dd attempts) is attached. I have
edited out stuff that isn't usb or scsi.
Helge Hafting
On Tue, 24 Oct 2006, Helge Hafting wrote:
> I just tested this. 2.6.18 does not crash. I still get tons of errors,
> and no data. Copying using 1MB chunks or 4kB chunks
> don't matter, it doesn't work. So card, reader or driver must be faulty.
> The card works in a windows machine though.
>
> 2.6.19-rc1 gets data with 4kB chunks, and BUGs with 1M chunks.
It would be interesting to compare 2.6.18 with 2.6.19-rc to see why the
first gets only errors while the second is able to transfer some data
using 4 KB chunks.
(By the way, what do you mean by 4 KB chunks or 1 MB chunks? Does this
refer to the bs= option for dd? That has almost nothing to do with the
size of the transfers actually sent to the device.)
But the log will be useless unless you turn on CONFIG_USB_STORAGE_DEBUG.
Alan Stern