ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm1/
- Somebody broke it on my powerpc G5, but I didn't have time to do yet
another bisection yet.
- There's a lengthy patch series here from Nick which attempts to address
the longstanding pagefault-vs-buffered-write deadlock.
A great shower of filesystems were broken and have been disabled with
CONFIG_BROKEN. This includes reiser4.
- Complex patches which eliminate the kernel's fixed size limit on the
command-line length. These break nommu builds.
Boilerplate:
- See the `hot-fixes' directory for any important updates to this patchset.
- To fetch an -mm tree using git, use (for example)
git-fetch git://git.kernel.org/pub/scm/linux/kernel/git/smurf/linux-trees.git tag v2.6.16-rc2-mm1
git-checkout -b local-v2.6.16-rc2-mm1 v2.6.16-rc2-mm1
- -mm kernel commit activity can be reviewed by subscribing to the
mm-commits mailing list.
echo "subscribe mm-commits" | mail [email protected]
- If you hit a bug in -mm and it is not obvious which patch caused it, it is
most valuable if you can perform a bisection search to identify which patch
introduced the bug. Instructions for this process are at
http://www.zip.com.au/~akpm/linux/patches/stuff/bisecting-mm-trees.txt
But beware that this process takes some time (around ten rebuilds and
reboots), so consider reporting the bug first and if we cannot immediately
identify the faulty patch, then perform the bisection search.
- When reporting bugs, please try to Cc: the relevant maintainer and mailing
list on any email.
- When reporting bugs in this kernel via email, please also rewrite the
email Subject: in some manner to reflect the nature of the bug. Some
developers filter by Subject: when looking for messages to read.
- Occasional snapshots of the -mm lineup are uploaded to
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/mm/ and are announced on
the mm-commits list.
Changes since 2.6.21-rc3-mm1:
git-acpi.patch
git-alsa.patch
git-arm-master.patch
git-arm.patch
git-avr32.patch
git-cifs.patch
git-cpufreq.patch
git-drm.patch
git-dvb.patch
git-gfs2-nmw.patch
git-hid.patch
git-ieee1394.patch
git-infiniband.patch
git-input.patch
git-kbuild.patch
git-kvm.patch
git-leds.patch
git-libata-all.patch
git-md-accel.patch
git-mips.patch
git-mmc.patch
git-ubi.patch
git-netdev-all.patch
git-net.patch
git-backlight.patch
git-battery.patch
git-ioat.patch
git-nfs.patch
git-nfs-server-cluster-locking-api.patch
git-ocfs2.patch
git-parisc.patch
git-r8169.patch
git-selinux.patch
git-s390.patch
git-sh.patch
git-scsi-misc.patch
git-scsi-rc-fixes.patch
git-scsi-target.patch
git-unionfs.patch
git-watchdog.patch
git-wireless.patch
git-ipwireless_cs.patch
git-newsetup.patch
git-xfs.patch
git-cryptodev.patch
git-xtensa.patch
git-gccbug.patch
git trees
-at91-fix-enable-disable_irq_wake-symmetry-in-pcmcia-driver.patch
-slub-more-documentation.patch
-slub-more-documentation-fix.patch
-smpboot-cachesize-comparison-fix-in-smp_tune_scheduling.patch
-pci-quirks-fix-msi-disabling-on-rs400-200-and-rs480.patch
-ntfs_init_locked_inode-fix-array-indexing.patch
-m68k-runtime-patching-infrastructure.patch
-slub-fix-numa--sysfs-bootstrap-issue.patch
-afs-needs-schedh.patch
-m68k-discontinuous-memory-support.patch
-fix-vmic-compilation.patch
-git-acpi-export-acpi_set_cstate_limit.patch
-acpi-bay-send-envp-with-uevent.patch
-remove-dell-optiplex-gx240-from-the-acpi-blacklist.patch
-fix-gregkh-driver-dmi-based-module-autoloading.patch
-fix-gregkh-driver-sysfs-fix-error-handling-in-binattr-write.patch
-power-management-use-mutexes-instead-of-semaphores.patch
-sysdev-use-mutex-instead-of-semaphore.patch
-saa7134-tvaudio-kthread-conversion.patch
-input-reduce-raciness-when-input-handlers-disconnect.patch
-input-convert-from-class-devices-to-standard-devices.patch
-drivers-input-mouse-kconfig-fix-typo.patch
-atm-fix-warning.patch
-pci-disable-msi-by-default-on-systems-with-serverworks-ht1000-chips.patch
-fix-pci_find_present.patch
-sh-support-older-gccs.patch
-scsi-fix-obvious-typo-spin_lock_irqrestore-in-gdthc.patch
-fix-for-bugzilla-8426-massive-slowdown-on-scsi-cd-dvd-drive-connected-to-mptspi-driver.patch
-scsi-fix-ambiguous-gdthtable-definition.patch
-sparc32-build-fix.patch
-b44-ssb-fix-an-invalid-pointer-casting.patch
-i386-pci-fixup-for-siemens-nixdorf-ag-fsc-multiprocessor-interrupt-controllers.patch
-x86_64-allocate-sparsemem-memmap-above-4g.patch
-add-select-phylib-to-the-ucc_geth-kconfig-option.patch
-fix-possible-udf-data-corruption.patch
-fix-possible-leakage-of-blocks-in-udf.patch
-fix-possible-leakage-of-blocks-in-udf-tidy.patch
-m68k-parenthesis-balance.patch
-msi-fix-the-ordering-of-msix-irqs.patch
-msi-mask-the-msix-vector-before-we-unmap-it.patch
-potential-parse-error-in-ifdef.patch
-potential-parse-error-in-ifdef-fix.patch
-potential-parse-error-in-ifdef-update.patch
-pci_ids-update-patch-for-intel-ich9m.patch
-x86-fix-oprofile-double-free-was-re-multiple-free.patch
-work-around-dell-e520-bios-reboot-bug.patch
-fix-compat-futex-code-for-private-futexes.patch
-skeletonfb-fix-of-xxxfb_setup-ifdef.patch
-vt8623fb-arkfb-null-pointer-dereference-fix.patch
-cfag12864bfb-use-sys_-instead-of-cfb_-framebuffer-accessors.patch
-fbdev-move-declaration-of-fb_class-to-linux-fbh.patch
-misc-tifm_7xx1-replace-deprecated-irq-flag.patch
-add-a-trivial-patch-style-checker-v2.patch
-documentation-how-to-use-gdb-to-decode-oopses.patch
-rtc-use-fallback-irq-if-pnp-tables-dont-provide-one.patch
-memory-hotplug-fix-unnecessary-calling-of-init_currenty_empty_zone.patch
-missing-include-linux-mmh-in-drivers-sbus-char-flashc.patch
-tty-fix-leakage-of-erestartsys-to-userland.patch
-isdn4linux-fix-maturity-label-v4.patch
-fix-broken-clir-in-isdn-driver.patch
-prism54-maintainers-update.patch
-aacraid-fix-shutdown-handler-to-also-disable-interrupts.patch
-atmel_spi-dma-address-bugfix.patch
-neofb-fix-pseudo_palette-array-overrun-in-neofb_setcolreg.patch
-ramfs-nommu-a-bug-in-ramfs_nommu_resize-function-passing-old-size-to-vmtruncate.patch
-h8300-trival-patches.patch
-alpha-support-graphics-on-non-zero-pci-domains.patch
-alpha-support-graphics-on-non-zero-pci-domains-fix.patch
-alpha-support-graphics-on-non-zero-pci-domains-fix-2.patch
-alpha-correct-low-level-i-o-routines-for-sable-lynx.patch
-alpha-misc-fixes.patch
Merged into mainline or a subsystem tree
+update-checkpatchpl-to-version-003.patch
+m68knommu-fix-coldfire-timer-off-by-1.patch
+nommu-report-correct-errno-in-message.patch
+document-acked-by.patch
+pi-futex-fixes.patch
+update-feature-removal-scheduletxt-to-include-deprecated-functions.patch
+mount-t-tmpfs-o-mpol=-check-nodes-online.patch
+slab-fix-alien-cache-handling.patch
+potential-parse-error-in-ifdef-part-3.patch
+slub-return-zero_size_ptr-for-kmalloc0.patch
+ramfs-nommu-missed-posix-uid-gid-inode-attribute-checking.patch
+uml-fix-kernel-stack-size-on-x86_64.patch
+documentation-atomic_opstxt.patch
2.6.22 queue
+checkpatch-produce-fewer-lines-of-output.patch
Probably for 2.6.22
+git-acpi-tickh-needs-hrtimerh.patch
+git-acpi-add-exports.patch
Fir git-acpi.patch
-git-alsa-fixup.patch
Unneeded
+yet-another-uniwill-laptop-with-alc861-codec.patch
ALSA fix
+intel_agp-add-support-for-965gme-gle.patch
+intel_agp-add-support-for-945gme.patch
+intel_agp-add-support-for-g33-q33-and-q35-chipsets.patch
AGP work
+bugfix-cpufreq-in-combination-with-performance-governor.patch
+bugfix-cpufreq-in-combination-with-performance-governor-fix.patch
cpufreq fix
+make-drivers-char-hvc_consoleckhvcd-static.patch
powerpc driver cleanup
+gregkh-driver-sysdev-use-mutex-instead-of-semaphore.patch
+gregkh-driver-power-management-use-mutexes-instead-of-semaphores.patch
+gregkh-driver-block-device.patch
Driver tree updates
+fix-2-gregkh-driver-dmi-based-module-autoloading.patch
Fix it
+git-dvb-fix-the-tea5761-tuner-support.patch
git-dvb fix
+jdelvare-i2c-video-matroxfb-crtc2-header-fix.patch
I2C tree update
+i2c-iop3xx-switch-to-static-adapter-numbering.patch
+thecus-n2100-register-rtc-rs5c372-i2c-device.patch
I2C things
+jdelvare-hwmon-hwmon-via686a-fix-temperature-interrupt-mode.patch
+jdelvare-hwmon-hwmon-via686a-to-platform-driver.patch
+jdelvare-hwmon-hwmon-via686a-dynamic-attributes.patch
+jdelvare-hwmon-hwmon-sis5595-to-platform-driver.patch
+jdelvare-hwmon-hwmon-sis5595-dynamic-attributes.patch
hwmon tree updates
+git-input-fixup.patch
Fix rejects in git-input.patch
+git-input-make-xpad_play_effect-static.patch
input cleanup
+libata-config_pm=n-compile-fix.patch
libata fix
+drivers-ata-add-sw-ncq-support-to-sata_nv-for-mcp51-mcp55-mcp61.patch
Restore wrong patch (needs updating)
+ide-serverworks-remove-crappy-code.patch
+ide-serverworks-fix-csb6-tuning-logic.patch
+ide-it821x-raid-mode-fixes.patch
+ide-ide-hpa-detect-from-resume.patch
IDE tree udpates
+ide-ide-generic-add-another-device-exception.patch
IDE tweak
+git-md-accel-fixup.patch
Fix rejects in git-md-accel.patch
+mtd-use-null-for-pointer.patch
MTD sparse fix
+sundance-phy-address-form-0-only-for-device-id-0x0200.patch
+sundance-phy-address-form-0-only-for-device-id-0x0200-fix.patch
netdev fixes
+ppp_mppe-account-for-osize-too-small-errors-in.patch
Fix mppe
-bluetooth-postpone-hci_dev-unregistration.patch
Dropped - unneeded, might be buggy.
-git-ioat-vs-git-md-accel.patch
Unneeded
-gregkh-pci-pci-reduce-aer-init-error-information.patch
-gregkh-pci-msi-fix-arm-compile.patch
-allow-aer-to-build-for-config_acpi-=-n.patch
Dropped
+pci_set_power_state-check-for-pm-capabilities-earlier.patch
PCI logspam fix
-git-pciseg.patch
-pci-device-ensure-sysdata-initialised-v2.patch
Other patches broke this
-git-scsi-misc-fixup.patch
Unneeded
+scsi-dont-build-scsi_dma_mapunmap-for-has_dma.patch
+scsi-dont-build-scsi_dma_mapunmap-for-has_dma-fix.patch
SCSI updates
+update-documentation-block-barriertxt.patch
Doc update
+usb-try-to-debug-bug-8561.patch
+usb-bugfix-gfp_kernel-gfp_atomic-in-spin_locked-region.patch
+usb-serial-fix-something.patch
USB stuff
+x86_64-mm-compat-syscall-u64.patch
+x86_64-mm-cpa-cache-flush.patch
+x86_64-mm-disable-watchdog.patch
+x86_64-mm-fix-eventd-syscall.patch
+x86_64-mm-fam10-l3cache.patch
x86 tree updates
+revert-x86_64-mm-verify-cpu-rename.patch
+revert-x86_64-mm-cpa-cache-flush.patch
+fix-x86_64-mm-xen-add-xen-virtual-block-device-driver.patch
Fix it
+round_jiffies-for-i386-and-x86-64-non-critical-corrected-mce-polling.patch
+mmconfig-validate-against-acpi-motherboard-resources.patch
+pci-disable-decode-of-io-memory-during-bar-sizing.patch
+x86_64-irq-check-remote-irr-bit-before-migrating-level-triggered-irq-v3.patch
+i386-remove-support-for-the-rise-cpu.patch
+x86-64-calgary-generalize-calgary_increase_split_completion_timeout.patch
+x86-64-calgary-update-copyright-notice.patch
+x86-64-calgary-introduce-handle_quirks-for-various-chipset-quirks.patch
+x86-64-calgary-introduce-chipset-specific-ops.patch
+x86-64-calgary-introduce-chipset-specific-ops-fix.patch
+x86-64-calgary-abstract-how-we-find-the-iommu_table-for-a-device.patch
+x86-64-calgary-introduce-calioc2-support.patch
+x86-64-calgary-add-chip_ops-and-a-quirk-function-for-calioc2.patch
+x86-64-calgary-add-chip_ops-and-a-quirk-function-for-calioc2-fix.patch
+x86-64-calgary-implement-calioc2-tce-cache-flush-sequence.patch
+x86-64-calgary-make-dump_error_regs-a-chip-op.patch
+x86-64-calgary-grab-plssr-too-when-a-dma-error-occurs.patch
+x86-64-calgary-reserve-tces-with-the-same-address-as-mem-regions.patch
+x86-64-calgary-reserve-tces-with-the-same-address-as-mem-regions-fix.patch
+x86-64-calgary-cleanup-of-unneeded-macros.patch
+x86-64-calgary-tabify-and-trim-trailing-whitespace.patch
+x86-64-calgary-only-reserve-the-first-1mb-of-io-space-for-calioc2.patch
+x86-64-calgary-tidy-up-debug-printks.patch
+i386-make-arch-i386-mm-pgtablecpgd_cdtor-static.patch
+i386-fix-section-mismatch-warning-in-intel_cacheinfo.patch
+i386-do-not-restore-reserved-memory-after-hibernation.patch
+i386-do-not-restore-reserved-memory-after-hibernation-fix.patch
+paravirt-helper-to-disable-all-io-space.patch
+paravirt-helper-to-disable-all-io-space-fix.patch
+xen-disable-all-non-virtual-devices.patch
+dmi_match-patch-in-rebootc-for-sff-dell-optiplex-745-fixes-hang.patch
+x86_64-use-null-for-pointer.patch
x86/x86-64 stuff
+ext3-lost-brelse-in-ext3_read_inode.patch
+ext4-lost-brelse-in-ext4_read_inode.patch
+acpi-preserve-the-ebx-value-in-acpi_copy_wakeup_routine.patch
Probable 2.6.22 queue
+console-more-buf-for-index-parsing.patch
+console-console-handover-to-preferred-console.patch
+x86-initial-fixmap-support.patch
+serial-convert-early_uart-to-earlycon-for-8250.patch
+serial-assert-dtr-for-serial-console-devices.patch
Another go at fixing some early console issues
+make-proc-slabinfo-use-seq_list_xxx-helpers-fix.patch
Fix make-proc-slabinfo-use-seq_list_xxx-helpers.patch
+rework-ptep_set_access_flags-and-fix-sun4c-fix.patch
+rework-ptep_set_access_flags-and-fix-sun4c-fix-fix.patch
+rework-ptep_set_access_flags-and-fix-sun4c-fix-fix-fix.patch
Fix rework-ptep_set_access_flags-and-fix-sun4c.patch
+vmscan-fix-comments-related-to-shrink_list.patch
Fix comments
+ocfs2-release-page-lock-before-calling-page_mkwrite.patch
+document-page_mkwrite-locking.patch
+slub-support-slub_debug-on-by-default.patch
+slub-support-slub_debug-on-by-default-tidy.patch
+numa-mempolicy-allow-tunable-policy-for-system-init.patch
+numa-mempolicy-allow-tunable-policy-for-system-init-fix.patch
+mm-revert-kernel_ds-buffered-write-optimisation.patch
+revert-81b0c8713385ce1b1b9058e916edcf9561ad76d6.patch
+revert-6527c2bdf1f833cc18e8f42bd97973d583e4aa83.patch
+mm-clean-up-buffered-write-code.patch
+mm-debug-write-deadlocks.patch
+mm-trim-more-holes.patch
+mm-buffered-write-cleanup.patch
+mm-write-iovec-cleanup.patch
+mm-fix-pagecache-write-deadlocks.patch
+mm-buffered-write-iterator.patch
+fs-fix-data-loss-on-error.patch
+fs-introduce-write_begin-write_end-and-perform_write-aops.patch
+mm-restore-kernel_ds-optimisations.patch
+implement-simple-fs-aops.patch
+block_dev-convert-to-new-aops.patch
+ext2-convert-to-new-aops.patch
+ext3-convert-to-new-aops.patch
+ext4-convert-to-new-aops.patch
+xfs-convert-to-new-aops.patch
+gfs2-convert-to-new-aops.patch
+fs-new-cont-helpers.patch
+fat-convert-to-new-aops.patch
+hfs-convert-to-new-aops.patch
+hfsplus-convert-to-new-aops.patch
+hpfs-convert-to-new-aops.patch
+bfs-convert-to-new-aops.patch
+qnx4-convert-to-new-aops.patch
+reiserfs-use-generic-write.patch
+reiserfs-convert-to-new-aops.patch
+reiserfs-use-generic_cont_expand_simple.patch
+with-reiserfs-no-longer-using-the-weird-generic_cont_expand-remove-it-completely.patch
+nfs-convert-to-new-aops.patch
+smb-convert-to-new-aops.patch
+fuse-convert-to-new-aops.patch
+hostfs-convert-to-new-aops.patch
+jffs2-convert-to-new-aops.patch
+ufs-convert-to-new-aops.patch
+udf-convert-to-new-aops.patch
+sysv-convert-to-new-aops.patch
+minix-convert-to-new-aops.patch
+jfs-convert-to-new-aops.patch
+nick-broke-stuff.patch
+nick-broke-more-stuff.patch
+nick-broke-even-more-stuff.patch
+nick-really-did-it-this-time.patch
Fix the pagefault-versus-buffered-write deadlock
+do-not-depend-on-max_order-when-grouping-pages-by-mobility.patch
+print-out-statistics-in-relation-to-fragmentation-avoidance-to-proc-pagetypeinfo.patch
More updates to the page-mobility patches
+hexdump-more-output-formatting.patch
hexdump.c feature creep
+freezer-make-kernel-threads-nonfreezable-by-default-fix-2.patch
Fix the oft-fixed freezer-make-kernel-threads-nonfreezable-by-default.patch
+nommu-stub-expand_stack-for-nommu-case.patch
+m68knommu-use-trhead_size-instead-of-hard-constant.patch
+m68knommu-remove-cruft-from-setup-code.patch
+m68knommu-remove-old-cache-management-cruft-from-mm-code.patch
nommu updates
+h8300-zimage-support-update.patch
h8300 feature work
+swsusp-remove-code-duplication-between-diskc-and-userc-fix.patch
Fix swsusp-remove-code-duplication-between-diskc-and-userc.patch
+pm-introduce-hibernation-and-suspend-notifiers.patch
+pm-introduce-hibernation-and-suspend-notifiers-fix.patch
+pm-introduce-hibernation-and-suspend-notifiers-tidy.patch
+pm-disable-usermode-helper-before-hibernation-and-suspend.patch
+pm-disable-usermode-helper-before-hibernation-and-suspend-fix.patch
More power-management work
+uml-fix-request-sector-update.patch
UML fixlet
-partitions-check-the-return-value-of-kobject_add-etc.patch
Dropped - people kept on breaking it and I got fed up.
-preserve-the-dirty-bit-in-init_page_buffers.patch
-rd-mark-ramdisk-buffer-heads-dirty-in-ramdisk_set_page_dirty.patch
-rd-mark-ramdisk-buffer-heads-dirty-in-ramdisk_set_page_dirty-fix.patch
-rd-simplify-by-using-the-same-helper-functions-in-libfs.patch
Shelved these for now - I think they're causing BUG_ONs to trigger.
+udf-coding-style-conversion-lindent-fixups-2.patch
More UDF whitespace fixing
+zs-move-to-the-serial-subsystem-update.patch
Fix zs-move-to-the-serial-subsystem.patch
+add-a-flag-to-indicate-deferrable-timers-in-proc-timer_stats.patch
+buffer-kill-old-incorrect-comment.patch
+introduce-o_cloexec-take-2.patch
+introduce-o_cloexec-parisc-fix.patch
+o_cloexec-for-scm_rights.patch
+o_cloexec-for-scm_rights-fix.patch
+o_cloexec-for-scm_rights-fix-2.patch
+init-wait-for-asynchronously-scanned-block-devices.patch
+atmel_serial-fix-break-handling.patch
+documentation-proc-pid-stat-files.patch
+seq_file-more-atomicity-in-traverse.patch
+lib-add-idr_for_each.patch
+lib-add-idr_for_each-fix.patch
+lib-add-idr_remove_all.patch
+remove-capabilityh-from-mmh.patch
+kernel-utf-8-handling.patch
+remove-sonypi_camera_command.patch
+drop-an-empty-isicomh-from-being-exported-to-user-space.patch
+cobalt-remove-all-traces-of-cobalt-from-nvramc.patch
+ext3-ext4-orphan-list-check-on-destroy_inode.patch
+ext3-ext4-orphan-list-check-on-destroy_inode-fix.patch
+ext3-ext4-orphan-list-corruption-due-bad-inode.patch
+allow-file-system-to-configure-for-no-leases.patch
+remove-apparently-useless-commented-apm_get_battery_status.patch
+taskstats-add-context-switch-counters.patch
+taskstats-add-context-switch-counters-fix.patch
+sony-laptop-use-null-for-pointer.patch
Misc
+introduce-i_sync.patch
Fix a VFS deadlock which nobody seems to be able to explain or reproduce.
+spi-controller-drivers-check-for-unsupported-modes-update.patch
Fix spi-controller-drivers-check-for-unsupported-modes.patch
+spi_lm70llp-parport-adapter-driver.patch
+spi_lm70llp-parport-adapter-driver-correction.patch
SPI device driver
+sane-irq-initialization-in-sedlbauer-hisax.patch
ISDN fix
+fs-introduce-write_begin-write_end-and-perform_write-aops-revoke.patch
Fix revoke for Nick's patches. Wrongly.
+lguest-speed-up-paravirt_lazy_flush-handling.patch
+lguest-more-lazy_hcalls.patch
+lguest-the-guest-code-tsc-fix.patch
+lguest-the-guest-code-suppress-ide-probing.patch
+lguest-faster-tls-switching.patch
+lguest-the-host-code-dont-signal-like-crazy-use-lhreq_break-command.patch
+lguest-the-host-code-use-tsc.patch
+lguest-the-host-code-use-hrtimers.patch
+lguest-the-host-code-update-for-mm-simplify-boot_params.patch
+lguest-the-net-driver-include-fix.patch
+lguest-the-documentation-example-launcher-example-launcher-fix.patch
+lguest-dont-signal-like-crazy-use-lhreq_break-command-doc.patch
lguest updates
+char-stallion-dont-fail-with-less-than-max-panels.patch
+char-stallion-alloc-tty-before-pci-devices-init.patch
+char-stallion-proper-fail-return-values.patch
+char-stallion-remove-user-class-report-request.patch
Stallion driver fixes.
I have a feeling these should be in 2.6.22.
+radeonfb-add-support-for-radeon-xpress-200m-rs485.patch
+nvidiafb-add-proper-support-for-geforce-7600-chipset.patch
+pm2fb-white-spaces-clean-up.patch
+fbcon-set_con2fb_map-fixes.patch
+fbcon-revise-primary-device-selection.patch
+fbdev-fbcon-console-unregistration-from-unregister_framebuffer.patch
+fbdev-fbcon-console-unregistration-from-unregister_framebuffer-fix.patch
+vt-add-comment-for-unbind_con_driver.patch
+68328fb-the-pseudo_palette-is-only-16-elements-long.patch
+controlfb-the-pseudo_palette-is-only-16-elements-long.patch
+cyblafb-fix-pseudo_palette-array-overrun-in-setcolreg.patch
+epson1355fb-color-setting-fixes.patch
+ffb-the-pseudo_palette-is-only-16-elements-long.patch
+fm2fb-the-pseudo_palette-is-only-16-elements-long.patch
+gbefb-the-pseudo_palette-is-only-16-elements-long.patch
+macfb-fix-pseudo_palette-size-and-overrun.patch
+offb-the-pseudo_palette-is-only-16-elements-long.patch
+platinumfb-the-pseudo_palette-is-only-16-elements.patch
+pvr2fb-fix-pseudo_palette-array-overrun-and-typecast.patch
+q40fb-the-pseudo_palette-is-only-16-elements-long.patch
+sgivwfb-the-pseudo_palette-is-only-16-elements-long.patch
+sunxvr2500fb-fix-pseudo_palette-array-size.patch
+sunxvr500fb-fix-pseudo_palette-array-size.patch
+tgafb-actually-allocate-memory-for-the-pseudo_palette.patch
+tridentfb-fix-pseudo_palette-array-overrun-in-setcolreg.patch
+tx3912fb-fix-improper-assignment-of-info-pseudo_palette.patch
+atyfb-the-pseudo_palette-is-only-16-elements-long.patch
+radeonfb-the-pseudo_palette-is-only-16-elements-long.patch
+i810fb-the-pseudo_palette-is-only-16-elements-long.patch
+intelfb-the-pseudo_palette-is-only-16-elements-long.patch
+sisfb-fix-pseudo_palette-array-size-and-overrun.patch
+matroxfb-color-setting-fixes.patch
+pm3fb-fillrect-acceleration.patch
+i386-set-6-bit-dac-channel-properties-in-vesa-video.patch
+pm3fb-possible-cleanups.patch
+vt8623fbc-make-code-static.patch
fbdev updates
+cfs-scheduler-v15-rc3-mm1.patch
+kernel-sched_fairc-make-code-static.patch
+fs-proc-basec-make-a-struct-static.patch
+cfs-warning-fixes.patch
CFS fixes
+arch-personality-independent-stack-top.patch
+audit-rework-execve-audit.patch
+audit-rework-execve-audit-fix.patch
+mm-move_page_tables_up.patch
+mm-variable-length-argument-support.patch
+mm-variable-length-argument-support-fix.patch
Remove the fixed limit on command line size
+drivers-edac-add-edac_mc_find-api.patch
+drivers-edac-core-make-functions-static.patch
+drivers-edac-add-rddr2-memory-types.patch
+drivers-edac-split-out-functions-to-unique-files.patch
+drivers-edac-add-edac_device-class.patch
+drivers-edac-mc-sysfs-add-missing-mem-types.patch
+drivers-edac-change-from-semaphore-to-mutex-operation.patch
+drivers-edac-new-intel-5000-mc-driver.patch
+drivers-edac-coreh-fix-scrubdefs.patch
+drivers-edac-new-i82443bxgz-mc-driver.patch
+drivers-edac-add-new-nmi-rescan.patch
+drivers-edac-mod-use-edac_coreh.patch
+drivers-edac-add-dev_name-getter-function.patch
+drivers-edac-new-inte-30x0-mc-driver.patch
+drivers-edac-mod-mc-to-use-workq-instead-of-kthread.patch
+drivers-edac-updated-pci-monitoring.patch
+drivers-edac-mod-assert_error-check.patch
+drivers-edac-mod-pci-poll-names.patch
+drivers-edac-core-lindent-cleanup.patch
+drivers-edac-edac_device-sysfs-cleanup.patch
+drivers-edac-cleanup-workq-ifdefs.patch
+drivers-edac-lindent-amd76x.patch
+drivers-edac-lindent-i5000.patch
+drivers-edac-lindent-e7xxx.patch
+drivers-edac-lindent-i3000.patch
+drivers-edac-lindent-i82860.patch
+drivers-edac-lindent-i82875p.patch
+drivers-edac-lindent-e752x.patch
+drivers-edac-lindent-i82443bxgx.patch
+drivers-edac-lindent-r82600.patch
+drivers-edac-drivers-to-use-new-pci-operation.patch
+drivers-edac-add-device-sysfs-attributes.patch
+drivers-edac-device-output-clenaup.patch
+drivers-edac-add-info-kconfig.patch
+drivers-edac-update-maintainers-files-for-edac.patch
+drivers-edac-cleanup-spaces-gotos-after-lindent-messup.patch
EDAC updates
+lockstat-human-readability-tweaks-fix.patch
Fix lockstat-human-readability-tweaks.patch
-statistics-infrastructure-prerequisite-list.patch
-statistics-infrastructure-prerequisite-parser.patch
-statistics-infrastructure-prerequisite-parser-fix.patch
-add-for_each_substring-and-match_substring.patch
-statistics-infrastructure-prerequisite-timestamp.patch
-statistics-infrastructure-make-printk_clock-a-generic-kernel-wide-nsec-resolution.patch
-statistics-infrastructure-documentation.patch
-statistics-infrastructure.patch
-statistics-infrastructure-add-for_each_substring-and-match_substring-exploitation.patch
-statistics-infrastructure-fix-parsing-of-statistics-type-attribute.patch
-statistics-infrastructure-simplify-statistics-debugfs-write-function.patch
-statistics-infrastructure-simplify-statistics-debugfs-read-functions.patch
-statistics-infrastructure-fix-string-termination.patch
-statistics-infrastructure-small-cleanup-in-debugfs-write-function.patch
-statistics-infrastructure-fix-cpu-hot-unplug-related-memory-leak.patch
-statistics-infrastructure-timer_stats-slimmed-down-statistics-prereq-cleanup.patch
-statistics-infrastructure-timer_stats-slimmed-down-statistics-prereq-labels.patch
-statistics-infrastructure-timer_stats-slimmed-down-statistics-prereq-keys.patch
-statistics-infrastructure-statistics-fix-sorted-list.patch
-add-suspend-related-notifications-for-cpu-hotplug-statistics.patch
-statistics-infrastructure-exploitation-zfcp.patch
Dropped, for now.
+nick-broke-reiser4-too.patch
argh
+print-out-page_owner-statistics-in-relation-to-fragmentation-avoidance.patch
Update -mm-only debug patch for Mel's changes
All 119 patches:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm1/patch-list
Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm1/
>
>
Compile error here :
...
LD .tmp_vmlinux1
drivers/built-in.o: In function `acpi_init':
bus.c:(.init.text+0x249a): undefined reference to `pci_mmcfg_late_init'
make: *** [.tmp_vmlinux1] Error 1
....
http://frugalware.org/~crazy/other/mm/2.6.22-rc4-mm1/config
Regards,
Gabriel
Hi Andrew,
When CONFIG_DEBUG_VM=y, boot on i386 and s390 (the only one tested) ends
with the following.
C.
------------[ cut here ]------------
kernel BUG at mm/rmap.c:557!
invalid opcode: 0000 [#1]
CPU: 0
EIP: 0060:[<c013cbbd>] Not tainted VLI
EFLAGS: 00000206 (2.6.22-rc4-mm1 #1)
EIP is at __page_check_anon_rmap+0x21/0x28
eax: c15bd431 ebx: c1024700 ecx: 000bffa6 edx: c15bb6d0
esi: c1024700 edi: 01238045 ebp: c1423e9c esp: c1423e98
ds: 007b es: 007b fs: 0000 gs: 0033 ss: 0068
Process init (pid: 1, ti=c1422000 task=c14216b0 task.ti=c1422000)
Stack: c1024700 c1423ea8 c013d631 01238045 c1423ef8 c01392a6 c15bb6d0 c15afc40
c15afa40 c15aebfc c15c3bfc bffa7000 bffa6000 bffa7000 c15bae98 c15d5e98
00000000 c15afa90 c15afc90 00000000 00000002 c15d66f0 00000000 c15bb6d0
Call Trace:
[<c010282d>] show_trace_log_lvl+0x1a/0x2f
[<c01028dd>] show_stack_log_lvl+0x9b/0xa3
[<c0102a94>] show_registers+0x1af/0x280
[<c0102c4b>] die+0xe6/0x1e5
[<c0102dd3>] do_trap+0x89/0xa2
[<c010313e>] do_invalid_op+0x88/0x92
[<c024d142>] error_code+0x6a/0x70
[<c013d631>] page_dup_rmap+0x1b/0x21
[<c01392a6>] copy_page_range+0x22b/0x2d0
[<c01109bc>] copy_process+0x964/0xf54
[<c01110d1>] do_fork+0x98/0x1b8
[<c0100716>] sys_clone+0x33/0x39
[<c010226c>] syscall_call+0x7/0xb
=======================
Code: 2a c0 ff 05 30 67 2f c0 5d c3 55 89 e5 53 89 c3 8b 42 3c 40 39 43 10 74 04 0f 0b eb fe 2b 4a 04 c1 e9 0c 03 4a 44 39 4b 14 74 04 <0f> 0b eb fe 5b 5d c3 55 89 e5 53 89 c3 8b 42 3c 85 c0 75 04 0f
EIP: [<c013cbbd>] __page_check_anon_rmap+0x21/0x28 SS:ESP 0068:c1423e98
Kernel panic - not syncing: Attempted to kill init!
Andrew Morton napsal(a):
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm1/
It freezes during bootup while searching for sata drives on sata_promise. There
were 2 issues with sata_promise in -rc4 IIRC, one was fixed, the latter remains
unresolved. Or, should be this solved too, Mikael, Tejun and is this yet
eanother problem? (In this case I'll post dmesg and co.)
thanks,
--
http://www.fi.muni.cz/~xslaby/ Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E
Andrew,
here's a minor fix for x86_64,
C.
when CONFIG_PM=y and CONFIG_SOFTWARE_SUSPEND=n,
CC arch/x86_64/kernel/e820.o
/home/legoater/linux/2.6.22-rc4-mm1/arch/x86_64/kernel/e820.c: In function `e820_mark_nosave_regions':
/home/legoater/linux/2.6.22-rc4-mm1/arch/x86_64/kernel/e820.c:248: warning: implicit declaration of function `register_nosave_region'
Signed-off-by: Cedric Le Goater <[email protected]>
---
include/linux/suspend.h | 8 ++++++++
1 file changed, 8 insertions(+)
Index: 2.6.22-rc4-mm1/include/linux/suspend.h
===================================================================
--- 2.6.22-rc4-mm1.orig/include/linux/suspend.h
+++ 2.6.22-rc4-mm1/include/linux/suspend.h
@@ -74,6 +74,14 @@
extern void hibernation_set_ops(struct hibernation_ops *ops);
extern int hibernate(void);
#else /* CONFIG_SOFTWARE_SUSPEND */
+static inline void register_nosave_region(unsigned long b, unsigned long e)
+{
+}
+
+static inline void register_nosave_region_late(unsigned long b, unsigned long e)
+{
+}
+
static inline int swsusp_page_is_forbidden(struct page *p) { return 0; }
static inline void swsusp_set_page_free(struct page *p) {}
static inline void swsusp_unset_page_free(struct page *p) {}
Cedric Le Goater wrote:
> Andrew,
>
> here's a minor fix for x86_64,
>
> C.
>
>
> when CONFIG_PM=y and CONFIG_SOFTWARE_SUSPEND=n,
>
> CC arch/x86_64/kernel/e820.o
> /home/legoater/linux/2.6.22-rc4-mm1/arch/x86_64/kernel/e820.c: In function `e820_mark_nosave_regions':
> /home/legoater/linux/2.6.22-rc4-mm1/arch/x86_64/kernel/e820.c:248: warning: implicit declaration of function `register_nosave_region'
>
> Signed-off-by: Cedric Le Goater <[email protected]>
> ---
> include/linux/suspend.h | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> Index: 2.6.22-rc4-mm1/include/linux/suspend.h
> ===================================================================
> --- 2.6.22-rc4-mm1.orig/include/linux/suspend.h
> +++ 2.6.22-rc4-mm1/include/linux/suspend.h
> @@ -74,6 +74,14 @@
> extern void hibernation_set_ops(struct hibernation_ops *ops);
> extern int hibernate(void);
> #else /* CONFIG_SOFTWARE_SUSPEND */
> +static inline void register_nosave_region(unsigned long b, unsigned long e)
> +{
> +}
> +
> +static inline void register_nosave_region_late(unsigned long b, unsigned long e)
> +{
> +}
> +
> static inline int swsusp_page_is_forbidden(struct page *p) { return 0; }
> static inline void swsusp_set_page_free(struct page *p) {}
> static inline void swsusp_unset_page_free(struct page *p) {}
> -
Looks like this is the cause of a bunch of compile failures across our
testing. Will shove this through tko.
-apw
Seeing this on an ia64:
drivers/built-in.o: In function `efi_setup_pcdp_console':
(.init.text+0x13be2): undefined reference to `early_serial_console_init'
drivers/built-in.o: In function `efi_setup_pcdp_console':
(.init.text+0x13de2): undefined reference to `early_serial_console_init'
make: *** [.tmp_vmlinux1] Error 1
Getting this on a bigger x86_64 (bl6-13):
Unable to handle kernel NULL pointer dereference at 0000000000000000 RIP:
[<ffffffff8037898b>] acpi_processor_throttling_seq_show+0xa7/0xd6
PGD 2d77067 PUD 34c3067 PMD 0
Oops: 0000 [1] SMP
CPU 3
Modules linked in: video output button battery asus_acpi ac lp
parport_pc parport floppy nvram amd_rng rng_core i2c_amd756 i2c_core
Pid: 1634, comm: head Not tainted 2.6.22-rc4-mm1-autokern1 #1
RIP: 0010:[<ffffffff8037898b>] [<ffffffff8037898b>]
acpi_processor_throttling_seq_show+0xa7/0xd6
RSP: 0018:ffff810003c9de48 EFLAGS: 00010246
RAX: 0000000000000020 RBX: ffff8100029e7800 RCX: 0000000000000000
RDX: 000000000000002a RSI: ffffffff805993e4 RDI: ffff810002d714c0
RBP: ffff810002d714c0 R08: ffff810003f82051 R09: ffff810002d714c0
R10: ffffffffffffffff R11: 0000000000000000 R12: 0000000000000000
R13: 0000000000000000 R14: 0000000000000000 R15: 00007fff64fd2b90
FS: 00002b3545aec6f0(0000) GS:ffff810001683a40(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000000000 CR3: 0000000003966000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process head (pid: 1634, threadinfo ffff810003c9c000, task ffff810001c8c810)
Stack: 00000000000000d0 ffff810002d714c0 0000000000000001 0000000000000001
0000000000002000 ffffffff802ab6eb ffff810003c9df50 ffff810002915d00
ffff810002d714f0 ffff810002fa2000 0000000000000000 fffffffffffffffb
Call Trace:
[<ffffffff802ab6eb>] seq_read+0x105/0x28e
[<ffffffff802ab5e6>] seq_read+0x0/0x28e
[<ffffffff802cd085>] proc_reg_read+0x80/0x9a
[<ffffffff802925a7>] vfs_read+0xcb/0x153
[<ffffffff80292943>] sys_read+0x45/0x6e
[<ffffffff8020bc5e>] system_call+0x7e/0x83
Code: 45 8b 44 0d 00 44 89 e1 0f 45 d0 31 c0 49 ff c4 49 83 c5 28
RIP [<ffffffff8037898b>] acpi_processor_throttling_seq_show+0xa7/0xd6
RSP <ffff810003c9de48>
CR2: 0000000000000000
FATAL: Error inserting acpi_cpufreq
(/lib/modules/2.6.22-rc4-mm1-autokern1/kernel/arch/x86_64/kernel/cpufreq/acpi-cpufreq.ko):
No such device
On Wed, 06 Jun 2007 15:04:00 +0200, Jiri Slaby wrote:
> Andrew Morton napsal(a):
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm1/
>
> It freezes during bootup while searching for sata drives on sata_promise. There
> were 2 issues with sata_promise in -rc4 IIRC, one was fixed, the latter remains
> unresolved. Or, should be this solved too, Mikael, Tejun and is this yet
> eanother problem? (In this case I'll post dmesg and co.)
I know of only one sata_promise-specific issue in 2.6.22-rc4.
Tejun's "sata_promise: use TF interface for polling NODATA commands"
patch posted today fixes it.
If there are any other sata_promise-specific issues, please
let us know.
/Mikael
Michal Piotrowski pisze:
> On 06/06/07, Andrew Morton <[email protected]> wrote:
>>
>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm1/
>>
>>
>
> It reboots immediately.
GOOD
#preserve-the-dirty-bit-in-init_page_buffers.patch
#rd-mark-ramdisk-buffer-heads-dirty-in-ramdisk_set_page_dirty.patch
#rd-mark-ramdisk-buffer-heads-dirty-in-ramdisk_set_page_dirty-fix.patch
#rd-simplify-by-using-the-same-helper-functions-in-libfs.patch
#rd-remove-ramdisk_set_page_dirty.patch
#rd-remove-ramdisk_set_page_dirty-fix.patch
mpu401-warning-fixes.patch
define-new-percpu-interface-for-shared-data.patch
use-the-new-percpu-interface-for-shared-data.patch
introduce-config_virt_to_bus.patch
BAD
Ok, these patches broke my P4 HT
define-new-percpu-interface-for-shared-data.patch
use-the-new-percpu-interface-for-shared-data.patch
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 2
model name : Intel(R) Pentium(R) 4 CPU 2.80GHz
stepping : 5
cpu MHz : 2798.721
cache size : 512 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 1
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe cid xtpr
bogomips : 5599.63
clflush size : 64
processor : 1
vendor_id : GenuineIntel
cpu family : 15
model : 2
model name : Intel(R) Pentium(R) 4 CPU 2.80GHz
stepping : 5
cpu MHz : 2798.721
cache size : 512 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 1
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe cid xtpr
bogomips : 5596.56
clflush size : 64
http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.22-rc4-mm1/mm-config
Regards,
Michal
--
"Najbardziej brakowa?o mi twojego milczenia."
-- Andrzej Sapkowski "Co? wi?cej"
Gabriel C wrote:
> Andrew Morton wrote:
>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm1/
>>
>>
>>
>
>
> Compile error here :
>
> ..
>
> LD .tmp_vmlinux1
> drivers/built-in.o: In function `acpi_init':
> bus.c:(.init.text+0x249a): undefined reference to `pci_mmcfg_late_init'
> make: *** [.tmp_vmlinux1] Error 1
>
> ...
>
>
> http://frugalware.org/~crazy/other/mm/2.6.22-rc4-mm1/config
>
> Regards,
>
> Gabriel
Presumably because:
# CONFIG_PCI_GOMMCONFIG is not set
I'll cook up a patch later today.
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from [email protected]
Home Page: http://www.roberthancock.com/
Cedric Le Goater pisze:
> Hi Andrew,
>
> When CONFIG_DEBUG_VM=y, boot on i386 and s390 (the only one tested) ends
> with the following.
>
> C.
>
> ------------[ cut here ]------------
> kernel BUG at mm/rmap.c:557!
> invalid opcode: 0000 [#1]
> CPU: 0
> EIP: 0060:[<c013cbbd>] Not tainted VLI
> EFLAGS: 00000206 (2.6.22-rc4-mm1 #1)
> EIP is at __page_check_anon_rmap+0x21/0x28
> eax: c15bd431 ebx: c1024700 ecx: 000bffa6 edx: c15bb6d0
> esi: c1024700 edi: 01238045 ebp: c1423e9c esp: c1423e98
> ds: 007b es: 007b fs: 0000 gs: 0033 ss: 0068
> Process init (pid: 1, ti=c1422000 task=c14216b0 task.ti=c1422000)
> Stack: c1024700 c1423ea8 c013d631 01238045 c1423ef8 c01392a6 c15bb6d0 c15afc40
> c15afa40 c15aebfc c15c3bfc bffa7000 bffa6000 bffa7000 c15bae98 c15d5e98
> 00000000 c15afa90 c15afc90 00000000 00000002 c15d66f0 00000000 c15bb6d0
> Call Trace:
> [<c010282d>] show_trace_log_lvl+0x1a/0x2f
> [<c01028dd>] show_stack_log_lvl+0x9b/0xa3
> [<c0102a94>] show_registers+0x1af/0x280
> [<c0102c4b>] die+0xe6/0x1e5
> [<c0102dd3>] do_trap+0x89/0xa2
> [<c010313e>] do_invalid_op+0x88/0x92
> [<c024d142>] error_code+0x6a/0x70
> [<c013d631>] page_dup_rmap+0x1b/0x21
> [<c01392a6>] copy_page_range+0x22b/0x2d0
> [<c01109bc>] copy_process+0x964/0xf54
> [<c01110d1>] do_fork+0x98/0x1b8
> [<c0100716>] sys_clone+0x33/0x39
> [<c010226c>] syscall_call+0x7/0xb
> =======================
> Code: 2a c0 ff 05 30 67 2f c0 5d c3 55 89 e5 53 89 c3 8b 42 3c 40 39 43 10 74 04 0f 0b eb fe 2b 4a 04 c1 e9 0c 03 4a 44 39 4b 14 74 04 <0f> 0b eb fe 5b 5d c3 55 89 e5 53 89 c3 8b 42 3c 85 c0 75 04 0f
> EIP: [<c013cbbd>] __page_check_anon_rmap+0x21/0x28 SS:ESP 0068:c1423e98
> Kernel panic - not syncing: Attempted to kill init!
> -
Same problem here
http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.22-rc4-mm1/console.log
http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.22-rc4-mm1/mm-config2
l *__page_check_anon_rmap+0x49
0xc1075ee5 is in __page_check_anon_rmap (mm/rmap.c:557).
552 * over the call to page_add_new_anon_rmap.
553 */
554 struct anon_vma *anon_vma = vma->anon_vma;
555 anon_vma = (void *) anon_vma + PAGE_MAPPING_ANON;
556 BUG_ON(page->mapping != (struct address_space *)anon_vma);
557 BUG_ON(page->index != linear_page_index(vma, address));
558 #endif
559 }
560
561 /**
I'll try to revert mm-merge-populate-and-nopage-into-fault-fixes-nonlinear.patch
Regards,
Michal
--
"Najbardziej brakowało mi twojego milczenia."
-- Andrzej Sapkowski "Coś więcej"
Mikael Pettersson napsal(a):
> On Wed, 06 Jun 2007 15:04:00 +0200, Jiri Slaby wrote:
>> Andrew Morton napsal(a):
>>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm1/
>> It freezes during bootup while searching for sata drives on sata_promise. There
>> were 2 issues with sata_promise in -rc4 IIRC, one was fixed, the latter remains
>> unresolved. Or, should be this solved too, Mikael, Tejun and is this yet
>> eanother problem? (In this case I'll post dmesg and co.)
>
> I know of only one sata_promise-specific issue in 2.6.22-rc4.
> Tejun's "sata_promise: use TF interface for polling NODATA commands"
> patch posted today fixes it.
It's in that -mm, so I think, this seems to be another problem.
> If there are any other sata_promise-specific issues, please
> let us know.
ACPI: PCI Interrupt 0000:02:01.0[A] -> GSI 21 (level, low) -> IRQ 19
sata_promise 0000:02:01.0: PATA port found
scsi4 : sata_promise
scsi5 : sata_promise
scsi6 : sata_promise
ata5: SATA max UDMA/133 cmd 0xf8812200 ctl 0xf8812238 bmdma 0x00000000 irq 0
ata6: SATA max UDMA/133 cmd 0xf8812280 ctl 0xf88122b8 bmdma 0x00000000 irq 0
ata7: PATA max UDMA/133 cmd 0xf8812300 ctl 0xf8812338 bmdma 0x00000000 irq 0
ata5: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata5.00: ata_hpa_resize 1: sectors = 156301488, hpa_sectors = 156301488
ata5.00: ATA-7: SAMSUNG HD080HJ, WT100-41, max UDMA7
ata5.00: 156301488 sectors, multi 0: LBA48 NCQ (depth 0/32)
ata5.00: qc timeout (cmd 0xef)
ata5.00: failed to set xfermode (err_mask=0x4)
ata5: failed to recover some devices, retrying in 5 secs
ata5: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata5.00: ata_hpa_resize 1: sectors = 156301488, hpa_sectors = 156301488
ata5.00: qc timeout (cmd 0xef)
ata5.00: failed to set xfermode (err_mask=0x4)
ata5.00: limiting speed to UDMA/133:PIO3
ata5: failed to recover some devices, retrying in 5 secs
ata5: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata5.00: ata_hpa_resize 1: sectors = 156301488, hpa_sectors = 156301488
ata5.00: qc timeout (cmd 0xef)
ata5.00: failed to set xfermode (err_mask=0x4)
ata5.00: disabled
regards,
--
http://www.fi.muni.cz/~xslaby/ Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E
> Same problem here
>
> http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.22-rc4-mm1/console.log
>
> http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.22-rc4-mm1/mm-config2
>
>
> l *__page_check_anon_rmap+0x49
> 0xc1075ee5 is in __page_check_anon_rmap (mm/rmap.c:557).
> 552 * over the call to page_add_new_anon_rmap.
> 553 */
> 554 struct anon_vma *anon_vma = vma->anon_vma;
> 555 anon_vma = (void *) anon_vma + PAGE_MAPPING_ANON;
> 556 BUG_ON(page->mapping != (struct address_space *)anon_vma);
> 557 BUG_ON(page->index != linear_page_index(vma, address));
> 558 #endif
> 559 }
> 560
> 561 /**
>
> I'll try to revert
> mm-merge-populate-and-nopage-into-fault-fixes-nonlinear.patch
yes, i gave it a try that but it seems that this patch is heavily
interlaced with others. I assume Nick has a better understanding
of the issue.
C.
On Wed, 06 Jun 2007 02:07:37 PDT, Andrew Morton said:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm1/
This one died a horrid death at boot time - console log indicates it found the
hard drive OK, found the 2 partitions on it. But when the initrd ran a
'lvm vgscan', it didn't find the LVM2 space on /dev/sda2, so it panic'ed when
it fell off the end of the initrd because the root= wasn't there.
My first guess for blame:
gregkh-driver-sysfs-allocate-inode-number-using-ida.patch
as that's awfully similar to gregkh-driver-sysfs-fix-i_ino-handling-in-sysfs.patch
that broke 'lvm vgscan' for me in the same way on 21-rc7-mm[12].
I'll hopefully get a chance to revert that one and test later today - a quick
'patch -p1 -R --dry-run' shows a number of conflicts that will need hand-fixing
at the very least.
On Wed, Jun 06, 2007 at 02:07:37AM -0700, Andrew Morton wrote:
>
>ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm1/
>
>- Somebody broke it on my powerpc G5, but I didn't have time to do yet
> another bisection yet.
>
It seems strange that a new C source file (mlguest.c) appears in the top dir of the
kernel source. There are some problems with it.
First, I used `make mlguest.o` to compile that file, but I got tons of warnings and errors.
(Too many to put here.) What's wrong with it? Or I didn't compile/configure it correctly?
Second, mlguest.c #includes a head file named "../../include/linux/lguest_launcher.h".
Since mlguest.c is in the top dir, so where is ../../include/linux/lguest_launcher.h?
Regards!
WANG Cong
On (06/06/07 18:01), Cedric Le Goater didst pronounce:
> > Same problem here
> >
> > http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.22-rc4-mm1/console.log
> >
> > http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.22-rc4-mm1/mm-config2
> >
> >
> > l *__page_check_anon_rmap+0x49
> > 0xc1075ee5 is in __page_check_anon_rmap (mm/rmap.c:557).
> > 552 * over the call to page_add_new_anon_rmap.
> > 553 */
> > 554 struct anon_vma *anon_vma = vma->anon_vma;
> > 555 anon_vma = (void *) anon_vma + PAGE_MAPPING_ANON;
> > 556 BUG_ON(page->mapping != (struct address_space *)anon_vma);
> > 557 BUG_ON(page->index != linear_page_index(vma, address));
> > 558 #endif
> > 559 }
> > 560
> > 561 /**
> >
> > I'll try to revert
> > mm-merge-populate-and-nopage-into-fault-fixes-nonlinear.patch
>
> yes, i gave it a try that but it seems that this patch is heavily
> interlaced with others. I assume Nick has a better understanding
> of the issue.
>
I do not believe this is Nick's problem. I encountered the same issue and
the bisect ended up here;
# BISECT HERE
mm-variable-length-argument-support.patch
mm-variable-length-argument-support-fix.patch
# BISECT BAD
Reverting those two patches boots ok on my standalone x86 laptop. Patch authors
cc'd. I have not read the patches yet to see what might be the problem.
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
On Wed, Jun 06, 2007 at 02:07:37AM -0700, Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm1/
> - Somebody broke it on my powerpc G5, but I didn't have time to do yet
> another bisection yet.
> - There's a lengthy patch series here from Nick which attempts to address
> the longstanding pagefault-vs-buffered-write deadlock.
> A great shower of filesystems were broken and have been disabled with
> CONFIG_BROKEN. This includes reiser4.
> - Complex patches which eliminate the kernel's fixed size limit on the
> command-line length. These break nommu builds.
Someone remind me what the pagefault vs. buffered write deadlock is.
Something brings down i386/qemu before even earlyprintk can handle.
Bisection has narrowed it down to patch 1140 after everything got
renumbered by peterz' fix for mm-variable-length-argument-support.patch,
namely containersv10-make-cpusets-a-client-of-containers.patch
-- wli
On Wed, Jun 06, 2007 at 05:26:49PM +0100, Mel Gorman wrote:
> I do not believe this is Nick's problem. I encountered the same issue and
> the bisect ended up here;
> # BISECT HERE
> mm-variable-length-argument-support.patch
> mm-variable-length-argument-support-fix.patch
> # BISECT BAD
> Reverting those two patches boots ok on my standalone x86 laptop.
> Patch authors cc'd. I have not read the patches yet to see what might
> be the problem.
I found this a while ago and peterz already has a tentative fix for it at
http://programming.kicks-ass.net/kernel-patches/max_arg_pages/move_anon_vma.patch
I'm sure he himself will chime in with more/better code when he returns.
-- wli
Here's a tentative fix for mm-merge-nopfn-into-fault.patch.
./arch/powerpc/platforms/cell/spufs/file.c: In function 'spufs_mem_mmap_fault':
./arch/powerpc/platforms/cell/spufs/file.c:122: error: 'address' undeclared (first use in this function)
./arch/powerpc/platforms/cell/spufs/file.c:122: error: (Each undeclared identifier is reported only once
./arch/powerpc/platforms/cell/spufs/file.c:122: error: for each function it appears in.)
./arch/powerpc/platforms/cell/spufs/file.c:141: error: expected ';' before 'if'
./arch/powerpc/platforms/cell/spufs/file.c:122: warning: unused variable 'addr0'
I'm not sure how useful is the addr0 variable.
Signed-off-by: Cedric Le Goater <[email protected]>
Cc: Arnd Bergmann <[email protected]>
Cc: Nick Piggin <[email protected]>
Cc: Andrew Morton <[email protected]>
---
arch/powerpc/platforms/cell/spufs/file.c | 23 +++++------------------
1 file changed, 5 insertions(+), 18 deletions(-)
Index: 2.6.22-rc4-mm1/arch/powerpc/platforms/cell/spufs/file.c
===================================================================
--- 2.6.22-rc4-mm1.orig/arch/powerpc/platforms/cell/spufs/file.c
+++ 2.6.22-rc4-mm1/arch/powerpc/platforms/cell/spufs/file.c
@@ -53,19 +53,6 @@ spufs_mem_open(struct inode *inode, stru
return 0;
}
-static int
-spufs_mem_release(struct inode *inode, struct file *file)
-{
- struct spufs_inode_info *i = SPUFS_I(inode);
- struct spu_context *ctx = i->i_ctx;
-
- spin_lock(&ctx->mapping_lock);
- if (!--i->i_openers)
- ctx->local_store = NULL;
- spin_unlock(&ctx->mapping_lock);
- return 0;
-}
-
static ssize_t
__spufs_mem_read(struct spu_context *ctx, char __user *buffer,
size_t size, loff_t *pos)
@@ -119,13 +106,13 @@ static struct page *spufs_mem_mmap_fault
struct fault_data *fdata)
{
struct spu_context *ctx = vma->vm_file->private_data;
- unsigned long pfn, offset, addr0 = address;
+ unsigned long pfn, offset, addr0 = fdata->address;
#ifdef CONFIG_SPU_FS_64K_LS
struct spu_state *csa = &ctx->csa;
int psize;
/* Check what page size we are using */
- psize = get_slice_psize(vma->vm_mm, address);
+ psize = get_slice_psize(vma->vm_mm, fdata->address);
/* Some sanity checking */
BUG_ON(csa->use_big_pages != (psize == MMU_PAGE_64K));
@@ -133,18 +120,18 @@ static struct page *spufs_mem_mmap_fault
/* Wow, 64K, cool, we need to align the address though */
if (csa->use_big_pages) {
BUG_ON(vma->vm_start & 0xffff);
- address &= ~0xfffful;
+ fdata->address &= ~0xfffful;
}
#endif /* CONFIG_SPU_FS_64K_LS */
- offset = fdata->pgoff << PAGE_SHIFT
+ offset = fdata->pgoff << PAGE_SHIFT;
if (offset >= LS_SIZE) {
fdata->type = VM_FAULT_SIGBUS;
return NULL;
}
pr_debug("spufs_mem_mmap_nopfn address=0x%lx -> 0x%lx, offset=0x%lx\n",
- addr0, address, offset);
+ addr0, fdata->address, offset);
spu_acquire(ctx);
On (06/06/07 09:35), William Lee Irwin III didst pronounce:
> On Wed, Jun 06, 2007 at 05:26:49PM +0100, Mel Gorman wrote:
> > I do not believe this is Nick's problem. I encountered the same issue and
> > the bisect ended up here;
> > # BISECT HERE
> > mm-variable-length-argument-support.patch
> > mm-variable-length-argument-support-fix.patch
> > # BISECT BAD
> > Reverting those two patches boots ok on my standalone x86 laptop.
> > Patch authors cc'd. I have not read the patches yet to see what might
> > be the problem.
>
> I found this a while ago and peterz already has a tentative fix for it at
> http://programming.kicks-ass.net/kernel-patches/max_arg_pages/move_anon_vma.patch
> I'm sure he himself will chime in with more/better code when he returns.
>
This patch also boots successfully on the machine.
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
On Wed, 06 Jun 2007 13:39:18 +0200 Gabriel C <[email protected]> wrote:
> Andrew Morton wrote:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm1/
> >
> >
>
>
> Compile error here :
>
> ...
>
> LD .tmp_vmlinux1
> drivers/built-in.o: In function `acpi_init':
> bus.c:(.init.text+0x249a): undefined reference to `pci_mmcfg_late_init'
> make: *** [.tmp_vmlinux1] Error 1
>
> ....
>
>
> http://frugalware.org/~crazy/other/mm/2.6.22-rc4-mm1/config
>
Yeah, this caused test.kernel.org to fail as well.
There are a couple of fixes in
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm1/hot-fixes/
which should get things going again.
Robert, I spent some time picking at
mmconfig-validate-against-acpi-motherboard-resources.patch then got bored
with fiddling with it and reverted it outright.
Please, we need to get those prototypes of pci_mmcfg_early_init() and
pci_mmcfg_late_init() into some sane place which works on all
architectures, not duplicate one of them in a C file and even see if we can
avoid the #ifdef CONFIG_PCI_MMCONFIG in arch/i386/pci/init.c
This code area is really messy, due partly to the x86_64 and i386 sharing.
Any changes in there need careful testing and checking.
Mel Gorman wrote:
> On (06/06/07 09:35), William Lee Irwin III didst pronounce:
>> On Wed, Jun 06, 2007 at 05:26:49PM +0100, Mel Gorman wrote:
>>> I do not believe this is Nick's problem. I encountered the same issue and
>>> the bisect ended up here;
>>> # BISECT HERE
>>> mm-variable-length-argument-support.patch
>>> mm-variable-length-argument-support-fix.patch
>>> # BISECT BAD
>>> Reverting those two patches boots ok on my standalone x86 laptop.
>>> Patch authors cc'd. I have not read the patches yet to see what might
>>> be the problem.
>> I found this a while ago and peterz already has a tentative fix for it at
>> http://programming.kicks-ass.net/kernel-patches/max_arg_pages/move_anon_vma.patch
>> I'm sure he himself will chime in with more/better code when he returns.
>>
>
> This patch also boots successfully on the machine.
Same for me.
thanks,
C.
On Wed, 2007-06-06 at 09:35 -0700, William Lee Irwin III wrote:
> On Wed, Jun 06, 2007 at 05:26:49PM +0100, Mel Gorman wrote:
> > I do not believe this is Nick's problem. I encountered the same issue and
> > the bisect ended up here;
> > # BISECT HERE
> > mm-variable-length-argument-support.patch
> > mm-variable-length-argument-support-fix.patch
> > # BISECT BAD
> > Reverting those two patches boots ok on my standalone x86 laptop.
> > Patch authors cc'd. I have not read the patches yet to see what might
> > be the problem.
>
> I found this a while ago and peterz already has a tentative fix for it at
> http://programming.kicks-ass.net/kernel-patches/max_arg_pages/move_anon_vma.patch
> I'm sure he himself will chime in with more/better code when he returns.
Ah, yes indeed. We were discussing wether it would be better to update
page->index (as this patch does) or not change vma->vm_pgoff. Bill
argued that the latter would be safe, it would just limit the merge
capabilities of the anon vma (and the stack rarely, if ever, merges
anyway).
I myself an not quite sure on the effects of ->vm_pgoff of anon vmas
yet.
On Wed, 06 Jun 2007 16:34:04 +0200 Michal Piotrowski <[email protected]> wrote:
> Ok, these patches broke my P4 HT
>
> define-new-percpu-interface-for-shared-data.patch
> use-the-new-percpu-interface-for-shared-data.patch
I dropped them, thanks.
On Wed, 06 Jun 2007 18:53:12 +0200 Cedric Le Goater <[email protected]> wrote:
> Mel Gorman wrote:
> > On (06/06/07 09:35), William Lee Irwin III didst pronounce:
> >> On Wed, Jun 06, 2007 at 05:26:49PM +0100, Mel Gorman wrote:
> >>> I do not believe this is Nick's problem. I encountered the same issue and
> >>> the bisect ended up here;
> >>> # BISECT HERE
> >>> mm-variable-length-argument-support.patch
> >>> mm-variable-length-argument-support-fix.patch
> >>> # BISECT BAD
> >>> Reverting those two patches boots ok on my standalone x86 laptop.
> >>> Patch authors cc'd. I have not read the patches yet to see what might
> >>> be the problem.
> >> I found this a while ago and peterz already has a tentative fix for it at
> >> http://programming.kicks-ass.net/kernel-patches/max_arg_pages/move_anon_vma.patch
> >> I'm sure he himself will chime in with more/better code when he returns.
> >>
> >
> > This patch also boots successfully on the machine.
>
> Same for me.
>
blah. I dropped the whole lot. Am shedding patches like leaves in autumn
at present. Expect -mm2 RSN.
On Wed, 06 Jun 2007 14:48:52 +0100 Andy Whitcroft <[email protected]> wrote:
> Cedric Le Goater wrote:
> > Andrew,
> >
> > here's a minor fix for x86_64,
> >
> > C.
> >
> >
> > when CONFIG_PM=y and CONFIG_SOFTWARE_SUSPEND=n,
> >
> > CC arch/x86_64/kernel/e820.o
> > /home/legoater/linux/2.6.22-rc4-mm1/arch/x86_64/kernel/e820.c: In function `e820_mark_nosave_regions':
> > /home/legoater/linux/2.6.22-rc4-mm1/arch/x86_64/kernel/e820.c:248: warning: implicit declaration of function `register_nosave_region'
> >
> > Signed-off-by: Cedric Le Goater <[email protected]>
> > ---
> > include/linux/suspend.h | 8 ++++++++
> > 1 file changed, 8 insertions(+)
> >
> > Index: 2.6.22-rc4-mm1/include/linux/suspend.h
> > ===================================================================
> > --- 2.6.22-rc4-mm1.orig/include/linux/suspend.h
> > +++ 2.6.22-rc4-mm1/include/linux/suspend.h
> > @@ -74,6 +74,14 @@
> > extern void hibernation_set_ops(struct hibernation_ops *ops);
> > extern int hibernate(void);
> > #else /* CONFIG_SOFTWARE_SUSPEND */
> > +static inline void register_nosave_region(unsigned long b, unsigned long e)
> > +{
> > +}
> > +
> > +static inline void register_nosave_region_late(unsigned long b, unsigned long e)
> > +{
> > +}
> > +
> > static inline int swsusp_page_is_forbidden(struct page *p) { return 0; }
> > static inline void swsusp_set_page_free(struct page *p) {}
> > static inline void swsusp_unset_page_free(struct page *p) {}
> > -
>
>
> Looks like this is the cause of a bunch of compile failures across our
> testing. Will shove this through tko.
>
Yeah. I put a different fix into the hot-fixes directory, thanks.
The powerpc failure is nasty - probably a toolchain stupidity. I reverted
slub-use-ilog2-instead-of-series-of-constant-comparisons.patch which
_should_ fix it, but really the problem is triggered by ilog2().
On Wed, 06 Jun 2007 14:49:25 +0100 Andy Whitcroft <[email protected]> wrote:
> Seeing this on an ia64:
>
> drivers/built-in.o: In function `efi_setup_pcdp_console':
> (.init.text+0x13be2): undefined reference to `early_serial_console_init'
> drivers/built-in.o: In function `efi_setup_pcdp_console':
> (.init.text+0x13de2): undefined reference to `early_serial_console_init'
> make: *** [.tmp_vmlinux1] Error 1
We really exceeded ourselves this time. .config, please?
On Wed, 06 Jun 2007 15:00:17 +0100 Andy Whitcroft <[email protected]> wrote:
> Getting this on a bigger x86_64 (bl6-13):
>
> Unable to handle kernel NULL pointer dereference at 0000000000000000 RIP:
> [<ffffffff8037898b>] acpi_processor_throttling_seq_show+0xa7/0xd6
> PGD 2d77067 PUD 34c3067 PMD 0
> Oops: 0000 [1] SMP
> CPU 3
> Modules linked in: video output button battery asus_acpi ac lp
> parport_pc parport floppy nvram amd_rng rng_core i2c_amd756 i2c_core
> Pid: 1634, comm: head Not tainted 2.6.22-rc4-mm1-autokern1 #1
> RIP: 0010:[<ffffffff8037898b>] [<ffffffff8037898b>]
> acpi_processor_throttling_seq_show+0xa7/0xd6
> RSP: 0018:ffff810003c9de48 EFLAGS: 00010246
> RAX: 0000000000000020 RBX: ffff8100029e7800 RCX: 0000000000000000
> RDX: 000000000000002a RSI: ffffffff805993e4 RDI: ffff810002d714c0
> RBP: ffff810002d714c0 R08: ffff810003f82051 R09: ffff810002d714c0
> R10: ffffffffffffffff R11: 0000000000000000 R12: 0000000000000000
> R13: 0000000000000000 R14: 0000000000000000 R15: 00007fff64fd2b90
> FS: 00002b3545aec6f0(0000) GS:ffff810001683a40(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> CR2: 0000000000000000 CR3: 0000000003966000 CR4: 00000000000006e0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Process head (pid: 1634, threadinfo ffff810003c9c000, task ffff810001c8c810)
> Stack: 00000000000000d0 ffff810002d714c0 0000000000000001 0000000000000001
> 0000000000002000 ffffffff802ab6eb ffff810003c9df50 ffff810002915d00
> ffff810002d714f0 ffff810002fa2000 0000000000000000 fffffffffffffffb
> Call Trace:
> [<ffffffff802ab6eb>] seq_read+0x105/0x28e
> [<ffffffff802ab5e6>] seq_read+0x0/0x28e
> [<ffffffff802cd085>] proc_reg_read+0x80/0x9a
> [<ffffffff802925a7>] vfs_read+0xcb/0x153
> [<ffffffff80292943>] sys_read+0x45/0x6e
> [<ffffffff8020bc5e>] system_call+0x7e/0x83
>
>
> Code: 45 8b 44 0d 00 44 89 e1 0f 45 d0 31 c0 49 ff c4 49 83 c5 28
> RIP [<ffffffff8037898b>] acpi_processor_throttling_seq_show+0xa7/0xd6
> RSP <ffff810003c9de48>
> CR2: 0000000000000000
> FATAL: Error inserting acpi_cpufreq
> (/lib/modules/2.6.22-rc4-mm1-autokern1/kernel/arch/x86_64/kernel/cpufreq/acpi-cpufreq.ko):
> No such device
Was the oops at modprobe time? If so, it seems weird that
acpi_processor_throttling_seq_show() would be getting run at that stage.
(The oops trace is supposed to show the oopsing process's
task_struct.comm[], but it isn't shown here?)
Anyway, there are extensive changes in there added by git-acpi.patch. I
suppose we can try to limp along with the below, but it'll probably just
oops later on.
--- a/drivers/acpi/processor_throttling.c~git-acpi-disable-acpi_processor_throttling_seq_show
+++ a/drivers/acpi/processor_throttling.c
@@ -648,6 +648,9 @@ static int acpi_processor_throttling_seq
goto end;
}
+ seq_puts(seq, "acpi_processor_throttling_seq_show() is busted\n");
+ goto end;
+
seq_printf(seq, "state count: %d\n"
"active state: T%d\n"
"state available: T%d to T%d\n",
_
On Wed, 06 Jun 2007 17:34:16 +0200 Jiri Slaby <[email protected]> wrote:
> Mikael Pettersson napsal(a):
> > On Wed, 06 Jun 2007 15:04:00 +0200, Jiri Slaby wrote:
> >> Andrew Morton napsal(a):
> >>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm1/
> >> It freezes during bootup while searching for sata drives on sata_promise. There
> >> were 2 issues with sata_promise in -rc4 IIRC, one was fixed, the latter remains
> >> unresolved. Or, should be this solved too, Mikael, Tejun and is this yet
> >> eanother problem? (In this case I'll post dmesg and co.)
> >
> > I know of only one sata_promise-specific issue in 2.6.22-rc4.
> > Tejun's "sata_promise: use TF interface for polling NODATA commands"
> > patch posted today fixes it.
>
> It's in that -mm, so I think, this seems to be another problem.
No, it wasn't in 2.6.22-rc4-mm1.
Here it is - please test?
From: Tejun Heo <[email protected]>
sata_promise uses two different command modes - packet and TF. Packet mode
is intelligent low-overhead mode while TF is the same old taskfile
interface. As with other advanced interface (ahci/sil24),
ATA_TFLAG_POLLING has no effect in packet mode. However, PIO commands are
issued using TF interface in polling mode, so pdc_interrupt() considers
interrupts spurious if ATA_TFLAG_POLLING is set.
This is broken for polling NODATA commands because command is issued using
packet mode but the interrupt handler ignores it due to ATA_TFLAG_POLLING.
Fix pdc_qc_issue_prot() such that ATA/ATAPI NODATA commands are issued
using TF interface if ATA_TFLAG_POLLING is set.
This patch fixes detection failure introduced by polling SETXFERMODE.
Signed-off-by: Tejun Heo <[email protected]>
Acked-by: Mikael Pettersson <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
---
drivers/ata/sata_promise.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff -puN drivers/ata/sata_promise.c~sata_promise-use-tf-interface-for-polling-nodata-commands drivers/ata/sata_promise.c
--- a/drivers/ata/sata_promise.c~sata_promise-use-tf-interface-for-polling-nodata-commands
+++ a/drivers/ata/sata_promise.c
@@ -784,9 +784,12 @@ static unsigned int pdc_qc_issue_prot(st
if (qc->dev->flags & ATA_DFLAG_CDB_INTR)
break;
/*FALLTHROUGH*/
+ case ATA_PROT_NODATA:
+ if (qc->tf.flags & ATA_TFLAG_POLLING)
+ break;
+ /*FALLTHROUGH*/
case ATA_PROT_ATAPI_DMA:
case ATA_PROT_DMA:
- case ATA_PROT_NODATA:
pdc_packet_start(qc);
return 0;
@@ -800,7 +803,7 @@ static unsigned int pdc_qc_issue_prot(st
static void pdc_tf_load_mmio(struct ata_port *ap, const struct ata_taskfile *tf)
{
WARN_ON (tf->protocol == ATA_PROT_DMA ||
- tf->protocol == ATA_PROT_NODATA);
+ tf->protocol == ATA_PROT_ATAPI_DMA);
ata_tf_load(ap, tf);
}
@@ -808,7 +811,7 @@ static void pdc_tf_load_mmio(struct ata_
static void pdc_exec_command_mmio(struct ata_port *ap, const struct ata_taskfile *tf)
{
WARN_ON (tf->protocol == ATA_PROT_DMA ||
- tf->protocol == ATA_PROT_NODATA);
+ tf->protocol == ATA_PROT_ATAPI_DMA);
ata_exec_command(ap, tf);
}
_
On Thu, 7 Jun 2007 00:19:36 +0800 WANG Cong <[email protected]> wrote:
> On Wed, Jun 06, 2007 at 02:07:37AM -0700, Andrew Morton wrote:
> >
> >ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm1/
> >
> >- Somebody broke it on my powerpc G5, but I didn't have time to do yet
> > another bisection yet.
> >
>
> It seems strange that a new C source file (mlguest.c) appears in the top dir of the
> kernel source. There are some problems with it.
>
> First, I used `make mlguest.o` to compile that file, but I got tons of warnings and errors.
> (Too many to put here.) What's wrong with it? Or I didn't compile/configure it correctly?
>
> Second, mlguest.c #includes a head file named "../../include/linux/lguest_launcher.h".
> Since mlguest.c is in the top dir, so where is ../../include/linux/lguest_launcher.h?
>
Confused. I've grepped the entire universe here for "mlguest" and came up
with nothing.
I don't have a clue where that file came from on your system.
Andrew Morton wrote:
> On Wed, 06 Jun 2007 14:49:25 +0100 Andy Whitcroft <[email protected]> wrote:
>
>> Seeing this on an ia64:
>>
>> drivers/built-in.o: In function `efi_setup_pcdp_console':
>> (.init.text+0x13be2): undefined reference to `early_serial_console_init'
>> drivers/built-in.o: In function `efi_setup_pcdp_console':
>> (.init.text+0x13de2): undefined reference to `early_serial_console_init'
>> make: *** [.tmp_vmlinux1] Error 1
>
> We really exceeded ourselves this time. .config, please?
Oh, i miss that file. will submit the patch.
YH
On Wed, 6 Jun 2007 09:30:53 -0700 William Lee Irwin III <[email protected]> wrote:
> On Wed, Jun 06, 2007 at 02:07:37AM -0700, Andrew Morton wrote:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm1/
> > - Somebody broke it on my powerpc G5, but I didn't have time to do yet
> > another bisection yet.
> > - There's a lengthy patch series here from Nick which attempts to address
> > the longstanding pagefault-vs-buffered-write deadlock.
> > A great shower of filesystems were broken and have been disabled with
> > CONFIG_BROKEN. This includes reiser4.
> > - Complex patches which eliminate the kernel's fixed size limit on the
> > command-line length. These break nommu builds.
>
> Someone remind me what the pagefault vs. buffered write deadlock is.
generic_file_write() does lock_page(), then copies the user's data into
pagecache. If that copy_from_user() encounters a major fault and the page
is not uptodate, the pagefault handler does lock_page() and deadlocks.
It requires that the user be writ()ing from a mmap of the page back into
the same page, which is weird.
The kernel tries to prefault the page to avoid the copy_from_user() fault,
but there are ways in whcih that can be defeated (super memory pressure,
malicious fadvise() from a second thread, etc).
> Something brings down i386/qemu before even earlyprintk can handle.
>
> Bisection has narrowed it down to patch 1140 after everything got
> renumbered by peterz' fix for mm-variable-length-argument-support.patch,
> namely containersv10-make-cpusets-a-client-of-containers.patch
erk. A step-by-step how-to-make-this-happen might help if poss, please.
Robert Hancock wrote:
> Gabriel C wrote:
>> Andrew Morton wrote:
>>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm1/
>>>
>>>
>>>
>>
>>
>> Compile error here :
>>
>> ..
>>
>> LD .tmp_vmlinux1
>> drivers/built-in.o: In function `acpi_init':
>> bus.c:(.init.text+0x249a): undefined reference to `pci_mmcfg_late_init'
>> make: *** [.tmp_vmlinux1] Error 1
>>
>> ...
>>
>>
>> http://frugalware.org/~crazy/other/mm/2.6.22-rc4-mm1/config
>>
>> Regards,
>>
>> Gabriel
>
> Presumably because:
>
> # CONFIG_PCI_GOMMCONFIG is not set
>
> I'll cook up a patch later today.
This one is affecting machines in TKO noce that the e820 problem is fixed.
-apw
William Lee Irwin III wrote:
> On Wed, Jun 06, 2007 at 02:07:37AM -0700, Andrew Morton wrote:
>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm1/
>> - Somebody broke it on my powerpc G5, but I didn't have time to do yet
>> another bisection yet.
>> - There's a lengthy patch series here from Nick which attempts to address
>> the longstanding pagefault-vs-buffered-write deadlock.
>> A great shower of filesystems were broken and have been disabled with
>> CONFIG_BROKEN. This includes reiser4.
>> - Complex patches which eliminate the kernel's fixed size limit on the
>> command-line length. These break nommu builds.
>
> Someone remind me what the pagefault vs. buffered write deadlock is.
>
> Something brings down i386/qemu before even earlyprintk can handle.
>
> Bisection has narrowed it down to patch 1140 after everything got
> renumbered by peterz' fix for mm-variable-length-argument-support.patch,
> namely containersv10-make-cpusets-a-client-of-containers.patch
Interestingly (and perhaps unrelatedly) on my _good_ boots the first
printk is no longer the kernel banner but the following which sounds
container related also:
Initializing container subsys cpuset
-apw
Andrew Morton napsal(a):
> On Wed, 06 Jun 2007 17:34:16 +0200 Jiri Slaby <[email protected]> wrote:
>
>> Mikael Pettersson napsal(a):
>>> On Wed, 06 Jun 2007 15:04:00 +0200, Jiri Slaby wrote:
>>>> Andrew Morton napsal(a):
>>>>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm1/
>>>> It freezes during bootup while searching for sata drives on sata_promise. There
>>>> were 2 issues with sata_promise in -rc4 IIRC, one was fixed, the latter remains
>>>> unresolved. Or, should be this solved too, Mikael, Tejun and is this yet
>>>> eanother problem? (In this case I'll post dmesg and co.)
>>> I know of only one sata_promise-specific issue in 2.6.22-rc4.
>>> Tejun's "sata_promise: use TF interface for polling NODATA commands"
>>> patch posted today fixes it.
>> It's in that -mm, so I think, this seems to be another problem.
>
> No, it wasn't in 2.6.22-rc4-mm1.
Huh, what did I smoke? Something rejects to patch and now I don't know what.
> Here it is - please test?
Ok, this solves this problem, but LVM is broken. Seems similar to
Re: 2.6.22-rc4-mm1 - 'lvm vgscan' busticated again...
Message-ID: <[email protected]>
Will try to play with this.
> From: Tejun Heo <[email protected]>
>
> sata_promise uses two different command modes - packet and TF. Packet mode
> is intelligent low-overhead mode while TF is the same old taskfile
> interface. As with other advanced interface (ahci/sil24),
> ATA_TFLAG_POLLING has no effect in packet mode. However, PIO commands are
> issued using TF interface in polling mode, so pdc_interrupt() considers
> interrupts spurious if ATA_TFLAG_POLLING is set.
>
> This is broken for polling NODATA commands because command is issued using
> packet mode but the interrupt handler ignores it due to ATA_TFLAG_POLLING.
> Fix pdc_qc_issue_prot() such that ATA/ATAPI NODATA commands are issued
> using TF interface if ATA_TFLAG_POLLING is set.
>
> This patch fixes detection failure introduced by polling SETXFERMODE.
>
> Signed-off-by: Tejun Heo <[email protected]>
> Acked-by: Mikael Pettersson <[email protected]>
> Signed-off-by: Andrew Morton <[email protected]>
> ---
>
> drivers/ata/sata_promise.c | 9 ++++++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff -puN drivers/ata/sata_promise.c~sata_promise-use-tf-interface-for-polling-nodata-commands drivers/ata/sata_promise.c
> --- a/drivers/ata/sata_promise.c~sata_promise-use-tf-interface-for-polling-nodata-commands
> +++ a/drivers/ata/sata_promise.c
> @@ -784,9 +784,12 @@ static unsigned int pdc_qc_issue_prot(st
> if (qc->dev->flags & ATA_DFLAG_CDB_INTR)
> break;
> /*FALLTHROUGH*/
> + case ATA_PROT_NODATA:
> + if (qc->tf.flags & ATA_TFLAG_POLLING)
> + break;
> + /*FALLTHROUGH*/
> case ATA_PROT_ATAPI_DMA:
> case ATA_PROT_DMA:
> - case ATA_PROT_NODATA:
> pdc_packet_start(qc);
> return 0;
>
> @@ -800,7 +803,7 @@ static unsigned int pdc_qc_issue_prot(st
> static void pdc_tf_load_mmio(struct ata_port *ap, const struct ata_taskfile *tf)
> {
> WARN_ON (tf->protocol == ATA_PROT_DMA ||
> - tf->protocol == ATA_PROT_NODATA);
> + tf->protocol == ATA_PROT_ATAPI_DMA);
> ata_tf_load(ap, tf);
> }
>
> @@ -808,7 +811,7 @@ static void pdc_tf_load_mmio(struct ata_
> static void pdc_exec_command_mmio(struct ata_port *ap, const struct ata_taskfile *tf)
> {
> WARN_ON (tf->protocol == ATA_PROT_DMA ||
> - tf->protocol == ATA_PROT_NODATA);
> + tf->protocol == ATA_PROT_ATAPI_DMA);
> ata_exec_command(ap, tf);
> }
regards,
--
http://www.fi.muni.cz/~xslaby/ Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E
On Wed, 06 Jun 2007 19:18:58 +0100 Andy Whitcroft <[email protected]> wrote:
> >> http://frugalware.org/~crazy/other/mm/2.6.22-rc4-mm1/config
> >>
> >> Regards,
> >>
> >> Gabriel
> >
> > Presumably because:
> >
> > # CONFIG_PCI_GOMMCONFIG is not set
> >
> > I'll cook up a patch later today.
>
> This one is affecting machines in TKO noce that the e820 problem is fixed.
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm1/hot-fixes/revert-mmconfig-validate-against-acpi-motherboard-resources.patch
should fix that.
Andrew Morton pisze:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm1/
>
Kay, your patch gregkh-driver-block-device.patch breaks Fedora 7 initrd
http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.22-rc4-mm1/initrd.jpg
Please fix it ASAP, I can't test kernel...
Regards,
Michal
--
"Najbardziej brakowało mi twojego milczenia."
-- Andrzej Sapkowski "Coś więcej"
Andrew Morton wrote:
> On Wed, 06 Jun 2007 19:18:58 +0100 Andy Whitcroft <[email protected]> wrote:
>
>>>> http://frugalware.org/~crazy/other/mm/2.6.22-rc4-mm1/config
>>>>
>>>> Regards,
>>>>
>>>> Gabriel
>>> Presumably because:
>>>
>>> # CONFIG_PCI_GOMMCONFIG is not set
>>>
>>> I'll cook up a patch later today.
>> This one is affecting machines in TKO noce that the e820 problem is fixed.
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm1/hot-fixes/revert-mmconfig-validate-against-acpi-motherboard-resources.patch
> should fix that.
TKO _should_ pick that up automatically.
Indeed there seem to be some GOOD status' popping out on those machines
now. They should be up on TKO shortly.
Thanks.
-apw
On Wed, 2007-06-06 at 19:06 +0200, Peter Zijlstra wrote:
> On Wed, 2007-06-06 at 09:35 -0700, William Lee Irwin III wrote:
> > On Wed, Jun 06, 2007 at 05:26:49PM +0100, Mel Gorman wrote:
> > > I do not believe this is Nick's problem. I encountered the same issue and
> > > the bisect ended up here;
> > > # BISECT HERE
> > > mm-variable-length-argument-support.patch
> > > mm-variable-length-argument-support-fix.patch
> > > # BISECT BAD
> > > Reverting those two patches boots ok on my standalone x86 laptop.
> > > Patch authors cc'd. I have not read the patches yet to see what might
> > > be the problem.
> >
> > I found this a while ago and peterz already has a tentative fix for it at
> > http://programming.kicks-ass.net/kernel-patches/max_arg_pages/move_anon_vma.patch
> > I'm sure he himself will chime in with more/better code when he returns.
>
> Ah, yes indeed. We were discussing wether it would be better to update
> page->index (as this patch does) or not change vma->vm_pgoff. Bill
> argued that the latter would be safe, it would just limit the merge
> capabilities of the anon vma (and the stack rarely, if ever, merges
> anyway).
>
> I myself an not quite sure on the effects of ->vm_pgoff of anon vmas
> yet.
Ok, from what I can make of it, nobody relies on the value of
vma->vm_pgoff for anon vmas as long as the following invariant is kept:
vaddr = vma->vm_start + (page->index - vma->vm_pgoff)*PAGE_SIZE
So the proper thing to do is not change vm_pgoff.
Hello,
This is from my P4 sony vaio laptop.
These warnings still there:
drivers/input/keyboard/Kconfig:170:warning: 'select' used by config symbol 'KEYBOARD_ATARI' refers to undefined symbol 'ATARI_KBD_CORE'
drivers/input/mouse/Kconfig:182:warning: 'select' used by config symbol 'MOUSE_ATARI' refers to undefined symbol 'ATARI_KBD_CORE'
sound/soc/sh/Kconfig:6:warning: 'select' used by config symbol 'SND_SOC_PCM_SH7760' refers to undefined symbol 'SH_DMABRG'
A hwmon related build error:
Building modules, stage 2.
MODPOST 187 modules
ERROR: "input_register_polled_device" [drivers/hwmon/hdaps.ko] undefined!
ERROR: "input_allocate_polled_device" [drivers/hwmon/hdaps.ko] undefined!
ERROR: "input_free_polled_device" [drivers/hwmon/hdaps.ko] undefined!
ERROR: "input_unregister_polled_device" [drivers/hwmon/hdaps.ko] undefined!
ERROR: "input_register_polled_device" [drivers/hwmon/applesmc.ko] undefined!
ERROR: "input_allocate_polled_device" [drivers/hwmon/applesmc.ko] undefined!
ERROR: "input_free_polled_device" [drivers/hwmon/applesmc.ko] undefined!
ERROR: "input_unregister_polled_device" [drivers/hwmon/applesmc.ko] undefined!
make[1]: *** [__modpost] Error 1
make: *** [modules] Error 2
And for some reason the whole Cryptographic API is under the main level of menu
(please find .config and menu.png attached).
More tests soon.
Mariusz
On Wed, 6 Jun 2007 09:30:53 -0700 William Lee Irwin III <[email protected]> wrote:
>> Something brings down i386/qemu before even earlyprintk can handle.
>> Bisection has narrowed it down to patch 1140 after everything got
>> renumbered by peterz' fix for mm-variable-length-argument-support.patch,
>> namely containersv10-make-cpusets-a-client-of-containers.patch
On Wed, Jun 06, 2007 at 11:13:15AM -0700, Andrew Morton wrote:
> erk. A step-by-step how-to-make-this-happen might help if poss, please.
(1) build for i386 with my .config
(2) attempt to boot in qemu's i386 system simulator
I'm not seeing the sort of nondeterminism Andy Whitcroft is. It breaks
every time when I try this.
-- wli
On Wed, 06 Jun 2007 20:48:45 +0200 Michal Piotrowski <[email protected]> wrote:
> Andrew Morton pisze:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm1/
> >
>
> Kay, your patch gregkh-driver-block-device.patch breaks Fedora 7 initrd
> http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.22-rc4-mm1/initrd.jpg
>
> Please fix it ASAP, I can't test kernel...
>
Yes, that looks just like what I was seeing on the yellowdog powerpc machine.
Is uses http://userweb.kernel.org/~akpm/config-g5.txt (plus `make oldconfig' of
course).
I'll revert it.
On Wed, 6 Jun 2007 21:32:36 +0200 Mariusz Kozlowski <[email protected]> wrote:
> Hello,
>
> This is from my P4 sony vaio laptop.
>
> These warnings still there:
>
> drivers/input/keyboard/Kconfig:170:warning: 'select' used by config symbol 'KEYBOARD_ATARI' refers to undefined symbol 'ATARI_KBD_CORE'
> drivers/input/mouse/Kconfig:182:warning: 'select' used by config symbol 'MOUSE_ATARI' refers to undefined symbol 'ATARI_KBD_CORE'
> sound/soc/sh/Kconfig:6:warning: 'select' used by config symbol 'SND_SOC_PCM_SH7760' refers to undefined symbol 'SH_DMABRG'
Yeah, people keep adding those and then never fixing them. I've given up
and I just ignore them.
> A hwmon related build error:
>
> Building modules, stage 2.
> MODPOST 187 modules
> ERROR: "input_register_polled_device" [drivers/hwmon/hdaps.ko] undefined!
> ERROR: "input_allocate_polled_device" [drivers/hwmon/hdaps.ko] undefined!
> ERROR: "input_free_polled_device" [drivers/hwmon/hdaps.ko] undefined!
> ERROR: "input_unregister_polled_device" [drivers/hwmon/hdaps.ko] undefined!
> ERROR: "input_register_polled_device" [drivers/hwmon/applesmc.ko] undefined!
> ERROR: "input_allocate_polled_device" [drivers/hwmon/applesmc.ko] undefined!
> ERROR: "input_free_polled_device" [drivers/hwmon/applesmc.ko] undefined!
> ERROR: "input_unregister_polled_device" [drivers/hwmon/applesmc.ko] undefined!
> make[1]: *** [__modpost] Error 1
> make: *** [modules] Error 2
Yes, this is being argued on the lm-sensors list, of all places. For now
you'll need to manually set CONFIG_INPUT_POLLDEV, I assume.
> And for some reason the whole Cryptographic API is under the main level of menu
> (please find .config and menu.png attached).
err, yes. git-cryptodev.patch did that. Herbert is being immodest ;)
Hi
On 6/6/07, Andrew Morton <[email protected]> wrote:
> On Wed, 6 Jun 2007 21:32:36 +0200 Mariusz Kozlowski <[email protected]> wrote:
>
> > Hello,
> >
> > This is from my P4 sony vaio laptop.
> >
> > These warnings still there:
> >
> > drivers/input/keyboard/Kconfig:170:warning: 'select' used by config symbol 'KEYBOARD_ATARI' refers to undefined symbol 'ATARI_KBD_CORE'
> > drivers/input/mouse/Kconfig:182:warning: 'select' used by config symbol 'MOUSE_ATARI' refers to undefined symbol 'ATARI_KBD_CORE'
> > sound/soc/sh/Kconfig:6:warning: 'select' used by config symbol 'SND_SOC_PCM_SH7760' refers to undefined symbol 'SH_DMABRG'
>
> Yeah, people keep adding those and then never fixing them. I've given up
> and I just ignore them.
Maybe it is because ATARI_KBD_CORE is defined only in arch/m68k.
On Wednesday 06 June 2007 10:07:37 Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm1/
Patch 'usb-try-to-debug-bug-8561' triggers when I plug in a usb flash drive:
[10998.881000] usb 1-10: new high speed USB device using ehci_hcd and address 3
[10999.001000] usb 1-10: new device found, idVendor=13fe, idProduct=1a00
[10999.002000] usb 1-10: new device strings: Mfr=1, Product=2, SerialNumber=3
[10999.016000] usb 1-10: Product: USB DISK 2.0
[10999.025000] usb 1-10: Manufacturer:
[10999.033000] usb 1-10: SerialNumber: 07720947018D
[10999.034000] usb 1-10: configuration #1 chosen from 1 choice
[10999.047000] scsi8 : SCSI emulation for USB Mass Storage devices
[11004.055000] WARNING: at drivers/usb/core/urb.c:293 usb_submit_urb()
[11004.055000]
[11004.055000] Call Trace:
[11004.055000] [<ffffffff8020d30f>] dump_trace+0x43f/0x480
[11004.055000] [<ffffffff8020d393>] show_trace+0x43/0x70
[11004.055000] [<ffffffff8020d3d5>] dump_stack+0x15/0x20
[11004.055000] [<ffffffff804b4314>] usb_submit_urb+0x224/0x240
[11004.055000] [<ffffffff804b5ff5>] usb_sg_wait+0xd5/0x180
[11004.055000] [<ffffffff804cf464>] usb_stor_bulk_transfer_sg+0xc4/0x120
[11004.055000] [<ffffffff804cf611>] usb_stor_Bulk_transport+0x151/0x2e0
[11004.055000] [<ffffffff804cfb57>] usb_stor_invoke_transport+0x37/0x380
[11004.055000] [<ffffffff804ce9f9>] usb_stor_transparent_scsi_command+0x9/0x10
[11004.055000] [<ffffffff804d0aea>] usb_stor_control_thread+0x18a/0x230
[11004.055000] [<ffffffff8024927d>] kthread+0x4d/0x80
[11004.055000] [<ffffffff8020c868>] child_rip+0xa/0x12
Cheers,
Grant
On Wed, Jun 06, 2007 at 01:24:39PM -0700, Andrew Morton wrote:
>
> > And for some reason the whole Cryptographic API is under the main level of menu
> > (please find .config and menu.png attached).
>
> err, yes. git-cryptodev.patch did that. Herbert is being immodest ;)
Is it this patch? If so then you sent to it me :)
Should I drop it?
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
commit a85e40c4a0d4fd87e3f9449faac98db0d7d6ac78
Author: Jan Engelhardt <[email protected]>
Date: Fri May 18 15:11:01 2007 +1000
[CRYPTO] Kconfig: Use menuconfig objects
Use menuconfigs instead of menus, so the whole menu can be disabled at once
instead of going through all options.
Signed-off-by: Jan Engelhardt <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
a85e40c4a0d4fd87e3f9449faac98db0d7d6ac78
diff --git a/crypto/Kconfig b/crypto/Kconfig
index 4ca0ab3..935301e 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -2,9 +2,7 @@
# Cryptographic API Configuration
#
-menu "Cryptographic options"
-
-config CRYPTO
+menuconfig CRYPTO
bool "Cryptographic API"
help
This option provides the core Cryptographic API.
@@ -463,5 +461,3 @@ config CRYPTO_TEST
source "drivers/crypto/Kconfig"
endif # if CRYPTO
-
-endmenu
On Wed, 2007-06-06 at 20:48 +0200, Michal Piotrowski wrote:
> Andrew Morton pisze:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm1/
> >
>
> Kay, your patch gregkh-driver-block-device.patch breaks Fedora 7 initrd
> http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.22-rc4-mm1/initrd.jpg
>
> Please fix it ASAP, I can't test kernel...
Do you have CONFIG_SYSFS_DEPRECATED set or unset?
Kay
On Wed, 6 Jun 2007 21:58:38 +0100 Grant Wilson <[email protected]> wrote:
> On Wednesday 06 June 2007 10:07:37 Andrew Morton wrote:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm1/
>
> Patch 'usb-try-to-debug-bug-8561' triggers when I plug in a usb flash drive:
Cool, thanks.
> [10998.881000] usb 1-10: new high speed USB device using ehci_hcd and address 3
> [10999.001000] usb 1-10: new device found, idVendor=13fe, idProduct=1a00
> [10999.002000] usb 1-10: new device strings: Mfr=1, Product=2, SerialNumber=3
> [10999.016000] usb 1-10: Product: USB DISK 2.0
> [10999.025000] usb 1-10: Manufacturer:
> [10999.033000] usb 1-10: SerialNumber: 07720947018D
> [10999.034000] usb 1-10: configuration #1 chosen from 1 choice
> [10999.047000] scsi8 : SCSI emulation for USB Mass Storage devices
> [11004.055000] WARNING: at drivers/usb/core/urb.c:293 usb_submit_urb()
> [11004.055000]
> [11004.055000] Call Trace:
> [11004.055000] [<ffffffff8020d30f>] dump_trace+0x43f/0x480
> [11004.055000] [<ffffffff8020d393>] show_trace+0x43/0x70
> [11004.055000] [<ffffffff8020d3d5>] dump_stack+0x15/0x20
> [11004.055000] [<ffffffff804b4314>] usb_submit_urb+0x224/0x240
> [11004.055000] [<ffffffff804b5ff5>] usb_sg_wait+0xd5/0x180
> [11004.055000] [<ffffffff804cf464>] usb_stor_bulk_transfer_sg+0xc4/0x120
> [11004.055000] [<ffffffff804cf611>] usb_stor_Bulk_transport+0x151/0x2e0
> [11004.055000] [<ffffffff804cfb57>] usb_stor_invoke_transport+0x37/0x380
> [11004.055000] [<ffffffff804ce9f9>] usb_stor_transparent_scsi_command+0x9/0x10
> [11004.055000] [<ffffffff804d0aea>] usb_stor_control_thread+0x18a/0x230
> [11004.055000] [<ffffffff8024927d>] kthread+0x4d/0x80
> [11004.055000] [<ffffffff8020c868>] child_rip+0xa/0x12
>
Alan, you got a bite - reel her in!
On Thu, 7 Jun 2007 07:28:31 +1000 Herbert Xu <[email protected]> wrote:
> On Wed, Jun 06, 2007 at 01:24:39PM -0700, Andrew Morton wrote:
> >
> > > And for some reason the whole Cryptographic API is under the main level of menu
> > > (please find .config and menu.png attached).
> >
> > err, yes. git-cryptodev.patch did that. Herbert is being immodest ;)
>
> Is it this patch?
looks like it.
> If so then you sent to it me :)
You merged it ;)
> Should I drop it?
Sure, Jan will fix it up, I assume. I might have broken it while repairing
the reject storm which occurred when that durned HAS_IOMEM thing went in
all over the tree.
Andrew Morton wrote:
> Yeah, this caused test.kernel.org to fail as well.
>
> There are a couple of fixes in
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm1/hot-fixes/
> which should get things going again.
>
> Robert, I spent some time picking at
> mmconfig-validate-against-acpi-motherboard-resources.patch then got bored
> with fiddling with it and reverted it outright.
The minimal fix would be to put #ifdef CONFIG_PCI_MMCONFIG around the
call to pci_mmcfg_late_init in drivers/acpi/bus.c.
>
> Please, we need to get those prototypes of pci_mmcfg_early_init() and
> pci_mmcfg_late_init() into some sane place which works on all
> architectures, not duplicate one of them in a C file and even see if we can
> avoid the #ifdef CONFIG_PCI_MMCONFIG in arch/i386/pci/init.c
>
> This code area is really messy, due partly to the x86_64 and i386 sharing.
> Any changes in there need careful testing and checking.
I'm not sure there's a point in making the prototypes for those
functions global to all architectures, since it's unlikely anything
non-X86 could make use of them with any similar semantics. We could
provide a no-op definition of those functions to avoid the need to ifdef
the calls, though.
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from [email protected]
Home Page: http://www.roberthancock.com/
On 6/6/07, William Lee Irwin III <[email protected]> wrote:
>
> (1) build for i386 with my .config
> (2) attempt to boot in qemu's i386 system simulator
>
> I'm not seeing the sort of nondeterminism Andy Whitcroft is. It breaks
> every time when I try this.
>
Looks to be lockdep related - it's reproducible for me when I turn on
CONFIG_LOCKDEP and the early crash goes away when I move the
container_init_early() call to after lockdep_init().
Paul
On Wed, 6 Jun 2007 17:32:33 -0700 "Paul Menage" <[email protected]> wrote:
> On 6/6/07, William Lee Irwin III <[email protected]> wrote:
> >
> > (1) build for i386 with my .config
> > (2) attempt to boot in qemu's i386 system simulator
> >
> > I'm not seeing the sort of nondeterminism Andy Whitcroft is. It breaks
> > every time when I try this.
> >
>
> Looks to be lockdep related - it's reproducible for me when I turn on
> CONFIG_LOCKDEP and the early crash goes away when I move the
> container_init_early() call to after lockdep_init().
>
ooh, yes, lockdep_init() really does want to be called before anything
else.
So do we take it that this code hasn't been tested with lockdep? Please
don't forget that step - lockdep finds some pretty nasty bugs sometimes.
This?
--- a/init/main.c~containersv10-basic-container-framework-fix-2
+++ a/init/main.c
@@ -503,7 +503,6 @@ asmlinkage void __init start_kernel(void
char * command_line;
extern struct kernel_param __start___param[], __stop___param[];
- container_init_early();
smp_setup_processor_id();
/*
@@ -512,6 +511,7 @@ asmlinkage void __init start_kernel(void
*/
unwind_init();
lockdep_init();
+ container_init_early();
local_irq_disable();
early_boot_irqs_off();
_
On Wed, Jun 06, 2007 at 11:09:31AM -0700, Andrew Morton wrote:
>On Thu, 7 Jun 2007 00:19:36 +0800 WANG Cong <[email protected]> wrote:
>
>> On Wed, Jun 06, 2007 at 02:07:37AM -0700, Andrew Morton wrote:
>> >
>> >ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm1/
>> >
>> >- Somebody broke it on my powerpc G5, but I didn't have time to do yet
>> > another bisection yet.
>> >
>>
>> It seems strange that a new C source file (mlguest.c) appears in the top dir of the
>> kernel source. There are some problems with it.
>>
>> First, I used `make mlguest.o` to compile that file, but I got tons of warnings and errors.
>> (Too many to put here.) What's wrong with it? Or I didn't compile/configure it correctly?
>>
>> Second, mlguest.c #includes a head file named "../../include/linux/lguest_launcher.h".
>> Since mlguest.c is in the top dir, so where is ../../include/linux/lguest_launcher.h?
>>
>
>Confused. I've grepped the entire universe here for "mlguest" and came up
>with nothing.
>
>I don't have a clue where that file came from on your system.
I used 'ketchup' to update my kernel from -rc3 to -rc4-mm1. I got the follow:
[wangcong@localhost linux-2.6.22-rc4-mm1]$ ls
arch Documentation ipc Makefile README System.map
block drivers Kbuild mlguest.c REPORTING-BUGS usr
COPYING fs kernel mm scripts vmlinux
CREDITS include lib Module.symvers security
crypto init MAINTAINERS net sound
Maybe there's something wrong with ketchup. ;(
On Thu, Jun 07, 2007 at 10:26:09AM +0800, WANG Cong wrote:
> On Wed, Jun 06, 2007 at 11:09:31AM -0700, Andrew Morton wrote:
> >On Thu, 7 Jun 2007 00:19:36 +0800 WANG Cong <[email protected]> wrote:
> >
> >> On Wed, Jun 06, 2007 at 02:07:37AM -0700, Andrew Morton wrote:
> >> >
> >> >ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm1/
> >> >
> >> >- Somebody broke it on my powerpc G5, but I didn't have time to do yet
> >> > another bisection yet.
> >> >
> >>
> >> It seems strange that a new C source file (mlguest.c) appears in the top dir of the
> >> kernel source. There are some problems with it.
> >>
> >> First, I used `make mlguest.o` to compile that file, but I got tons of warnings and errors.
> >> (Too many to put here.) What's wrong with it? Or I didn't compile/configure it correctly?
> >>
> >> Second, mlguest.c #includes a head file named "../../include/linux/lguest_launcher.h".
> >> Since mlguest.c is in the top dir, so where is ../../include/linux/lguest_launcher.h?
> >>
> >
> >Confused. I've grepped the entire universe here for "mlguest" and came up
> >with nothing.
> >
> >I don't have a clue where that file came from on your system.
>
>
> I used 'ketchup' to update my kernel from -rc3 to -rc4-mm1. I got the follow:
>
> [wangcong@localhost linux-2.6.22-rc4-mm1]$ ls
> arch Documentation ipc Makefile README System.map
> block drivers Kbuild mlguest.c REPORTING-BUGS usr
> COPYING fs kernel mm scripts vmlinux
> CREDITS include lib Module.symvers security
> crypto init MAINTAINERS net sound
>
> Maybe there's something wrong with ketchup. ;(
Can you do an 'lsdiff | grep lguest' on the patch in your ~/.ketchup directory?
Ketchup simply applies patches, it never touches filenames directly.
So for something to go wrong here and drop a file in the tree with a
damaged pathname, you've either got a damaged patch, a bug in patch
itself, or some form of filesystem corruption.
--
Mathematics is the supreme nostalgia of our time.
On Wed, Jun 06, 2007 at 06:09:24PM -0700, Andrew Morton wrote:
> ooh, yes, lockdep_init() really does want to be called before anything
> else.
> So do we take it that this code hasn't been tested with lockdep? Please
> don't forget that step - lockdep finds some pretty nasty bugs sometimes.
> This?
I found this patch when I woke and it got things booting with the full
-mm stack. Now to fix the sparc32 build and see if it boots.
-- wli
[email protected] wrote:
> On Wed, 06 Jun 2007 02:07:37 PDT, Andrew Morton said:
>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm1/
>
> This one died a horrid death at boot time - console log indicates it found the
> hard drive OK, found the 2 partitions on it. But when the initrd ran a
> 'lvm vgscan', it didn't find the LVM2 space on /dev/sda2, so it panic'ed when
> it fell off the end of the initrd because the root= wasn't there.
>
> My first guess for blame:
>
> gregkh-driver-sysfs-allocate-inode-number-using-ida.patch
>
> as that's awfully similar to gregkh-driver-sysfs-fix-i_ino-handling-in-sysfs.patch
> that broke 'lvm vgscan' for me in the same way on 21-rc7-mm[12].
>
> I'll hopefully get a chance to revert that one and test later today - a quick
> 'patch -p1 -R --dry-run' shows a number of conflicts that will need hand-fixing
> at the very least.
Did rc3-mm1 work? Can you find out the first broken -mm?
Thanks.
--
tejun
On Thu, Jun 07, 2007 at 12:59:13AM -0500, Matt Mackall wrote:
>On Thu, Jun 07, 2007 at 10:26:09AM +0800, WANG Cong wrote:
>> On Wed, Jun 06, 2007 at 11:09:31AM -0700, Andrew Morton wrote:
>> >On Thu, 7 Jun 2007 00:19:36 +0800 WANG Cong <[email protected]> wrote:
>> >
>> >> On Wed, Jun 06, 2007 at 02:07:37AM -0700, Andrew Morton wrote:
>> >> >
>> >> >ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm1/
>> >> >
>> >> >- Somebody broke it on my powerpc G5, but I didn't have time to do yet
>> >> > another bisection yet.
>> >> >
>> >>
>> >> It seems strange that a new C source file (mlguest.c) appears in the top dir of the
>> >> kernel source. There are some problems with it.
>> >>
>> >> First, I used `make mlguest.o` to compile that file, but I got tons of warnings and errors.
>> >> (Too many to put here.) What's wrong with it? Or I didn't compile/configure it correctly?
>> >>
>> >> Second, mlguest.c #includes a head file named "../../include/linux/lguest_launcher.h".
>> >> Since mlguest.c is in the top dir, so where is ../../include/linux/lguest_launcher.h?
>> >>
>> >
>> >Confused. I've grepped the entire universe here for "mlguest" and came up
>> >with nothing.
>> >
>> >I don't have a clue where that file came from on your system.
>>
>>
>> I used 'ketchup' to update my kernel from -rc3 to -rc4-mm1. I got the follow:
>>
>> [wangcong@localhost linux-2.6.22-rc4-mm1]$ ls
>> arch Documentation ipc Makefile README System.map
>> block drivers Kbuild mlguest.c REPORTING-BUGS usr
>> COPYING fs kernel mm scripts vmlinux
>> CREDITS include lib Module.symvers security
>> crypto init MAINTAINERS net sound
>>
>> Maybe there's something wrong with ketchup. ;(
>
>Can you do an 'lsdiff | grep lguest' on the patch in your ~/.ketchup directory?
>
>Ketchup simply applies patches, it never touches filenames directly.
>So for something to go wrong here and drop a file in the tree with a
>damaged pathname, you've either got a damaged patch, a bug in patch
>itself, or some form of filesystem corruption.
Thanks for your point.
It should be Documentation/lguest/lguest.c, maybe it was corrupted and ketchup
backuped it as mlguest.c.
Sorry for this.
Jiri Slaby wrote:
> Andrew Morton napsal(a):
>> On Wed, 06 Jun 2007 17:34:16 +0200 Jiri Slaby <[email protected]> wrote:
>>
>>> Mikael Pettersson napsal(a):
>>>> On Wed, 06 Jun 2007 15:04:00 +0200, Jiri Slaby wrote:
>>>>> Andrew Morton napsal(a):
>>>>>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm1/
>>>>> It freezes during bootup while searching for sata drives on sata_promise. There
>>>>> were 2 issues with sata_promise in -rc4 IIRC, one was fixed, the latter remains
>>>>> unresolved. Or, should be this solved too, Mikael, Tejun and is this yet
>>>>> eanother problem? (In this case I'll post dmesg and co.)
>>>> I know of only one sata_promise-specific issue in 2.6.22-rc4.
>>>> Tejun's "sata_promise: use TF interface for polling NODATA commands"
>>>> patch posted today fixes it.
>>> It's in that -mm, so I think, this seems to be another problem.
>> No, it wasn't in 2.6.22-rc4-mm1.
>
> Huh, what did I smoke? Something rejects to patch and now I don't know what.
>
>> Here it is - please test?
>
> Ok, this solves this problem, but LVM is broken. Seems similar to
> Re: 2.6.22-rc4-mm1 - 'lvm vgscan' busticated again...
> Message-ID: <[email protected]>
> Will try to play with this.
Did -rc3-mm1 work?
--
tejun
On Jun 6 2007 16:42, Andrew Morton wrote:
>> If so then you sent to it me :)
>
>You merged it ;)
>
>> Should I drop it?
>
>Sure, Jan will fix it up, I assume. I might have broken it while repairing
>the reject storm which occurred when that durned HAS_IOMEM thing went in
>all over the tree.
/me points at Herbert
Andrew would not add options between the "menuconfig CRYPTO" and
the "if CRYPTO" line... :)
Jan
===
Unbreak the crypto menu breakage.
Signed-off-by: Jan Engelhardt <[email protected]>
---
crypto/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: linux-2.6.22-rc4/crypto/Kconfig
===================================================================
--- linux-2.6.22-rc4.orig/crypto/Kconfig
+++ linux-2.6.22-rc4/crypto/Kconfig
@@ -7,6 +7,8 @@ menuconfig CRYPTO
help
This option provides the core Cryptographic API.
+if CRYPTO
+
#
# Generic algorithms support
#
@@ -18,8 +20,6 @@ config XOR_BLOCKS
#
source "crypto/async_tx/Kconfig"
-if CRYPTO
-
config CRYPTO_ALGAPI
tristate
help
Tejun Heo napsal(a):
> Jiri Slaby wrote:
>> Andrew Morton napsal(a):
>>> On Wed, 06 Jun 2007 17:34:16 +0200 Jiri Slaby <[email protected]> wrote:
>>>
>>>> Mikael Pettersson napsal(a):
>>>>> On Wed, 06 Jun 2007 15:04:00 +0200, Jiri Slaby wrote:
>>>>>> Andrew Morton napsal(a):
>>>>>>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm1/
>>>>>> It freezes during bootup while searching for sata drives on sata_promise. There
>>>>>> were 2 issues with sata_promise in -rc4 IIRC, one was fixed, the latter remains
>>>>>> unresolved. Or, should be this solved too, Mikael, Tejun and is this yet
>>>>>> eanother problem? (In this case I'll post dmesg and co.)
>>>>> I know of only one sata_promise-specific issue in 2.6.22-rc4.
>>>>> Tejun's "sata_promise: use TF interface for polling NODATA commands"
>>>>> patch posted today fixes it.
>>>> It's in that -mm, so I think, this seems to be another problem.
>>> No, it wasn't in 2.6.22-rc4-mm1.
>> Huh, what did I smoke? Something rejects to patch and now I don't know what.
>>
>>> Here it is - please test?
>> Ok, this solves this problem, but LVM is broken. Seems similar to
>> Re: 2.6.22-rc4-mm1 - 'lvm vgscan' busticated again...
>> Message-ID: <[email protected]>
>> Will try to play with this.
>
> Did -rc3-mm1 work?
Yes. Now I'm compiling -rc4-mm2.
regards,
--
http://www.fi.muni.cz/~xslaby/ Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E
On Thu, Jun 07, 2007 at 08:54:50AM +0200, Jan Engelhardt wrote:
>
> /me points at Herbert
> Andrew would not add options between the "menuconfig CRYPTO" and
> the "if CRYPTO" line... :)
Actually this patch is not even in my tree :)
> Index: linux-2.6.22-rc4/crypto/Kconfig
> ===================================================================
> --- linux-2.6.22-rc4.orig/crypto/Kconfig
> +++ linux-2.6.22-rc4/crypto/Kconfig
> @@ -7,6 +7,8 @@ menuconfig CRYPTO
> help
> This option provides the core Cryptographic API.
>
> +if CRYPTO
> +
> #
> # Generic algorithms support
> #
> @@ -18,8 +20,6 @@ config XOR_BLOCKS
> #
> source "crypto/async_tx/Kconfig"
Andrew, do you want me to pick the async_tx stuff up instead?
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Jiri Slaby wrote:
>>>> Here it is - please test?
>>> Ok, this solves this problem, but LVM is broken. Seems similar to
>>> Re: 2.6.22-rc4-mm1 - 'lvm vgscan' busticated again...
>>> Message-ID: <[email protected]>
>>> Will try to play with this.
>> Did -rc3-mm1 work?
Hmmm... I see.
> Yes. Now I'm compiling -rc4-mm2.
It's probably caused by new sysfs slimdown patches and I'm pretty sure
-rc4-mm2 would fail the same way. The offending one should be one of
the following patches.
gregkh-driver-sysfs-fix-parent-refcounting-during-rename-and-move.patch
gregkh-driver-sysfs-reorganize-sysfs_new_indoe-and-sysfs_create.patch
gregkh-driver-sysfs-use-iget_locked-instead-of-new_inode.patch
gregkh-driver-sysfs-fix-root-sysfs_dirent-root-dentry-association.patch
gregkh-driver-sysfs-move-s_active-functions-to-fs-sysfs-dirc.patch
gregkh-driver-sysfs-slim-down-sysfs_dirent-s_active.patch
gregkh-driver-sysfs-use-singly-linked-list-for-sysfs_dirent-tree.patch
Can you bisect the above patches?
--
tejun
On Thu, 7 Jun 2007 17:01:08 +1000 Herbert Xu <[email protected]> wrote:
> On Thu, Jun 07, 2007 at 08:54:50AM +0200, Jan Engelhardt wrote:
> >
> > /me points at Herbert
> > Andrew would not add options between the "menuconfig CRYPTO" and
> > the "if CRYPTO" line... :)
>
> Actually this patch is not even in my tree :)
uh, OK, sorry.
> > Index: linux-2.6.22-rc4/crypto/Kconfig
> > ===================================================================
> > --- linux-2.6.22-rc4.orig/crypto/Kconfig
> > +++ linux-2.6.22-rc4/crypto/Kconfig
> > @@ -7,6 +7,8 @@ menuconfig CRYPTO
> > help
> > This option provides the core Cryptographic API.
> >
> > +if CRYPTO
> > +
> > #
> > # Generic algorithms support
> > #
> > @@ -18,8 +20,6 @@ config XOR_BLOCKS
> > #
> > source "crypto/async_tx/Kconfig"
>
> Andrew, do you want me to pick the async_tx stuff up instead?
>
I wouldn't recommend it. It's an ongoing source of bustage frankly, has a
habit of getting unpleasantly tangled with git-ioat.patch and afaik is
still awaiting a go-ahead from Neil.
Tejun Heo napsal(a):
> Jiri Slaby wrote:
>> Yes. Now I'm compiling -rc4-mm2.
>
> It's probably caused by new sysfs slimdown patches and I'm pretty sure
> -rc4-mm2 would fail the same way. The offending one should be one of
> the following patches.
There's reverted gregkh-driver-block-device in -mm2. So I wanted to give it a
try. Do you think it's pointless and that patch has no impact on the behaviour?
> gregkh-driver-sysfs-fix-parent-refcounting-during-rename-and-move.patch
> gregkh-driver-sysfs-reorganize-sysfs_new_indoe-and-sysfs_create.patch
> gregkh-driver-sysfs-use-iget_locked-instead-of-new_inode.patch
> gregkh-driver-sysfs-fix-root-sysfs_dirent-root-dentry-association.patch
> gregkh-driver-sysfs-move-s_active-functions-to-fs-sysfs-dirc.patch
> gregkh-driver-sysfs-slim-down-sysfs_dirent-s_active.patch
> gregkh-driver-sysfs-use-singly-linked-list-for-sysfs_dirent-tree.patch
>
> Can you bisect the above patches?
Sure, in 12 hours or tomorrow.
thanks,
--
http://www.fi.muni.cz/~xslaby/ Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E
Jiri Slaby wrote:
> Tejun Heo napsal(a):
>> Jiri Slaby wrote:
>>> Yes. Now I'm compiling -rc4-mm2.
>> It's probably caused by new sysfs slimdown patches and I'm pretty sure
>> -rc4-mm2 would fail the same way. The offending one should be one of
>> the following patches.
>
> There's reverted gregkh-driver-block-device in -mm2. So I wanted to give it a
> try. Do you think it's pointless and that patch has no impact on the behaviour?
I'm not familiar with how lvm vgscan works and the patch does look like
it can affect that. Please give a shot at -mm2.
Thanks a lot.
--
tejun
ACPI Exception (processor_throttling-0084): AE_NOT_FOUND, Evaluating
_PTC [20070126]
ACPI Exception (processor_throttling-0147): AE_NOT_FOUND, Evaluating
_TSS [20070126]
On 2.6.20.9 I don't have this exceptions.
Other problem:
2.6.22rc4-mm1:
rutek:/home/maciek# cat /proc/acpi/processor/CPU0/throttling
Naruszenie ochrony pamięci (segmentation fault)
compared to 2.6.20.9:
maciek@rutek:~$ cat /proc/acpi/processor/CPU0/throttling
state count: 8
active state: T0
states:
*T0: 00%
T1: 12%
T2: 25%
T3: 37%
T4: 50%
T5: 62%
T6: 75%
T7: 87%
Other info (2.6.22-rc4-mm1):
rutek:/home/maciek# ls /proc/acpi/processor/CPU0/
info limit power throttling
rutek:/home/maciek# cat /proc/acpi/processor/CPU0/info
processor id: 0
acpi id: 1
bus mastering control: yes
power management: yes
throttling control: yes
limit interface: yes
rutek:/home/maciek# cat /proc/acpi/processor/CPU0/limit
active limit: P0:T0
user limit: P0:T0
thermal limit: P0:T0
rutek:/home/maciek# cat /proc/acpi/processor/CPU0/power
active state: C0
max_cstate: C8
bus master activity: 00000000
maximum allowed latency: 8000 usec
states:
C1: type[C1] promotion[--] demotion[--]
latency[001] usage[00000000] duration[00000000000000000000]
C2: type[C2] promotion[--] demotion[--]
latency[001] usage[00000000] duration[00000000000000000000]
For CPU1 is similar.
config, dmesg, acpidump:
http://www.unixy.pl/maciek/download/kernel/2.6.22-rc4-mm1/
--
Maciej Rutecki
http://www.maciek.unixy.pl
Kay Sievers pisze:
> On Wed, 2007-06-06 at 20:48 +0200, Michal Piotrowski wrote:
>> Andrew Morton pisze:
>>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm1/
>>>
>> Kay, your patch gregkh-driver-block-device.patch breaks Fedora 7 initrd
>> http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.22-rc4-mm1/initrd.jpg
>>
>> Please fix it ASAP, I can't test kernel...
>
> Do you have CONFIG_SYSFS_DEPRECATED set or unset?
>
> Kay
>
>
cat ../linux-mm-bo/.config | grep CONFIG_SYSFS_DEPRECATED
# CONFIG_SYSFS_DEPRECATED is not set
Regards,
Michal
--
"Najbardziej brakowa?o mi twojego milczenia."
-- Andrzej Sapkowski "Co? wi?cej"
On Thu, 2007-06-07 at 10:40 +0200, Michal Piotrowski wrote:
> Kay Sievers pisze:
> > On Wed, 2007-06-06 at 20:48 +0200, Michal Piotrowski wrote:
> >> Andrew Morton pisze:
> >>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm1/
> >>>
> >> Kay, your patch gregkh-driver-block-device.patch breaks Fedora 7 initrd
> >> http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.22-rc4-mm1/initrd.jpg
> >>
> >> Please fix it ASAP, I can't test kernel...
> >
> > Do you have CONFIG_SYSFS_DEPRECATED set or unset?
> >
> > Kay
> >
> >
>
> cat ../linux-mm-bo/.config | grep CONFIG_SYSFS_DEPRECATED
> # CONFIG_SYSFS_DEPRECATED is not set
Oh, could you possibly try (with the block patch included) setting it to
yes and see if it works? That would help to find what's going wrong.
Thanks,
Kay
Please test the attached patch.
Thanks,
Luming
On 6/7/07, Maciej Rutecki <[email protected]> wrote:
> ACPI Exception (processor_throttling-0084): AE_NOT_FOUND, Evaluating
> _PTC [20070126]
> ACPI Exception (processor_throttling-0147): AE_NOT_FOUND, Evaluating
> _TSS [20070126]
>
> On 2.6.20.9 I don't have this exceptions.
>
> Other problem:
>
> 2.6.22rc4-mm1:
> rutek:/home/maciek# cat /proc/acpi/processor/CPU0/throttling
> Naruszenie ochrony pami?ci (segmentation fault)
>
> compared to 2.6.20.9:
> maciek@rutek:~$ cat /proc/acpi/processor/CPU0/throttling
> state count: 8
> active state: T0
> states:
> *T0: 00%
> T1: 12%
> T2: 25%
> T3: 37%
> T4: 50%
> T5: 62%
> T6: 75%
> T7: 87%
>
>
> Other info (2.6.22-rc4-mm1):
> rutek:/home/maciek# ls /proc/acpi/processor/CPU0/
> info limit power throttling
> rutek:/home/maciek# cat /proc/acpi/processor/CPU0/info
> processor id: 0
> acpi id: 1
> bus mastering control: yes
> power management: yes
> throttling control: yes
> limit interface: yes
> rutek:/home/maciek# cat /proc/acpi/processor/CPU0/limit
> active limit: P0:T0
> user limit: P0:T0
> thermal limit: P0:T0
> rutek:/home/maciek# cat /proc/acpi/processor/CPU0/power
> active state: C0
> max_cstate: C8
> bus master activity: 00000000
> maximum allowed latency: 8000 usec
> states:
> C1: type[C1] promotion[--] demotion[--]
> latency[001] usage[00000000] duration[00000000000000000000]
> C2: type[C2] promotion[--] demotion[--]
> latency[001] usage[00000000] duration[00000000000000000000]
>
> For CPU1 is similar.
>
> config, dmesg, acpidump:
> http://www.unixy.pl/maciek/download/kernel/2.6.22-rc4-mm1/
>
> --
> Maciej Rutecki
> http://www.maciek.unixy.pl
>
>
>
Maciej Rutecki pisze:
> ACPI Exception (processor_throttling-0084): AE_NOT_FOUND, Evaluating
> _PTC [20070126]
> ACPI Exception (processor_throttling-0147): AE_NOT_FOUND, Evaluating
> _TSS [20070126]
>
> On 2.6.20.9 I don't have this exceptions.
>
> Other problem:
>
> 2.6.22rc4-mm1:
> rutek:/home/maciek# cat /proc/acpi/processor/CPU0/throttling
> Naruszenie ochrony pamięci (segmentation fault)
Update (2.6.22-rc4-mm2):
rutek:/home/maciek# cat /proc/acpi/processor/CPU0/throttling
acpi_processor_throttling_seq_show() is busted
rutek:/home/maciek# cat /proc/acpi/processor/CPU1/throttling
acpi_processor_throttling_seq_show() is busted
--
Maciej Rutecki
http://www.maciek.unixy.pl
Kay Sievers pisze:
> On Thu, 2007-06-07 at 10:40 +0200, Michal Piotrowski wrote:
>> Kay Sievers pisze:
>>> On Wed, 2007-06-06 at 20:48 +0200, Michal Piotrowski wrote:
>>>> Andrew Morton pisze:
>>>>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm1/
>>>>>
>>>> Kay, your patch gregkh-driver-block-device.patch breaks Fedora 7 initrd
>>>> http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.22-rc4-mm1/initrd.jpg
>>>>
>>>> Please fix it ASAP, I can't test kernel...
>>> Do you have CONFIG_SYSFS_DEPRECATED set or unset?
>>>
>>> Kay
>>>
>>>
>> cat ../linux-mm-bo/.config | grep CONFIG_SYSFS_DEPRECATED
>> # CONFIG_SYSFS_DEPRECATED is not set
>
> Oh, could you possibly try (with the block patch included) setting it to
> yes and see if it works? That would help to find what's going wrong.
I enabled CONFIG_SYSFS_DEPRECATED and 2.6.22-rc4-mm2 boots fine.
Regards,
Michal
--
"Najbardziej brakowa?o mi twojego milczenia."
-- Andrzej Sapkowski "Co? wi?cej"
Luming Yu pisze:
> Please test the attached patch.
>
It works. I still have exceptions in dmesg (probably my dsdt doesn't
support _PTC and _TSS), but already I can read
/proc/acpi/processor/CPU0/throttling:
maciek@rutek:~$ cat /proc/acpi/processor/CPU0/throttling
state count: 8
active state: T0
state available: T0 to T7
states:
*T0: 00%
T1: 12%
T2: 25%
T3: 37%
T4: 50%
T5: 62%
T6: 75%
T7: 87%
> Thanks,
> Luming
>
Thanks for help.
--
Maciej Rutecki
http://www.maciek.unixy.pl
Question.
While writing memory unplug, I noticed this code.
==
static int
fixup_anon_page(pte_t *pte, unsigned long start, unsigned long end, void *priv)
{
struct vm_area_struct *vma = priv;
struct page *page = vm_normal_page(vma, start, *pte);
if (page && PageAnon(page))
page->index = linear_page_index(vma, start);
return 0;
}
static int fixup_anon_pages(struct vm_area_struct *vma)
{
struct mm_walk walk = {
.pte_entry = fixup_anon_page,
};
return walk_page_range(vma->vm_mm,
vma->vm_start, vma->vm_end, &walk, vma);
}
==
I think that 'pte' passed to fixup_anon_page() by walk_page_range()
is not guaranteed to be 'Present'.
Then, vm_normal_page() will show print_bad_pte().
If this never occur now, I'll add my own check code for memory migration by kernel here.
(Sorry, I can't find who should be CCed.)
-Kame
On Thu, Jun 07, 2007 at 02:51:58PM +0800, WANG Cong wrote:
> >> Maybe there's something wrong with ketchup. ;(
> >
> >Can you do an 'lsdiff | grep lguest' on the patch in your ~/.ketchup directory?
> >
> >Ketchup simply applies patches, it never touches filenames directly.
> >So for something to go wrong here and drop a file in the tree with a
> >damaged pathname, you've either got a damaged patch, a bug in patch
> >itself, or some form of filesystem corruption.
>
> Thanks for your point.
>
> It should be Documentation/lguest/lguest.c, maybe it was corrupted and ketchup
> backuped it as mlguest.c.
It'd be interesting to figure out how that happened, still.
If your patch file is intact (are you using GPG's signature-checking
support?), the most likely explanation is an operating system or
filesystem bug.
Can you reproduce it?
--
Mathematics is the supreme nostalgia of our time.
On Wed, 6 Jun 2007, Andrew Morton wrote:
> On Wed, 6 Jun 2007 21:58:38 +0100 Grant Wilson <[email protected]> wrote:
>
> > On Wednesday 06 June 2007 10:07:37 Andrew Morton wrote:
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm1/
> >
> > Patch 'usb-try-to-debug-bug-8561' triggers when I plug in a usb flash drive:
>
> Cool, thanks.
>
> > [10998.881000] usb 1-10: new high speed USB device using ehci_hcd and address 3
> > [10999.001000] usb 1-10: new device found, idVendor=13fe, idProduct=1a00
> > [10999.002000] usb 1-10: new device strings: Mfr=1, Product=2, SerialNumber=3
> > [10999.016000] usb 1-10: Product: USB DISK 2.0
> > [10999.025000] usb 1-10: Manufacturer:
> > [10999.033000] usb 1-10: SerialNumber: 07720947018D
> > [10999.034000] usb 1-10: configuration #1 chosen from 1 choice
> > [10999.047000] scsi8 : SCSI emulation for USB Mass Storage devices
> > [11004.055000] WARNING: at drivers/usb/core/urb.c:293 usb_submit_urb()
> > [11004.055000]
> > [11004.055000] Call Trace:
> > [11004.055000] [<ffffffff8020d30f>] dump_trace+0x43f/0x480
> > [11004.055000] [<ffffffff8020d393>] show_trace+0x43/0x70
> > [11004.055000] [<ffffffff8020d3d5>] dump_stack+0x15/0x20
> > [11004.055000] [<ffffffff804b4314>] usb_submit_urb+0x224/0x240
> > [11004.055000] [<ffffffff804b5ff5>] usb_sg_wait+0xd5/0x180
> > [11004.055000] [<ffffffff804cf464>] usb_stor_bulk_transfer_sg+0xc4/0x120
> > [11004.055000] [<ffffffff804cf611>] usb_stor_Bulk_transport+0x151/0x2e0
> > [11004.055000] [<ffffffff804cfb57>] usb_stor_invoke_transport+0x37/0x380
> > [11004.055000] [<ffffffff804ce9f9>] usb_stor_transparent_scsi_command+0x9/0x10
> > [11004.055000] [<ffffffff804d0aea>] usb_stor_control_thread+0x18a/0x230
> > [11004.055000] [<ffffffff8024927d>] kthread+0x4d/0x80
> > [11004.055000] [<ffffffff8020c868>] child_rip+0xa/0x12
> >
>
> Alan, you got a bite - reel her in!
Thanks for forwarding the message. Unforunately it's a false alarm.
As mentioned in the original patch, the test it uses isn't precise.
To tell you the truth, I rather think there's not much point in keeping
usb-try-to-debug-bug-8561.patch around. Anything seriously wrong that
it could catch ought to have shown up long ago. And it is now clear
that bug 8561 has nothing to do with this; it is a programming error
common to many of the USB serial drivers. (Still waiting to hear back
from Paulo Pereira whether the fix to the USB Option driver works...)
My vote goes toward reverting usb-try-to-debug-bug-8561.patch.
However just to be thorough, for anyone wants to keep it here's an
untested patch to remove those false alarms.
Alan Stern
---------------------------------
Remove some false alarms generated by usb-try-to-debug-bug-8561.patch.
Signed-off-by: Alan Stern <[email protected]>
---
Index: usb-2.6/drivers/usb/core/message.c
===================================================================
--- usb-2.6.orig/drivers/usb/core/message.c
+++ usb-2.6/drivers/usb/core/message.c
@@ -404,8 +404,6 @@ int usb_sg_init (
io->urbs [i]->complete = sg_complete;
io->urbs [i]->context = io;
- io->urbs [i]->status = -EINPROGRESS;
- io->urbs [i]->actual_length = 0;
/*
* Some systems need to revert to PIO when DMA is temporarily
On Thu, 2007-06-07 at 11:41 +0200, Michal Piotrowski wrote:
> Kay Sievers pisze:
> > On Thu, 2007-06-07 at 10:40 +0200, Michal Piotrowski wrote:
> >> Kay Sievers pisze:
> >>> On Wed, 2007-06-06 at 20:48 +0200, Michal Piotrowski wrote:
> >>>> Andrew Morton pisze:
> >>>>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm1/
> >>>>>
> >>>> Kay, your patch gregkh-driver-block-device.patch breaks Fedora 7 initrd
> >>>> http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.22-rc4-mm1/initrd.jpg
> >>>>
> >>>> Please fix it ASAP, I can't test kernel...
> >>> Do you have CONFIG_SYSFS_DEPRECATED set or unset?
> >>>
> >>> Kay
> >>>
> >>>
> >> cat ../linux-mm-bo/.config | grep CONFIG_SYSFS_DEPRECATED
> >> # CONFIG_SYSFS_DEPRECATED is not set
> >
> > Oh, could you possibly try (with the block patch included) setting it to
> > yes and see if it works? That would help to find what's going wrong.
>
> I enabled CONFIG_SYSFS_DEPRECATED and 2.6.22-rc4-mm2 boots fine.
Michal, thanks a lot for the testing.
Peter, looking at your mkinitrd code, it works only with
CONFIG_SYSFS_DEPRECATED enabled when block devices are converted to
class devices.
Any chance to replace lstat() with stat() while looking for devices in
sysfs? Remember, _anything_ in sysfs can be symlink or a directory, you
can't assume one or the other. When things change internally in the
kernel, we can often provide symlinks for backwards compatibility, but
lstat() obviously can't works here.
Thanks,
Kay
Kay Sievers wrote:
> On Thu, 2007-06-07 at 11:41 +0200, Michal Piotrowski wrote:
>> Kay Sievers pisze:
>>> On Thu, 2007-06-07 at 10:40 +0200, Michal Piotrowski wrote:
>>>> Kay Sievers pisze:
>>>>> On Wed, 2007-06-06 at 20:48 +0200, Michal Piotrowski wrote:
>>>>>> Andrew Morton pisze:
>>>>>>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm1/
>>>>>>>
>>>>>> Kay, your patch gregkh-driver-block-device.patch breaks Fedora 7 initrd
>>>>>> http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.22-rc4-mm1/initrd.jpg
>>>>>>
>>>>>> Please fix it ASAP, I can't test kernel...
>>>>> Do you have CONFIG_SYSFS_DEPRECATED set or unset?
>>>>>
>>>>> Kay
>>>>>
>>>>>
>>>> cat ../linux-mm-bo/.config | grep CONFIG_SYSFS_DEPRECATED
>>>> # CONFIG_SYSFS_DEPRECATED is not set
>>> Oh, could you possibly try (with the block patch included) setting it to
>>> yes and see if it works? That would help to find what's going wrong.
>> I enabled CONFIG_SYSFS_DEPRECATED and 2.6.22-rc4-mm2 boots fine.
>
> Michal, thanks a lot for the testing.
>
> Peter, looking at your mkinitrd code, it works only with
> CONFIG_SYSFS_DEPRECATED enabled when block devices are converted to
> class devices.
> Any chance to replace lstat() with stat() while looking for devices in
> sysfs? Remember, _anything_ in sysfs can be symlink or a directory, you
> can't assume one or the other. When things change internally in the
> kernel, we can often provide symlinks for backwards compatibility, but
> lstat() obviously can't works here.
Fixed in mkinitrd-6.0.9-6 , which I'll build now and push to
updates-testing. Thanks for getting my attention here.
--
Peter
On Thu, 7 Jun 2007 21:47:06 +0900 KAMEZAWA Hiroyuki <[email protected]> wrote:
> Question.
>
> While writing memory unplug, I noticed this code.
> ==
> static int
> fixup_anon_page(pte_t *pte, unsigned long start, unsigned long end, void *priv)
> {
> struct vm_area_struct *vma = priv;
> struct page *page = vm_normal_page(vma, start, *pte);
>
> if (page && PageAnon(page))
> page->index = linear_page_index(vma, start);
>
> return 0;
> }
>
> static int fixup_anon_pages(struct vm_area_struct *vma)
> {
> struct mm_walk walk = {
> .pte_entry = fixup_anon_page,
> };
>
> return walk_page_range(vma->vm_mm,
> vma->vm_start, vma->vm_end, &walk, vma);
> }
I assume the above is your code - it's not in the tree?
>
> I think that 'pte' passed to fixup_anon_page() by walk_page_range()
> is not guaranteed to be 'Present'.
yup - the pagewalker only checks for !pte_none().
> Then, vm_normal_page() will show print_bad_pte().
> If this never occur now, I'll add my own check code for memory migration by kernel here.
Yes, you'll need to perform additional filtering where appropriate.
> (Sorry, I can't find who should be CCed.)
Matt and David did most of the work here.
On Thu, Jun 07, 2007 at 09:04:44AM -0500, Matt Mackall wrote:
>On Thu, Jun 07, 2007 at 02:51:58PM +0800, WANG Cong wrote:
>> >> Maybe there's something wrong with ketchup. ;(
>> >
>> >Can you do an 'lsdiff | grep lguest' on the patch in your ~/.ketchup directory?
>> >
>> >Ketchup simply applies patches, it never touches filenames directly.
>> >So for something to go wrong here and drop a file in the tree with a
>> >damaged pathname, you've either got a damaged patch, a bug in patch
>> >itself, or some form of filesystem corruption.
>>
>> Thanks for your point.
>>
>> It should be Documentation/lguest/lguest.c, maybe it was corrupted and ketchup
>> backuped it as mlguest.c.
>
>It'd be interesting to figure out how that happened, still.
>
>If your patch file is intact (are you using GPG's signature-checking
>support?), the most likely explanation is an operating system or
>filesystem bug.
Yes, I am using GPG's checking.
I think the most possible reason is that source file might be corrupted.
It's hardly the filesystem's fault, since I am using a stable kernel.
>
>Can you reproduce it?
May be very hard.;(
I deleted all the files of that version and download a new version to use.
Thanks!
On Thu, 7 Jun 2007 08:43:42 -0700 Greg KH <[email protected]> wrote:
> > Fixed in mkinitrd-6.0.9-6 , which I'll build now and push to
> > updates-testing. Thanks for getting my attention here.
>
> Great, Andrew, can you please reenable the block-device patch that is in
> my tree now that the problem has been solved?
I think we're screwed, aren't we? Everyone needs to upgrade mkinitrd to be
able to boot the kernel? Not viable :(
For example, what about my two-year-old yellowdog machine?
Tejun Heo napsal(a):
> Jiri Slaby wrote:
>> Tejun Heo napsal(a):
>>> Jiri Slaby wrote:
>>>> Yes. Now I'm compiling -rc4-mm2.
>>> It's probably caused by new sysfs slimdown patches and I'm pretty sure
>>> -rc4-mm2 would fail the same way. The offending one should be one of
>>> the following patches.
>> There's reverted gregkh-driver-block-device in -mm2. So I wanted to give it a
>> try. Do you think it's pointless and that patch has no impact on the behaviour?
>
> I'm not familiar with how lvm vgscan works and the patch does look like
> it can affect that. Please give a shot at -mm2.
Yup, it works without any further patches. So it seems like
gregkh-driver-block-device is the culprit?
regards,
--
http://www.fi.muni.cz/~xslaby/ Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E
On Thu, Jun 07, 2007 at 11:40:08PM +0800, WANG Cong wrote:
> On Thu, Jun 07, 2007 at 09:04:44AM -0500, Matt Mackall wrote:
> >On Thu, Jun 07, 2007 at 02:51:58PM +0800, WANG Cong wrote:
> >> >> Maybe there's something wrong with ketchup. ;(
> >> >
> >> >Can you do an 'lsdiff | grep lguest' on the patch in your ~/.ketchup directory?
> >> >
> >> >Ketchup simply applies patches, it never touches filenames directly.
> >> >So for something to go wrong here and drop a file in the tree with a
> >> >damaged pathname, you've either got a damaged patch, a bug in patch
> >> >itself, or some form of filesystem corruption.
> >>
> >> Thanks for your point.
> >>
> >> It should be Documentation/lguest/lguest.c, maybe it was corrupted and ketchup
> >> backuped it as mlguest.c.
> >
> >It'd be interesting to figure out how that happened, still.
> >
> >If your patch file is intact (are you using GPG's signature-checking
> >support?), the most likely explanation is an operating system or
> >filesystem bug.
>
> Yes, I am using GPG's checking.
Well that gives a pretty solid assurance that the patch you downloaded
matches the one on kernel.org. And that one doesn't contain an
mlguest.c.
Ketchup doesn't even look inside patches, and patch doesn't invent
names, so something in the bzip2 -> patch(1) -> filesystem chain got
corrupted. Probably not bzip2, as it has CRCs.
Do you have ECC memory?
--
Mathematics is the supreme nostalgia of our time.
On Thu, Jun 07, 2007 at 11:25:57AM -0400, Peter Jones wrote:
> Kay Sievers wrote:
> > On Thu, 2007-06-07 at 11:41 +0200, Michal Piotrowski wrote:
> >> Kay Sievers pisze:
> >>> On Thu, 2007-06-07 at 10:40 +0200, Michal Piotrowski wrote:
> >>>> Kay Sievers pisze:
> >>>>> On Wed, 2007-06-06 at 20:48 +0200, Michal Piotrowski wrote:
> >>>>>> Andrew Morton pisze:
> >>>>>>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm1/
> >>>>>>>
> >>>>>> Kay, your patch gregkh-driver-block-device.patch breaks Fedora 7
> >>>>>> initrd
> >>>>>> http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.22-rc4-mm1/initrd.jpg
> >>>>>>
> >>>>>> Please fix it ASAP, I can't test kernel...
> >>>>> Do you have CONFIG_SYSFS_DEPRECATED set or unset?
> >>>>>
> >>>>> Kay
> >>>>>
> >>>>>
> >>>> cat ../linux-mm-bo/.config | grep CONFIG_SYSFS_DEPRECATED
> >>>> # CONFIG_SYSFS_DEPRECATED is not set
> >>> Oh, could you possibly try (with the block patch included) setting it to
> >>> yes and see if it works? That would help to find what's going wrong.
> >> I enabled CONFIG_SYSFS_DEPRECATED and 2.6.22-rc4-mm2 boots fine.
> > Michal, thanks a lot for the testing.
> > Peter, looking at your mkinitrd code, it works only with
> > CONFIG_SYSFS_DEPRECATED enabled when block devices are converted to
> > class devices.
> > Any chance to replace lstat() with stat() while looking for devices in
> > sysfs? Remember, _anything_ in sysfs can be symlink or a directory, you
> > can't assume one or the other. When things change internally in the
> > kernel, we can often provide symlinks for backwards compatibility, but
> > lstat() obviously can't works here.
>
> Fixed in mkinitrd-6.0.9-6 , which I'll build now and push to
> updates-testing. Thanks for getting my attention here.
Great, Andrew, can you please reenable the block-device patch that is in
my tree now that the problem has been solved?
thanks,
greg k-h
On Thu, Jun 07, 2007 at 08:52:00AM -0700, Andrew Morton wrote:
> On Thu, 7 Jun 2007 08:43:42 -0700 Greg KH <[email protected]> wrote:
>
> > > Fixed in mkinitrd-6.0.9-6 , which I'll build now and push to
> > > updates-testing. Thanks for getting my attention here.
> >
> > Great, Andrew, can you please reenable the block-device patch that is in
> > my tree now that the problem has been solved?
>
> I think we're screwed, aren't we? Everyone needs to upgrade mkinitrd to be
> able to boot the kernel? Not viable :(
>
> For example, what about my two-year-old yellowdog machine?
Enable CONFIG_SYSFS_DEPRECATED and it should all work just fine. That's
what Michal said worked for him.
thanks,
greg k-h
On Thu, Jun 07, 2007 at 05:54:13PM +0200, Jiri Slaby wrote:
> Tejun Heo napsal(a):
> > Jiri Slaby wrote:
> >> Tejun Heo napsal(a):
> >>> Jiri Slaby wrote:
> >>>> Yes. Now I'm compiling -rc4-mm2.
> >>> It's probably caused by new sysfs slimdown patches and I'm pretty sure
> >>> -rc4-mm2 would fail the same way. The offending one should be one of
> >>> the following patches.
> >> There's reverted gregkh-driver-block-device in -mm2. So I wanted to give it a
> >> try. Do you think it's pointless and that patch has no impact on the behaviour?
> >
> > I'm not familiar with how lvm vgscan works and the patch does look like
> > it can affect that. Please give a shot at -mm2.
>
> Yup, it works without any further patches. So it seems like
> gregkh-driver-block-device is the culprit?
Culprit for what kind of symptom? Is CONFIG_SYSFS_DEPRECATED enabled?
If not, can you try that?
thanks,
greg k-h
On Thu, 7 Jun 2007 08:59:53 -0700 Greg KH <[email protected]> wrote:
> On Thu, Jun 07, 2007 at 08:52:00AM -0700, Andrew Morton wrote:
> > On Thu, 7 Jun 2007 08:43:42 -0700 Greg KH <[email protected]> wrote:
> >
> > > > Fixed in mkinitrd-6.0.9-6 , which I'll build now and push to
> > > > updates-testing. Thanks for getting my attention here.
> > >
> > > Great, Andrew, can you please reenable the block-device patch that is in
> > > my tree now that the problem has been solved?
> >
> > I think we're screwed, aren't we? Everyone needs to upgrade mkinitrd to be
> > able to boot the kernel? Not viable :(
> >
> > For example, what about my two-year-old yellowdog machine?
>
> Enable CONFIG_SYSFS_DEPRECATED and it should all work just fine. That's
> what Michal said worked for him.
>
Actually, it _was_ enabled.
Ho hum, I'll have a poke at it this evening.
So... what's the story here? Should our position be that
CONFIG_SYSFS_DEPRECATED=n should only be used by distro kernel-builders,
who are concurrently shipping userspace which can handle it? And that
these distros should (probably) set CONFIG_SYSFS_DEPRECATED=y in their
update kernels for older distributions?
On Thu, Jun 07, 2007 at 09:06:32AM -0700, Andrew Morton wrote:
> On Thu, 7 Jun 2007 08:59:53 -0700 Greg KH <[email protected]> wrote:
>
> > On Thu, Jun 07, 2007 at 08:52:00AM -0700, Andrew Morton wrote:
> > > On Thu, 7 Jun 2007 08:43:42 -0700 Greg KH <[email protected]> wrote:
> > >
> > > > > Fixed in mkinitrd-6.0.9-6 , which I'll build now and push to
> > > > > updates-testing. Thanks for getting my attention here.
> > > >
> > > > Great, Andrew, can you please reenable the block-device patch that is in
> > > > my tree now that the problem has been solved?
> > >
> > > I think we're screwed, aren't we? Everyone needs to upgrade mkinitrd to be
> > > able to boot the kernel? Not viable :(
> > >
> > > For example, what about my two-year-old yellowdog machine?
> >
> > Enable CONFIG_SYSFS_DEPRECATED and it should all work just fine. That's
> > what Michal said worked for him.
> >
>
> Actually, it _was_ enabled.
>
> Ho hum, I'll have a poke at it this evening.
Yeah, that sounds odd, it should have worked.
> So... what's the story here? Should our position be that
> CONFIG_SYSFS_DEPRECATED=n should only be used by distro kernel-builders,
> who are concurrently shipping userspace which can handle it?
Yes.
There are a number of distros out there right now who can support that
option disabled. I'm pretty sure they are the following right now:
Gentoo unstable (actually stable works now for me, but I'm not
going to guarantee it just yet...)
Debian unstable (again stable might work, but I have not heard
any reports from testers.)
openSUSE FACTORY (the 10.3 alpha releases)
and now it sounds like Red Hat rawhide will also work properly.
> And that these distros should (probably) set CONFIG_SYSFS_DEPRECATED=y
> in their update kernels for older distributions?
Yes, unless they have tested things and it all works properly (all old
usages of libsysfs need to be removed and 'odd' initrd scripts need to
be updated as in the case of Red Hat.)
thanks,
greg k-h
On Thu, Jun 07, 2007 at 10:59:14AM -0500, Matt Mackall wrote:
>On Thu, Jun 07, 2007 at 11:40:08PM +0800, WANG Cong wrote:
>> On Thu, Jun 07, 2007 at 09:04:44AM -0500, Matt Mackall wrote:
>> >On Thu, Jun 07, 2007 at 02:51:58PM +0800, WANG Cong wrote:
>> >> >> Maybe there's something wrong with ketchup. ;(
>> >> >
>> >> >Can you do an 'lsdiff | grep lguest' on the patch in your ~/.ketchup directory?
>> >> >
>> >> >Ketchup simply applies patches, it never touches filenames directly.
>> >> >So for something to go wrong here and drop a file in the tree with a
>> >> >damaged pathname, you've either got a damaged patch, a bug in patch
>> >> >itself, or some form of filesystem corruption.
>> >>
>> >> Thanks for your point.
>> >>
>> >> It should be Documentation/lguest/lguest.c, maybe it was corrupted and ketchup
>> >> backuped it as mlguest.c.
>> >
>> >It'd be interesting to figure out how that happened, still.
>> >
>> >If your patch file is intact (are you using GPG's signature-checking
>> >support?), the most likely explanation is an operating system or
>> >filesystem bug.
>>
>> Yes, I am using GPG's checking.
>
>Well that gives a pretty solid assurance that the patch you downloaded
>matches the one on kernel.org. And that one doesn't contain an
>mlguest.c.
>
I agree.
>Ketchup doesn't even look inside patches, and patch doesn't invent
>names, so something in the bzip2 -> patch(1) -> filesystem chain got
>corrupted. Probably not bzip2, as it has CRCs.
>
Do you mean ketchup doesn't do anything if a file is corrupted?
>Do you have ECC memory?
>
No. Do you mean it's an error of my RAM? I have never met such things before,
how often does such kind of things happen? May be less often than a bug in
a stable kernel?
Thanks!
On Fri, Jun 08, 2007 at 12:39:30AM +0800, WANG Cong wrote:
> >Ketchup doesn't even look inside patches, and patch doesn't invent
> >names, so something in the bzip2 -> patch(1) -> filesystem chain got
> >corrupted. Probably not bzip2, as it has CRCs.
> >
>
> Do you mean ketchup doesn't do anything if a file is corrupted?
Ketchup never even sees the filenames. It just calls bzip2 | patch. So
it can't be responsible for damaging the filename.
> >Do you have ECC memory?
>
> No. Do you mean it's an error of my RAM? I have never met such things before,
> how often does such kind of things happen? May be less often than a bug in
> a stable kernel?
The best studies I've seen suggest so-called "soft errors" in DRAM
happen at a rate of once a week to once a day per gigabyte of RAM at
sea-level. It's unknown how many of these errors manifest by visibly
corrupting data, but it wouldn't be surprising if it were
significantly less than 10%. But ECC is definitely not just for the
paranoid!
So if I were to rank the reliability of everything, it'd look
something like this, highest to lowest:
bzip: simple, stable and heavily-used codebase, built-in safeguards like CRC
patch: simple, stable, heavily-used, limited detection of input errors
CPU: heavily used, very low non-catastrophic failure rate
disk: heavily used, CRC on cable, ECC on disk
kernel: complex, rapidly-changing, but heavily-used
Non-ECC DRAM: significant known transient failure rate
When the error rate for the kernel approaches that of DRAM, it gets
very hard to assign blame.
(And of course, there's the user, who tends to be near the bottom of
this range, but I'll let you judge that.)
--
Mathematics is the supreme nostalgia of our time.
It'Greg KH napsal(a):
> On Thu, Jun 07, 2007 at 05:54:13PM +0200, Jiri Slaby wrote:
>> Tejun Heo napsal(a):
>>> Jiri Slaby wrote:
>>>> Tejun Heo napsal(a):
>>>>> Jiri Slaby wrote:
>>>>>> Yes. Now I'm compiling -rc4-mm2.
>>>>> It's probably caused by new sysfs slimdown patches and I'm pretty sure
>>>>> -rc4-mm2 would fail the same way. The offending one should be one of
>>>>> the following patches.
>>>> There's reverted gregkh-driver-block-device in -mm2. So I wanted to give it a
>>>> try. Do you think it's pointless and that patch has no impact on the behaviour?
>>> I'm not familiar with how lvm vgscan works and the patch does look like
>>> it can affect that. Please give a shot at -mm2.
>> Yup, it works without any further patches. So it seems like
>> gregkh-driver-block-device is the culprit?
>
> Culprit for what kind of symptom? Is CONFIG_SYSFS_DEPRECATED enabled?
> If not, can you try that?
LVM (lvm whatever) writes can't initialize lock 1 and quits.
SYSFS_DEPRECATED solves the issue (-rc4-mm2 minus the revert + SYSFS_DEPRECATED).
thanks,
--
http://www.fi.muni.cz/~xslaby/ Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E
Greg KH ([email protected]) said:
> There are a number of distros out there right now who can support that
> option disabled. I'm pretty sure they are the following right now:
> Gentoo unstable (actually stable works now for me, but I'm not
> going to guarantee it just yet...)
> Debian unstable (again stable might work, but I have not heard
> any reports from testers.)
> openSUSE FACTORY (the 10.3 alpha releases)
>
> and now it sounds like Red Hat rawhide will also work properly.
I suspect while it will work for mkinitrd, the installer will not
work properly.
Bill
On Thu, Jun 07, 2007 at 08:54:50AM +0200, Jan Engelhardt wrote:
>
> On Jun 6 2007 16:42, Andrew Morton wrote:
>
> >> If so then you sent to it me :)
> >
> >You merged it ;)
> >
> >> Should I drop it?
> >
> >Sure, Jan will fix it up, I assume. I might have broken it while repairing
> >the reject storm which occurred when that durned HAS_IOMEM thing went in
> >all over the tree.
>
> /me points at Herbert
> Andrew would not add options between the "menuconfig CRYPTO" and
> the "if CRYPTO" line... :)
>
>
> Jan
>
>
> ===
>
> Unbreak the crypto menu breakage.
>
> Signed-off-by: Jan Engelhardt <[email protected]>
>
> ---
> crypto/Kconfig | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> Index: linux-2.6.22-rc4/crypto/Kconfig
> ===================================================================
> --- linux-2.6.22-rc4.orig/crypto/Kconfig
> +++ linux-2.6.22-rc4/crypto/Kconfig
> @@ -7,6 +7,8 @@ menuconfig CRYPTO
> help
> This option provides the core Cryptographic API.
>
> +if CRYPTO
> +
> #
> # Generic algorithms support
> #
> @@ -18,8 +20,6 @@ config XOR_BLOCKS
> #
> source "crypto/async_tx/Kconfig"
>
> -if CRYPTO
> -
> config CRYPTO_ALGAPI
> tristate
> help
This seems to be buggy since the options in crypto/async_tx/Kconfig do
not depend on the crypto subsystem (and they are not user visible
options that get select'ed).
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Thu, Jun 07, 2007 at 02:48:05PM -0400, Bill Nottingham wrote:
> Greg KH ([email protected]) said:
> > There are a number of distros out there right now who can support that
> > option disabled. I'm pretty sure they are the following right now:
> > Gentoo unstable (actually stable works now for me, but I'm not
> > going to guarantee it just yet...)
> > Debian unstable (again stable might work, but I have not heard
> > any reports from testers.)
> > openSUSE FACTORY (the 10.3 alpha releases)
> >
> > and now it sounds like Red Hat rawhide will also work properly.
>
> I suspect while it will work for mkinitrd, the installer will not
> work properly.
Ah, but the installer doesn't matter until you do a Fedora 8 release,
right? This is just for people who want to run their own kernel on an
already-set-up Fedora machine.
thanks,
greg k-h
On Thu, Jun 07, 2007 at 07:02:23PM +0200, Jiri Slaby wrote:
> It'Greg KH napsal(a):
> > On Thu, Jun 07, 2007 at 05:54:13PM +0200, Jiri Slaby wrote:
> >> Tejun Heo napsal(a):
> >>> Jiri Slaby wrote:
> >>>> Tejun Heo napsal(a):
> >>>>> Jiri Slaby wrote:
> >>>>>> Yes. Now I'm compiling -rc4-mm2.
> >>>>> It's probably caused by new sysfs slimdown patches and I'm pretty sure
> >>>>> -rc4-mm2 would fail the same way. The offending one should be one of
> >>>>> the following patches.
> >>>> There's reverted gregkh-driver-block-device in -mm2. So I wanted to give it a
> >>>> try. Do you think it's pointless and that patch has no impact on the behaviour?
> >>> I'm not familiar with how lvm vgscan works and the patch does look like
> >>> it can affect that. Please give a shot at -mm2.
> >> Yup, it works without any further patches. So it seems like
> >> gregkh-driver-block-device is the culprit?
> >
> > Culprit for what kind of symptom? Is CONFIG_SYSFS_DEPRECATED enabled?
> > If not, can you try that?
>
> LVM (lvm whatever) writes can't initialize lock 1 and quits.
>
> SYSFS_DEPRECATED solves the issue (-rc4-mm2 minus the revert + SYSFS_DEPRECATED).
Great, thanks for letting us know.
Kay, what userspace tool is involved here that is getting confused?
thanks,
greg k-h
On Thu, 07 Jun 2007 15:44:56 +0900, Tejun Heo said:
> [email protected] wrote:
> > On Wed, 06 Jun 2007 02:07:37 PDT, Andrew Morton said:
> >> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2
.6.22-rc4-mm1/
> >
> > This one died a horrid death at boot time - console log indicates it found
the
> > hard drive OK, found the 2 partitions on it. But when the initrd ran a
> > 'lvm vgscan', it didn't find the LVM2 space on /dev/sda2, so it panic'ed wh
en
> > it fell off the end of the initrd because the root= wasn't there.
> >
> > My first guess for blame:
> >
> > gregkh-driver-sysfs-allocate-inode-number-using-ida.patch
> >
> > as that's awfully similar to gregkh-driver-sysfs-fix-i_ino-handling-in-sysfs.patch
> > that broke 'lvm vgscan' for me in the same way on 21-rc7-mm[12].
> >
> > I'll hopefully get a chance to revert that one and test later today - a quick
> > 'patch -p1 -R --dry-run' shows a number of conflicts that will need hand-fixing
> > at the very least.
>
> Did rc3-mm1 work? Can you find out the first broken -mm?
21-rc5-mm2 worked, -rc6-mm* were busticated for other reasons on my laptop,
21-rc7-mm[12] were broken, 21-mm1 through 21-rc3-mm1 worked, -rc4-mm1 broke,
and -rc4-mm2 works. I could bisect through -rc4-mm1 if it's deemed useful,
Andrew just pushed -mm2 before I had a chance.
Greg KH wrote:
> On Thu, Jun 07, 2007 at 02:48:05PM -0400, Bill Nottingham wrote:
>> Greg KH ([email protected]) said:
>>> There are a number of distros out there right now who can support that
>>> option disabled. I'm pretty sure they are the following right now:
>>> Gentoo unstable (actually stable works now for me, but I'm not
>>> going to guarantee it just yet...)
>>> Debian unstable (again stable might work, but I have not heard
>>> any reports from testers.)
>>> openSUSE FACTORY (the 10.3 alpha releases)
>>>
>>> and now it sounds like Red Hat rawhide will also work properly.
>> I suspect while it will work for mkinitrd, the installer will not
>> work properly.
>
> Ah, but the installer doesn't matter until you do a Fedora 8 release,
> right? This is just for people who want to run their own kernel on an
> already-set-up Fedora machine.
Eh, not so sure that's true. It's really kudzu rather than the
installer itself, and that's used by, for example, system-config-network.
--
Peter
> Ah, but the installer doesn't matter until you do a Fedora 8 release,
> right? This is just for people who want to run their own kernel on an
> already-set-up Fedora machine.
People can and do roll updated install images because you get systems
that aren't supported by the released CD boot image. The installer/initrd
etc shouldn't keep getting broken by these kind of changes, its about
time that all the sysfs type breakage causing patches simply got
rejected, like such patches would in every other subsystem.
Yes it might cause a little pain, yes someone might have to tweak sysfs a
bit to keep compatibility and decouple the external and internal view a
bit - Matthew and others pointed out this problem several years ago and
predicted the current state of affairs, so its had a lot of time to get
fixed.
Alan
On Thu, Jun 07, 2007 at 11:32:58PM +0100, Alan Cox wrote:
> > Ah, but the installer doesn't matter until you do a Fedora 8 release,
> > right? This is just for people who want to run their own kernel on an
> > already-set-up Fedora machine.
>
> People can and do roll updated install images because you get systems
> that aren't supported by the released CD boot image. The installer/initrd
> etc shouldn't keep getting broken by these kind of changes, its about
> time that all the sysfs type breakage causing patches simply got
> rejected, like such patches would in every other subsystem.
>
> Yes it might cause a little pain, yes someone might have to tweak sysfs a
> bit to keep compatibility and decouple the external and internal view a
> bit - Matthew and others pointed out this problem several years ago and
> predicted the current state of affairs, so its had a lot of time to get
> fixed.
If CONFIG_SYSFS_DEPRECATED everything should work just fine with all old
initrd scripts. It's only if you enable that option (which is enabled
by default) that you need to ensure that your distro has the latest
functionality so that everything works properly.
So, we should be fine here. The distros that are up to date, and the
users of them, can disable the option. All others need to keep it on.
thanks,
greg k-h
On Thu, Jun 07, 2007 at 05:00:41PM -0400, Peter Jones wrote:
> Greg KH wrote:
> > On Thu, Jun 07, 2007 at 02:48:05PM -0400, Bill Nottingham wrote:
> >> Greg KH ([email protected]) said:
> >>> There are a number of distros out there right now who can support that
> >>> option disabled. I'm pretty sure they are the following right now:
> >>> Gentoo unstable (actually stable works now for me, but I'm not
> >>> going to guarantee it just yet...)
> >>> Debian unstable (again stable might work, but I have not heard
> >>> any reports from testers.)
> >>> openSUSE FACTORY (the 10.3 alpha releases)
> >>>
> >>> and now it sounds like Red Hat rawhide will also work properly.
> >> I suspect while it will work for mkinitrd, the installer will not
> >> work properly.
> > Ah, but the installer doesn't matter until you do a Fedora 8 release,
> > right? This is just for people who want to run their own kernel on an
> > already-set-up Fedora machine.
>
> Eh, not so sure that's true. It's really kudzu rather than the installer
> itself, and that's used by, for example, system-config-network.
Ok, then for Fedora 7 users, we should just recommend to keep
CONFIG_SYSFS_DEPRECATED enabled if you are using the -mm tree now, or
after 2.6.23 is out (which is the earliest I expect this block patch to
show up in mainline.)
thanks,
greg k-h
On Thu, 7 Jun 2007 08:34:58 -0700
Andrew Morton <[email protected]> wrote:
>
> I assume the above is your code - it's not in the tree?
>
Ah, that code was disappeared in -mm2.
But it informed me that I should consider memory unplug v.s. sys_mremap case...
Thanks, anyway.
-Kame
On Thu, Jun 07, 2007 at 10:53:29AM -0400, Alan Stern wrote:
> To tell you the truth, I rather think there's not much point in keeping
> usb-try-to-debug-bug-8561.patch around. Anything seriously wrong that
> it could catch ought to have shown up long ago. And it is now clear
> that bug 8561 has nothing to do with this; it is a programming error
> common to many of the USB serial drivers. (Still waiting to hear back
> from Paulo Pereira whether the fix to the USB Option driver works...)
What error in the usb-serial drivers are you speaking about?
thanks,
greg k-h
On Thu, Jun 07, 2007 at 11:59:16AM -0500, Matt Mackall wrote:
>On Fri, Jun 08, 2007 at 12:39:30AM +0800, WANG Cong wrote:
>> >Ketchup doesn't even look inside patches, and patch doesn't invent
>> >names, so something in the bzip2 -> patch(1) -> filesystem chain got
>> >corrupted. Probably not bzip2, as it has CRCs.
>> >
>>
>> Do you mean ketchup doesn't do anything if a file is corrupted?
>
>Ketchup never even sees the filenames. It just calls bzip2 | patch. So
>it can't be responsible for damaging the filename.
>
>> >Do you have ECC memory?
>>
>> No. Do you mean it's an error of my RAM? I have never met such things before,
>> how often does such kind of things happen? May be less often than a bug in
>> a stable kernel?
>
>The best studies I've seen suggest so-called "soft errors" in DRAM
>happen at a rate of once a week to once a day per gigabyte of RAM at
>sea-level. It's unknown how many of these errors manifest by visibly
>corrupting data, but it wouldn't be surprising if it were
>significantly less than 10%. But ECC is definitely not just for the
>paranoid!
>
>So if I were to rank the reliability of everything, it'd look
>something like this, highest to lowest:
>
> bzip: simple, stable and heavily-used codebase, built-in safeguards like CRC
> patch: simple, stable, heavily-used, limited detection of input errors
> CPU: heavily used, very low non-catastrophic failure rate
> disk: heavily used, CRC on cable, ECC on disk
> kernel: complex, rapidly-changing, but heavily-used
> Non-ECC DRAM: significant known transient failure rate
>
>When the error rate for the kernel approaches that of DRAM, it gets
>very hard to assign blame.
>
>(And of course, there's the user, who tends to be near the bottom of
>this range, but I'll let you judge that.)
Good explanation! Thanks!
That the RAM error occurs so often really surprises me.
I think it might be RAM's fault, because, at least, it's less reproduceable than
a bug in a stable kernel.
Regards!
[email protected] wrote:
> On Thu, 07 Jun 2007 15:44:56 +0900, Tejun Heo said:
>> [email protected] wrote:
>>> On Wed, 06 Jun 2007 02:07:37 PDT, Andrew Morton said:
>>>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2
> .6.22-rc4-mm1/
>>> This one died a horrid death at boot time - console log indicates it found
> the
>>> hard drive OK, found the 2 partitions on it. But when the initrd ran a
>>> 'lvm vgscan', it didn't find the LVM2 space on /dev/sda2, so it panic'ed wh
> en
>>> it fell off the end of the initrd because the root= wasn't there.
>>>
>>> My first guess for blame:
>>>
>>> gregkh-driver-sysfs-allocate-inode-number-using-ida.patch
>>>
>>> as that's awfully similar to gregkh-driver-sysfs-fix-i_ino-handling-in-sysfs.patch
>>> that broke 'lvm vgscan' for me in the same way on 21-rc7-mm[12].
>>>
>>> I'll hopefully get a chance to revert that one and test later today - a quick
>>> 'patch -p1 -R --dry-run' shows a number of conflicts that will need hand-fixing
>>> at the very least.
>> Did rc3-mm1 work? Can you find out the first broken -mm?
>
> 21-rc5-mm2 worked, -rc6-mm* were busticated for other reasons on my laptop,
> 21-rc7-mm[12] were broken, 21-mm1 through 21-rc3-mm1 worked, -rc4-mm1 broke,
> and -rc4-mm2 works. I could bisect through -rc4-mm1 if it's deemed useful,
> Andrew just pushed -mm2 before I had a chance.
Thanks. The offending patch was
gregkh-driver-block-device
Which is pulled from -mm2. Jiri Slaby reports that turning on
SYSFS_DEPRECATED fixes the problem.
Thanks.
--
tejun
On Thu, 7 Jun 2007 09:15:25 -0700 Greg KH <[email protected]> wrote:
> On Thu, Jun 07, 2007 at 09:06:32AM -0700, Andrew Morton wrote:
> > On Thu, 7 Jun 2007 08:59:53 -0700 Greg KH <[email protected]> wrote:
> >
> > > On Thu, Jun 07, 2007 at 08:52:00AM -0700, Andrew Morton wrote:
> > > > On Thu, 7 Jun 2007 08:43:42 -0700 Greg KH <[email protected]> wrote:
> > > >
> > > > > > Fixed in mkinitrd-6.0.9-6 , which I'll build now and push to
> > > > > > updates-testing. Thanks for getting my attention here.
> > > > >
> > > > > Great, Andrew, can you please reenable the block-device patch that is in
> > > > > my tree now that the problem has been solved?
> > > >
> > > > I think we're screwed, aren't we? Everyone needs to upgrade mkinitrd to be
> > > > able to boot the kernel? Not viable :(
> > > >
> > > > For example, what about my two-year-old yellowdog machine?
> > >
> > > Enable CONFIG_SYSFS_DEPRECATED and it should all work just fine. That's
> > > what Michal said worked for him.
> > >
> >
> > Actually, it _was_ enabled.
> >
> > Ho hum, I'll have a poke at it this evening.
>
> Yeah, that sounds odd, it should have worked.
yup, yellowdog 4.1 on a mac g5:
gregkh-driver-block-device.patch applied, CONFIG_SYSFS_DEPRECATED=y:
http://userweb.kernel.org/~akpm/s5000552.jpg
gregkh-driver-block-device.patch applied, CONFIG_SYSFS_DEPRECATED=n:
Can't open /dev/sdb6 (root partition)
gregkh-driver-block-device.patch not applied, CONFIG_SYSFS_DEPRECATED=y:
Happy camper
gregkh-driver-block-device.patch not applied, CONFIG_SYSFS_DEPRECATED=n:
Still happy
The only problem known as to the acpi throttling changes in the mm tree
is a typo ,and the patch to fix it is available here. Please test and
get results back to me. BTW,the log shows that the acpi-cpufreq.ko has
problem. Would please also try not to load acpi-cpufreq.
http://www.ussg.iu.edu/hypermail/linux/kernel/0706.0/2509.html
On 6/7/07, Andrew Morton <[email protected]> wrote:
> On Wed, 06 Jun 2007 15:00:17 +0100 Andy Whitcroft <[email protected]> wrote:
>
> > Getting this on a bigger x86_64 (bl6-13):
> >
> > Unable to handle kernel NULL pointer dereference at 0000000000000000 RIP:
> > [<ffffffff8037898b>] acpi_processor_throttling_seq_show+0xa7/0xd6
> > PGD 2d77067 PUD 34c3067 PMD 0
> > Oops: 0000 [1] SMP
> > CPU 3
> > Modules linked in: video output button battery asus_acpi ac lp
> > parport_pc parport floppy nvram amd_rng rng_core i2c_amd756 i2c_core
> > Pid: 1634, comm: head Not tainted 2.6.22-rc4-mm1-autokern1 #1
> > RIP: 0010:[<ffffffff8037898b>] [<ffffffff8037898b>]
> > acpi_processor_throttling_seq_show+0xa7/0xd6
> > RSP: 0018:ffff810003c9de48 EFLAGS: 00010246
> > RAX: 0000000000000020 RBX: ffff8100029e7800 RCX: 0000000000000000
> > RDX: 000000000000002a RSI: ffffffff805993e4 RDI: ffff810002d714c0
> > RBP: ffff810002d714c0 R08: ffff810003f82051 R09: ffff810002d714c0
> > R10: ffffffffffffffff R11: 0000000000000000 R12: 0000000000000000
> > R13: 0000000000000000 R14: 0000000000000000 R15: 00007fff64fd2b90
> > FS: 00002b3545aec6f0(0000) GS:ffff810001683a40(0000) knlGS:0000000000000000
> > CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> > CR2: 0000000000000000 CR3: 0000000003966000 CR4: 00000000000006e0
> > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> > Process head (pid: 1634, threadinfo ffff810003c9c000, task ffff810001c8c810)
> > Stack: 00000000000000d0 ffff810002d714c0 0000000000000001 0000000000000001
> > 0000000000002000 ffffffff802ab6eb ffff810003c9df50 ffff810002915d00
> > ffff810002d714f0 ffff810002fa2000 0000000000000000 fffffffffffffffb
> > Call Trace:
> > [<ffffffff802ab6eb>] seq_read+0x105/0x28e
> > [<ffffffff802ab5e6>] seq_read+0x0/0x28e
> > [<ffffffff802cd085>] proc_reg_read+0x80/0x9a
> > [<ffffffff802925a7>] vfs_read+0xcb/0x153
> > [<ffffffff80292943>] sys_read+0x45/0x6e
> > [<ffffffff8020bc5e>] system_call+0x7e/0x83
> >
> >
> > Code: 45 8b 44 0d 00 44 89 e1 0f 45 d0 31 c0 49 ff c4 49 83 c5 28
> > RIP [<ffffffff8037898b>] acpi_processor_throttling_seq_show+0xa7/0xd6
> > RSP <ffff810003c9de48>
> > CR2: 0000000000000000
> > FATAL: Error inserting acpi_cpufreq
> > (/lib/modules/2.6.22-rc4-mm1-autokern1/kernel/arch/x86_64/kernel/cpufreq/acpi-cpufreq.ko):
> > No such device
>
> Was the oops at modprobe time? If so, it seems weird that
> acpi_processor_throttling_seq_show() would be getting run at that stage.
>
> (The oops trace is supposed to show the oopsing process's
> task_struct.comm[], but it isn't shown here?)
>
> Anyway, there are extensive changes in there added by git-acpi.patch. I
> suppose we can try to limp along with the below, but it'll probably just
> oops later on.
>
> --- a/drivers/acpi/processor_throttling.c~git-acpi-disable-acpi_processor_throttling_seq_show
> +++ a/drivers/acpi/processor_throttling.c
> @@ -648,6 +648,9 @@ static int acpi_processor_throttling_seq
> goto end;
> }
>
> + seq_puts(seq, "acpi_processor_throttling_seq_show() is busted\n");
> + goto end;
> +
> seq_printf(seq, "state count: %d\n"
> "active state: T%d\n"
> "state available: T%d to T%d\n",
> _
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
On Thu, 7 Jun 2007, Greg KH wrote:
> On Thu, Jun 07, 2007 at 10:53:29AM -0400, Alan Stern wrote:
> > To tell you the truth, I rather think there's not much point in keeping
> > usb-try-to-debug-bug-8561.patch around. Anything seriously wrong that
> > it could catch ought to have shown up long ago. And it is now clear
> > that bug 8561 has nothing to do with this; it is a programming error
> > common to many of the USB serial drivers. (Still waiting to hear back
> > from Paulo Pereira whether the fix to the USB Option driver works...)
>
> What error in the usb-serial drivers are you speaking about?
The one addressed by usb-option-fix-usage-of-urb-status-abuse.patch. I
thought it might be worthwhile to spend some time fixing all of these.
Here's a quick summary showing the extent of the problem (note that
not all the usages are in error):
$ grep EINPROGRESS drivers/usb/serial/*.c drivers/usb/misc/*.c
drivers/usb/serial/digi_acceleport.c:* return 256 when -EINPROGRESS is set, as the line discipline
drivers/usb/serial/digi_acceleport.c: while( oob_port->write_urb->status == -EINPROGRESS
drivers/usb/serial/digi_acceleport.c: while( (port->write_urb->status == -EINPROGRESS
drivers/usb/serial/digi_acceleport.c: while( oob_port->write_urb->status == -EINPROGRESS
drivers/usb/serial/digi_acceleport.c: if( port->write_urb->status == -EINPROGRESS
drivers/usb/serial/digi_acceleport.c: if( port->open_count && port->write_urb->status != -EINPROGRESS
drivers/usb/serial/digi_acceleport.c: if( port->write_urb->status == -EINPROGRESS
drivers/usb/serial/digi_acceleport.c: if( port->write_urb->status == -EINPROGRESS
drivers/usb/serial/empeg.c: if (write_urb_pool[i]->status != -EINPROGRESS) {
drivers/usb/serial/empeg.c: if (write_urb_pool[i]->status != -EINPROGRESS) {
drivers/usb/serial/empeg.c: if (write_urb_pool[i]->status == -EINPROGRESS) {
drivers/usb/serial/keyspan.c: if (this_urb->status == -EINPROGRESS) {
drivers/usb/serial/keyspan.c: } while (urb->status != -EINPROGRESS);
drivers/usb/serial/keyspan.c: if (this_urb->status != -EINPROGRESS)
drivers/usb/serial/keyspan.c: if (this_urb->status != -EINPROGRESS)
drivers/usb/serial/keyspan.c: if (urb && urb->status == -EINPROGRESS)
drivers/usb/serial/keyspan.c: /*while (p_priv->outcont_urb->status == -EINPROGRESS) {
drivers/usb/serial/keyspan.c: if (this_urb->status == -EINPROGRESS) {
drivers/usb/serial/keyspan.c: if (this_urb->status == -EINPROGRESS) {
drivers/usb/serial/keyspan.c: if (this_urb->status == -EINPROGRESS) {
drivers/usb/serial/keyspan.c: if (this_urb->status == -EINPROGRESS) {
drivers/usb/serial/keyspan.c: if (this_urb->status == -EINPROGRESS) {
drivers/usb/serial/keyspan_pda.c: * urb status is -EINPROGRESS, meaning it cannot write at the moment
drivers/usb/serial/keyspan_pda.c: again (the only sudden transition was the one from EINPROGRESS to
drivers/usb/serial/kl5kusb105.c: if (priv->write_urb_pool[i]->status != -EINPROGRESS) {
drivers/usb/serial/kl5kusb105.c: if (priv->write_urb_pool[i]->status == -EINPROGRESS) {
drivers/usb/serial/kl5kusb105.c: if (priv->write_urb_pool[i]->status != -EINPROGRESS) {
drivers/usb/serial/mos7720.c: if (port->read_urb->status != -EINPROGRESS) {
drivers/usb/serial/mos7720.c: if (mos7720_port->write_urb_pool[i] && mos7720_port->write_urb_pool[i]->status == -EINPROGRESS)
drivers/usb/serial/mos7720.c: if (mos7720_port->write_urb_pool[i] && mos7720_port->write_urb_pool[i]->status != -EINPROGRESS)
drivers/usb/serial/mos7720.c: if (mos7720_port->write_urb_pool[i] && mos7720_port->write_urb_pool[i]->status != -EINPROGRESS) {
drivers/usb/serial/mos7720.c: if (port->read_urb->status != -EINPROGRESS) {
drivers/usb/serial/mos7720.c: if(port->read_urb->status != -EINPROGRESS) {
drivers/usb/serial/mos7840.c: if (mos7840_port->read_urb->status != -EINPROGRESS) {
drivers/usb/serial/mos7840.c: if (mos7840_port->read_urb->status != -EINPROGRESS) {
drivers/usb/serial/sierra.c: if (this_urb->status == -EINPROGRESS) {
drivers/usb/serial/sierra.c: if (this_urb && this_urb->status != -EINPROGRESS)
drivers/usb/serial/sierra.c: if (this_urb && this_urb->status == -EINPROGRESS)
drivers/usb/misc/adutux.c: if (dev->interrupt_in_urb->status == -EINPROGRESS) {
drivers/usb/misc/adutux.c: if (should_submit && !dev->interrupt_in_urb->status==-EINPROGRESS) {
drivers/usb/misc/adutux.c: if (dev->interrupt_out_urb->status == -EINPROGRESS) {
drivers/usb/misc/auerswald.c: urb->status = -EINPROGRESS; /* usb_submit_urb does this, too */
drivers/usb/misc/auerswald.c: the result is 0 if the urb is cancelled, or -EINPROGRESS if
drivers/usb/misc/auerswald.c: if (urb->status != -EINPROGRESS) { /* No callback?!! */
drivers/usb/misc/auerswald.c:-EINPROGRESS during submission until end
drivers/usb/misc/usbtest.c: case -EINPROGRESS:
drivers/usb/misc/usbtest.c: if (!(retval == 0 || retval == -EINPROGRESS)) {
Alan Stern
On Thu, 07 Jun 2007 16:09:04 PDT, Greg KH said:
> If CONFIG_SYSFS_DEPRECATED everything should work just fine with all old
> initrd scripts. It's only if you enable that option (which is enabled
> by default) that you need to ensure that your distro has the latest
> functionality so that everything works properly.
Can somebody document what an initrd has to do differently? Some of us
run with initrd's not created by mkinitrd.
On Fri, Jun 08, 2007 at 11:33:38AM -0400, [email protected] wrote:
> On Thu, 07 Jun 2007 16:09:04 PDT, Greg KH said:
> > If CONFIG_SYSFS_DEPRECATED everything should work just fine with all old
> > initrd scripts. It's only if you enable that option (which is enabled
> > by default) that you need to ensure that your distro has the latest
> > functionality so that everything works properly.
>
> Can somebody document what an initrd has to do differently? Some of us
> run with initrd's not created by mkinitrd.
So I'm guessing that you wrote your own initrd?
The main issue is that /sys/block/ is now full of symlinks, not real
directories, if CONFIG_SYSFS_DEPRECATED is not enabled. That means that
any program that was doing stat() should be doing lstat() for the block
directory to work on all instances (remember, whenever looking for a
directory or a file in sysfs, it could be either a real file/directory
or a symlink, you should not care either way.)
People have also reported that for some reason, removing the '--movedev'
argument to switchroot is also needed, but that might just be a Fedora 7
specific thing, I'm not quite sure.
See the post from Alan Stern on lkml with the subject:
Re: [RFC PATCH] /sys/block -> /sys/class/block (Fedora 3 & 4 testers wanted)
for more details on that.
Hope this helps,
greg k-h
On Fri, Jun 08, 2007 at 12:31:18AM -0700, Andrew Morton wrote:
> On Thu, 7 Jun 2007 09:15:25 -0700 Greg KH <[email protected]> wrote:
>
> > On Thu, Jun 07, 2007 at 09:06:32AM -0700, Andrew Morton wrote:
> > > On Thu, 7 Jun 2007 08:59:53 -0700 Greg KH <[email protected]> wrote:
> > >
> > > > On Thu, Jun 07, 2007 at 08:52:00AM -0700, Andrew Morton wrote:
> > > > > On Thu, 7 Jun 2007 08:43:42 -0700 Greg KH <[email protected]> wrote:
> > > > >
> > > > > > > Fixed in mkinitrd-6.0.9-6 , which I'll build now and push to
> > > > > > > updates-testing. Thanks for getting my attention here.
> > > > > >
> > > > > > Great, Andrew, can you please reenable the block-device patch that is in
> > > > > > my tree now that the problem has been solved?
> > > > >
> > > > > I think we're screwed, aren't we? Everyone needs to upgrade mkinitrd to be
> > > > > able to boot the kernel? Not viable :(
> > > > >
> > > > > For example, what about my two-year-old yellowdog machine?
> > > >
> > > > Enable CONFIG_SYSFS_DEPRECATED and it should all work just fine. That's
> > > > what Michal said worked for him.
> > > >
> > >
> > > Actually, it _was_ enabled.
> > >
> > > Ho hum, I'll have a poke at it this evening.
> >
> > Yeah, that sounds odd, it should have worked.
>
> yup, yellowdog 4.1 on a mac g5:
>
> gregkh-driver-block-device.patch applied, CONFIG_SYSFS_DEPRECATED=y:
> http://userweb.kernel.org/~akpm/s5000552.jpg
Ugh.
Kay, any thoughts? Does switchroot need to have the --movedev option
removed for some reason?
thanks,
greg k-h
On Fri, 2007-06-08 at 11:33 -0400, [email protected] wrote:
> On Thu, 07 Jun 2007 16:09:04 PDT, Greg KH said:
> > If CONFIG_SYSFS_DEPRECATED everything should work just fine with all old
> > initrd scripts. It's only if you enable that option (which is enabled
> > by default) that you need to ensure that your distro has the latest
> > functionality so that everything works properly.
>
> Can somebody document what an initrd has to do differently? Some of us
> run with initrd's not created by mkinitrd.
You should be fine if you don't explicitly distinguish between symlinks
and directories.
Or just look what almost everybody is doing in initramfs, Debian,
Gentoo, Ubuntu, SUSE, ..., all use uevent-driven udev bootup there, and
it just works without caring about anything in sysfs or weird timing
issues.
Kay
On Fri, Jun 08, 2007 at 08:50:27AM -0700, Greg KH wrote:
> On Fri, Jun 08, 2007 at 11:33:38AM -0400, [email protected] wrote:
> > On Thu, 07 Jun 2007 16:09:04 PDT, Greg KH said:
> > > If CONFIG_SYSFS_DEPRECATED everything should work just fine with all old
> > > initrd scripts. It's only if you enable that option (which is enabled
> > > by default) that you need to ensure that your distro has the latest
> > > functionality so that everything works properly.
> >
> > Can somebody document what an initrd has to do differently? Some of us
> > run with initrd's not created by mkinitrd.
>
> So I'm guessing that you wrote your own initrd?
>
> The main issue is that /sys/block/ is now full of symlinks, not real
> directories, if CONFIG_SYSFS_DEPRECATED is not enabled. That means that
> any program that was doing stat() should be doing lstat() for the block
> directory to work on all instances (remember, whenever looking for a
> directory or a file in sysfs, it could be either a real file/directory
> or a symlink, you should not care either way.)
Oops, sorry about that, it should be the other way around, stat(), not
lstat().
greg k-h
On Fri, 2007-06-08 at 08:51 -0700, Greg KH wrote:
> On Fri, Jun 08, 2007 at 12:31:18AM -0700, Andrew Morton wrote:
> > On Thu, 7 Jun 2007 09:15:25 -0700 Greg KH <[email protected]> wrote:
> >
> > > On Thu, Jun 07, 2007 at 09:06:32AM -0700, Andrew Morton wrote:
> > > > On Thu, 7 Jun 2007 08:59:53 -0700 Greg KH <[email protected]> wrote:
> > > >
> > > > > On Thu, Jun 07, 2007 at 08:52:00AM -0700, Andrew Morton wrote:
> > > > > > On Thu, 7 Jun 2007 08:43:42 -0700 Greg KH <[email protected]> wrote:
> > > > > >
> > > > > > > > Fixed in mkinitrd-6.0.9-6 , which I'll build now and push to
> > > > > > > > updates-testing. Thanks for getting my attention here.
> > > > > > >
> > > > > > > Great, Andrew, can you please reenable the block-device patch that is in
> > > > > > > my tree now that the problem has been solved?
> > > > > >
> > > > > > I think we're screwed, aren't we? Everyone needs to upgrade mkinitrd to be
> > > > > > able to boot the kernel? Not viable :(
> > > > > >
> > > > > > For example, what about my two-year-old yellowdog machine?
> > > > >
> > > > > Enable CONFIG_SYSFS_DEPRECATED and it should all work just fine. That's
> > > > > what Michal said worked for him.
> > > > >
> > > >
> > > > Actually, it _was_ enabled.
> > > >
> > > > Ho hum, I'll have a poke at it this evening.
> > >
> > > Yeah, that sounds odd, it should have worked.
> >
> > yup, yellowdog 4.1 on a mac g5:
> >
> > gregkh-driver-block-device.patch applied, CONFIG_SYSFS_DEPRECATED=y:
> > http://userweb.kernel.org/~akpm/s5000552.jpg
>
> Ugh.
>
> Kay, any thoughts? Does switchroot need to have the --movedev option
> removed for some reason?
Hmm, no idea, /sys/block should not have changed with
CONFIG_SYSFS_DEPRECATED=y. And it works fine for Michal and FC7.
Alan Stern mentioned the --movedev option with its customized initramfs,
or did other people report something similar?
Peter, any idea what it could be, that goes wrong on Andrew's box, or
how to look for what exactly is going wrong?
http://userweb.kernel.org/~akpm/s5000552.jpg
Seems that yellowdog uses RH's nash.
Thanks,
Kay
Kay Sievers wrote:
> Peter, any idea what it could be, that goes wrong on Andrew's box, or
> how to look for what exactly is going wrong?
> http://userweb.kernel.org/~akpm/s5000552.jpg
> Seems that yellowdog uses RH's nash.
Yeah, but a /really/ old version -- 4.2.11 is from May 2005 :/ . I feel
I should point out that that version IS using udev, but just like
mkinitrd and nash, the udev there is probably just as old. At the same
time, that does make it an excellent test case for this sort of situation.
Andrew, is there any chance you can put that initrd.img somewhere that I
can download it? That'd really help me to figure out what's going on,
as the minutia of our initrds from 2005 have faded a bit in my memory.
--
Peter
On Fri, 8 Jun 2007 17:15:45 +0800
"Luming Yu" <[email protected]> wrote:
> The only problem known as to the acpi throttling changes in the mm tree
> is a typo ,and the patch to fix it is available here. Please test and
> get results back to me. BTW,the log shows that the acpi-cpufreq.ko has
> problem. Would please also try not to load acpi-cpufreq.
>
> http://www.ussg.iu.edu/hypermail/linux/kernel/0706.0/2509.html
Sigh. Is this some sort of contest to see how many things we can
do wrong in a single patch?
- Include a changelog
- Include Signed-off-by:
- Don't use attachments
- If you _must_ use attachments, use text/plain, not application/octet-stream
- Format code to remain within 80 columns.
- Don't do "if(". Do "if ("
Oh well. Good to hear that the oops got fixed, thanks.
From: "Luming Yu" <[email protected]>
Cc: Len Brown <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
---
drivers/acpi/processor_throttling.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff -puN drivers/acpi/processor_throttling.c~acpi-fix-oops-in-acpi_processor_throttling_seq_show drivers/acpi/processor_throttling.c
--- a/drivers/acpi/processor_throttling.c~acpi-fix-oops-in-acpi_processor_throttling_seq_show
+++ a/drivers/acpi/processor_throttling.c
@@ -656,18 +656,20 @@ static int acpi_processor_throttling_seq
pr->throttling.state_count - 1);
seq_puts(seq, "states:\n");
- if (acpi_processor_get_throttling == acpi_processor_get_throttling_fadt)
+ if (pr->throttling.acpi_processor_get_throttling ==
+ acpi_processor_get_throttling_fadt) {
for (i = 0; i < pr->throttling.state_count; i++)
seq_printf(seq, " %cT%d: %02d%%\n",
(i == pr->throttling.state ? '*' : ' '), i,
(pr->throttling.states[i].performance ? pr->
throttling.states[i].performance / 10 : 0));
- else
+ } else {
for (i = 0; i < pr->throttling.state_count; i++)
seq_printf(seq, " %cT%d: %02d%%\n",
(i == pr->throttling.state ? '*' : ' '), i,
(int)pr->throttling.states_tss[i].
freqpercentage);
+ }
end:
return 0;
_
On Fri, Jun 08, 2007 at 10:06:21AM -0400, Alan Stern wrote:
> On Thu, 7 Jun 2007, Greg KH wrote:
>
> > On Thu, Jun 07, 2007 at 10:53:29AM -0400, Alan Stern wrote:
> > > To tell you the truth, I rather think there's not much point in keeping
> > > usb-try-to-debug-bug-8561.patch around. Anything seriously wrong that
> > > it could catch ought to have shown up long ago. And it is now clear
> > > that bug 8561 has nothing to do with this; it is a programming error
> > > common to many of the USB serial drivers. (Still waiting to hear back
> > > from Paulo Pereira whether the fix to the USB Option driver works...)
> >
> > What error in the usb-serial drivers are you speaking about?
>
> The one addressed by usb-option-fix-usage-of-urb-status-abuse.patch. I
> thought it might be worthwhile to spend some time fixing all of these.
> Here's a quick summary showing the extent of the problem (note that
> not all the usages are in error):
Ah, yeah, I cleaned up a lot of them a while ago, but they keep creaping
back.
I _really_ think we need to just get rid of that field and pass the
status in the urb callback. That would fix this problem once and for
all.
But, from what I remember, the uhci host controller didn't make it easy
for me to acomplish this. Or it might have been another host
controller, can't remember anymore...
So, anyone looking to make up some patches that touch every USB driver
in the tree? I'd be glad to take them :)
thanks,
greg k-h
On 6/7/07, Andrew Morton <[email protected]> wrote:
> On Thu, 7 Jun 2007 17:01:08 +1000 Herbert Xu <[email protected]> wrote:
>
> > On Thu, Jun 07, 2007 at 08:54:50AM +0200, Jan Engelhardt wrote:
> > >
> > > /me points at Herbert
> > > Andrew would not add options between the "menuconfig CRYPTO" and
> > > the "if CRYPTO" line... :)
> >
> > Actually this patch is not even in my tree :)
>
> uh, OK, sorry.
>
> > > Index: linux-2.6.22-rc4/crypto/Kconfig
> > > ===================================================================
> > > --- linux-2.6.22-rc4.orig/crypto/Kconfig
> > > +++ linux-2.6.22-rc4/crypto/Kconfig
> > > @@ -7,6 +7,8 @@ menuconfig CRYPTO
> > > help
> > > This option provides the core Cryptographic API.
> > >
> > > +if CRYPTO
> > > +
> > > #
> > > # Generic algorithms support
> > > #
> > > @@ -18,8 +20,6 @@ config XOR_BLOCKS
> > > #
> > > source "crypto/async_tx/Kconfig"
> >
> > Andrew, do you want me to pick the async_tx stuff up instead?
> >
>
It would be very helpful to have a clear merge path for dmaengine
changes and the async offload api. Neil has been extremely helpful
reviewing the raid specific changes, and I received his "Acked-by" for
the changes to MD[1]. However I have thus far been unable to attract
someone to 'ack/nak' the async_tx api and the changes to drivers/dma/
[2]. Jeff commented on an early revision...
I have recently gravitated to Herbert and the crypto directory since
async_tx and crypto have some structural similarities [3].
> I wouldn't recommend it. It's an ongoing source of bustage frankly, has a
> habit of getting unpleasantly tangled with git-ioat.patch and afaik is
> still awaiting a go-ahead from Neil.
>
Sorry, the crypto/Kconfig bustage was a goof on my part as I moved the
async_tx files from drivers/dma/, to the top-level directory, and
finally to crypto/. Hopefully these recent build breakages I have
caused in -mm have not put the series in too negative a light...
I was hoping the git-ioat.patch situation would be solved by me
rebasing my series on a version of mainline with Chris' changes
merged, but his attempts over the past two merge windows were ignored.
Should my series wait outside of -mm until git-ioat.patch makes
forward progress?
Overall, I feel that async_tx is perhaps justifiably receiving the
silent treatment because offload engines are not a mainstream
occurrence. Currently only people with an Xscale IOP or a PPC 440spe
[4] will notice that mainline lacks support for all the features of
their platform. I see async_tx as a nod to the embedded space where
offload engines act to make up for the absence of multi-Ghz CPUs with
streaming SIMD instructions.
Herbert's offer is greatly appreciated as it will give guidance to the
parts of the series outside of Neil's purview.
Regards,
Dan
[1]: The ack from Neil was in an offlist message for the MD specific
portion of the series
[2]: I asked DaveM and netdev to take a look at the two patches in the
series that change drivers/dma/ and net/core/dev.c since that was the
original merge path for I/OAT and dmaengine
[3]: async_tx is similar to crypto in that they both provide a library
of memory transforms that can in some cases be carried out by
hardware.
[4]: async_tx has attracted at least one other developer that I know
about to write a driver for their engines:
http://marc.info/?l=linux-raid&m=117400143317440&w=2
On Sun, 10 Jun 2007 22:01:34 -0700 "Dan Williams" <[email protected]> wrote:
> It would be very helpful to have a clear merge path for dmaengine
> changes and the async offload api.
Yes, this needs some attention.
I'd suggest that you prepare a standalone tree for Linus to pull and we aim at
asking him to pull that for 2.6.23-rc1.
In the meanwhile I'd suggest that you get the core patch(es) out
onto the relevant lists again and cc'ed to the relevant maintainers.
Of course, good changelogging and commenting makes the review a) more
effective, b) more likely to happen and c) less work for reviewers. The
changelog you have for 7556477664edcbe1c9a2fdf60edddfd8455d198b is nice,
but it's awfully short for a 1/4MB patch. It tells us at a high level what
the code does, but it has nothing to say about how it does it: a high-level
design description, of you will.
Put yourself in the position of an experienced kernel developer who doesn't
know this code, and who doesn't know the hardware. What can you do to make
their review easier and more effective?
So. Please have a think about what you can do there, and also see what can
be done about the 312 warnings which
perl scripts/checkpatch.pl patches/git-md-accel.patch
emits. Then send 'em all out again (say, a week from now) and let's all just dig
in and make this thing happen?
On Sun, Jun 10, 2007 at 10:01:34PM -0700, Dan Williams wrote:
> Overall, I feel that async_tx is perhaps justifiably receiving the
> silent treatment because offload engines are not a mainstream
> occurrence. Currently only people with an Xscale IOP or a PPC 440spe
> [4] will notice that mainline lacks support for all the features of
> their platform. I see async_tx as a nod to the embedded space where
> offload engines act to make up for the absence of multi-Ghz CPUs with
> streaming SIMD instructions.
>
For what it's worth, I'm planning on tying in the SH DMA stuff to
the dmaengine code, as the async_tx stuff certainly has quite a few bits
of interest. This is probably something I won't get around to for 2.6.23
though, due to time constraints.
Applied.
thanks,
-Len
On Friday 08 June 2007 14:12, Andrew Morton wrote:
> On Fri, 8 Jun 2007 17:15:45 +0800
> "Luming Yu" <[email protected]> wrote:
>
> > The only problem known as to the acpi throttling changes in the mm tree
> > is a typo ,and the patch to fix it is available here. Please test and
> > get results back to me. BTW,the log shows that the acpi-cpufreq.ko has
> > problem. Would please also try not to load acpi-cpufreq.
> >
> > http://www.ussg.iu.edu/hypermail/linux/kernel/0706.0/2509.html
>
> Sigh. Is this some sort of contest to see how many things we can
> do wrong in a single patch?
>
> - Include a changelog
>
> - Include Signed-off-by:
>
> - Don't use attachments
>
> - If you _must_ use attachments, use text/plain, not application/octet-stream
>
> - Format code to remain within 80 columns.
>
> - Don't do "if(". Do "if ("
>
> Oh well. Good to hear that the oops got fixed, thanks.
>
>
> From: "Luming Yu" <[email protected]>
>
> Cc: Len Brown <[email protected]>
> Signed-off-by: Andrew Morton <[email protected]>
> ---
>
> drivers/acpi/processor_throttling.c | 6 ++++--
> 1 files changed, 4 insertions(+), 2 deletions(-)
>
> diff -puN drivers/acpi/processor_throttling.c~acpi-fix-oops-in-acpi_processor_throttling_seq_show drivers/acpi/processor_throttling.c
> --- a/drivers/acpi/processor_throttling.c~acpi-fix-oops-in-acpi_processor_throttling_seq_show
> +++ a/drivers/acpi/processor_throttling.c
> @@ -656,18 +656,20 @@ static int acpi_processor_throttling_seq
> pr->throttling.state_count - 1);
>
> seq_puts(seq, "states:\n");
> - if (acpi_processor_get_throttling == acpi_processor_get_throttling_fadt)
> + if (pr->throttling.acpi_processor_get_throttling ==
> + acpi_processor_get_throttling_fadt) {
> for (i = 0; i < pr->throttling.state_count; i++)
> seq_printf(seq, " %cT%d: %02d%%\n",
> (i == pr->throttling.state ? '*' : ' '), i,
> (pr->throttling.states[i].performance ? pr->
> throttling.states[i].performance / 10 : 0));
> - else
> + } else {
> for (i = 0; i < pr->throttling.state_count; i++)
> seq_printf(seq, " %cT%d: %02d%%\n",
> (i == pr->throttling.state ? '*' : ' '), i,
> (int)pr->throttling.states_tss[i].
> freqpercentage);
> + }
>
> end:
> return 0;
> _
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
