ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18/2.6.18-mm1/
- 2.6.18-rc7-mm1 had quite a lot of problems due to changes in the driver
tree. All of those have been dropped from this patchset.
Boilerplate:
- See the `hot-fixes' directory for any important updates to this patchset.
- To fetch an -mm tree using git, use (for example)
git fetch git://git.kernel.org/pub/scm/linux/kernel/git/smurf/linux-trees.git v2.6.16-rc2-mm1
- -mm kernel commit activity can be reviewed by subscribing to the
mm-commits mailing list.
echo "subscribe mm-commits" | mail [email protected]
- If you hit a bug in -mm and it is not obvious which patch caused it, it is
most valuable if you can perform a bisection search to identify which patch
introduced the bug. Instructions for this process are at
http://www.zip.com.au/~akpm/linux/patches/stuff/bisecting-mm-trees.txt
But beware that this process takes some time (around ten rebuilds and
reboots), so consider reporting the bug first and if we cannot immediately
identify the faulty patch, then perform the bisection search.
- When reporting bugs, please try to Cc: the relevant maintainer and mailing
list on any email.
- When reporting bugs in this kernel via email, please also rewrite the
email Subject: in some manner to reflect the nature of the bug. Some
developers filter by Subject: when looking for messages to read.
- Semi-daily snapshots of the -mm lineup are uploaded to
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/mm/ and are announced on
the mm-commits list.
Changes since 2.6.18-rc7-mm1:
origin.patch
git-acpi.patch
git-arm.patch
git-block.patch
git-cifs.patch
git-drm.patch
git-dvb.patch
git-geode.patch
git-gfs2.patch
git-ia64.patch
git-ieee1394.patch
git-intelfb.patch
git-jfs.patch
git-kbuild.patch
git-libata-all.patch
git-lxdialog.patch
git-magic.patch
git-mmc.patch
git-netdev-all.patch
git-ocfs2.patch
git-parisc.patch
git-pcmcia.patch
git-serial.patch
git-scsi-rc-fixes.patch
git-scsi-target.patch
git-watchdog.patch
git-xfs.patch
git trees
-add-headers_check-target-to-output-of-make-help.patch
-fix-make-headers_check-on-m68k.patch
-headers_check-clean-up-asm-parisc-pageh-for-user-headers.patch
-ext2-remove-superblock-lock-contention-in-ext2_statfs-2.patch
-sound-core-use-seek_set-cur.patch
-opl4-use-seek_set-cur.patch
-gus-use-seek_set-cur.patch
-mixart-use-seek_set-cur.patch
-cifs-use-seek_end-instead-of-hardcoded-value.patch
-git-cpufreq-sw_any_bug_dmi_table-can-be-used-on-resume.patch
-git-magic-fixup.patch
-git-magic-fixup-2.patch
-mtd-maps-ixp4xx-partition-parsing.patch
-fix-the-unlock-addr-lookup-bug-in-mtd-jedec-probe.patch
-fs-jffs2-jffs2_fs_ih-removal-of-old-code.patch
-drivers-mtd-nand-au1550ndc-removal-of-old-code.patch
-e1000-disable-device-on-pci-error.patch
-drivers-returning-proper-error-from-serial-driver.patch
-omap1510-serial-fix-for-115200-baud.patch
-git-scsi-misc-nlmsg_multicast-fix.patch
-megaraid-gcc-41-warning-fix.patch
-aha152x-fix.patch
-x86-remaining-pda-patches.patch
-x86-restore-i8259a-eoi-status-on-resume.patch
-pci-mtd-switch-to-pci_get_device-and-do-ref-counting.patch
Merged into mainline or a subsystem tree.
+rtc-lockdep-fix-workaround.patch
+i386-bootioremap--kexec-fix.patch
+do-not-free-non-slab-allocated-per_cpu_pageset.patch
+vidioc_enumstd-bug.patch
+backlight-fix-oops-in-__mutex_lock_slowpath-during-head-sys-class-graphics-fb0.patch
+cpu-to-node-relationship-fixup-take2.patch
+cpu-to-node-relationship-fixup-map-cpu-to-node.patch
+i386-fix-flat-mode-numa-on-a-real-numa-system.patch
+load_module-no-bug-if-module_subsys-uninitialized.patch
Various fixes, many takked for 2.6.18.x
+git-block-fixup.patch
Fix rejects in git-block.patch
+gregkh-driver-documentation-abi-devfs-is-not-obsolete-but-removed.patch
+gregkh-driver-device_bin_file.patch
-gregkh-driver-config_sysfs_deprecated.patch
-gregkh-driver-udev-devices.patch
-gregkh-driver-mem-devices.patch
-gregkh-driver-misc-devices.patch
-gregkh-driver-tty-device.patch
-gregkh-driver-vt-device.patch
-gregkh-driver-vc-device.patch
-gregkh-driver-raw-device.patch
-gregkh-driver-msr-device.patch
-gregkh-driver-cpuid-device.patch
-gregkh-driver-sound-device.patch
-gregkh-driver-ppp-device.patch
-gregkh-driver-ppdev-device.patch
-gregkh-driver-mmc-device.patch
-gregkh-driver-pcmcia-device.patch
-gregkh-driver-input-device.patch
-gregkh-driver-firmware-device.patch
-gregkh-driver-fb-device.patch
-gregkh-driver-usb-move-usb_device_class-class-devices-to-be-real-devices.patch
-gregkh-driver-usb-convert-usb-class-devices-to-real-devices.patch
-gregkh-driver-network-class_device-to-device.patch
-gregkh-driver-class_device_rename-remove.patch
+gregkh-driver-driver-core-fix-potential-deadlock-in-driver-core.patch
+gregkh-driver-driver-core-remove-unneeded-routines-from-driver-core.patch
+gregkh-driver-driver-core-don-t-call-put-methods-while-holding-a-spinlock.patch
-gregkh-driver-input-device-a3d-fix.patch
-gregkh-driver-input-device-more-fixes.patch
-gregkh-driver-input-device-even-more-fixes.patch
-gregkh-driver-input-device-even-more-fixes-2.patch
-gregkh-driver-fb-device-fixes.patch
-more-driver-tree-fixes.patch
Driver tree updates
+driver-core-fixes-make_class_name-retval-check.patch
+driver-core-fixes-device_register-retval-check-in.patch
+driver-core-fixes-sysfs_create_link-retval-check-in.patch
+driver-core-fixes-bus_add_attrs-retval-check.patch
+driver-core-fixes-bus_add_device-cleanup-on-error.patch
+driver-core-fixes-device_add-cleanup-on-error.patch
+driver-core-fixes-device_create_file-retval-check-in.patch
+driver-core-fixes-sysfs_create_group-retval-in-topologyc.patch
+sysfs-remove-duplicated-dput-in-sysfs_update_file.patch
+sysfs-update-obsolete-comment-in-sysfs_update_file.patch
Fix various things in driver core.
-dvb-usb-vs-driver-tree.patch
Dropped
+allow-rc5-codes-64-127-in-ir-kbd-i2cc.patch
+v4l-support-for-saa7134-based-avertv-hybrid-a16ar.patch
DVB things.
+gregkh-i2c-i2c-isa-plan-for-removal.patch
i2v tree update
+git-geode-fixup.patch
Fix rejects in git-geode.patch
+git-gfs2-fixup.patch
Fix rejects in git-gfs2.patch
+ia64-kprobes-fixup-the-pagefault-exception-caused-by-probehandlers.patch
ia64 fix
-stowaway-vs-driver-tree.patch
Dropped
+wistron-fix-detection-of-special-buttons.patch
input driver fix
+mmc-driver-for-ti-flashmedia-card-reader-source.patch
+mmc-driver-for-ti-flashmedia-card-reader-source-tidy.patch
+mmc-driver-for-ti-flashmedia-card-reader-source-alpha-fix.patch
+mmc-driver-for-ti-flashmedia-card-reader-source-vs-git-mmc.patch
+mmc-driver-for-ti-flashmedia-card-reader-kconfig-makefile.patch
mmc driver
+git-netdev-all-fixup.patch
Fix rejects in git-netdev-all.patch
-ip100a-fix-tx-pause-bug-reset_tx-intr_handler.patch
-ip100a-change-phy-address-search-from-phy=1-to-phy=0.patch
-ip100a-correct-initial-and-close-hardware-step.patch
-ip100a-solve-host-error-problem-in-low-performance.patch
Dropped, needs redoing.
+forcedeth-hardirq-lockdep-warning.patch
+e1000-account-for-net_ip_align-when-calculating-bufsiz.patch
netdev updates
-git-net-fixup.patch
Dropped.
-dev_change_name-debug.patch
Dropped, unneeded.
-bluetooth-small-cleanups.patch
Nacked.
-git-nfs-fixup.patch
Dropped.
+revert-genirq-core-fix-handle_level_irq.patch
Needed to make the parisc tree apply.
+git-parisc-fixup.patch
Fix rejects in git-parisc.patch
+pcmcia-au1000_generic-fix.patch
pcmcia fix
+ppc-fix-typo-in-cpm2h.patch
ppc fix
+git-serial-fixup.patch
Fix rejects in git-serial.patch
-gregkh-pci-pci-sort-device-lists-breadth-first.patch
-gregkh-pci-pci_bridge-device.patch
+gregkh-pci-acpiphp-set-hpp-values-before-starting-devices.patch
+gregkh-pci-acpiphp-initialize-ioapics-before-starting-devices.patch
+gregkh-pci-acpiphp-do-not-initialize-existing-ioapics.patch
+gregkh-pci-pci-add-pci_stop_bus_device.patch
+gregkh-pci-acpiphp-stop-bus-device-before-acpi_bus_trim.patch
+gregkh-pci-acpiphp-disable-bridges.patch
+gregkh-pci-pci-assign-ioapic-resource-at-hotplug.patch
+gregkh-pci-acpiphp-add-support-for-ioapic-hot-remove.patch
+gregkh-pci-ia64-pci-dont-disable-irq-which-is-not-enabled.patch
+gregkh-pci-pciehp-fix-wrong-return-value.patch
PCI tree updates
-git-scsi-misc-fixup.patch
Dropped.
+3w-xxxx-fix-ata-udma-upgrade-message-number.patch
+scsi-included-header-cleanup.patch
+pci-error-recovery-symbios-scsi-device-driver.patch
SCSI updates
+gregkh-usb-usb-unusual_devs-entry-for-lacie-dvd-rw.patch
+gregkh-usb-usb-unusual_dev-entry-for-sony-p990i.patch
-gregkh-usb-usb-introduce-usb_reenumerate_device.patch
+gregkh-usb-usb-fix-root-hub-resume-when-config_usb_suspend-is-not-set.patch
+gregkh-usb-usb-serial-support-alcor-micro-corp.-usb-2.0-to-rs-232-through-pl2303-driver.patch
+gregkh-usb-usb-ftdi-elan-client-driver-for-elan-uxxx-adapters.patch
+gregkh-usb-usb-u132-hcd-host-controller-driver-for-elan-u132-adapter.patch
+gregkh-usb-usb-remove-unneeded-void-casts-in-core-files.patch
+gregkh-usb-usb-dealias-110-code.patch
+gregkh-usb-usb-ohci_usb-can-oops-on-shutdown.patch
+gregkh-usb-usb-force-root-hub-resume-after-power-loss.patch
+gregkh-usb-usb-ehci-update-via-workaround.patch
+gregkh-usb-usb-remove-otg-build-warning.patch
USB tree updates
-revert-gregkh-usb-usbcore-remove-usb_suspend_root_hub.patch
Dropped.
+xpad-dance-pad-support.patch
+xpad-dance-pad-support-tidy.patch
USB updates
-x86_64-mm-via-force-dma-mask.patch
-x86_64-mm-iommu-setup-style.patch
-x86_64-mm-i386-acpi-mcfg-check.patch
-x86_64-mm-acpi-mcfg-check.patch
-x86_64-mm-remove-mcfg-dmi.patch
+x86_64-mm-mcfg-type1-heuristic.patch
+x86_64-mm-restore-i8259a-eoi.patch
+x86_64-mm-core2-rep-good.patch
+x86_64-mm-mmconfig-fix-comment.patch
+x86_64-mm-amd-single-cpu-sync-rdtsc.patch
+x86_64-mm-remove-signal-map.patch
+x86_64-mm-ia32-signal-regparm.patch
+x86_64-mm-ia32-signal-style.patch
+x86_64-mm-unwind-signal-frame-detect.patch
+x86_64-mm-dont-leak-nt.patch
+x86_64-mm-early-scan-depends-on-pci.patch
+x86_64-mm-move-pci-direct-out-of-line.patch
+x86_64-mm-allow-disabling-early-pci-scans.patch
+x86_64-mm-fix-unw-pc-warning.patch
+x86_64-mm-i386-fix-unwind-disabled.patch
+x86_64-mm-add-64bit-jiffies-compares-for-use-with-get_jiffies_64.patch
+x86_64-mm-refactor-thermal-throttle-processing.patch
+x86_64-mm-make-the-jiffies-compares-use-the-64bit-safe-macros..patch
+x86_64-mm-add-a-cumulative-thermal-throttle-event-counter..patch
x86_64 tree updates
-revert-x86_64-mm-detect-cfi.patch
-unwinder-warning-fixes.patch
-fix-x86_64-mm-i386-backtrace-ebp-fallback.patch
Dropped.
+revert-x86_64-mm-i386-pda-current.patch
+revert-x86_64-mm-i386-pda-smp-processorid.patch
+revert-x86_64-mm-i386-pda-vm86.patch
+revert-x86_64-mm-i386-pda-user-abi.patch
+revert-x86_64-mm-i386-pda-use-gs.patch
+revert-x86_64-mm-i386-pda-init-pda.patch
Revert busted PDA patches.
+gfp_thisnode-for-the-slab-allocator-v2-fix-3.patch
Fix gfp_thisnode-for-the-slab-allocator-v2.patch some more
+optional-zone_dma-in-the-vm-tidy.patch
Clean up optional-zone_dma-in-the-vm.patch
+mm-micro-optimise-zone_watermark_ok.patch
+do_no_pfn.patch
+do_no_pfn-tweaks.patch
+mspec-driver.patch
+shared-page-table-for-hugetlb-page-v2.patch
+shared-page-table-for-hugetlb-page-v2-tidy.patch
+shared-page-table-for-hugetlb-page-v2-comments.patch
Memory management updates
+remove-zone_dma-remains-from-avr32.patch
-avr32-mtd-unlock-flash-if-necessary.patch
AVR32 updates
+m32r-fix-make-headers_check.patch
m32r fix
-inode-diet-eliminate-i_blksize-and-use-a-per-superblock-default-vs-gfs2.patch
+inode-diet-eliminate-i_blksize-and-use-a-per-superblock-default-fix-fix.patch
+inode-diet-eliminate-i_blksize-and-use-a-per-superblock-default-xfs-fix.patch
More work on
inode-diet-eliminate-i_blksize-and-use-a-per-superblock-default.patch
+ams-check-return-values-from-device_create_file.patch
Update apple-motion-sensor-driver-2.patch (wrongly, apparently)
-mxser-upgrade-to-191.patch
Dropped.
+ext3-inode-numbers-are-unsigned-long-fix.patch
Fix ext3-inode-numbers-are-unsigned-long.patch
+submit-checklist-mention-headers_check.patch
+doc-lockdep-design-explain-display-of-state-bits.patch
+leds-turn-led-off-when-changing-triggers.patch
+directed-yield-cpu_relax-variants-for-spinlocks-and-rw-locks.patch
+directed-yield-direct-yield-of-spinlocks-for-powerpc.patch
+directed-yield-direct-yield-of-spinlocks-for-s390.patch
+synclink_gt-add-bisync-and-monosync-modes.patch
+synclink_gt-increase-max-devices.patch
+cciss-remove-unneeded-spaces-in-output-for-attached-volumes-resend.patch
+remove-superfluous-call-to-call-to-cdev_del.patch
+howto-mention-bughunting.patch
+isicom-correct-firmware-loading.patch
+jbd-16t-fixes.patch
+dontdiff-add-utsreleaseh.patch
Misc updates and fixes
+clean-up-unused-kiocb-variables.patch
AIO cleanup
+fs-cache-make-kafs-use-fs-cache-kconfig-fix.patch
Fix fs-cache-make-kafs-use-fs-cache.patch some more
+nfs-use-local-caching-kconfig-fix.patch
Fix nfs-use-local-caching.patch some more.
+afs-amend-the-afs-configuration-options.patch
AFS config fix
+pci-mxser-pci-refcounts.patch
+mxser-make-an-experimental-clone.patch
Prepare to generate a new mxser driver
+hisax-niccy-cleanup.patch
ISDN driver cleanups
-sched-generic-sched_group-cpu-power-setup.patch
+sched-introduce-child-field-in-sched_domain.patch
+sched-cleanup-sched_group-cpu_power-setup.patch
This patch was split up
+namespaces-exit_task_namespaces-invalidates-nsproxy.patch
namespace fix
+provide-kernel_execve-on-all-architectures-fix-4.patch
Fix provide-kernel_execve-on-all-architectures.patch even more
+replace-cad_pid-by-a-struct-pid.patch
+replace-cad_pid-by-a-struct-pid-fixes.patch
Use `struct pid'
+documentation-fixes-in-intel810txt.patch
+radeonfb-supend-resume-support-for-acer-aspire-2010.patch
fbdev updates
+integrity-service-api-and-dummy-provider-cleanup-use-of-configh.patch
+slim-main-patch-misc-cleanups-requested-at-inclusion-time.patch
+slim-main-patch-handle-failure-to-register.patch
+slim-main-patch-fix-bug-with-mm_users-usage.patch
+slim-secfs-patch-slim-correct-use-of-snprintf.patch
+slim-secfs-patch-cleanup-use-of-configh.patch
+slim-make-and-config-stuff-makefile-fix.patch
Update the SLIM security module
-documentation-ioctl-messtxt-start-tree-wide-ioctl-registry.patch
-ioctl-messtxt-xfs-typos.patch
-post-halloween-doc.patch
Dropped
All 2,040 patches:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18/2.6.18-mm1/patch-list
On Sun, Sep 24, 2006 at 04:02:15AM -0700, Andrew Morton wrote:
> git-arm.patch
It's worth pointing out that something has gone horribly wrong in the
devel branch of this tree, resulting in a load of files being deleted
which shouldn't have been.
Absolutely no idea how that happened, but it's a commit buried behind
lots of other commits and has taken some 4 days to be spotted. At a
guess, a perl bug where a new associative array somehow manages to pick
up on old values and forget values from previous assignments.
Oddly, running the script in debug mode (where the only things which
don't happen is the git commands get called) appears to give correct
behaviour.
So I'm in the situation where I need to rebuild 4 days work in the ARM
devel tree. ;(
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
On Sun, Sep 24, 2006 at 01:46:47PM +0100, Russell King wrote:
> On Sun, Sep 24, 2006 at 04:02:15AM -0700, Andrew Morton wrote:
> > git-arm.patch
>
> It's worth pointing out that something has gone horribly wrong in the
> devel branch of this tree, resulting in a load of files being deleted
> which shouldn't have been.
>
> Absolutely no idea how that happened, but it's a commit buried behind
> lots of other commits and has taken some 4 days to be spotted. At a
> guess, a perl bug where a new associative array somehow manages to pick
> up on old values and forget values from previous assignments.
>
> Oddly, running the script in debug mode (where the only things which
> don't happen is the git commands get called) appears to give correct
> behaviour.
>
> So I'm in the situation where I need to rebuild 4 days work in the ARM
> devel tree. ;(
Okay, it's not as serious as I first thought, but there is still a
problem.
The issue is as follows. When applying patches, my perl script effectively
does:
patch -p1 < patch
git add list-of-files-which-patch-added
git rm list-of-files-which-patch-removed
echo commit-message | git commit -F - -- list-of-files-added-and-changed
For 3834/1 (2172590e3aea712a4da90ac4eb6ca88f19a4ebea) which only removed
files, "list-of-files-added-and-changed" was empty, so it committed
_everything_.
However, one might ask why don't I include the list of deleted files
there. Well, if I do, I get the following from my script and from
git:
Patching 3817/1...
patching file arch/arm/Kconfig
patching file arch/arm/Makefile
patching file arch/arm/configs/ep80219_defconfig
patching file arch/arm/configs/iq31244_defconfig
patching file arch/arm/configs/iq80321_defconfig
patching file arch/arm/configs/iq80331_defconfig
patching file arch/arm/configs/iq80332_defconfig
patching file arch/arm/mach-iop32x/Kconfig
patching file arch/arm/mach-iop32x/Makefile
patching file arch/arm/mach-iop32x/Makefile.boot
patching file arch/arm/mach-iop32x/common.c
patching file arch/arm/mach-iop32x/iq31244-mm.c
patching file arch/arm/mach-iop32x/iq31244-pci.c
patching file arch/arm/mach-iop32x/iq80321-mm.c
patching file arch/arm/mach-iop32x/iq80321-pci.c
patching file arch/arm/mach-iop32x/irq.c
patching file arch/arm/mach-iop32x/pci.c
patching file arch/arm/mach-iop32x/setup.c
patching file arch/arm/mach-iop32x/time.c
patching file arch/arm/mach-iop33x/Kconfig
patching file arch/arm/mach-iop33x/Makefile
patching file arch/arm/mach-iop33x/Makefile.boot
patching file arch/arm/mach-iop33x/common.c
patching file arch/arm/mach-iop33x/iq80331-mm.c
patching file arch/arm/mach-iop33x/iq80331-pci.c
patching file arch/arm/mach-iop33x/iq80332-mm.c
patching file arch/arm/mach-iop33x/iq80332-pci.c
patching file arch/arm/mach-iop33x/irq.c
patching file arch/arm/mach-iop33x/pci.c
patching file arch/arm/mach-iop33x/setup.c
patching file arch/arm/mach-iop33x/time.c
patching file arch/arm/mach-iop3xx/Kconfig
patching file arch/arm/mach-iop3xx/Makefile
patching file arch/arm/mach-iop3xx/Makefile.boot
patching file arch/arm/mach-iop3xx/common.c
patching file arch/arm/mach-iop3xx/iop321-irq.c
patching file arch/arm/mach-iop3xx/iop321-pci.c
patching file arch/arm/mach-iop3xx/iop321-setup.c
patching file arch/arm/mach-iop3xx/iop321-time.c
patching file arch/arm/mach-iop3xx/iop331-irq.c
patching file arch/arm/mach-iop3xx/iop331-pci.c
patching file arch/arm/mach-iop3xx/iop331-setup.c
patching file arch/arm/mach-iop3xx/iop331-time.c
patching file arch/arm/mach-iop3xx/iq31244-mm.c
patching file arch/arm/mach-iop3xx/iq31244-pci.c
patching file arch/arm/mach-iop3xx/iq80321-mm.c
patching file arch/arm/mach-iop3xx/iq80321-pci.c
patching file arch/arm/mach-iop3xx/iq80331-mm.c
patching file arch/arm/mach-iop3xx/iq80331-pci.c
patching file arch/arm/mach-iop3xx/iq80332-mm.c
patching file arch/arm/mach-iop3xx/iq80332-pci.c
patching file arch/arm/mm/Kconfig
patching file drivers/i2c/busses/Kconfig
patching file include/asm-arm/arch-iop32x/debug-macro.S
patching file include/asm-arm/arch-iop32x/dma.h
patching file include/asm-arm/arch-iop32x/entry-macro.S
patching file include/asm-arm/arch-iop32x/hardware.h
patching file include/asm-arm/arch-iop32x/io.h
patching file include/asm-arm/arch-iop32x/iop321.h
patching file include/asm-arm/arch-iop32x/iq31244.h
patching file include/asm-arm/arch-iop32x/iq80321.h
patching file include/asm-arm/arch-iop32x/irqs.h
patching file include/asm-arm/arch-iop32x/memory.h
patching file include/asm-arm/arch-iop32x/system.h
patching file include/asm-arm/arch-iop32x/timex.h
patching file include/asm-arm/arch-iop32x/uncompress.h
patching file include/asm-arm/arch-iop32x/vmalloc.h
patching file include/asm-arm/arch-iop33x/debug-macro.S
patching file include/asm-arm/arch-iop33x/dma.h
patching file include/asm-arm/arch-iop33x/entry-macro.S
patching file include/asm-arm/arch-iop33x/hardware.h
patching file include/asm-arm/arch-iop33x/io.h
patching file include/asm-arm/arch-iop33x/iop331.h
patching file include/asm-arm/arch-iop33x/iq80331.h
patching file include/asm-arm/arch-iop33x/iq80332.h
patching file include/asm-arm/arch-iop33x/irqs.h
patching file include/asm-arm/arch-iop33x/memory.h
patching file include/asm-arm/arch-iop33x/system.h
patching file include/asm-arm/arch-iop33x/timex.h
patching file include/asm-arm/arch-iop33x/uncompress.h
patching file include/asm-arm/arch-iop33x/vmalloc.h
patching file include/asm-arm/arch-iop3xx/debug-macro.S
patching file include/asm-arm/arch-iop3xx/dma.h
patching file include/asm-arm/arch-iop3xx/entry-macro.S
patching file include/asm-arm/arch-iop3xx/hardware.h
patching file include/asm-arm/arch-iop3xx/io.h
patching file include/asm-arm/arch-iop3xx/iop321-irqs.h
patching file include/asm-arm/arch-iop3xx/iop321.h
patching file include/asm-arm/arch-iop3xx/iop331-irqs.h
patching file include/asm-arm/arch-iop3xx/iop331.h
patching file include/asm-arm/arch-iop3xx/iq31244.h
patching file include/asm-arm/arch-iop3xx/iq80321.h
patching file include/asm-arm/arch-iop3xx/iq80331.h
patching file include/asm-arm/arch-iop3xx/iq80332.h
patching file include/asm-arm/arch-iop3xx/irqs.h
patching file include/asm-arm/arch-iop3xx/memory.h
patching file include/asm-arm/arch-iop3xx/system.h
patching file include/asm-arm/arch-iop3xx/timex.h
patching file include/asm-arm/arch-iop3xx/uncompress.h
patching file include/asm-arm/arch-iop3xx/vmalloc.h
rm 'arch/arm/mach-iop3xx/Kconfig'
rm 'arch/arm/mach-iop3xx/Makefile'
rm 'arch/arm/mach-iop3xx/Makefile.boot'
rm 'arch/arm/mach-iop3xx/common.c'
rm 'arch/arm/mach-iop3xx/iop321-irq.c'
rm 'arch/arm/mach-iop3xx/iop321-pci.c'
rm 'arch/arm/mach-iop3xx/iop321-setup.c'
rm 'arch/arm/mach-iop3xx/iop321-time.c'
rm 'arch/arm/mach-iop3xx/iop331-irq.c'
rm 'arch/arm/mach-iop3xx/iop331-pci.c'
rm 'arch/arm/mach-iop3xx/iop331-setup.c'
rm 'arch/arm/mach-iop3xx/iop331-time.c'
rm 'arch/arm/mach-iop3xx/iq31244-mm.c'
rm 'arch/arm/mach-iop3xx/iq31244-pci.c'
rm 'arch/arm/mach-iop3xx/iq80321-mm.c'
rm 'arch/arm/mach-iop3xx/iq80321-pci.c'
rm 'arch/arm/mach-iop3xx/iq80331-mm.c'
rm 'arch/arm/mach-iop3xx/iq80331-pci.c'
rm 'arch/arm/mach-iop3xx/iq80332-mm.c'
rm 'arch/arm/mach-iop3xx/iq80332-pci.c'
rm 'include/asm-arm/arch-iop3xx/debug-macro.S'
rm 'include/asm-arm/arch-iop3xx/dma.h'
rm 'include/asm-arm/arch-iop3xx/entry-macro.S'
rm 'include/asm-arm/arch-iop3xx/hardware.h'
rm 'include/asm-arm/arch-iop3xx/io.h'
rm 'include/asm-arm/arch-iop3xx/iop321-irqs.h'
rm 'include/asm-arm/arch-iop3xx/iop321.h'
rm 'include/asm-arm/arch-iop3xx/iop331-irqs.h'
rm 'include/asm-arm/arch-iop3xx/iop331.h'
rm 'include/asm-arm/arch-iop3xx/iq31244.h'
rm 'include/asm-arm/arch-iop3xx/iq80321.h'
rm 'include/asm-arm/arch-iop3xx/iq80331.h'
rm 'include/asm-arm/arch-iop3xx/iq80332.h'
rm 'include/asm-arm/arch-iop3xx/irqs.h'
rm 'include/asm-arm/arch-iop3xx/memory.h'
rm 'include/asm-arm/arch-iop3xx/system.h'
rm 'include/asm-arm/arch-iop3xx/timex.h'
rm 'include/asm-arm/arch-iop3xx/uncompress.h'
rm 'include/asm-arm/arch-iop3xx/vmalloc.h'
Checking in...
Different in index and the last commit:
D arch/arm/mach-iop3xx/Kconfig
D arch/arm/mach-iop3xx/Makefile
D arch/arm/mach-iop3xx/Makefile.boot
D arch/arm/mach-iop3xx/common.c
D arch/arm/mach-iop3xx/iop321-irq.c
D arch/arm/mach-iop3xx/iop321-pci.c
D arch/arm/mach-iop3xx/iop321-setup.c
D arch/arm/mach-iop3xx/iop321-time.c
D arch/arm/mach-iop3xx/iop331-irq.c
D arch/arm/mach-iop3xx/iop331-pci.c
D arch/arm/mach-iop3xx/iop331-setup.c
D arch/arm/mach-iop3xx/iop331-time.c
D arch/arm/mach-iop3xx/iq31244-mm.c
D arch/arm/mach-iop3xx/iq31244-pci.c
D arch/arm/mach-iop3xx/iq80321-mm.c
D arch/arm/mach-iop3xx/iq80321-pci.c
D arch/arm/mach-iop3xx/iq80331-mm.c
D arch/arm/mach-iop3xx/iq80331-pci.c
D arch/arm/mach-iop3xx/iq80332-mm.c
D arch/arm/mach-iop3xx/iq80332-pci.c
D include/asm-arm/arch-iop3xx/debug-macro.S
D include/asm-arm/arch-iop3xx/dma.h
D include/asm-arm/arch-iop3xx/entry-macro.S
D include/asm-arm/arch-iop3xx/hardware.h
D include/asm-arm/arch-iop3xx/io.h
D include/asm-arm/arch-iop3xx/iop321-irqs.h
D include/asm-arm/arch-iop3xx/iop321.h
D include/asm-arm/arch-iop3xx/iop331-irqs.h
D include/asm-arm/arch-iop3xx/iop331.h
D include/asm-arm/arch-iop3xx/iq31244.h
D include/asm-arm/arch-iop3xx/iq80321.h
D include/asm-arm/arch-iop3xx/iq80331.h
D include/asm-arm/arch-iop3xx/iq80332.h
D include/asm-arm/arch-iop3xx/irqs.h
D include/asm-arm/arch-iop3xx/memory.h
D include/asm-arm/arch-iop3xx/system.h
D include/asm-arm/arch-iop3xx/timex.h
D include/asm-arm/arch-iop3xx/uncompress.h
D include/asm-arm/arch-iop3xx/vmalloc.h
You might have meant to say 'git commit -i paths...', perhaps?
git commit -F - -- arch/arm/mach-iop32x/Kconfig arch/arm/mach-iop32x/Makefile arch/arm/mach-iop32x/Makefile.boot arch/arm/mach-iop32x/common.c arch/arm/mach-iop32x/iq31244-mm.c arch/arm/mach-iop32x/iq31244-pci.c arch/arm/mach-iop32x/iq80321-mm.c arch/arm/mach-iop32x/iq80321-pci.c arch/arm/mach-iop32x/irq.c arch/arm/mach-iop32x/pci.c arch/arm/mach-iop32x/setup.c arch/arm/mach-iop32x/time.c arch/arm/mach-iop33x/Kconfig arch/arm/mach-iop33x/Makefile arch/arm/mach-iop33x/Makefile.boot arch/arm/mach-iop33x/common.c arch/arm/mach-iop33x/iq80331-mm.c arch/arm/mach-iop33x/iq80331-pci.c arch/arm/mach-iop33x/iq80332-mm.c arch/arm/mach-iop33x/iq80332-pci.c arch/arm/mach-iop33x/irq.c arch/arm/mach-iop33x/pci.c arch/arm/mach-iop33x/setup.c arch/arm/mach-iop33x/time.c include/asm-arm/arch-iop32x/debug-macro.S include/asm-arm/arch-iop32x/dma.h include/asm-arm/arch-iop32x/entry-macro.S include/asm-arm/arch-iop32x/hardware.h include/asm-arm/arch-iop32x/io.h include/asm-arm/arch-iop32x/iop321.h include/asm-arm/arch-iop32x/iq31244.h include/asm-arm/arch-iop32x/iq80321.h include/asm-arm/arch-iop32x/irqs.h include/asm-arm/arch-iop32x/memory.h include/asm-arm/arch-iop32x/system.h include/asm-arm/arch-iop32x/timex.h include/asm-arm/arch-iop32x/uncompress.h include/asm-arm/arch-iop32x/vmalloc.h include/asm-arm/arch-iop33x/debug-macro.S include/asm-arm/arch-iop33x/dma.h include/asm-arm/arch-iop33x/entry-macro.S include/asm-arm/arch-iop33x/hardware.h include/asm-arm/arch-iop33x/io.h include/asm-arm/arch-iop33x/iop331.h include/asm-arm/arch-iop33x/iq80331.h include/asm-arm/arch-iop33x/iq80332.h include/asm-arm/arch-iop33x/irqs.h include/asm-arm/arch-iop33x/memory.h include/asm-arm/arch-iop33x/system.h include/asm-arm/arch-iop33x/timex.h include/asm-arm/arch-iop33x/uncompress.h include/asm-arm/arch-iop33x/vmalloc.h arch/arm/Kconfig arch/arm/Makefile arch/arm/configs/ep80219_defconfig arch/arm/configs/iq31244_defconfig arch/arm/configs/iq80321_defconfig arch/arm/configs/iq80331_defconfig arch/arm/configs/iq80332_defconfig arch/arm/m!
m/Kconfi
g drivers/i2c/busses/Kconfig arch/arm/mach-iop3xx/Kconfig arch/arm/mach-iop3xx/Makefile arch/arm/mach-iop3xx/Makefile.boot arch/arm/mach-iop3xx/common.c arch/arm/mach-iop3xx/iop321-irq.c arch/arm/mach-iop3xx/iop321-pci.c arch/arm/mach-iop3xx/iop321-setup.c arch/arm/mach-iop3xx/iop321-time.c arch/arm/mach-iop3xx/iop331-irq.c arch/arm/mach-iop3xx/iop331-pci.c arch/arm/mach-iop3xx/iop331-setup.c arch/arm/mach-iop3xx/iop331-time.c arch/arm/mach-iop3xx/iq31244-mm.c arch/arm/mach-iop3xx/iq31244-pci.c arch/arm/mach-iop3xx/iq80321-mm.c arch/arm/mach-iop3xx/iq80321-pci.c arch/arm/mach-iop3xx/iq80331-mm.c arch/arm/mach-iop3xx/iq80331-pci.c arch/arm/mach-iop3xx/iq80332-mm.c arch/arm/mach-iop3xx/iq80332-pci.c include/asm-arm/arch-iop3xx/debug-macro.S include/asm-arm/arch-iop3xx/dma.h include/asm-arm/arch-iop3xx/entry-macro.S include/asm-arm/arch-iop3xx/hardware.h include/asm-arm/arch-iop3xx/io.h include/asm-arm/arch-iop3xx/iop321-irqs.h include/asm-arm/arch-iop3xx/iop321.h include/asm-arm/arch-iop3xx/iop331-irqs.h include/asm-arm/arch-iop3xx/iop331.h include/asm-arm/arch-iop3xx/iq31244.h include/asm-arm/arch-iop3xx/iq80321.h include/asm-arm/arch-iop3xx/iq80331.h include/asm-arm/arch-iop3xx/iq80332.h include/asm-arm/arch-iop3xx/irqs.h include/asm-arm/arch-iop3xx/memory.h include/asm-arm/arch-iop3xx/system.h include/asm-arm/arch-iop3xx/timex.h include/asm-arm/arch-iop3xx/uncompress.h include/asm-arm/arch-iop3xx/vmalloc.h exited with non-zero status: 256
Unable to commit: at /usr/local/bin/pdb line 253.
Yes, git refuses to commit because I specified files which I wanted to be
committed but were deleted. It seems that if I _don't_ specify these
files, they aren't committed in any case, unless I specify no files.
git bug I'd say - no way to specify a list of files added, changed _and_
_removed_ to be committed.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
Dear diary, on Sun, Sep 24, 2006 at 02:46:47PM CEST, I got a letter
where Russell King <[email protected]> said that...
> On Sun, Sep 24, 2006 at 04:02:15AM -0700, Andrew Morton wrote:
> > git-arm.patch
>
> It's worth pointing out that something has gone horribly wrong in the
> devel branch of this tree, resulting in a load of files being deleted
> which shouldn't have been.
>
> Absolutely no idea how that happened, but it's a commit buried behind
> lots of other commits and has taken some 4 days to be spotted. At a
> guess, a perl bug where a new associative array somehow manages to pick
> up on old values and forget values from previous assignments.
>
> Oddly, running the script in debug mode (where the only things which
> don't happen is the git commands get called) appears to give correct
> behaviour.
>
> So I'm in the situation where I need to rebuild 4 days work in the ARM
> devel tree. ;(
If I understand correctly, you just need to get rid of that bad commit?
Can you copy the missing files (in the suitable tree structure) to
/tmp/missing/ and try this?
cg-admin-rewritehist -r EVILCOMMIT \
--tree-filter 'cp -r /tmp/missing/* .' \
--commit-filter \
'if [ "$GIT_COMMIT" = "EVILCOMMIT" ]; then
shift;
while [ -n "$1" ]; do
shift; echo "$1"; shift;
done;
else
git-commit-tree "$@";
fi' \
fixedbranch
(s/EVILCOMMIT/thesha1id/)
Now check if fixedbranch looks ok.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
On Sun, Sep 24, 2006 at 03:22:13PM +0200, Petr Baudis wrote:
> Dear diary, on Sun, Sep 24, 2006 at 02:46:47PM CEST, I got a letter
> where Russell King <[email protected]> said that...
> > On Sun, Sep 24, 2006 at 04:02:15AM -0700, Andrew Morton wrote:
> > > git-arm.patch
> >
> > It's worth pointing out that something has gone horribly wrong in the
> > devel branch of this tree, resulting in a load of files being deleted
> > which shouldn't have been.
> >
> > Absolutely no idea how that happened, but it's a commit buried behind
> > lots of other commits and has taken some 4 days to be spotted. At a
> > guess, a perl bug where a new associative array somehow manages to pick
> > up on old values and forget values from previous assignments.
> >
> > Oddly, running the script in debug mode (where the only things which
> > don't happen is the git commands get called) appears to give correct
> > behaviour.
> >
> > So I'm in the situation where I need to rebuild 4 days work in the ARM
> > devel tree. ;(
>
> If I understand correctly, you just need to get rid of that bad commit?
I'm now told that the resulting tree after all the commits is correct.
The problem is that all the files which were supposed to be deleted by
previous patches ended up actually being deleted by the final patch in
the series.
So the resulting tree is fine, it's just that the history is rather
broken.
I think a solution to this might be to use git-apply, but there's one
draw back - I currently have the facility to unpatch at a later date,
but git-apply doesn't support -R. I'd have to fall back to the patch
+ git add + git rm + git commit method, but that's been shown to be
fundamentally broken.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
Dear diary, on Sun, Sep 24, 2006 at 04:20:06PM CEST, I got a letter
where Russell King <[email protected]> said that...
> I'm now told that the resulting tree after all the commits is correct.
> The problem is that all the files which were supposed to be deleted by
> previous patches ended up actually being deleted by the final patch in
> the series.
>
> So the resulting tree is fine, it's just that the history is rather
> broken.
Well, that rewritehist batch should work fine even in this case.
(Of course that's assuming that no change was supposed to happen to
those files in the last four days.)
> I think a solution to this might be to use git-apply, but there's one
> draw back - I currently have the facility to unpatch at a later date,
> but git-apply doesn't support -R.
Yes, if there's not too many patches perhaps using git-apply -R would be
simpler. git-apply in git-1.4.2.1 does support -R.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
On Sun, Sep 24, 2006 at 04:29:58PM +0200, Petr Baudis wrote:
> Dear diary, on Sun, Sep 24, 2006 at 04:20:06PM CEST, I got a letter
> where Russell King <[email protected]> said that...
> > I'm now told that the resulting tree after all the commits is correct.
> > The problem is that all the files which were supposed to be deleted by
> > previous patches ended up actually being deleted by the final patch in
> > the series.
> >
> > So the resulting tree is fine, it's just that the history is rather
> > broken.
>
> Well, that rewritehist batch should work fine even in this case.
>
> (Of course that's assuming that no change was supposed to happen to
> those files in the last four days.)
>
> > I think a solution to this might be to use git-apply, but there's one
> > draw back - I currently have the facility to unpatch at a later date,
> > but git-apply doesn't support -R.
>
> Yes, if there's not too many patches perhaps using git-apply -R would be
> simpler. git-apply in git-1.4.2.1 does support -R.
I'm just experimenting with git-apply for the forward case, and I'm
hitting a small problem. I can do:
cat patch | git-apply --stat
then I come to commit it:
git commit -F -
but if I just use that, _all_ changes which happen to be in the tree
get committed, not just those which are in the index file. Manually
doing each step of the commit is far too much work in perl...
Grumble.
And no, I'm not about to try to rewrite my patch database handling
using shell script - I don't know of any way to sanely access a mysql
database from shell.
I guess we'll just have to live with the screwed history until some
of the issues I've brought up with git are resolved (the biggest one
being git commit being able to take a list of files deleted.)
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
On Sunday 24 September 2006 07:02, Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18/2.6.18-mm1/
>
> - 2.6.18-rc7-mm1 had quite a lot of problems due to changes in the driver
> ? tree. ?All of those have been dropped from this patchset.
>
Andrew,
Any chance you could start pulling in input tree again?
--
Dmitry
Dear diary, on Sun, Sep 24, 2006 at 04:47:10PM CEST, I got a letter
where Russell King <[email protected]> said that...
> On Sun, Sep 24, 2006 at 04:29:58PM +0200, Petr Baudis wrote:
> > Dear diary, on Sun, Sep 24, 2006 at 04:20:06PM CEST, I got a letter
> > where Russell King <[email protected]> said that...
> > > I'm now told that the resulting tree after all the commits is correct.
> > > The problem is that all the files which were supposed to be deleted by
> > > previous patches ended up actually being deleted by the final patch in
> > > the series.
> > >
> > > So the resulting tree is fine, it's just that the history is rather
> > > broken.
> >
> > Well, that rewritehist batch should work fine even in this case.
> >
> > (Of course that's assuming that no change was supposed to happen to
> > those files in the last four days.)
> >
> > > I think a solution to this might be to use git-apply, but there's one
> > > draw back - I currently have the facility to unpatch at a later date,
> > > but git-apply doesn't support -R.
> >
> > Yes, if there's not too many patches perhaps using git-apply -R would be
> > simpler. git-apply in git-1.4.2.1 does support -R.
>
> I'm just experimenting with git-apply for the forward case, and I'm
> hitting a small problem. I can do:
>
> cat patch | git-apply --stat
>
> then I come to commit it:
>
> git commit -F -
>
> but if I just use that, _all_ changes which happen to be in the tree
> get committed, not just those which are in the index file. Manually
> doing each step of the commit is far too much work in perl...
Hmm, I'm sorry but I'm not all that well-versed in git commit inner
workings. The best way to get help is to cc' [email protected].
According to git-commit documentation, when you do what you wrote you
use, it _should_ commit just the index file...
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
On Sun, 24 Sep 2006 12:35:49 -0400
Dmitry Torokhov <[email protected]> wrote:
> On Sunday 24 September 2006 07:02, Andrew Morton wrote:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18/2.6.18-mm1/
> >
> > - 2.6.18-rc7-mm1 had quite a lot of problems due to changes in the driver
> > ? tree. ?All of those have been dropped from this patchset.
> >
>
> Andrew,
>
> Any chance you could start pulling in input tree again?
>
doh, I forgot to restore it, sorry.
Russell King <[email protected]> writes:
> I'm just experimenting with git-apply for the forward case, and I'm
> hitting a small problem. I can do:
>
> cat patch | git-apply --stat
>
> then I come to commit it:
>
> git commit -F -
>
> but if I just use that, _all_ changes which happen to be in the tree
> get committed, not just those which are in the index file.
That does not sound right.
* "git apply --stat patch" (you do not need "cat |" there) is
only to inspect the changes; it does not apply the change to
your working tree. Think of it as "diffstat for git".
If you want to apply it _and_ view diffstat, you can say "git
apply --stat --apply patch".
* Not having any pathname in the "git commit" like quoted above
in the final step should commit what is in index. What will
be committed may not match what is in your working tree (iow
"git diff" can still show some local changes you are not
committing). We often call this "partial commit".
* When doing partial commits, having "git apply" to prepare
what you want to commit in the index is less error prone
(otherwise you would somehow need to parse the patch and find
out what is added and what is deleted). I do not exactly
know what you are doing in your Perl wrapper, but I suspect
bulk of that is to figure out what is changed and run
git-update-index on them -- you can lose all that code by
using "git apply --index patch". Then added, removed and
modified paths are all updated in the index.
> I guess we'll just have to live with the screwed history until some
> of the issues I've brought up with git are resolved (the biggest one
> being git commit being able to take a list of files deleted.)
If you _are_ updating index yourself before calling git-commit,
you do not need to (and indeed you should not) pass _any_
pathnames to it. I think that's where this confusion comes from.
As an old-timer, you may remember that git-commit did not take
any path arguments initially. You were supposed to do update-index
the paths you care about to build the image of what you want to
record in your next commit and then tell git-commit to commit
the index, and that was the only way to make a commit. We still
support that model of operation.
Then "git-commit -a" was added. This made git-commit to notice
modified and deleted files (but not added ones) and run
update-index automatically on them before doing its work.
In addition, git-commit started to take path parameters.
Originally, this was meant to tell git-commit "Oh, I forgot to
run update-index on these paths so far, so the changes I made to
the index is fine, but also include the change to these paths in
the commit as well". This made git-commit run update-index on
the given paths ON TOP OF the current index before making a
commit. We still support this model of operation, but it now
requires an explicit -i option to invoke it.
What "git-commit paths..." without an explicit -i option
currently does is a compromise made to mollify CVS minded
people's argument to help newbies. You are telling git-commit:
Ignore any change I made to the index so far. The
commit I want to make now is the last commit plus
changes I have in my working tree on these paths.
This is only meant to support the workflow for people who do not
want to deal with index at all. After checking out the last
commit, you muck with what is in your working tree, and say
"git-commit paths..." to commit only changes made to the paths
explicitly listed on the command line. Hence, as a safety
measure, we require a few things when this option is used:
* The index entries for paths you named on the command line
should match what is in the last commit. Otherwise, it means
you have done something like this:
checkout
edit foo
update-index foo ;# happy with _THIS_ state of foo
edit foo ;# further work
edit bar
commit foo bar
The new "commit paths..." without -i is not "index has what I
want but in addition I want changes to these", so without
this check you will end up committing foo after "further
work", and you would lose the state you marked with the
manual update-index. Now it may be what the user wanted, or
it may not be (remember, this "explicit paths" is now for
people who do not usually deal with index, so index entry for
named paths being different from the last commit indicates
there is something else going on -- maybe the user really
cared). So we flag the problem when we notice it.
* The named paths must exist in the index (they do not have to
exist in your working tree -- so "rm foo; git commit foo"
commits the removal of foo). This is to catch typo on the
command line.
So in short,
patch -p1 < patch
git add $added
git rm $removed
git update-index $modified
echo commit-message | git commit -F - -- $added $modified
is mixing two incompatible mode of operations from separate
workflows. You are index-aware by using update-index (or git
add/rm) but you are driving git-commit as if you are not.
Two possibilities (I would recommend 1b).
(1) Use index-aware workflow consistently (1a):
patch -p1 <patch
parse patch and figure out $added $removed and $modified
git update-index --add --remove $added $removed $modified
git commit -F $logfile
Or slightly simpler (1b):
git apply --index patch
git commit -F $logfile
(2) Use index-unaware workflow consistently:
patch -p1 <patch
parse patch and figure out $added $removed and $modified
git add $added
git rm $removed
git update-index $modified
git commit -F $logfile
Andrew - see the bottom of this message.
On Sun, Sep 24, 2006 at 11:48:26AM -0700, Junio C Hamano wrote:
> Russell King <[email protected]> writes:
>
> > I'm just experimenting with git-apply for the forward case, and I'm
> > hitting a small problem. I can do:
> >
> > cat patch | git-apply --stat
> >
> > then I come to commit it:
> >
> > git commit -F -
> >
> > but if I just use that, _all_ changes which happen to be in the tree
> > get committed, not just those which are in the index file.
>
> That does not sound right.
You're right - I was looking at doing git-apply --stat --apply
> * "git apply --stat patch" (you do not need "cat |" there) is
> only to inspect the changes; it does not apply the change to
> your working tree. Think of it as "diffstat for git".
The "cat" bit was in there to represent the perl script piping the
patch directly into the program - there isn't a literal "cat"
command in there. 8)
> * When doing partial commits, having "git apply" to prepare
> what you want to commit in the index is less error prone
> (otherwise you would somehow need to parse the patch and find
> out what is added and what is deleted). I do not exactly
> know what you are doing in your Perl wrapper, but I suspect
> bulk of that is to figure out what is changed and run
> git-update-index on them -- you can lose all that code by
> using "git apply --index patch". Then added, removed and
> modified paths are all updated in the index.
The problem is that git apply doesn't have a "patch -R" mode - so
if I want to revert such a patch (okay, there's only been one instance
so far) it means falling back to the old way. So that code exists
one way or t'other.
> > I guess we'll just have to live with the screwed history until some
> > of the issues I've brought up with git are resolved (the biggest one
> > being git commit being able to take a list of files deleted.)
>
> If you _are_ updating index yourself before calling git-commit,
> you do not need to (and indeed you should not) pass _any_
> pathnames to it. I think that's where this confusion comes from.
Yes, that is where the confusion's happening.
Thanks for explaining it - the script's now fixed and appears to work
as desired.
akpm - I'm afraid the ARM devel tree has been regenerated almost from
scratch, so you might encouter some issues next time you pull it.
However, despite this issue, the end result appears to be idential
(git-diff-tree -u broken-devel devel shows no changes, but the
individual changes for each commit are now correct.)
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
On Sun, 24 Sep 2006 22:34:22 +0100
Russell King <[email protected]> wrote:
> akpm - I'm afraid the ARM devel tree has been regenerated almost from
> scratch, so you might encouter some issues next time you pull it.
It turns out that this sort of thing is a non-issue for me. I very
frequently get the does-not-fast-forward thing, so I just blow the branch
away and repull.
In fact for a while I was doing a `git-branch -D' against _every_ tree
prior to pulling it, but I turned that off for some reason.
Russell King <[email protected]> writes:
> The problem is that git apply doesn't have a "patch -R" mode - so
I thought Pasky already pointed out that is a misinformation.
When I apply:
x86_64-mm-insert-ioapics-and-local-apic-into-resource-map
My e1000 fails to initializes and complains about a bad eeprom checksum.
I haven't tracked this down to root cause yet and I am in the process of building
2.6.18-mm1 with just that patch reverted to confirm that is the only cause.
I could not see anything obvious in the patch. I don't have a clue the patch
could be triggering the problem I'm seeing.
At a quick visual diff I'm not seeing any other differences in the kernel boot
logs, or in /proc/iomem.
Eric
The good.
> # cat /proc/iomem
> 00000000-00000c3f : reserved
> 00000c40-0009ffff : System RAM
> 000a0000-000bffff : Video RAM area
> 000c0000-000effff : System RAM
> 000f0000-000fffff : System ROM
> e2000000-e20fffff : PCI Bus #05
> e2000000-e201ffff : 0000:05:0c.0
> fb000000-fc0fffff : PCI Bus #05
> fb000000-fbffffff : 0000:05:0c.0
> fc000000-fc000fff : 0000:05:0c.0
> fd000000-fdffffff : PCI Bus #01
> fd000000-fdffffff : PCI Bus #02
> fd000000-fdffffff : 0000:02:03.0
> fe000000-fe2fffff : PCI Bus #01
> fe000000-fe0fffff : PCI Bus #02
> fe000000-fe07ffff : 0000:02:03.0
> fe100000-fe1fffff : PCI Bus #03
> fe100000-fe11ffff : 0000:03:04.0
> fe100000-fe11ffff : e1000
> fe120000-fe13ffff : 0000:03:04.1
> fe120000-fe13ffff : e1000
> fe200000-fe200fff : 0000:01:00.1
> fe201000-fe201fff : 0000:01:00.3
> fe300000-fe300fff : 0000:00:00.0
> fe301000-fe301fff : 0000:00:01.0
> fe302000-fe3023ff : 0000:00:1d.7
> fe303000-fe3033ff : 0000:00:1f.1
> 100000000-11fffffff : System RAM
The bad.
> # cat /proc/iomem
> 00000000-00000c3f : reserved
> 00000c40-0009ffff : System RAM
> 000a0000-000bffff : Video RAM area
> 000c0000-000effff : System RAM
> 000f0000-000fffff : System ROM
> e2000000-e22fffff : PCI Bus #01
> e2000000-e20fffff : PCI Bus #02
> e2000000-e207ffff : 0000:02:03.0
> e2100000-e21fffff : PCI Bus #03
> e2100000-e211ffff : 0000:03:04.0
> e2120000-e213ffff : 0000:03:04.1
> e2200000-e2200fff : 0000:01:00.1
> e2201000-e2201fff : 0000:01:00.3
> e2300000-e23fffff : PCI Bus #05
> e2300000-e231ffff : 0000:05:0c.0
> fb000000-fc0fffff : PCI Bus #05
> fb000000-fbffffff : 0000:05:0c.0
> fc000000-fc000fff : 0000:05:0c.0
> fd000000-fdffffff : PCI Bus #01
> fd000000-fdffffff : PCI Bus #02
> fd000000-fdffffff : 0000:02:03.0
> fe200000-fe200fff : IOAPIC 1
> fe201000-fe201fff : IOAPIC 2
> fe300000-fe300fff : 0000:00:00.0
> fe301000-fe301fff : 0000:00:01.0
> fe302000-fe3023ff : 0000:00:1d.7
> fe303000-fe3033ff : 0000:00:1f.1
> fec00000-fec00fff : IOAPIC 0
> fee00000-fee00fff : Local APIC
> 100000000-11fffffff : System RAM
The bad kernel boot messages:
> Linux version 2.6.18-eb-g27fb4c0a ([email protected]) (gcc
> Tue Sep 26 18:58:15 MDT 2006
> Command line: console=ttyS0,115200 reboot=hard panic=5 debug
> BIOS-provided physical RAM map:
> BIOS-e820: 0000000000000000 - 0000000000000c40 (reserved)
> BIOS-e820: 0000000000000c40 - 00000000000a0000 (usable)
> BIOS-e820: 00000000000c0000 - 00000000000f0000 (usable)
> BIOS-e820: 00000000000f0000 - 00000000000f0400 (reserved)
> BIOS-e820: 00000000000f0400 - 00000000e0000000 (usable)
> BIOS-e820: 0000000100000000 - 0000000120000000 (usable)
> DMI not present or invalid.
> No NUMA configuration found
> Faking a node at 0000000000000000-0000000120000000
> Bootmem setup node 0 0000000000000000-0000000120000000
> On node 0 totalpages: 1029374
> DMA zone: 966 pages, LIFO batch:0
> DMA32 zone: 899128 pages, LIFO batch:31
> Normal zone: 129280 pages, LIFO batch:31
> Intel MultiProcessor Specification v1.4
> MPTABLE: OEM ID: LNXI MPTABLE: Product ID: SE7520JR20 MP
> Processor #0 (Bootup-CPU)
> Processor #6
> I/O APIC #8 at 0xFEC00000.
> I/O APIC #9 at 0xFE200000.
> I/O APIC #10 at 0xFE201000.
> Setting APIC routing to flat
> Processors: 2
> Allocating PCI resources starting at e2000000 (gap: e0000000:2
> PERCPU: Allocating 31872 bytes of per cpu data
> Built 1 zonelists. Total pages: 1029374
> Kernel command line: console=ttyS0,115200 reboot=hard panic=5
> Initializing CPU#0
> PID hash table entries: 4096 (order: 12, 32768 bytes)
> spurious 8259A interrupt: IRQ7.
> Console: colour dummy device 80x25
> Dentry cache hash table entries: 524288 (order: 10, 4194304 by
> Inode-cache hash table entries: 262144 (order: 9, 2097152 byte
> Checking aperture...
> PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
> Placing software IO TLB between 0x2637000 - 0x6637000
> Memory: 4028780k/4718592k available (2553k kernel code, 165388
> Calibrating delay using timer specific routine.. 6813.94 BogoM
> Security Framework v1.0.0 initialized
> Capability LSM initialized
> Mount-cache hash table entries: 256
> CPU: Trace cache: 12K uops, L1 D cache: 16K
> CPU: L2 cache: 1024K
> CPU 0/0 -> Node 0
> using mwait in idle threads.
> CPU: Physical Processor ID: 0
> CPU: Processor Core ID: 0
> CPU0: Thermal monitoring enabled (TM1)
> Freeing SMP alternatives: 36k freed
> GSI 24 sharing vector 0xA9 and IRQ 24
> GSI 25 sharing vector 0xB1 and IRQ 25
> GSI 26 sharing vector 0xB9 and IRQ 26
> GSI 27 sharing vector 0xC1 and IRQ 27
> GSI 28 sharing vector 0xC9 and IRQ 28
> GSI 29 sharing vector 0xD1 and IRQ 29
> GSI 49 sharing vector 0xD9 and IRQ 49
> GSI 50 sharing vector 0xE1 and IRQ 50
> GSI 51 sharing vector 0xE9 and IRQ 51
> GSI 52 sharing vector 0x32 and IRQ 52
> GSI 54 sharing vector 0x3A and IRQ 54
> GSI 55 sharing vector 0x42 and IRQ 55
> Using local APIC timer interrupts.
> result 12500623
> Detected 12.500 MHz APIC timer.
> Booting processor 1/2 APIC 0x6
> Initializing CPU#1
> Calibrating delay using timer specific routine.. 6800.70 BogoM
> CPU: Trace cache: 12K uops, L1 D cache: 16K
> CPU: L2 cache: 1024K
> CPU 1/6 -> Node 0
> CPU: Physical Processor ID: 3
> CPU: Processor Core ID: 0
> CPU1: Thermal monitoring enabled (TM1)
> Intel(R) Xeon(TM) CPU 3.40GHz stepping 04
> Brought up 2 CPUs
> testing NMI watchdog ... OK.
> time.c: Using 1.193182 MHz WALL PIT GTOD PIT/TSC timer.
> time.c: Detected 3400.184 MHz processor.
> migration_cost=629
> checking if image is initramfs... it is
> Freeing initrd memory: 7256k freed
> NET: Registered protocol family 16
> PCI: Using configuration type 1
> ACPI: Interpreter disabled.
> usbcore: registered new interface driver usbfs
> usbcore: registered new interface driver hub
> usbcore: registered new device driver usb
> PCI: Probing PCI hardware
> PCI: Probing PCI hardware (bus 00)
> PCI quirk: region 3000-307f claimed by ICH4 ACPI/GPIO/TCO
> PCI quirk: region 3080-30bf claimed by ICH4 GPIO
> PCI: Ignoring BAR0-3 of IDE controller 0000:00:1f.1
> PCI: Ignoring BAR0-3 of IDE controller 0000:00:1f.2
> PCI: PXH quirk detected, disabling MSI for SHPC device
> PCI: PXH quirk detected, disabling MSI for SHPC device
> PCI: Transparent bridge - 0000:00:1e.0
> PCI: Using IRQ router PIIX/ICH [8086/24d0] at 0000:00:1f.0
> PCI->APIC IRQ transform: 0000:02:03.0[A] -> IRQ 24
> PCI->APIC IRQ transform: 0000:03:04.0[A] -> IRQ 54
> PCI->APIC IRQ transform: 0000:03:04.1[B] -> IRQ 55
> GSI 17 sharing vector 0x4A and IRQ 17
> PCI->APIC IRQ transform: 0000:05:0c.0[A] -> IRQ 17
> PCI: Cannot allocate resource region 8 of bridge 0000:00:02.0
> PCI: Cannot allocate resource region 8 of bridge 0000:01:00.0
> PCI: Cannot allocate resource region 8 of bridge 0000:01:00.2
> PCI: Cannot allocate resource region 0 of device 0000:01:00.1
> PCI: Cannot allocate resource region 0 of device 0000:01:00.3
> PCI: Cannot allocate resource region 0 of device 0000:03:04.0
> PCI: Cannot allocate resource region 0 of device 0000:03:04.1
> PCI-GART: No AMD northbridge found.
> PCI: Bridge: 0000:01:00.0
> IO window: disabled.
> MEM window: e2000000-e20fffff
> PREFETCH window: fd000000-fdffffff
> PCI: Bridge: 0000:01:00.2
> IO window: 1000-1fff
> MEM window: e2100000-e21fffff
> PREFETCH window: disabled.
> PCI: Bridge: 0000:00:02.0
> IO window: 1000-1fff
> MEM window: e2000000-e22fffff
> PREFETCH window: fd000000-fdffffff
> PCI: Bridge: 0000:00:06.0
> IO window: disabled.
> MEM window: disabled.
> PREFETCH window: disabled.
> PCI: Bridge: 0000:00:1e.0
> IO window: 2000-2fff
> MEM window: fb000000-fc0fffff
> PREFETCH window: e2300000-e23fffff
> PCI: No IRQ known for interrupt pin A of device 0000:00:02.0.
> PCI: Setting latency timer of device 0000:00:02.0 to 64
> PCI: Setting latency timer of device 0000:01:00.0 to 64
> PCI: Setting latency timer of device 0000:01:00.2 to 64
> PCI: No IRQ known for interrupt pin A of device 0000:00:06.0.
> PCI: Setting latency timer of device 0000:00:06.0 to 64
> PCI: Setting latency timer of device 0000:00:1e.0 to 64
> NET: Registered protocol family 2
> IP route cache hash table entries: 131072 (order: 8, 1048576 b
> TCP established hash table entries: 262144 (order: 10, 4194304
> TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
> TCP: Hash tables configured (established 262144 bind 65536)
> TCP reno registered
> IA-32 Microcode Update Driver: v1.14a <[email protected]>
> Total HugeTLB memory allocated, 0
> io scheduler noop registered
> io scheduler anticipatory registered (default)
> io scheduler deadline registered
> io scheduler cfq registered
> Intel E7520/7320/7525 detected.<7>PCI: Setting latency timer o
> pcie_portdrv_probe->Dev[3595:8086] has invalid IRQ. Check vend
> Allocate Port Service[0000:00:02.0:pcie00]
> PCI: Setting latency timer of device 0000:00:06.0 to 64
> pcie_portdrv_probe->Dev[3599:8086] has invalid IRQ. Check vend
> Allocate Port Service[0000:00:06.0:pcie00]
> pci_hotplug: PCI Hot Plug PCI Core version: 0.5
> Real Time Clock Driver v1.12ac
> Linux agpgart interface v0.101 (c) Dave Jones
> Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ shari
> serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
> serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
> RAMDISK driver initialized: 16 RAM disks of 64000K size 1024 b
> Intel(R) PRO/1000 Network Driver - version 7.2.7-k2-NAPI
> Copyright (c) 1999-2006 Intel Corporation.
> e1000: 0000:03:04.0: e1000_probe: The EEPROM Checksum Is Not V
> e1000: probe of 0000:03:04.0 failed with error -5
> e1000: 0000:03:04.1: e1000_probe: The EEPROM Checksum Is Not V
> e1000: probe of 0000:03:04.1 failed with error -5
> forcedeth.c: Reverse Engineered nForce ethernet driver. Versio
> netconsole: not configured, aborting
> usbmon: debugfs is not available
> serio: i8042 AUX port at 0x60,0x64 irq 12
> serio: i8042 KBD port at 0x60,0x64 irq 1
> mice: PS/2 mouse device common for all mice
> EDAC MC: Ver: 2.0.1 Sep 26 2006
> IPv4 over IPv4 tunneling driver
> GRE over IPv4 tunneling driver
> TCP bic registered
> Initializing XFRM netlink socket
> NET: Registered protocol family 1
> NET: Registered protocol family 10
> lo: Disabled Privacy Extensions
> IPv6 over IPv4 tunneling driver
> NET: Registered protocol family 17
> NET: Registered protocol family 15
> Bridge firewalling registered
> NET: Registered protocol family 8
> NET: Registered protocol family 20
> 802.1Q VLAN Support v1.8 Ben Greear <[email protected]>
> All bugs added by David S. Miller <[email protected]>
> TIPC: Activated (version 1.6.1 compiled Sep 26 2006 18:53:22)
> NET: Registered protocol family 30
> TIPC: Started in single node mode
> /home/eric/projects/linux/linux-2.6-ns/drivers/rtc/hctosys.c:
> Freeing unused kernel memory: 220k freed
The good kernel boot messages:
> Linux version 2.6.18-eb-g94187b95 ([email protected]) (gcc version 3.4.4 20050314 (prerelease) (Debian 3.4.3-13)) #15 SMP Tue Sep 26 19:10:14 MDT 2006
> Command line: console=ttyS0,115200 reboot=hard panic=5 debug acpi=off crashkernel=16M@16M
> BIOS-provided physical RAM map:
> BIOS-e820: 0000000000000000 - 0000000000000c40 (reserved)
> BIOS-e820: 0000000000000c40 - 00000000000a0000 (usable)
> BIOS-e820: 00000000000c0000 - 00000000000f0000 (usable)
> BIOS-e820: 00000000000f0000 - 00000000000f0400 (reserved)
> BIOS-e820: 00000000000f0400 - 00000000e0000000 (usable)
> BIOS-e820: 0000000100000000 - 0000000120000000 (usable)
> DMI not present or invalid.
> No NUMA configuration found
> Faking a node at 0000000000000000-0000000120000000
> Bootmem setup node 0 0000000000000000-0000000120000000
> On node 0 totalpages: 1029374
> DMA zone: 966 pages, LIFO batch:0
> DMA32 zone: 899128 pages, LIFO batch:31
> Normal zone: 129280 pages, LIFO batch:31
> Intel MultiProcessor Specification v1.4
> MPTABLE: OEM ID: LNXI MPTABLE: Product ID: SE7520JR20 MPTABLE: APIC at: 0xFEE00000
> Processor #0 (Bootup-CPU)
> Processor #6
> I/O APIC #8 at 0xFEC00000.
> I/O APIC #9 at 0xFE200000.
> I/O APIC #10 at 0xFE201000.
> Setting APIC routing to flat
> Processors: 2
> Allocating PCI resources starting at e2000000 (gap: e0000000:20000000)
> PERCPU: Allocating 31872 bytes of per cpu data
> Built 1 zonelists. Total pages: 1029374
> Kernel command line: console=ttyS0,115200 reboot=hard panic=5 debug acpi=off crashkernel=16M@16M
> Initializing CPU#0
> PID hash table entries: 4096 (order: 12, 32768 bytes)
> spurious 8259A interrupt: IRQ7.
> Console: colour dummy device 80x25
> Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes)
> Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes)
> Checking aperture...
> PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
> Placing software IO TLB between 0x2636000 - 0x6636000
> Memory: 4028784k/4718592k available (2553k kernel code, 165384k reserved, 1597k data, 220k init)
> Calibrating delay using timer specific routine.. 6812.89 BogoMIPS (lpj=13625785)
> Security Framework v1.0.0 initialized
> Capability LSM initialized
> Mount-cache hash table entries: 256
> CPU: Trace cache: 12K uops, L1 D cache: 16K
> CPU: L2 cache: 1024K
> CPU 0/0 -> Node 0
> using mwait in idle threads.
> CPU: Physical Processor ID: 0
> CPU: Processor Core ID: 0
> CPU0: Thermal monitoring enabled (TM1)
> Freeing SMP alternatives: 36k freed
> GSI 24 sharing vector 0xA9 and IRQ 24
> GSI 25 sharing vector 0xB1 and IRQ 25
> GSI 26 sharing vector 0xB9 and IRQ 26
> GSI 27 sharing vector 0xC1 and IRQ 27
> GSI 28 sharing vector 0xC9 and IRQ 28
> GSI 29 sharing vector 0xD1 and IRQ 29
> GSI 49 sharing vector 0xD9 and IRQ 49
> GSI 50 sharing vector 0xE1 and IRQ 50
> GSI 51 sharing vector 0xE9 and IRQ 51
> GSI 52 sharing vector 0x32 and IRQ 52
> GSI 54 sharing vector 0x3A and IRQ 54
> GSI 55 sharing vector 0x42 and IRQ 55
> Using local APIC timer interrupts.
> result 12500733
> Detected 12.500 MHz APIC timer.
> Booting processor 1/2 APIC 0x6
> Initializing CPU#1
> Calibrating delay using timer specific routine.. 6800.74 BogoMIPS (lpj=13601490)
> CPU: Trace cache: 12K uops, L1 D cache: 16K
> CPU: L2 cache: 1024K
> CPU 1/6 -> Node 0
> CPU: Physical Processor ID: 3
> CPU: Processor Core ID: 0
> CPU1: Thermal monitoring enabled (TM1)
> Intel(R) Xeon(TM) CPU 3.40GHz stepping 04
> Brought up 2 CPUs
> testing NMI watchdog ... OK.
> time.c: Using 1.193182 MHz WALL PIT GTOD PIT/TSC timer.
> time.c: Detected 3400.214 MHz processor.
> migration_cost=632
> checking if image is initramfs... it is
> Freeing initrd memory: 7256k freed
> NET: Registered protocol family 16
> PCI: Using configuration type 1
> ACPI: Interpreter disabled.
> usbcore: registered new interface driver usbfs
> usbcore: registered new interface driver hub
> usbcore: registered new device driver usb
> PCI: Probing PCI hardware
> PCI: Probing PCI hardware (bus 00)
> PCI quirk: region 3000-307f claimed by ICH4 ACPI/GPIO/TCO
> PCI quirk: region 3080-30bf claimed by ICH4 GPIO
> PCI: Ignoring BAR0-3 of IDE controller 0000:00:1f.1
> PCI: Ignoring BAR0-3 of IDE controller 0000:00:1f.2
> PCI: PXH quirk detected, disabling MSI for SHPC device
> PCI: PXH quirk detected, disabling MSI for SHPC device
> PCI: Transparent bridge - 0000:00:1e.0
> PCI: Using IRQ router PIIX/ICH [8086/24d0] at 0000:00:1f.0
> PCI->APIC IRQ transform: 0000:02:03.0[A] -> IRQ 24
> PCI->APIC IRQ transform: 0000:03:04.0[A] -> IRQ 54
> PCI->APIC IRQ transform: 0000:03:04.1[B] -> IRQ 55
> GSI 17 sharing vector 0x4A and IRQ 17
> PCI->APIC IRQ transform: 0000:05:0c.0[A] -> IRQ 17
> PCI-GART: No AMD northbridge found.
> PCI: Bridge: 0000:01:00.0
> IO window: disabled.
> MEM window: fe000000-fe0fffff
> PREFETCH window: fd000000-fdffffff
> PCI: Bridge: 0000:01:00.2
> IO window: 1000-1fff
> MEM window: fe100000-fe1fffff
> PREFETCH window: disabled.
> PCI: Bridge: 0000:00:02.0
> IO window: 1000-1fff
> MEM window: fe000000-fe2fffff
> PREFETCH window: fd000000-fdffffff
> PCI: Bridge: 0000:00:06.0
> IO window: disabled.
> MEM window: disabled.
> PREFETCH window: disabled.
> PCI: Bridge: 0000:00:1e.0
> IO window: 2000-2fff
> MEM window: fb000000-fc0fffff
> PREFETCH window: e2000000-e20fffff
> PCI: No IRQ known for interrupt pin A of device 0000:00:02.0. Probably buggy MP table.
> PCI: Setting latency timer of device 0000:00:02.0 to 64
> PCI: Setting latency timer of device 0000:01:00.0 to 64
> PCI: Setting latency timer of device 0000:01:00.2 to 64
> PCI: No IRQ known for interrupt pin A of device 0000:00:06.0. Probably buggy MP table.
> PCI: Setting latency timer of device 0000:00:06.0 to 64
> PCI: Setting latency timer of device 0000:00:1e.0 to 64
> NET: Registered protocol family 2
> IP route cache hash table entries: 131072 (order: 8, 1048576 bytes)
> TCP established hash table entries: 262144 (order: 10, 4194304 bytes)
> TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
> TCP: Hash tables configured (established 262144 bind 65536)
> TCP reno registered
> IA-32 Microcode Update Driver: v1.14a <[email protected]>
> Total HugeTLB memory allocated, 0
> io scheduler noop registered
> io scheduler anticipatory registered (default)
> io scheduler deadline registered
> io scheduler cfq registered
> Intel E7520/7320/7525 detected.<7>PCI: Setting latency timer of device 0000:00:02.0 to 64
> pcie_portdrv_probe->Dev[3595:8086] has invalid IRQ. Check vendor BIOS
> Allocate Port Service[0000:00:02.0:pcie00]
> PCI: Setting latency timer of device 0000:00:06.0 to 64
> pcie_portdrv_probe->Dev[3599:8086] has invalid IRQ. Check vendor BIOS
> Allocate Port Service[0000:00:06.0:pcie00]
> pci_hotplug: PCI Hot Plug PCI Core version: 0.5
> Real Time Clock Driver v1.12ac
> Linux agpgart interface v0.101 (c) Dave Jones
> Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
> serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
> serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
> RAMDISK driver initialized: 16 RAM disks of 64000K size 1024 blocksize
> Intel(R) PRO/1000 Network Driver - version 7.2.7-k2-NAPI
> Copyright (c) 1999-2006 Intel Corporation.
> e1000: 0000:03:04.0: e1000_probe: (PCI-X:100MHz:64-bit) 00:02:b3:e8:fa:c8
> e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection
> e1000: 0000:03:04.1: e1000_probe: (PCI-X:100MHz:64-bit) 00:02:b3:e8:fa:c9
> e1000: eth1: e1000_probe: Intel(R) PRO/1000 Network Connection
> forcedeth.c: Reverse Engineered nForce ethernet driver. Version 0.57.
> netconsole: not configured, aborting
> usbmon: debugfs is not available
> serio: i8042 AUX port at 0x60,0x64 irq 12
> serio: i8042 KBD port at 0x60,0x64 irq 1
> mice: PS/2 mouse device common for all mice
> EDAC MC: Ver: 2.0.1 Sep 26 2006
> IPv4 over IPv4 tunneling driver
> GRE over IPv4 tunneling driver
> TCP bic registered
> Initializing XFRM netlink socket
> NET: Registered protocol family 1
> NET: Registered protocol family 10
> lo: Disabled Privacy Extensions
> IPv6 over IPv4 tunneling driver
> NET: Registered protocol family 17
> NET: Registered protocol family 15
> Bridge firewalling registered
> NET: Registered protocol family 8
> NET: Registered protocol family 20
> 802.1Q VLAN Support v1.8 Ben Greear <[email protected]>
> All bugs added by David S. Miller <[email protected]>
> TIPC: Activated (version 1.6.1 compiled Sep 26 2006 18:53:22)
> NET: Registered protocol family 30
> TIPC: Started in single node mode
> /home/eric/projects/linux/linux-2.6-ns/drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
> Freeing unused kernel memory: 220k freed
On Tue, 26 Sep 2006 20:04:05 -0600
[email protected] (Eric W. Biederman) wrote:
> When I apply:
> x86_64-mm-insert-ioapics-and-local-apic-into-resource-map
>
> My e1000 fails to initializes and complains about a bad eeprom checksum.
> I haven't tracked this down to root cause yet and I am in the process of building
> 2.6.18-mm1 with just that patch reverted to confirm that is the only cause.
>
> I could not see anything obvious in the patch. I don't have a clue the patch
> could be triggering the problem I'm seeing.
>
> At a quick visual diff I'm not seeing any other differences in the kernel boot
> logs, or in /proc/iomem.
This bit looks fishy:
GSI 17 sharing vector 0x4A and IRQ 17
PCI->APIC IRQ transform: 0000:05:0c.0[A] -> IRQ 17
+PCI: Cannot allocate resource region 8 of bridge 0000:00:02.0
+PCI: Cannot allocate resource region 8 of bridge 0000:01:00.0
+PCI: Cannot allocate resource region 8 of bridge 0000:01:00.2
+PCI: Cannot allocate resource region 0 of device 0000:01:00.1
+PCI: Cannot allocate resource region 0 of device 0000:01:00.3
+PCI: Cannot allocate resource region 0 of device 0000:03:04.0
+PCI: Cannot allocate resource region 0 of device 0000:03:04.1
PCI-GART: No AMD northbridge found.
PCI: Bridge: 0000:01:00.0
IO window: disabled.
- MEM window: fe000000-fe0fffff
+ MEM window: e2000000-e20fffff
PREFETCH window: fd000000-fdffffff
PCI: Bridge: 0000:01:00.2
IO window: 1000-1fff
- MEM window: fe100000-fe1fffff
+ MEM window: e2100000-e21fffff
PREFETCH window: disabled.
PCI: Bridge: 0000:00:02.0
IO window: 1000-1fff
- MEM window: fe000000-fe2fffff
+ MEM window: e2000000-e22fffff
PREFETCH window: fd000000-fdffffff
PCI: Bridge: 0000:00:06.0
IO window: disabled.
@@ -123,17 +131,17 @@
PCI: Bridge: 0000:00:1e.0
IO window: 2000-2fff
MEM window: fb000000-fc0fffff
- PREFETCH window: e2000000-e20fffff
Wanna hack into arch/i386/pci/i386.c:pcibios_allocate_bus_resources() and
see what is conflicting with what?
Andrew Morton <[email protected]> writes:
> On Tue, 26 Sep 2006 20:04:05 -0600
> [email protected] (Eric W. Biederman) wrote:
>
>> When I apply:
>> x86_64-mm-insert-ioapics-and-local-apic-into-resource-map
>>
>> My e1000 fails to initializes and complains about a bad eeprom checksum.
>> I haven't tracked this down to root cause yet and I am in the process of
> building
>> 2.6.18-mm1 with just that patch reverted to confirm that is the only cause.
>>
>> I could not see anything obvious in the patch. I don't have a clue the patch
>> could be triggering the problem I'm seeing.
>>
>> At a quick visual diff I'm not seeing any other differences in the kernel boot
>> logs, or in /proc/iomem.
>
> This bit looks fishy:
>
> GSI 17 sharing vector 0x4A and IRQ 17
> PCI->APIC IRQ transform: 0000:05:0c.0[A] -> IRQ 17
> +PCI: Cannot allocate resource region 8 of bridge 0000:00:02.0
> +PCI: Cannot allocate resource region 8 of bridge 0000:01:00.0
> +PCI: Cannot allocate resource region 8 of bridge 0000:01:00.2
> +PCI: Cannot allocate resource region 0 of device 0000:01:00.1
> +PCI: Cannot allocate resource region 0 of device 0000:01:00.3
> +PCI: Cannot allocate resource region 0 of device 0000:03:04.0
> +PCI: Cannot allocate resource region 0 of device 0000:03:04.1
> PCI-GART: No AMD northbridge found.
> PCI: Bridge: 0000:01:00.0
> IO window: disabled.
> - MEM window: fe000000-fe0fffff
> + MEM window: e2000000-e20fffff
> PREFETCH window: fd000000-fdffffff
> PCI: Bridge: 0000:01:00.2
> IO window: 1000-1fff
> - MEM window: fe100000-fe1fffff
> + MEM window: e2100000-e21fffff
> PREFETCH window: disabled.
> PCI: Bridge: 0000:00:02.0
> IO window: 1000-1fff
> - MEM window: fe000000-fe2fffff
> + MEM window: e2000000-e22fffff
> PREFETCH window: fd000000-fdffffff
> PCI: Bridge: 0000:00:06.0
> IO window: disabled.
> @@ -123,17 +131,17 @@
> PCI: Bridge: 0000:00:1e.0
> IO window: 2000-2fff
> MEM window: fb000000-fc0fffff
> - PREFETCH window: e2000000-e20fffff
>
>
> Wanna hack into arch/i386/pci/i386.c:pcibios_allocate_bus_resources() and
> see what is conflicting with what?
Good catch. Add that to the earlier /proc/iomem output.
> fe200000-fe200fff : IOAPIC 1
> fe201000-fe201fff : IOAPIC 2
On that board I have ioapics on pci devices and it appears the way
the patch is reserving them it doesn't account for ioapics that
have that property. I.e. Those ioapics regions show up in lspci
on an ioapic pci device and the regions are specified with normal
base address registers.
I'm trying to finish up my msi work, so I'm going to avoid further
digging. Hopefully this is enough now that we have a reasonable
explanation someone can actually dig in and fix this problem.
Eric
On 9/26/06, Eric W. Biederman <[email protected]> wrote:
> Andrew Morton <[email protected]> writes:
>
> > On Tue, 26 Sep 2006 20:04:05 -0600
> > [email protected] (Eric W. Biederman) wrote:
> >
> >> When I apply:
> >> x86_64-mm-insert-ioapics-and-local-apic-into-resource-map
> >>
> >> My e1000 fails to initializes and complains about a bad eeprom checksum.
> >> I haven't tracked this down to root cause yet and I am in the process of
> > building
> >> 2.6.18-mm1 with just that patch reverted to confirm that is the only cause.
> >>
> >> I could not see anything obvious in the patch. I don't have a clue the patch
> >> could be triggering the problem I'm seeing.
> >>
> >> At a quick visual diff I'm not seeing any other differences in the kernel boot
> >> logs, or in /proc/iomem.
> >
> > This bit looks fishy:
> >
> > GSI 17 sharing vector 0x4A and IRQ 17
> > PCI->APIC IRQ transform: 0000:05:0c.0[A] -> IRQ 17
> > +PCI: Cannot allocate resource region 8 of bridge 0000:00:02.0
> > +PCI: Cannot allocate resource region 8 of bridge 0000:01:00.0
> > +PCI: Cannot allocate resource region 8 of bridge 0000:01:00.2
> > +PCI: Cannot allocate resource region 0 of device 0000:01:00.1
> > +PCI: Cannot allocate resource region 0 of device 0000:01:00.3
> > +PCI: Cannot allocate resource region 0 of device 0000:03:04.0
> > +PCI: Cannot allocate resource region 0 of device 0000:03:04.1
> > PCI-GART: No AMD northbridge found.
> > PCI: Bridge: 0000:01:00.0
> > IO window: disabled.
> > - MEM window: fe000000-fe0fffff
> > + MEM window: e2000000-e20fffff
> > PREFETCH window: fd000000-fdffffff
> > PCI: Bridge: 0000:01:00.2
> > IO window: 1000-1fff
> > - MEM window: fe100000-fe1fffff
> > + MEM window: e2100000-e21fffff
> > PREFETCH window: disabled.
> > PCI: Bridge: 0000:00:02.0
> > IO window: 1000-1fff
> > - MEM window: fe000000-fe2fffff
> > + MEM window: e2000000-e22fffff
> > PREFETCH window: fd000000-fdffffff
> > PCI: Bridge: 0000:00:06.0
> > IO window: disabled.
> > @@ -123,17 +131,17 @@
> > PCI: Bridge: 0000:00:1e.0
> > IO window: 2000-2fff
> > MEM window: fb000000-fc0fffff
> > - PREFETCH window: e2000000-e20fffff
> >
> >
> > Wanna hack into arch/i386/pci/i386.c:pcibios_allocate_bus_resources() and
> > see what is conflicting with what?
>
> Good catch. Add that to the earlier /proc/iomem output.
> > fe200000-fe200fff : IOAPIC 1
> > fe201000-fe201fff : IOAPIC 2
>
> On that board I have ioapics on pci devices and it appears the way
> the patch is reserving them it doesn't account for ioapics that
> have that property. I.e. Those ioapics regions show up in lspci
> on an ioapic pci device and the regions are specified with normal
> base address registers.
>
That patch marks each IOAPIC resource as IORESOURCE_BUSY. This why
the pci allocation fails. I will post patch to fix this in the
morning.
-Aaron
"Aaron Durbin" <[email protected]> writes:
> On 9/26/06, Eric W. Biederman <[email protected]> wrote:
>> Andrew Morton <[email protected]> writes:
>>
>> > On Tue, 26 Sep 2006 20:04:05 -0600
>> > [email protected] (Eric W. Biederman) wrote:
>> >
>> >> When I apply:
>> >> x86_64-mm-insert-ioapics-and-local-apic-into-resource-map
>> >>
>> >> My e1000 fails to initializes and complains about a bad eeprom checksum.
>> >> I haven't tracked this down to root cause yet and I am in the process of
>> > building
>> >> 2.6.18-mm1 with just that patch reverted to confirm that is the only cause.
>> >>
>> >> I could not see anything obvious in the patch. I don't have a clue the
> patch
>> >> could be triggering the problem I'm seeing.
>> >>
>> >> At a quick visual diff I'm not seeing any other differences in the kernel
> boot
>> >> logs, or in /proc/iomem.
>> >
>> > This bit looks fishy:
>> >
>> > GSI 17 sharing vector 0x4A and IRQ 17
>> > PCI->APIC IRQ transform: 0000:05:0c.0[A] -> IRQ 17
>> > +PCI: Cannot allocate resource region 8 of bridge 0000:00:02.0
>> > +PCI: Cannot allocate resource region 8 of bridge 0000:01:00.0
>> > +PCI: Cannot allocate resource region 8 of bridge 0000:01:00.2
>> > +PCI: Cannot allocate resource region 0 of device 0000:01:00.1
>> > +PCI: Cannot allocate resource region 0 of device 0000:01:00.3
>> > +PCI: Cannot allocate resource region 0 of device 0000:03:04.0
>> > +PCI: Cannot allocate resource region 0 of device 0000:03:04.1
>> > PCI-GART: No AMD northbridge found.
>> > PCI: Bridge: 0000:01:00.0
>> > IO window: disabled.
>> > - MEM window: fe000000-fe0fffff
>> > + MEM window: e2000000-e20fffff
>> > PREFETCH window: fd000000-fdffffff
>> > PCI: Bridge: 0000:01:00.2
>> > IO window: 1000-1fff
>> > - MEM window: fe100000-fe1fffff
>> > + MEM window: e2100000-e21fffff
>> > PREFETCH window: disabled.
>> > PCI: Bridge: 0000:00:02.0
>> > IO window: 1000-1fff
>> > - MEM window: fe000000-fe2fffff
>> > + MEM window: e2000000-e22fffff
>> > PREFETCH window: fd000000-fdffffff
>> > PCI: Bridge: 0000:00:06.0
>> > IO window: disabled.
>> > @@ -123,17 +131,17 @@
>> > PCI: Bridge: 0000:00:1e.0
>> > IO window: 2000-2fff
>> > MEM window: fb000000-fc0fffff
>> > - PREFETCH window: e2000000-e20fffff
>> >
>> >
>> > Wanna hack into arch/i386/pci/i386.c:pcibios_allocate_bus_resources() and
>> > see what is conflicting with what?
>>
>> Good catch. Add that to the earlier /proc/iomem output.
>> > fe200000-fe200fff : IOAPIC 1
>> > fe201000-fe201fff : IOAPIC 2
>>
>> On that board I have ioapics on pci devices and it appears the way
>> the patch is reserving them it doesn't account for ioapics that
>> have that property. I.e. Those ioapics regions show up in lspci
>> on an ioapic pci device and the regions are specified with normal
>> base address registers.
>>
>
> That patch marks each IOAPIC resource as IORESOURCE_BUSY. This why
> the pci allocation fails. I will post patch to fix this in the
> morning.
I'm not certain that is enough. Please not that those bridge resources
are larger then the ioapics, and I believe you are reserving the ioapic
resources first. So I don't believe simply clearing IORESOURCE_BUSY
is enough. Also if you look because my ioapics are pci devices these
resource are already getting reserved.
Look below at devices 1:00.1 and 1:00.3
I think the correct solution is most likely to test to see if the
ioapic is in the ioapic legacy range and only to reserve it if that
is the case. Although if we find all of the pci devices before we
reserve their resources we could remove your reservation for the
ioapics if we find a corresponding BAR, which would be cleaner
and more general then relying on a magic memory range.
# cat /proc/iomem
00000000-00000c3f : reserved
00000c40-0009ffff : System RAM
000a0000-000bffff : Video RAM area
000c0000-000effff : System RAM
000f0000-000fffff : System ROM
e2000000-e20fffff : PCI Bus #05
e2000000-e201ffff : 0000:05:0c.0
fb000000-fc0fffff : PCI Bus #05
fb000000-fbffffff : 0000:05:0c.0
fc000000-fc000fff : 0000:05:0c.0
fd000000-fdffffff : PCI Bus #01
fd000000-fdffffff : PCI Bus #02
fd000000-fdffffff : 0000:02:03.0
fe000000-fe2fffff : PCI Bus #01
fe000000-fe0fffff : PCI Bus #02
fe000000-fe07ffff : 0000:02:03.0
fe100000-fe1fffff : PCI Bus #03
fe100000-fe11ffff : 0000:03:04.0
fe100000-fe11ffff : e1000
fe120000-fe13ffff : 0000:03:04.1
fe120000-fe13ffff : e1000
fe200000-fe200fff : 0000:01:00.1
fe201000-fe201fff : 0000:01:00.3
fe300000-fe300fff : 0000:00:00.0
fe301000-fe301fff : 0000:00:01.0
fe302000-fe3023ff : 0000:00:1d.7
fe303000-fe3033ff : 0000:00:1f.1
100000000-11fffffff : System RAM
Eric
On Wednesday 27 September 2006 04:04, Eric W. Biederman wrote:
>
> When I apply:
> x86_64-mm-insert-ioapics-and-local-apic-into-resource-map
>
> My e1000 fails to initializes and complains about a bad eeprom checksum.
> I haven't tracked this down to root cause yet and I am in the process of building
> 2.6.18-mm1 with just that patch reverted to confirm that is the only cause.
Is this with Linux BIOS?
-Andi
Andi Kleen <[email protected]> writes:
> On Wednesday 27 September 2006 04:04, Eric W. Biederman wrote:
>>
>> When I apply:
>> x86_64-mm-insert-ioapics-and-local-apic-into-resource-map
>>
>> My e1000 fails to initializes and complains about a bad eeprom checksum.
>> I haven't tracked this down to root cause yet and I am in the process of
> building
>> 2.6.18-mm1 with just that patch reverted to confirm that is the only cause.
>
> Is this with Linux BIOS?
Yes. Not that it matters in this case.
Eric
On Wednesday 27 September 2006 09:39, Eric W. Biederman wrote:
> Andi Kleen <[email protected]> writes:
>
> > On Wednesday 27 September 2006 04:04, Eric W. Biederman wrote:
> >>
> >> When I apply:
> >> x86_64-mm-insert-ioapics-and-local-apic-into-resource-map
> >>
> >> My e1000 fails to initializes and complains about a bad eeprom checksum.
> >> I haven't tracked this down to root cause yet and I am in the process of
> > building
> >> 2.6.18-mm1 with just that patch reverted to confirm that is the only cause.
> >
> > Is this with Linux BIOS?
>
> Yes. Not that it matters in this case.
Well Linus BIOS is known to play very fast-and-lose regarding supplying
correct BIOS tables.
Perhaps it conflicts with a broken e820 map?
-Andi
Ok. Now that we've got past the linker changes breaking down under
older tool chains I am getting following panic on boot. The machine has
one of these, other machines do seem to boot:
0000:02:04.0 SCSI storage controller: LSI Logic / Symbios Logic 53c1030
PCI-X Fusion-MPT Dual Ultra320 SCSI (rev 07)
It appears that this driver is unchanged between 2.6.18 and -mm1.
2.6.18 boots just fine. Odd.
Any suggestions?
-apw
mptbase: Initiating ioc0 bringup
ioc0: 53C1030: Capabilities={Initiator}
mptbase: Initiating ioc0 recovery
Unable to handle kernel NULL pointer dereference at 0000000000000500 RIP:
[<ffffffff803fadfb>] mptspi_dv_renegotiate_work+0x10/0x4a
PGD 0
Oops: 0000 [1] SMP
last sysfs file:
CPU 0
Modules linked in:
Pid: 14, comm: events/0 Not tainted 2.6.18-mm1-autokern1 #1
RIP: 0010:[<ffffffff803fadfb>] [<ffffffff803fadfb>]
mptspi_dv_renegotiate_work+0x10/0x4a
RSP: 0000:ffff8101000e1e20 EFLAGS: 00010282
RAX: 0000000000000001 RBX: ffff810001fe6940 RCX: 000000000000001f
RDX: 0000000000000000 RSI: ffff810001fe6940 RDI: 0000000000001fe6
RBP: ffff8101000e1e30 R08: ffff8101000e0000 R09: 0000000000000011
R10: ffff810001014820 R11: ffff810001014820 R12: 0000000000000500
R13: ffff810001ef1640 R14: 0000000000000206 R15: ffff810001fe6940
FS: 0000000000000000(0000) GS:ffffffff80582000(0000) knlGS:0000000000000000
CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: 0000000000000500 CR3: 0000000000201000 CR4: 00000000000006e0
Process events/0 (pid: 14, threadinfo ffff8101000e0000, task
ffff8100816b1040)
Stack: ffff810001fe6940 ffff810001fe6948 ffff8101000e1e70 ffffffff80239163
ffffffff803fadeb ffff810001ef1640 ffff810001f0dd40 ffffffff802391a7
00000000fffffffc ffffffff804b08d4 ffff8101000e1f00 ffffffff8023929a
Call Trace:
[<ffffffff80239163>] run_workqueue+0xa2/0xe6
[<ffffffff803fadeb>] mptspi_dv_renegotiate_work+0x0/0x4a
[<ffffffff802391a7>] worker_thread+0x0/0x126
[<ffffffff8023929a>] worker_thread+0xf3/0x126
[<ffffffff80224de3>] default_wake_function+0x0/0xf
[<ffffffff80224de3>] default_wake_function+0x0/0xf
[<ffffffff802391a7>] worker_thread+0x0/0x126
[<ffffffff8023c304>] kthread+0xd0/0xfc
[<ffffffff8020a658>] child_rip+0xa/0x12
[<ffffffff8023c234>] kthread+0x0/0xfc
[<ffffffff8020a64e>] child_rip+0x0/0x12
Code: 49 8b 04 24 31 f6 48 8b b8 48 01 00 00 e8 5f 8f fe ff 48 85
RIP [<ffffffff803fadfb>] mptspi_dv_renegotiate_work+0x10/0x4a
RSP <ffff8101000e1e20>
CR2: 0000000000000500
Andi Kleen <[email protected]> writes:
> On Wednesday 27 September 2006 09:39, Eric W. Biederman wrote:
>> Andi Kleen <[email protected]> writes:
>>
>> > On Wednesday 27 September 2006 04:04, Eric W. Biederman wrote:
>> >>
>> >> When I apply:
>> >> x86_64-mm-insert-ioapics-and-local-apic-into-resource-map
>> >>
>> >> My e1000 fails to initializes and complains about a bad eeprom checksum.
>> >> I haven't tracked this down to root cause yet and I am in the process of
>> > building
>> >> 2.6.18-mm1 with just that patch reverted to confirm that is the only cause.
>> >
>> > Is this with Linux BIOS?
>>
>> Yes. Not that it matters in this case.
>
> Well Linus BIOS is known to play very fast-and-lose regarding supplying
> correct BIOS tables.
Agreed it does tend to push the envelop of what is allowed, and doesn't
try to work around OS bugs. Which does tend to expose things.
> Perhaps it conflicts with a broken e820 map?
No. Did you not get the other part of the discussion?
The reservation was wrong because those IOAPICs were on ordinary pci
devices. So the two reservations for the same resource conflicted,
so the pci allocator tried to move the pci device.
The problem is totally contained within the patch under discussion.
The role LinuxBIOS plays seems to be that it is atypical to enable
ioapics as ordinary pci devices.
Eric
On Wed, 27 Sep 2006 10:25:40 +0100
Andy Whitcroft <[email protected]> wrote:
> Ok. Now that we've got past the linker changes breaking down under
> older tool chains I am getting following panic on boot. The machine has
> one of these, other machines do seem to boot:
>
> 0000:02:04.0 SCSI storage controller: LSI Logic / Symbios Logic 53c1030
> PCI-X Fusion-MPT Dual Ultra320 SCSI (rev 07)
>
> It appears that this driver is unchanged between 2.6.18 and -mm1.
> 2.6.18 boots just fine. Odd.
>
> Any suggestions?
>
> -apw
>
> mptbase: Initiating ioc0 bringup
> ioc0: 53C1030: Capabilities={Initiator}
> mptbase: Initiating ioc0 recovery
> Unable to handle kernel NULL pointer dereference at 0000000000000500 RIP:
> [<ffffffff803fadfb>] mptspi_dv_renegotiate_work+0x10/0x4a
> PGD 0
> Oops: 0000 [1] SMP
> last sysfs file:
> CPU 0
> Modules linked in:
> Pid: 14, comm: events/0 Not tainted 2.6.18-mm1-autokern1 #1
> RIP: 0010:[<ffffffff803fadfb>] [<ffffffff803fadfb>]
> mptspi_dv_renegotiate_work+0x10/0x4a
> RSP: 0000:ffff8101000e1e20 EFLAGS: 00010282
> RAX: 0000000000000001 RBX: ffff810001fe6940 RCX: 000000000000001f
> RDX: 0000000000000000 RSI: ffff810001fe6940 RDI: 0000000000001fe6
> RBP: ffff8101000e1e30 R08: ffff8101000e0000 R09: 0000000000000011
> R10: ffff810001014820 R11: ffff810001014820 R12: 0000000000000500
> R13: ffff810001ef1640 R14: 0000000000000206 R15: ffff810001fe6940
> FS: 0000000000000000(0000) GS:ffffffff80582000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
> CR2: 0000000000000500 CR3: 0000000000201000 CR4: 00000000000006e0
> Process events/0 (pid: 14, threadinfo ffff8101000e0000, task
> ffff8100816b1040)
> Stack: ffff810001fe6940 ffff810001fe6948 ffff8101000e1e70 ffffffff80239163
> ffffffff803fadeb ffff810001ef1640 ffff810001f0dd40 ffffffff802391a7
> 00000000fffffffc ffffffff804b08d4 ffff8101000e1f00 ffffffff8023929a
> Call Trace:
> [<ffffffff80239163>] run_workqueue+0xa2/0xe6
> [<ffffffff803fadeb>] mptspi_dv_renegotiate_work+0x0/0x4a
> [<ffffffff802391a7>] worker_thread+0x0/0x126
> [<ffffffff8023929a>] worker_thread+0xf3/0x126
> [<ffffffff80224de3>] default_wake_function+0x0/0xf
> [<ffffffff80224de3>] default_wake_function+0x0/0xf
> [<ffffffff802391a7>] worker_thread+0x0/0x126
> [<ffffffff8023c304>] kthread+0xd0/0xfc
> [<ffffffff8020a658>] child_rip+0xa/0x12
> [<ffffffff8023c234>] kthread+0x0/0xfc
> [<ffffffff8020a64e>] child_rip+0x0/0x12
>
>
> Code: 49 8b 04 24 31 f6 48 8b b8 48 01 00 00 e8 5f 8f fe ff 48 85
> RIP [<ffffffff803fadfb>] mptspi_dv_renegotiate_work+0x10/0x4a
> RSP <ffff8101000e1e20>
> CR2: 0000000000000500
There are mpt-fusion changes in 2.6.18-mm1, but afaict they're in mainline
now. Do you know if current -linus works OK?
Andrew Morton wrote:
> On Wed, 27 Sep 2006 10:25:40 +0100
> Andy Whitcroft <[email protected]> wrote:
>
>> Ok. Now that we've got past the linker changes breaking down under
>> older tool chains I am getting following panic on boot. The machine has
>> one of these, other machines do seem to boot:
>>
>> 0000:02:04.0 SCSI storage controller: LSI Logic / Symbios Logic 53c1030
>> PCI-X Fusion-MPT Dual Ultra320 SCSI (rev 07)
>>
>> It appears that this driver is unchanged between 2.6.18 and -mm1.
>> 2.6.18 boots just fine. Odd.
>>
>> Any suggestions?
>>
>> -apw
>>
>> mptbase: Initiating ioc0 bringup
>> ioc0: 53C1030: Capabilities={Initiator}
>> mptbase: Initiating ioc0 recovery
>> Unable to handle kernel NULL pointer dereference at 0000000000000500 RIP:
>> [<ffffffff803fadfb>] mptspi_dv_renegotiate_work+0x10/0x4a
>> PGD 0
>> Oops: 0000 [1] SMP
>> last sysfs file:
>> CPU 0
>> Modules linked in:
>> Pid: 14, comm: events/0 Not tainted 2.6.18-mm1-autokern1 #1
>> RIP: 0010:[<ffffffff803fadfb>] [<ffffffff803fadfb>]
>> mptspi_dv_renegotiate_work+0x10/0x4a
>> RSP: 0000:ffff8101000e1e20 EFLAGS: 00010282
>> RAX: 0000000000000001 RBX: ffff810001fe6940 RCX: 000000000000001f
>> RDX: 0000000000000000 RSI: ffff810001fe6940 RDI: 0000000000001fe6
>> RBP: ffff8101000e1e30 R08: ffff8101000e0000 R09: 0000000000000011
>> R10: ffff810001014820 R11: ffff810001014820 R12: 0000000000000500
>> R13: ffff810001ef1640 R14: 0000000000000206 R15: ffff810001fe6940
>> FS: 0000000000000000(0000) GS:ffffffff80582000(0000) knlGS:0000000000000000
>> CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
>> CR2: 0000000000000500 CR3: 0000000000201000 CR4: 00000000000006e0
>> Process events/0 (pid: 14, threadinfo ffff8101000e0000, task
>> ffff8100816b1040)
>> Stack: ffff810001fe6940 ffff810001fe6948 ffff8101000e1e70 ffffffff80239163
>> ffffffff803fadeb ffff810001ef1640 ffff810001f0dd40 ffffffff802391a7
>> 00000000fffffffc ffffffff804b08d4 ffff8101000e1f00 ffffffff8023929a
>> Call Trace:
>> [<ffffffff80239163>] run_workqueue+0xa2/0xe6
>> [<ffffffff803fadeb>] mptspi_dv_renegotiate_work+0x0/0x4a
>> [<ffffffff802391a7>] worker_thread+0x0/0x126
>> [<ffffffff8023929a>] worker_thread+0xf3/0x126
>> [<ffffffff80224de3>] default_wake_function+0x0/0xf
>> [<ffffffff80224de3>] default_wake_function+0x0/0xf
>> [<ffffffff802391a7>] worker_thread+0x0/0x126
>> [<ffffffff8023c304>] kthread+0xd0/0xfc
>> [<ffffffff8020a658>] child_rip+0xa/0x12
>> [<ffffffff8023c234>] kthread+0x0/0xfc
>> [<ffffffff8020a64e>] child_rip+0x0/0x12
>>
>>
>> Code: 49 8b 04 24 31 f6 48 8b b8 48 01 00 00 e8 5f 8f fe ff 48 85
>> RIP [<ffffffff803fadfb>] mptspi_dv_renegotiate_work+0x10/0x4a
>> RSP <ffff8101000e1e20>
>> CR2: 0000000000000500
>
> There are mpt-fusion changes in 2.6.18-mm1, but afaict they're in mainline
> now. Do you know if current -linus works OK?
Arse, it seems that the other problem that we are talking about on this
machine also just got pushed up to mainline (2.6.18-git7) so it
currently doesn't compile.
Will try the same fix on that I used on -mm1 and see if it fixes that.
-apw
On 9/27/06, Eric W. Biederman <[email protected]> wrote:
> Andi Kleen <[email protected]> writes:
>
> > On Wednesday 27 September 2006 09:39, Eric W. Biederman wrote:
> >> Andi Kleen <[email protected]> writes:
> >>
> >> > On Wednesday 27 September 2006 04:04, Eric W. Biederman wrote:
> >> >>
> >> >> When I apply:
> >> >> x86_64-mm-insert-ioapics-and-local-apic-into-resource-map
> >> >>
> >> >> My e1000 fails to initializes and complains about a bad eeprom checksum.
> >> >> I haven't tracked this down to root cause yet and I am in the process of
> >> > building
> >> >> 2.6.18-mm1 with just that patch reverted to confirm that is the only cause.
> >> >
> >> > Is this with Linux BIOS?
> >>
> >> Yes. Not that it matters in this case.
> >
> > Well Linus BIOS is known to play very fast-and-lose regarding supplying
> > correct BIOS tables.
>
> Agreed it does tend to push the envelop of what is allowed, and doesn't
> try to work around OS bugs. Which does tend to expose things.
>
> > Perhaps it conflicts with a broken e820 map?
>
> No. Did you not get the other part of the discussion?
>
> The reservation was wrong because those IOAPICs were on ordinary pci
> devices. So the two reservations for the same resource conflicted,
> so the pci allocator tried to move the pci device.
>
> The problem is totally contained within the patch under discussion.
>
> The role LinuxBIOS plays seems to be that it is atypical to enable
> ioapics as ordinary pci devices.
>
> Eric
>
Eric,
I agree that clearing the IORESOURCE_BUSY flag would not alleviate
this problem. Could you please post the output of 'lspci -vvvvx' so
we could better understand the layout of your box? Perhaps I might
have to defer the registration of the resources until later. It seems
weird that the IO APIC are mapped in as PCI devices though.
-Aaron
On Wed, 27 Sep 2006 15:06:14 -0700
"Aaron Durbin" <[email protected]> wrote:
>
> I agree that clearing the IORESOURCE_BUSY flag would not alleviate
> this problem. Could you please post the output of 'lspci -vvvvx' so
> we could better understand the layout of your box? Perhaps I might
> have to defer the registration of the resources until later. It seems
> weird that the IO APIC are mapped in as PCI devices though.
I think we should aim to get some extra debugging into this code, to help
us diagnose things like http://bugzilla.kernel.org/show_bug.cgi?id=7218
We get quite a few reports of this nature, and the kernel does seem to have
regressed.