2.6.17-mm1

2.6.17-mm1

[Andrew Morton]

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


- powerpc is bust (on g5, at least).  git-klibc is causing nash to fail on
  startup and some later patch is causing a big crash (I didn't bisect that
  one - later).

- ia64 doesn't compile for me, due to git-klibc problems (a truly ancient
  toolchain might be implicated).

- git-sas.patch has been dropped due to build failures.

- git-s390.patch has been dropped due to patching rejects





Boilerplate:

- See the `hot-fixes' directory for any important updates to this patchset.

- To fetch an -mm tree using git, use (for example)

  git fetch git://git.kernel.org/pub/scm/linux/kernel/git/smurf/linux-trees.git v2.6.16-rc2-mm1

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

        echo "subscribe mm-commits" | mail majordomo@vger.kernel.org

- If you hit a bug in -mm and it is not obvious which patch caused it, it is
  most valuable if you can perform a bisection search to identify which patch
  introduced the bug.  Instructions for this process are at

        http://www.zip.com.au/~akpm/linux/patches/stuff/bisecting-mm-trees.txt

  But beware that this process takes some time (around ten rebuilds and
  reboots), so consider reporting the bug first and if we cannot immediately
  identify the faulty patch, then perform the bisection search.

- When reporting bugs, please try to Cc: the relevant maintainer and mailing
  list on any email.




Changes since 2.6.17-rc6-mm2:


 origin.patch
 git-acpi.patch
 git-agpgart.patch
 git-alsa.patch
 git-block.patch
 git-cifs.patch
 git-cpufreq.patch
 git-dvb.patch
 git-gfs2.patch
 git-ia64.patch
 git-infiniband.patch
 git-input.patch
 git-jfs.patch
 git-kbuild.patch
 git-klibc.patch
 git-hdrinstall2.patch
 git-libata-all.patch
 git-netdev-all.patch
 git-nfs.patch
 git-ocfs2.patch
 git-powerpc.patch
 git-pcmcia.patch
 git-scsi-target.patch
 git-supertrak.patch
 git-watchdog.patch
 git-xfs.patch
 git-cryptodev.patch

 git trees

-further-alterations-for-memory-barrier-document.patch
-powernow-k8-crash-workaround.patch
-bugfixes-to-get-i2o-working-again.patch
-fix-possible-oops-in-cs4281-irq-handler.patch
-trivial-videodev2h-patch.patch
-zoran-strncpy-cleanup.patch
-scx200_acb-use-pci-i-o-resource-when-appropriate.patch
-i2c-pca954x-i2c-mux-driver.patch
-i2c-pca954x-fix-initial-access-to-first-mux-switch-port.patch
-ieee1394-video1394-be-quiet.patch
-ieee1394-ohci1394c-function-calls-without.patch
-ieee1394-sbp2-make-tsb42aa9-workaround-specific.patch
-ieee1394-semaphore-to-mutex-conversion.patch
-ieee1394-raw1394-fix-whitespace-after-x86_64.patch
-ieee1394-ieee1394-ohci1394-cycletoolong.patch
-ieee1394-ieee1394-support-for-slow-links-or-slow.patch
-ieee1394-ieee1394-save-ram-by-using-a-single.patch
-ieee1394-sbp2-remove-manipulation-of-inquiry.patch
-ieee1394-sbp2-log-number-of-supported-concurrent.patch
-ieee1394-ieee1394-extend-lowlevel-api-for.patch
-ieee1394-ohci1394-set-address-range-properties.patch
-ieee1394-ohci1394-make-phys_dma-parameter.patch
-ieee1394-sbp2-sbp2-remove-ohci1394-specific.patch
-ieee1394-sbp2-fix-s800-transfers-if-phys_dma-is.patch
-ieee1394-update-feature-removal-of-obsolete.patch
-ieee1394-sbp2-provide-helptext-for.patch
-ieee1394-sbp2-kconfig-fix.patch
-ieee1394-sbp2-use-__attribute__packed-for.patch
-ieee1394-speed-up-of-dma_region_sync_for_cpu.patch
-ieee1394-sbp2-fix-deregistration-of-status-fifo-address-space.patch
-ieee1394-add-preprocessor-constant-for-invalid-csr.patch
-fix-broken-suspend-resume-in-ohci1394-was-acpi-suspend.patch
-ieee1394_core-switch-to-kthread-api.patch
-eth1394-endian-fixes.patch
-ieee1394-hl_irqs_lock-is-taken-in-hardware.patch
-ieee1394-adjust-code-formatting-in.patch
-git-kbuild-modpost-build-fix.patch
-git-klibc-ia64-build-fix.patch
-git-hdrcleanup.patch
-git-hdrcleanup-fixup.patch
-libata-add-missing-data_xfer-for-pata_pdc2027x-and-pdc_adma.patch
-sata_sil24-endian-anotations.patch
-sdhci-truncated-pointer-fix.patch
-git-netdev-all-fixup.patch
-smc911x-Kconfig-fix.patch
-e1000-prevent-statistics-from-getting-garbled-during-reset.patch
-forcedeth-config-ring-sizes.patch
-forcedeth-config-flow-control.patch
-forcedeth-config-phy.patch
-forcedeth-config-wol.patch
-forcedeth-config-csum.patch
-forcedeth-config-statistics.patch
-forcedeth-config-diagnostics.patch
-forcedeth-config-module-parameters.patch
-forcedeth-config-version.patch
-forcedeth-new-device-ids.patch
-ipw2200-locking-fix.patch
-forcedeth-xmit_lock-went-away.patch
-client-side-nfsacl-caching-fix.patch
-nfs-really-return-status-from-decode_recall_args.patch
-gregkh-pci-pci-add-pci_cap_id_vndr.patch
-gregkh-pci-pci-fix-pciehp-compile-issue-when-config_acpi-is-not-enabled.patch
-remove-drivers-scsi-constantscscsi_print_req_sense.patch
-scsi-remove-documentation-scsi-cpqfctxt.patch
-mpt-fusion-driver-initialization-failure-fix.patch
-drivers-scsi-use-array_size-macro.patch
-hptiop-highpoint-rocketraid-3xxx-controller-driver.patch
-remove-the-scsi_request-interface-from-the-gdth-driver.patch
-git-scsi-target-warning-fix.patch
-mm-x86_64-mm-polling-thread-status-fix.patch
-x86_64-setupc-print-cmp-related-boottime-information.patch
-alpha-generic-hweight-build-fix.patch
-add-__iowrite64_copy.patch
-add-__iowrite64_copy-s390-fix.patch
-inotify-split-kernel-api-from-userspace-support.patch
-inotify-add-names-inode-to-event-handler.patch
-inotify-add-interfaces-to-kernel-api.patch
-inotify-allow-watch-removal-from-event-handler.patch
-inotify-update-kernel-documentation.patch
-sound-vxpocket-fix-printk-warning.patch

 Merged into mainline or a subsystem tree

+uml-fix-wall_to_monotonic-initialization.patch
+sparc-build-breakage.patch
+ntfs-critical-bug-fix-affects-mips-and-possibly-others.patch
+selinux-add-hooks-for-key-subsystem.patch
+keys-fix-race-between-two-instantiators-of-a-key.patch
+suspend_console-warning-fix.patch
+myri10ge-build-fix.patch

 to-merge-asap queue.

+git-acpi-pre.patch
+git-acpi-post.patch

 Things to make git-acpi easier to apply.

+git-acpi-fixup.patch

 Fix reject due to git-apci.

+git-acpi-ia64-build-fix.patch

 Fix git-acpi build error
 
+pnpacpi-reject-acpi_producer-resources.patch
+acpi-add-ibm-r60e-laptop-to-proc-idle-blacklist.patch
+acpi-c-states-accounting-of-sleep-states.patch
+acpi-c-states-bm_activity-improvements.patch
+acpi-c-states-only-demote-on-current-bus-mastering-activity.patch

 ACPI patches.

+acpi-sony-add-fn-hotkey-support.patch

 2.6-sony_acpi4.patch feature

+ati-agp-build-fix.patch

 Fix git-agpgart.patch

-git-cpufreq-fixup.patch

 Unneeded

+gregkh-driver-make_class_name-kobj.patch
+gregkh-driver-device-class.patch
+gregkh-driver-driver-core-add-generic-subsystem-link-to-all-devices.patch
+gregkh-driver-device-symlinks-for-classes.patch
+gregkh-driver-driver-core-make-dev_info-and-friends-print-the-bus-name-if-there-is-no-driver.patch
+gregkh-driver-driver-model-add-isa-bus.patch

 driver tree updates

+saa7134-card-lifeview3000-ntsc.patch
+tea575x-tuner-build-fix.patch
+git-dvb-versus-matroxfb.patch
+git-dvb-printk-warning-fix.patch

 Fix git-dvb.patch

+gregkh-i2c-i2c-opencores-cleanup.patch
+gregkh-i2c-i2c-mark-data-const-for-write-block.patch
+gregkh-i2c-i2c-scx200_acb-use-PCI-IO-resource-when-appropriate.patch
+gregkh-i2c-i2c-scx200_acb-mark-scx200_acb_probe-init.patch
+gregkh-i2c-i2c-scx200_acb-documentation-update.patch
+gregkh-i2c-i2c-i801-01-fix-block-transaction-poll-loops.patch
+gregkh-i2c-i2c-i801-02-remove-force_addr-parameter.patch
+gregkh-i2c-i2c-i801-03-remove-pci-function-check.patch
+gregkh-i2c-i2c-i801-04-cleanups.patch
+gregkh-i2c-i2c-i801-05-better-pci-subsystem-integration.patch
+gregkh-i2c-i2c-i801-06-merge-setup-function.patch
+gregkh-i2c-hwmon-kconfig-header-fix.patch
+gregkh-i2c-hwmon-lm70-new-driver.patch
+gregkh-i2c-hwmon-vid-add-core-and-conroe-support.patch
+gregkh-i2c-i2c-i2c-controllers-go-into-right-place-on-sysfs.patch

 I2C tree updates

+i2c-801-64bit-resource-fix.patch

 Fix it.

+git-infiniband-fixup.patch

 Fix reject in git-infiniband.patch

+input-mouse-sermouse-fix-memleak-and-potential-buffer-overflow.patch

 input fix

+revert-sparc-build-breakage.patch

 Make git-klibc.patch easier to apply.

+git-klibc-fixup.patch

 Fix rejects in git-klibc.patch

-git-hdrinstall.patch
+git-hdrinstall2.patch

 Renamed

-revert-sata_sil24-sii3124-sata-driver-endian-problem.patch

 Dropped

+git-libata-all-fixup.patch
+git-libata-all-data_xfer-fixes.patch
+git-libata-all-data_xfer-fixes-fixes.patch
+git-libata-pata_cs5535-is-bust.patch

 Fix git-libata-all.patch

+via-pata-fails-on-some-atapi-drives.patch
+via-pata-fails-on-some-atapi-drives-tidy.patch

 ATA fix

-git-mtd-fixup.patch

 Unneeded

+ni5010-netcard-cleanup.patch

 netdev cleanup

-git-net-git-klibc-fixup.patch

 Unneeded

+netpoll-dont-spin-forever-sending-to-blocked-queues.patch
+netpoll-break-recursive-loop-in-netpoll-rx-path.patch
+irda-add-some-ibm-think-pads.patch
+atm-mpcc-warning-fix.patch

 net fixes

+git-nfs-build-fixes.patch
+nfs-build-fix-99.patch

 Fix git-nfs.patch wreckage

+nfs-remove-nfs_put_link.patch

 nfs cleanup

-git-sas.patch

 Dropped

+serial-add-tsi108-8250-serial-support.patch
+8250_pnp-add-support-for-other-wacom-tablets.patch
+serial-8250-sysrq-deadlock-fix.patch

 Serial things

+gregkh-pci-64bit-resource-c99-changes-for-struct-resource-declarations.patch
+gregkh-pci-64bit-resource-fix-up-printks-for-resources-in-sound-drivers.patch
+gregkh-pci-64bit-resource-fix-up-printks-for-resources-in-networks-drivers.patch
+gregkh-pci-64bit-resource-fix-up-printks-for-resources-in-pci-core-and-hotplug-drivers.patch
+gregkh-pci-64bit-resource-fix-up-printks-for-resources-in-mtd-drivers.patch
+gregkh-pci-64bit-resource-fix-up-printks-for-resources-in-ide-drivers.patch
+gregkh-pci-64bit-resource-fix-up-printks-for-resources-in-video-drivers.patch
+gregkh-pci-64bit-resource-fix-up-printks-for-resources-in-pcmcia-drivers.patch
+gregkh-pci-64bit-resource-fix-up-printks-for-resources-in-arch-and-core-code.patch
+gregkh-pci-64bit-resource-fix-up-printks-for-resources-in-misc-drivers.patch
+gregkh-pci-64bit-resource-introduce-resource_size_t-for-the-start-and-end-of-struct-resource.patch
+gregkh-pci-64bit-resource-change-resource-core-to-use-resource_size_t.patch
+gregkh-pci-64bit-resource-change-pci-core-and-arch-code-to-use-resource_size_t.patch
+gregkh-pci-64bit-resource-change-pnp-core-to-use-resource_size_t.patch
+gregkh-pci-64bit-resource-convert-a-few-remaining-drivers-to-use-resource_size_t-where-needed.patch
+gregkh-pci-64bit-resource-finally-enable-64bit-resource-sizes.patch
+gregkh-pci-i386-export-memory-more-than-4g-through-proc-iomem.patch
-gregkh-pci-pci-legacy-i-o-port-free-driver-changes-to-generic-pci-code.patch
-gregkh-pci-pci-legacy-i-o-port-free-driver-update-documentation-pci_txt.patch
-gregkh-pci-pci-legacy-i-o-port-free-driver-make-intel-e1000-driver-legacy-i-o-port-free.patch
-gregkh-pci-pci-legacy-i-o-port-free-driver-make-emulex-lpfc-driver-legacy-i-o-port-free.patch
-gregkh-pci-pci-64-bit-resources-core-changes.patch
-gregkh-pci-pci-64-bit-resources-drivers-pci-changes.patch
-gregkh-pci-pci-64-bit-resources-drivers-ide-changes.patch
-gregkh-pci-pci-64-bit-resources-drivers-media-changes.patch
-gregkh-pci-pci-64-bit-resources-drivers-net-changes.patch
-gregkh-pci-pci-64-bit-resources-drivers-pcmcia-changes.patch
-gregkh-pci-pci-64-bit-resources-drivers-others-changes.patch
-gregkh-pci-pci-64-bit-resources-sound-changes.patch
-gregkh-pci-pci-64-bit-resources-arch-changes.patch
-gregkh-pci-pci-64-bit-resources-arch-powerpc-changes.patch
-gregkh-pci-pci-64-bit-resources-more-drivers-others-changes.patch
-gregkh-pci-pci-64-bit-resources-more-sound-changes.patch
-gregkh-pci-pci-64-bit-resources-drivers-pci-changes-sparc32-fix.patch
-gregkh-pci-pci-64-bit-resource-fixup-pci-resource-dbg-code-to-handle-size-change.patch
-gregkh-pci-pci-64-bit-resource-fix-amba-build-warning.patch
-gregkh-pci-pci-64-bit-resources-fix-pnp-sysfs-interface.patch
-gregkh-pci-pci-64-bit-resources-arch-powerpc-changes-update.patch
-gregkh-pci-pci-64-bit-resource-drivers-mips-changes.patch
-gregkh-pci-kconfigurable-resources-core-changes.patch
-gregkh-pci-kconfigurable-resources-driver-pci-changes.patch
-gregkh-pci-kconfigurable-resources-driver-others-changes.patch
-gregkh-pci-kconfigurable-resources-arch-dependent-changes.patch
-gregkh-pci-kconfigurable-resources-arch-dependent-changes-arch.patch
-gregkh-pci-kconfigurable-resources-arch-dependent-changes-arch-q-z.patch
-gregkh-pci-i386-export-memory-more-than-4g-through-proc-iomem.patch
-gregkh-pci-pci-msi-abstractions-and-support-for-altix.patch
-gregkh-pci-pci-per-platform-ia64_-first-last-_device_vector-definitions.patch
-gregkh-pci-pci-altix-msi-support.patch
-gregkh-pci-pci-error-handling-on-pci-device-resume.patch
+gregkh-pci-pci-hotplug-don-t-use-acpi_os_free.patch
-gregkh-pci-pci-improve-pci-config-space-writeback.patch
-gregkh-pci-pci-reverse-pci-config-space-restore-order.patch
-gregkh-pci-pci-add-pci_assign_resource_fixed-allow-fixed-address-assignments.patch
-gregkh-pci-pci-add-a-enable-sysfs-attribute-to-the-pci-devices-to-allow-userspace-to-enable-devices-without-doing-foul-direct-access.patch
-gregkh-pci-pci-don-t-enable-device-if-already-enabled.patch
-gregkh-pci-pci-acpi-rename-the-functions-to-avoid-multiple-instances.patch
-gregkh-pci-pci-ignore-pre-set-64-bit-bars-on-32-bit-platforms.patch
-gregkh-pci-pci-i386-x86_84-disable-pci-resource-decode-on-device-disable.patch
-gregkh-pci-pci-bus-parity-status-broken-hardware-attribute-edac-foundation.patch
-gregkh-pci-pci-hotplug-fix-recovery-path-from-errors-during-pcie_init.patch
+gregkh-pci-pci-hotplug-fake-null-pointer-dereferences-in-ibm-hot-plug-controller-driver.patch
+gregkh-pci-pci-hotplug-fix-recovery-path-from-errors-during-pcie_init.patch
+gregkh-pci-pci-add-pci_cap_id_vndr.patch
+gregkh-pci-pci-legacy-i-o-port-free-driver-changes-to-generic-pci-code.patch
+gregkh-pci-pci-legacy-i-o-port-free-driver-update-documentation-pci_txt.patch
+gregkh-pci-pci-legacy-i-o-port-free-driver-make-intel-e1000-driver-legacy-i-o-port-free.patch
+gregkh-pci-pci-legacy-i-o-port-free-driver-make-emulex-lpfc-driver-legacy-i-o-port-free.patch
+gregkh-pci-pci-msi-abstractions-and-support-for-altix.patch
+gregkh-pci-pci-per-platform-ia64_-first-last-_device_vector-definitions.patch
+gregkh-pci-pci-altix-msi-support.patch
+gregkh-pci-pci-ignore-pre-set-64-bit-bars-on-32-bit-platforms.patch
+gregkh-pci-pci-fix-to-pci-ignore-pre-set-64-bit-bars-on-32-bit-platforms.patch
+gregkh-pci-pci-add-pci_assign_resource_fixed-allow-fixed-address-assignments.patch
+gregkh-pci-pci-add-a-enable-sysfs-attribute-to-the-pci-devices-to-allow-userspace-to-enable-devices-without-doing-foul-direct-access.patch
+gregkh-pci-pci-don-t-enable-device-if-already-enabled.patch
+gregkh-pci-pci-acpi-rename-the-functions-to-avoid-multiple-instances.patch
+gregkh-pci-pci-i386-x86_84-disable-pci-resource-decode-on-device-disable.patch
+gregkh-pci-pci-bus-parity-status-broken-hardware-attribute-edac-foundation.patch
-gregkh-pci-pci-hotplug-fake-null-pointer-dereferences-in-ibm-hot-plug-controller-driver.patch
+gregkh-pci-pci-fix-memory-leak-in-mmconfig-error-path.patch
+gregkh-pci-pci-bus-parity-status-sysfs-interface.patch
+gregkh-pci-pci-fix-issues-with-extended-conf-space-when-mmconfig-disabled-because-of-e820.patch
+gregkh-pci-pci-nvidia-quirk-to-make-aer-pci-e-extended-capability-visible.patch

 PCI tree changes.  Some of it was merged, I think.
-mm-gregkh-pci-pci-ignore-pre-set-64-bit-bars-on-32-bit-platforms-fix.patch
+64-bit-resources-lose-some-ifdefs.patch

 Fix it.

+clear-abnormal-poweroff-flag-on-via-southbridges-fix-resume.patch
+clear-abnormal-poweroff-flag-on-via-southbridges-fix-resume-fix.patch

 VIA fix

-git-pcmcia-fixup.patch
-git-pcmcia-fixup-2.patch

 Unneeded

+com20020_cs-more-device-support.patch
+kill-open-coded-offsetof-in-cm4000_csc-zero_dev.patch

 PCMCIA work

-megaraid_sas-switch-fw_outstanding-to-an-atomic_t.patch
-megaraid_sas-add-support-for-zcr-controller.patch
-megaraid_sas-add-support-for-zcr-controller-fix.patch
+megaraid_sas-zcr-with-fix.patch

 Updated patch

+megaraid-dell-cerc-ata100-4ch-support.patch

 megaraid-old device support.

+gregkh-usb-airprime.c-add-kyocera-wireless-kpc650-passport-support.patch
+gregkh-usb-usb-io_edgeport-touch-up.patch
+gregkh-usb-usb-update-usbmon-fix-glued-lines.patch
+gregkh-usb-usb-implement-error-event-in-usbmon.patch
+gregkh-usb-usb-update-usbmontxt.patch
+gregkh-usb-usb-new-driver-for-cypress-cy7c63xxx-mirco-controllers.patch
+gregkh-usb-usb-trivial-debug-message-correction-in-gadget-ether-driver.patch
+gregkh-usb-usb-serial-clean-tty-fields-on-failed-device-open.patch
+gregkh-usb-usb-gadget-serial-fix-a-deadlock-when-closing-the-serial-device.patch
+gregkh-usb-usb-gadget-serial-do-not-save-restore-irq-flags-in-gs_close.patch
+gregkh-usb-usb-gadget-allow-drivers-support-speeds-higher-than-full-speed.patch
+gregkh-usb-usb-gadget-fix-compile-errors.patch
+gregkh-usb-usb-gadget-update-pxa2xx_udc.c-driver-to-fully-support-ixp4xx-platform.patch
+gregkh-usb-usbserial-fixes-wrong-return-values.patch
+gregkh-usb-usb-unusual_devs-entry-for-nokia-n80.patch
+gregkh-usb-usb-whitespace-removal-from-usb-gadget-ether.patch
+gregkh-usb-usb-move-linux-usb_cdc.h-to-linux-usb-cdc.h.patch
+gregkh-usb-usb-move-hardware-specific-linux-usb_-.h-to-linux-usb-.h.patch
+gregkh-usb-usb-move-linux-usb_input.h-to-linux-usb-input.h.patch
+gregkh-usb-usb-endpoint.patch
+gregkh-usb-usb-endpoint-pass-struct-device.patch
+gregkh-usb-usb-endpoint-mess.patch
+gregkh-usb-usb-devio-class-to-device.patch
+gregkh-usb-usb-class-device-to-device.patch
+gregkh-usb-usb-dynamic-usb-class.patch

 USB tree updates

+usb-move-linux-usb_input.h-to-linux-usb-input-fix.patch
+ehci-fix-bogus-alteration-of-a-local-variable.patch
+ipaqc-bugfixes.patch
+ipaqc-timing-parameters.patch
+ipaqc-timing-parameters-fix.patch

 USB things

+x86_64-mm-twofish-cipher---split-out-common-c-code.patch
+x86_64-mm-twofish-cipher---priority-fix.patch
+x86_64-mm-twofish-cipher---i586-assembler.patch
+x86_64-mm-twofish-cipher---x86_64-assembler.patch
+x86_64-mm-unify-cpu-boottime-output.patch

 x86_64 tree udpates

+revert-x86_64-mm-twofish-cipher---x86_64-assembler.patch
+revert-x86_64-mm-twofish-cipher---i586-assembler.patch
+revert-x86_64-mm-twofish-cipher---priority-fix.patch
+revert-x86_64-mm-twofish-cipher---split-out-common-c-code.patch

 Drop most of it again.

+xfs-remove-dir-check-in-xfs_link.patch
+xfs-use-container_of-in-vn_from_inode.patch
+xfs-pass-inode-to-xfs_ioc_space.patch
+xfs-remove-unused-behaviour-lock.patch

 XFS fixlets

-zone-init-check-and-report-unaligned-zone-boundaries.patch
-x86-align-highmem-zone-boundaries-with-numa.patch
-zone-allow-unaligned-zone-boundaries.patch
-zone-allow-unaligned-zone-boundaries-x86-add-zone-alignment-qualifier.patch
+zone-handle-unaligned-zone-boundaries.patch

 Updated patch

+pgdat-allocation-for-new-node-add-export-kswapd-start-func-fix.patch

 Fix pgdat-allocation-for-new-node-add-export-kswapd-start-func.patch

+add-page_mkwrite-vm_operations-method-fix.patch

 Fix add-page_mkwrite-vm_operations-method.patch

+slab-kmalloc-kzalloc-comments-cleanup-and-fix.patch
+kernel-doc-for-mm-filemapc.patch
+delete-unused-definitions-of-kvaddr_to_nid.patch
+printk-should-not-be-called-under-zone-lock.patch

 MM things

-page-migration-simplify-migrate_pages-tweaks.patch

 Foded into page-migration-simplify-migrate_pages.patch

-page-migration-detailed-status-for-moving-of-individual-pages.patch
-page-migration-support-moving-of-individual-pages-fixes.patch

 Folded into page-migration-support-moving-of-individual-pages.patch

-page-migration-support-moving-of-individual-pages-x86-support-fix.patch

 Folded into page-migration-support-moving-of-individual-pages-x86-support.patch

+radix-tree-rcu-lockless-readside.patch
+radix-tree-rcu-lockless-readside-wraning-fix.patch
+radix-tree-rcu-lockless-readside-fix.patch

 radix-tree work.

-zoned-vm-counters-per-zone-counter-functionality.patch
-zoned-vm-counters-per-zone-counter-functionality-tidy.patch
-zoned-vm-counters-per-zone-counter-functionality-fix.patch
-zoned-vm-counters-per-zone-counter-functionality-fix-fix.patch
-zoned-vm-counters-include-per-zone-counters-in-proc-vmstat.patch
-zoned-vm-counters-conversion-of-nr_mapped-to-per-zone-counter.patch
-zoned-vm-counters-conversion-of-nr_pagecache-to-per-zone-counter.patch
-zoned-vm-counters-conversion-of-nr_pagecache-to-per-zone-counter-fix.patch
-zoned-vm-counters-use-per-zone-counters-to-remove-zone_reclaim_interval.patch
-zoned-vm-counters-add-per-zone-counters-to-zone-node-and-global-vm-statistics.patch
-zoned-vm-counters-conversion-of-nr_slab-to-per-zone-counter.patch
-zoned-vm-counters-conversion-of-nr_pagetable-to-per-zone-counter.patch
-zoned-vm-counters-conversion-of-nr_dirty-to-per-zone-counter.patch
-zoned-vm-counters-conversion-of-nr_writeback-to-per-zone-counter.patch
-zoned-vm-counters-conversion-of-nr_unstable-to-per-zone-counter.patch
-zoned-vm-counters-remove-unused-get_page_stat-functions.patch
-zoned-vm-counters-conversion-of-nr_bounce-to-per-zone-counter.patch
-zoned-vm-counters-remove-useless-writeback-structure.patch
-zoned-vm-stats-remove-nr_mapped-from-zone-reclaim.patch
-zoned-vm-stats-add-nr_anon.patch
-light-weight-counters-framework.patch
-light-weight-counters-framework-warning-fixes.patch
-light-weight-counters-framework-fix.patch
-light-weight-counters-framework-s390-fix.patch
-light-weight-counters-framework-s390-fix-fix.patch
-light-weight-counters-framework-s390-fix-fix-fix.patch
-light-weight-counters-framework-arm-fix.patch
-light-weight-counters-framework-uml-fix.patch

 Dropped.

+selinux-add-security-hooks-to-getsetaffinity.patch
+selinux-add-security-hook-call-to-mediate-attach_task.patch

 Wire up SELinux hooks.

+frv-__user-infrastructure.patch
+frv-basic-__iomem-annotations.patch
+frv-signal-annotations.patch
+frv-sysctl-__user-annotations.patch
+frv-binfmt_elf_fdpic-__user-annotations.patch
+frv-misc-__user-annotations.patch
+frv-misc-sparse-annotations.patch
+frv-wrong-syscall.patch
+ext2-xip-wont-build-without-mmu.patch
+frv-initrd-is-grossly-broken-on-frv-never-built.patch
+frv-null-noise-removal-in-frv-xchg.patch
+frv-ieee1394-is-borken-on-frv.patch
+frv-add-missing-qualifier-to-memcpy_fromio-prototype.patch
+frv-trivial-cleanups-in-frv_ksymsc.patch
+frv-clean-frv-unistdh.patch

 FRV updates

+i386-use-c-code-for-current_thread_info.patch
+i386-extra-checks-in-show_registers.patch
+via-c7-cpu-flags.patch
+x86-compile-fix-for-asm-i386-alternativesh.patch
+clean-up-and-refactor-i386-sub-architecture-setup.patch

 x86 updates

+move-do_suspend_lowlevel-to-correct-segment.patch

 suspend fix

+m68k-typo-fix.patch
+m68k-trapsc-constraints.patch
+m68k-windfarm-is-powerpc-only-dont-do-it-on-m68k-macs.patch

 m68k updates

+s390-move-var-declarations-behind-ifdef.patch

 s390 fix

+ufs-missed-brelse-and-wrong-baseblk.patch
+ufs-one-way-to-access-super-block.patch
+ufs-fsync-implementation.patch
+ufs-make-fsck-f-happy.patch
+ufs-ubh_ll_rw_block-cleanup.patch

 More ufs fixes

+readahead-backoff-on-i-o-error.patch
+readahead-backoff-on-i-o-error-tweaks.patch
+rcu-documentation-self-limiting-updates-and-call_rcu.patch
+link-error-when-futexes-are-disabled-on-64bit-architectures.patch
+cyclades-cleanup.patch
+cyclades-cleanup-cleanup.patch
+cleanup-char-espc.patch
+autofs4-need-to-invalidate-children-on-tree-mount-expire.patch
+update-contact-information-in-credits.patch
+more-tty-cleanups-in-drivers-char.patch
+another-couple-of-alterations-to-the-memory-barrier-doc.patch
+fuse-use-misc_major.patch
+fuse-no-backgrounding-on-interrupt.patch
+fuse-add-control-filesystem.patch
+fuse-add-control-filesystem-printk-fix.patch
+fuse-add-posix-file-locking-support.patch
+fuse-ensure-flush-reaches-userspace.patch
+fuse-rename-the-interrupted-flag.patch
+fuse-add-request-interruption.patch
+mark-profile-notifier-blocks-__read_mostly.patch
+kernel-doc-warn-on-malformed-function-docs.patch
+ide-floppy-fix-debug-only-syntax-error.patch
+remove-needless-checks-in-fs-9p-vfs_inodec.patch
+kernel-doc-for-lib-bitmapc.patch
+kernel-doc-for-lib-cmdlinec.patch
+kernel-doc-for-lib-crcc.patch
+kthread-update-loopc-to-use-kthread.patch
+kthread-update-loopc-to-use-kthread-fix.patch
+kthread-convert-lock-to-use-kthread.patch
+kthread-convert-smbiod.patch
+kthread-convert-smbiod-tidy.patch
+kthread-convert-s390machc-from-kernel_thread.patch
+initramfs-docs-update.patch
+cciss-disable-device-when-returning-failure.patch
+cciss-request-all-pci-resources.patch
+cciss-announce-cciss%d-devices-with-pci-address-irq-dac-info.patch
+cciss-use-array_size-without-intermediates.patch
+cciss-fix-a-few-spelling-errors.patch
+cciss-remove-parens-around-return-values.patch
+cciss-run-through-lindent.patch
+cciss-tidy-up-product-table-indentation.patch
+i-force-joystick-remove-some-pointless-casts.patch
+affs_fill_super-%s-abuses-2.patch
+kthread-convert-stop_machine-into-a-kthread.patch
+fs-sys_poll-with-timeout-1-bug-fix.patch
+cpu-hotplug-fix-cpu_up_cancel-handling.patch
+add-select-gpio_vr41xx-for-tanbac_tb0229.patch
+#let-even-non-dumpable-tasks-access-proc-self-fd.patch
+#enable-oprofile-on-pentium-d.patch: Andi had issues
+enable-oprofile-on-pentium-d.patch
+implement-at_symlink_follow-flag-for-linkat.patch
+fix-memory-leak-in-rocketport-rp_do_receive.patch
+kernel-doc-dont-use-xml-escapes-in-text-or-man-output.patch
+kernel-doc-use-members-for-struct-fields-consistently.patch
+reed-solomon-fix-kernel-doc-comments.patch
+ktime-hrtimer-fix-kernel-doc-comments.patch
+stop-on-cpu-lost.patch
+stop-on-cpu-lost-tidy.patch
+led-add-led-heartbeat-trigger.patch
+fix-bounds-check-in-vsnprintf-to-allow-for-a-0-size-and.patch
+fix-bounds-check-in-vsnprintf-to-allow-for-a-0-size-and-tidy.patch
+implement-kasprintf.patch
+dmi-cleanup-kernel-doc-add-to-docbook.patch
+kthread-move-kernel-doc-and-put-it-into-docbook.patch
+irda-usb-printk-fix.patch
+autofs4-needs-to-force-fail-return-revalidate.patch

 Misc patches.

+keys-sort-out-key-quota-system.patch
+keys-discard-the-contents-of-a-key-on-revocation.patch
+keys-let-keyctl_chown-change-a-keys-owner.patch
+keys-allocate-key-serial-numbers-randomly.patch
+keys-restrict-contents-of-proc-keys-to-viewable-keys.patch
+keys-add-a-way-to-store-the-appropriate-context-for-newly-created-keys.patch

 Key management API updates

+reiserfs-remove-reiserfs_aio_write.patch
+reiserfs-fix-is_reusable-bitmap-check-to-not-traverse-the-bitmap-info-array.patch
+reiserfs-clean-up-bitmap-block-buffer-head-references.patch
+reiserfs-reorganize-bitmap-loading-functions.patch
+reiserfs-on-demand-bitmap-loading.patch
+reiserfs-on-demand-bitmap-loading-fix.patch
+reiserfs-use-generic_file_open-for-open-checks.patch

 reiser3 updates

+per-task-delay-accounting-taskstats-interface-fix-exit-race-in-per-task-delay-accounting.patch

 per-task delay accounting fix

+add-bcm43xx-hw-rng-support-locking-update.patch

 Fix add-bcm43xx-hw-rng-support.patch

+chardev-gpio-for-scx200-pc-8736x-whitespace.patch
+chardev-gpio-for-scx200-pc-8736x-modernize.patch
+chardev-gpio-for-scx200-pc-8736x-add-platforn_device.patch
+chardev-gpio-for-scx200-pc-8736x-device-minor.patch
+chardev-gpio-for-scx200-pc-8736x-put-gpio_dump.patch
+chardev-gpio-for-scx200-pc-8736x-add-v-command.patch
+chardev-gpio-for-scx200-pc-8736x-refactor-scx200_probe.patch
+chardev-gpio-for-scx200-pc-8736x-add-gpio-ops.patch
+chardev-gpio-for-scx200-pc-8736x-dispatch.patch
+chardev-gpio-for-scx200-pc-8736x-add-empty.patch
+chardev-gpio-for-scx200-pc-8736x-migrate-file-ops.patch
+chardev-gpio-for-scx200-pc-8736x-migrate-gpio_dump.patch
+chardev-gpio-for-scx200-pc-8736x-add-new-pc8736x_gpio.patch
+chardev-gpio-for-scx200-pc-8736x-add-platform_device.patch
+chardev-gpio-for-scx200-pc-8736x-use-dev_dbg.patch
+chardev-gpio-for-scx200-pc-8736x-fix-gpio_current.patch
+chardev-gpio-for-scx200-pc-8736x-replace-spinlocks.patch
+chardev-gpio-for-scx200-pc-8736x-display-pin.patch
+chardev-gpio-for-scx200-pc-8736x-add-proper.patch

 GPIO driver framework.

+isdn4linux-gigaset-base-driver-improve-error-recovery.patch
+isdn4linux-gigaset-driver-cleanup.patch
+i4l-gigaset-drivers-add-ioctls-to-compat_ioctlh.patch

 i4l driver updates

-mm-implement-swap-prefetching-fix.patch
-mm-implement-swap-prefetching-sched-batch.patch
-swap-prefetch-fix-lru_cache_add_tail.patch
-swap-prefetch-fix-lru_cache_add_tail-tidy.patch
-mm-swap-prefetch-fix-lowmem-reserve-calc.patch

 Folded into mm-implement-swap-prefetching.patch

-swap_prefetch-conversion-of-nr_mapped-to-per-zone-counter.patch
-swap_prefetch-conversion-of-nr_slab-to-per-zone-counter.patch
-swap_prefetch-conversion-of-nr_dirty-to-per-zone-counter.patch
-swap_prefetch-conversion-of-nr_writeback-to-per-zone-counter.patch
-swap_prefetch-conversion-of-nr_unstable-to-per-zone-counter.patch
-swap_prefetch-remove-unused-get_page_stat-functions.patch
-zoned-vm-stats-nr_slab-is-accurate-fix-comment.patch
-swap_prefetch-zoned-vm-stats-add-nr_anon.patch

 Dropped.

+pi-futex-futex_lock_pi-futex_unlock_pi-support-fix.patch

 Fix pi-futex-futex_lock_pi-futex_unlock_pi-support.patch

+ecryptfs-dont-muck-with-the-existing-nameidata-structures.patch
+ecryptfs-asm-scatterlisth-linux-scatterlisth.patch
+ecryptfs-support-for-larger-maximum-key-size.patch
+ecryptfs-add-codes-for-additional-ciphers.patch
+ecryptfs-unencrypted-key-size-based-on-encrypted-key-size.patch
+ecryptfs-packet-and-key-management-update-for-variable-key-size.patch
+ecryptfs-add-ecryptfs_-prefix-to-mount-options-key-size-parameter.patch
+ecryptfs-set-the-key-size-from-the-default-for-the-mount.patch
+ecryptfs-check-for-weak-keys.patch
+ecryptfs-add-define-values-for-cipher-codes-from-rfc2440-openpgp.patch
+ecryptfs-convert-bits-to-bytes.patch
+ecryptfs-more-elegant-aes-key-size-manipulation.patch
+ecryptfs-more-elegant-aes-key-size-manipulation-tidy.patch
+ecryptfs-more-intelligent-use-of-tfm-objects.patch

 ecryptfs updates

+ipc-namespace-core-unshare-fix.patch
+ipc-namespace-utils-compilation-fix.patch

 Update IPC namespace patches in -mm.

+task-watchers-task-watchers.patch
+task-watchers-task-watchers-tidy.patch
+task-watchers-register-process-events-task-watcher.patch
+task-watchers-refactor-process-events.patch
+task-watchers-make-process-events-configurable-as.patch
+task-watchers-allow-task-watchers-to-block.patch
+task-watchers-register-audit-task-watcher.patch
+task-watchers-register-per-task-delay-accounting.patch
+task-watchers-register-profile-as-a-task-watcher.patch
+task-watchers-add-support-for-per-task-watchers.patch
+task-watchers-add-support-for-per-task-watchers-warning-fix.patch
+task-watchers-register-semundo-task-watcher.patch
+task-watchers-register-per-task-semundo-watcher.patch

 API for registering against task lifecycle events.

+ipc-replace-kmalloc-and-memset-in-get_undo_list-with-kzalloc.patch

 Cleanup

-readahead-backoff-on-i-o-error.patch

 Dropped.

-reiser4-conversion-of-nr_dirty-to-per-zone-counter.patch

 Dropped.

+hpt370-clean-up-dma-timeout-handling.patch
+hpt370-clean-up-dma-timeout-handling-cleanup.patch
+pdc202xx_old-depends-on-config_blk_dev_idedma.patch
+remove-code-that-has-long-been-commented-out-from-pdc20265_old.patch
+enable-cdrom-dma-access-with-pdc20265_old.patch
+ide-fix-revision-comparison-in-ide_in_drive_list.patch

 IDE updates

+fbdev-fix-logo-rotation-if-width-=-height.patch
+macmodes-fix-section-warning.patch
+atyfb-fix-section-warnings.patch

 fbdev updates

-vt-binding-add-sysfs-support.patch

 Dropped.

+vt-binding-add-sysfs-control-to-the-vt-layer.patch
+vt-binding-add-sysfs-control-to-the-vt-layer-fix.patch
+vt-binding-make-vt-binding-a-kconfig-option.patch
+vt-binding-do-not-create-a-device-file-for-class-device.patch
+vt-binding-update-documentation.patch
+vt-binding-make-mdacon-support-binding.patch
+vt-binding-make-newport_con-support-binding.patch
+vt-binding-make-promcon-support-binding.patch
+vt-binding-make-sticon-support-binding.patch

 VT binding updates

+statistics-infrastructure-update-4.patch
+statistics-infrastructure-update-5.patch

 Update statistics patches in -mm.

+genirq-rename-desc-handler-to-desc-chip-terminate_irqs-fix.patch
+genirq-allow-usage-of-no_irq_chip.patch
+genirq-ia64-build-fix.patch

 genirq fixes

+lock-validator-core-provide-lockdep_off-lockdep_on-apis.patch
+lock-validator-core-provide-lockdep_reinit_key-api.patch
+lock-validator-core-print-info-not-bug.patch
+lock-validator-special-locking-af_unix-undo-af_unix-_bh-locking-changes-and-split-lock-type.patch
+lock-validator-special-locking-af_unix-undo-af_unix-_bh-locking-changes-and-split-lock-type-fix.patch
+lock-validator-annotate-ntfs-locking-rules.patch
+lock-validator-s390-stacktrace-interface.patch
+lock-validator-s390-config_frame_pointer-support.patch
+lock-validator-s390-rwsem-semaphore-changes.patch
+lock-validator-early_init_irq_lock_type--console_init.patch
+lock-validator-s390-irqtrace-support.patch
+lock-validator-__local_bh_enable-_local_bh_enable.patch
+lock-validator-s390-use-raw_spinlock-in-mcck-handler.patch
+lock-validator-add-s390-to-supported-options.patch
+lockdep-avoid-false-positive-illegal-lock-usage-message-in-qeth-driver.patch
+lockdep-hack-around-build-errors.patch

 lockdep fixes

-acpi-identify-which-device-is-not-power-manageable-fix.patch

 Folded into acpi-identify-which-device-is-not-power-manageable.patch



All 1738 patches:

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

Re: 2.6.17-mm1

[Michal Piotrowski]

Hi,

On 21/06/06, Andrew Morton <akpm@osdl.org> wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm1/
>
>
> - powerpc is bust (on g5, at least).  git-klibc is causing nash to fail on
>   startup and some later patch is causing a big crash (I didn't bisect that
>   one - later).
>
> - ia64 doesn't compile for me, due to git-klibc problems (a truly ancient
>   toolchain might be implicated).
>

I have the similar problem here

usr/klibc/syscalls/typesize.c:1:23: error: syscommon.h: No such file
or directory
usr/klibc/syscalls/typesize.c:5: error: '__u32' undeclared here (not
in a function)
usr/klibc/syscalls/typesize.c:9: error: expected ')' before 'gid_t'
usr/klibc/syscalls/typesize.c:9: warning: type defaults to 'int' in
declaration of 'type name'
usr/klibc/syscalls/typesize.c:10: error: expected ')' before 'sigset_t'
usr/klibc/syscalls/typesize.c:10: warning: type defaults to 'int' in
declaration of 'type name'
usr/klibc/syscalls/typesize.c:21: error: 'dev_t' undeclared here (not
in a function)
usr/klibc/syscalls/typesize.c:22: error: 'fd_set' undeclared here (not
in a function)
usr/klibc/syscalls/typesize.c:22: error: expected expression before ')' token
make[4]: *** [usr/klibc/syscalls/typesize.o] Error 1
make[3]: *** [usr/klibc/syscalls] Error 2
make[2]: *** [_usr_klibc] Error 2
make[1]: *** [usr] Error 2
make: *** [_all] Error 2

Linux ltg01-fedora.pl 2.6.17-g25f42b6a #63 SMP PREEMPT Tue Jun 20
14:28:14 CEST 2006 i686 i686 i386 GNU/Linux

Gnu C                  4.1.1
Gnu make               3.80
binutils               2.16.91.0.6
util-linux             2.13-pre7
mount                  2.13-pre7
module-init-tools      3.2.2
e2fsprogs              1.38
jfsutils               1.1.10
reiserfsprogs          3.6.19
xfsprogs               2.7.3
PPP                    2.4.3
Linux C Library        > libc.2.4
Dynamic linker (ldd)   2.4
Procps                 3.2.6
Net-tools              1.60
Kbd                    1.12
Sh-utils               5.96
udev                   084

Regards,
Michal

-- 
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)

Re: 2.6.17-mm1

[Andrew Morton]

On Wed, 21 Jun 2006 13:07:41 +0200
"Michal Piotrowski" <michal.k.k.piotrowski@gmail.com> wrote:

> On 21/06/06, Andrew Morton <akpm@osdl.org> wrote:
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm1/
> >
> >
> > - powerpc is bust (on g5, at least).  git-klibc is causing nash to fail on
> >   startup and some later patch is causing a big crash (I didn't bisect that
> >   one - later).
> >
> > - ia64 doesn't compile for me, due to git-klibc problems (a truly ancient
> >   toolchain might be implicated).
> >
> 
> I have the similar problem here
> 
> usr/klibc/syscalls/typesize.c:1:23: error: syscommon.h: No such file
> or directory

That one's probably just a parallel kbuild race.  Type `make' again.

Re: 2.6.17-mm1

[Andrew Morton]

On Wed, 21 Jun 2006 03:48:57 -0700
Andrew Morton <akpm@osdl.org> wrote:

> - ia64 doesn't compile for me, due to git-klibc problems (a truly ancient
>   toolchain might be implicated).

Actually I did do a full ia64 allmodconfig build on a recent distro.  So
it's "broken on RHAS 2.1".

Re: 2.6.17-mm1

[Michal Piotrowski]

On 21/06/06, Andrew Morton <akpm@osdl.org> wrote:
> On Wed, 21 Jun 2006 13:07:41 +0200
> "Michal Piotrowski" <michal.k.k.piotrowski@gmail.com> wrote:
>
> > On 21/06/06, Andrew Morton <akpm@osdl.org> wrote:
> > >
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm1/
> > >
> > >
> > > - powerpc is bust (on g5, at least).  git-klibc is causing nash to fail on
> > >   startup and some later patch is causing a big crash (I didn't bisect that
> > >   one - later).
> > >
> > > - ia64 doesn't compile for me, due to git-klibc problems (a truly ancient
> > >   toolchain might be implicated).
> > >
> >
> > I have the similar problem here
> >
> > usr/klibc/syscalls/typesize.c:1:23: error: syscommon.h: No such file
> > or directory
>
> That one's probably just a parallel kbuild race.  Type `make' again.
>

"make O=/dir" is culprit.

Regards,
Michal

-- 
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)

Re: 2.6.17-mm1

[Michal Piotrowski]

Hi,

On 21/06/06, Andrew Morton <akpm@osdl.org> wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm1/
>

It looks like an ACPI problem.

Setting up standard PCI resources
=============================================
[ INFO: possible recursive locking detected ]
---------------------------------------------
idle/1 is trying to acquire lock:
 (lock_ptr){....}, at: [<c021cbd2>] acpi_os_acquire_lock+0x8/0xa

but task is already holding lock:
 (lock_ptr){....}, at: [<c021cbd2>] acpi_os_acquire_lock+0x8/0xa

other info that might help us debug this:
1 lock held by idle/1:
 #0:  (lock_ptr){....}, at: [<c021cbd2>] acpi_os_acquire_lock+0x8/0xa

stack backtrace:
 [<c0103e89>] show_trace+0xd/0x10
 [<c0104483>] dump_stack+0x19/0x1b
 [<c01395fa>] __lock_acquire+0x7d9/0xa50
 [<c0139a98>] lock_acquire+0x71/0x91
 [<c02f0beb>] _spin_lock_irqsave+0x2c/0x3c
 [<c021cbd2>] acpi_os_acquire_lock+0x8/0xa
 [<c0222d95>] acpi_ev_gpe_detect+0x4d/0x10e
 [<c02215c3>] acpi_ev_sci_xrupt_handler+0x15/0x1d
 [<c021c8b1>] acpi_irq+0xe/0x18
 [<c014d36e>] request_irq+0xbe/0x10c
 [<c021cf33>] acpi_os_install_interrupt_handler+0x59/0x87
 [<c02215e7>] acpi_ev_install_sci_handler+0x1c/0x21
 [<c0220d41>] acpi_ev_install_xrupt_handlers+0x9/0x50
 [<c0231772>] acpi_enable_subsystem+0x7d/0x9a
 [<c0416656>] acpi_init+0x3f/0x170
 [<c01003ae>] _stext+0x116/0x26c
 [<c0101005>] kernel_thread_helper+0x5/0xb
ACPI: Interpreter enabled

Here is a dmesg log http://www.stardust.webpages.pl/files/mm/2.6.17-mm1/mm-dmesg
Here is a config file
http://www.stardust.webpages.pl/files/mm/2.6.17-mm1/mm-config

Regards,
Michal

-- 
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)

Re: 2.6.17-mm1

[Cedric Le Goater]

[-- Attachment #1: Type: text/plain, Size: 324 bytes --]

Michal Piotrowski wrote:

>> > usr/klibc/syscalls/typesize.c:1:23: error: syscommon.h: No such file
>> > or directory
>>
>> That one's probably just a parallel kbuild race.  Type `make' again.
>>
> 
> "make O=/dir" is culprit.
> 
> Regards,
> Michal
> 

That's how i fixed it. Is that the right way to do it ?

Thanks,

C.


[-- Attachment #2: klibc-fix-kbuild-output-issue.patch --]
[-- Type: text/x-patch, Size: 917 bytes --]

From: Cedric Le Goater <clg@fr.ibm.com>
Subject: [KLIBC] fix compile issue when KBUILD_OUTPUT is used

Signed-off-by: Cedric Le Goater <clg@fr.ibm.com>

---
 scripts/Kbuild.klibc |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: 2.6.17-mm1/scripts/Kbuild.klibc
===================================================================
--- 2.6.17-mm1.orig/scripts/Kbuild.klibc
+++ 2.6.17-mm1/scripts/Kbuild.klibc
@@ -85,7 +85,7 @@ KLIBCCPPFLAGS    := -I$(KLIBCINC)/arch/$
 # kernel include paths
 KLIBCKERNELSRC	 ?= $(srctree)/
 KLIBCCPPFLAGS    += -I$(KLIBCKERNELSRC)include		\
-                     $(if $(KBUILD_SRC),-I$(KLIBCKERNELOBJ)include2 -I$(KLIBCKERNELOBJ)include -I$(srctree)/include)    \
+                     $(if $(KBUILD_SRC),-I$(KLIBCKERNELOBJ)include2 -I$(KLIBCKERNELOBJ)include -I$(srctree)/include -I$(srctree)/usr/klibc/syscalls)    \
 		     $(KLIBCARCHINCFLAGS)
 
 # klibc definitions

Re: 2.6.17-mm1

[Michal Piotrowski]

Hi Cedric,

On 21/06/06, Cedric Le Goater <clg@fr.ibm.com> wrote:
> Michal Piotrowski wrote:
>
> >> > usr/klibc/syscalls/typesize.c:1:23: error: syscommon.h: No such file
> >> > or directory
> >>
> >> That one's probably just a parallel kbuild race.  Type `make' again.
> >>
> >
> > "make O=/dir" is culprit.
> >
> > Regards,
> > Michal
> >
>
> That's how i fixed it.

Problem fixed, thanks.

> Is that the right way to do it ?
>
> Thanks,
>
> C.
>

Regards,
Michal

-- 
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)

[-mm patch] drivers/net/ni5010.c: fix compile error

[Adrian Bunk]

On Wed, Jun 21, 2006 at 03:48:57AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.17-rc6-mm2:
>...
> +ni5010-netcard-cleanup.patch
> 
>  netdev cleanup
>...

This patch fixes the following compile error with CONFIG_NI5010=y:

<--  snip  -->

...
  LD      .tmp_vmlinux1
drivers/built-in.o:(.init.data+0x2b280): undefined reference to `ni5010_probe'
make: *** [.tmp_vmlinux1] Error 1

<--  snip  -->

Signed-off-by: Adrian Bunk <bunk@stusta.de>

--- linux-2.6.17-mm1-full/drivers/net/ni5010.c.old	2006-06-21 16:21:26.000000000 +0200
+++ linux-2.6.17-mm1-full/drivers/net/ni5010.c	2006-06-21 16:21:46.000000000 +0200
@@ -117,7 +117,7 @@
 static int io;
 static int irq;
 
-static struct net_device * __init ni5010_probe(int unit)
+struct net_device * __init ni5010_probe(int unit)
 {
 	struct net_device *dev = alloc_etherdev(sizeof(struct ni5010_local));
 	int *port;

Re: 2.6.17-mm1

[Christoph Lameter]

On Wed, 21 Jun 2006, Andrew Morton wrote:

> On Wed, 21 Jun 2006 03:48:57 -0700
> Andrew Morton <akpm@osdl.org> wrote:
> 
> > - ia64 doesn't compile for me, due to git-klibc problems (a truly ancient
> >   toolchain might be implicated).
> 
> Actually I did do a full ia64 allmodconfig build on a recent distro.  So
> it's "broken on RHAS 2.1".

Builds fine on SLES9.

Re: 2.6.17-mm1

[H. Peter Anvin]

[-- Attachment #1: Type: text/plain, Size: 448 bytes --]

Cedric Le Goater wrote:
> Michal Piotrowski wrote:
> 
>>>> usr/klibc/syscalls/typesize.c:1:23: error: syscommon.h: No such file
>>>> or directory
>>> That one's probably just a parallel kbuild race.  Type `make' again.
>>>
>> "make O=/dir" is culprit.
>>
>> Regards,
>> Michal
>>
> 
> That's how i fixed it. Is that the right way to do it ?
> 

Probably not.  I suspect what's needed is the same EXTRA_KLIBCCFLAGS as 
in socketcalls/Kbuild.

	-hpa

[-- Attachment #2: diff --]
[-- Type: text/plain, Size: 424 bytes --]

diff --git a/usr/klibc/syscalls/Kbuild b/usr/klibc/syscalls/Kbuild
index debcd16..e7ae1d2 100644
--- a/usr/klibc/syscalls/Kbuild
+++ b/usr/klibc/syscalls/Kbuild
@@ -28,6 +28,8 @@ clean-files += $(KLIBCINC)/klibc/havesys
 # All the syscall stubs
 clean-files += *.o *.S *.c *.list *.bin
 
+EXTRA_KLIBCCFLAGS := -I$(srctree)/$(src)
+
 quiet_cmd_makelist = LIST    $@
       cmd_makelist = echo '$(filter-out FORCE,$^)' > $@
 

[PATCH] pi-futex-rt-mutex-core-merge.patch (was Re: 2.6.17-mm1

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 764 bytes --]

On Wed, 21 Jun 2006 03:48:57 PDT, Andrew Morton said:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm1/

pi-futex-rt-mutex-core.patch has what looks like a merge error in it.

Patch to clean it up attached.

Signed-off-by: Valdis Kletnieks <valdis.kletnieks@vt.edu>

--- linux-2.6.17-mm1/include/linux/sysctl.h.fix1	2006-06-21 13:24:32.000000000 -0400
+++ linux-2.6.17-mm1/include/linux/sysctl.h	2006-06-21 14:16:46.000000000 -0400
@@ -153,7 +153,7 @@ enum
 	KERN_NMI_WATCHDOG=74, /* int: enable/disable nmi watchdog */
 	KERN_PANIC_ON_NMI=75, /* int: whether we will panic on an unrecovered */
 	KERN_STOP_ON_CPU_LOST=76, /* int: SIGSTOP when a task losts its cpus */
-	KERN_MAX_LOCK_DEPTH=76,
+	KERN_MAX_LOCK_DEPTH=77,
 };
 
 



[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: 2.6.17-mm1

[Cedric Le Goater]

H. Peter Anvin wrote:

>> That's how i fixed it. Is that the right way to do it ?
> 
> Probably not.  I suspect what's needed is the same EXTRA_KLIBCCFLAGS as
> in socketcalls/Kbuild.

it works fine.

thanks !

C.

Re: 2.6.17-mm1

[Michal Piotrowski]

Hi Peter,

On 21/06/06, H. Peter Anvin <hpa@zytor.com> wrote:
> Cedric Le Goater wrote:
> > Michal Piotrowski wrote:
> >
> >>>> usr/klibc/syscalls/typesize.c:1:23: error: syscommon.h: No such file
> >>>> or directory
> >>> That one's probably just a parallel kbuild race.  Type `make' again.
> >>>
> >> "make O=/dir" is culprit.
> >>
> >> Regards,
> >> Michal
> >>
> >
> > That's how i fixed it. Is that the right way to do it ?
> >
>
> Probably not.  I suspect what's needed is the same EXTRA_KLIBCCFLAGS as
> in socketcalls/Kbuild.

Thanks for fixing that.

>
>         -hpa
>
>

Regards,
Michal

-- 
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)

swsusp regression [Was: 2.6.17-mm1]

[Jiri Slaby]

Andrew Morton napsal(a):
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm1/

[32512.214000] Suspending device usbdev3.2_ep81
[32512.214040] Suspending device 3-2:1.0
[32512.214081] wacom 3-2:1.0: no suspend for driver wacom?
[32512.214128] Suspending device usbdev3.2_ep00
[32512.214169] Suspending device 3-2
[32512.214209] suspend_device(): usb_generic_suspend+0x0/0x128() returns -16
[32512.214319] Could not suspend device 3-2: error -16
[32512.214361] wacom 3-2:1.0: no resume for driver wacom?
[32512.242552] Some devices failed to suspend

Bus 003 Device 002: ID 056a:0011 Wacom Co., Ltd Graphire 2

Wacom messages are not new, but it now causes not suspending.

2.6.17-rc6-mm2 was OK.

Is there any more info needed?

-- 
Jiri Slaby         www.fi.muni.cz/~xslaby
\_.-^-._   jirislaby@gmail.com   _.-^-._/
B67499670407CE62ACC8 22A032CC55C339D47A7E

[-mm patch] drivers/acpi/scan.c: make acpi_bus_type static

[Adrian Bunk]

On Wed, Jun 21, 2006 at 03:48:57AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.17-rc6-mm2:
>...
>  git-acpi.patch
>...
>  git trees
>...

This patch makes the needlessly global acpi_bus_type static.

I'd also suggest to rename this struct, since although it's named 
acpi_bus_type, it's of type "struct bus_type",
not "struct acpi_bus_type" as defined in include/acpi/acpi_bus.h .

Signed-off-by: Adrian Bunk <bunk@stusta.de>

--- linux-2.6.17-mm1-full/drivers/acpi/scan.c.old	2006-06-21 22:35:30.000000000 +0200
+++ linux-2.6.17-mm1-full/drivers/acpi/scan.c	2006-06-21 22:35:40.000000000 +0200
@@ -1450,7 +1450,7 @@
 }
 
 
-struct bus_type acpi_bus_type = {
+static struct bus_type acpi_bus_type = {
 	.name		= "acpi",
 	.suspend	= acpi_device_suspend,
 	.resume		= acpi_device_resume,

[-mm patch] drivers/ide/legacy/ide-cs.c: make 2 functions static

[Adrian Bunk]

On Wed, Jun 21, 2006 at 03:48:57AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.17-rc6-mm2:
>...
>  git-pcmcia.patch
>...
>  git trees
>...

This patch makes two needlessly global functions static.
 
Signed-off-by: Adrian Bunk <bunk@stusta.de>

---

 drivers/ide/legacy/ide-cs.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- linux-2.6.17-mm1-full/drivers/ide/legacy/ide-cs.c.old	2006-06-21 22:54:20.000000000 +0200
+++ linux-2.6.17-mm1-full/drivers/ide/legacy/ide-cs.c	2006-06-21 22:54:37.000000000 +0200
@@ -170,11 +170,11 @@
         return ide_register_hw_with_fixup(&hw, NULL, ide_undecoded_slave);
 }
 
-void outb_io(unsigned char value, unsigned long port) {
+static void outb_io(unsigned char value, unsigned long port) {
 	outb(value, port);
 }
 
-void outb_mem(unsigned char value, unsigned long port) {
+static void outb_mem(unsigned char value, unsigned long port) {
 	writeb(value, (void __iomem *) port);
 }
 

[-mm patch] drivers/md/md.c: make code static

[Adrian Bunk]

This patch makes needlessly global code static.

Signed-off-by: Adrian Bunk <bunk@stusta.de>

---

 drivers/md/md.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- linux-2.6.17-mm1-full/drivers/md/md.c.old	2006-06-21 22:59:44.000000000 +0200
+++ linux-2.6.17-mm1-full/drivers/md/md.c	2006-06-21 23:00:02.000000000 +0200
@@ -175,7 +175,7 @@
 /* Alternate version that can be called from interrupts
  * when calling sysfs_notify isn't needed.
  */
-void md_new_event_inintr(mddev_t *mddev)
+static void md_new_event_inintr(mddev_t *mddev)
 {
 	atomic_inc(&md_event_count);
 	wake_up(&md_event_waiters);
@@ -2309,7 +2309,7 @@
  */
 enum array_state { clear, inactive, suspended, readonly, read_auto, clean, active,
 		   write_pending, active_idle, bad_word};
-char *array_states[] = {
+static char *array_states[] = {
 	"clear", "inactive", "suspended", "readonly", "read-auto", "clean", "active",
 	"write-pending", "active-idle", NULL };
 

[-mm patch] drivers/media/video/vivi.c: make 2 functions static

[Adrian Bunk]

On Wed, Jun 21, 2006 at 03:48:57AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.17-rc6-mm2:
>...
>  git-dvb.patch
>...
>  git trees
>...

This patch makes two needlessly global functions static.

Signed-off-by: Adrian Bunk <bunk@stusta.de>

---

 drivers/media/video/vivi.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- linux-2.6.17-mm1-full/drivers/media/video/vivi.c.old	2006-06-21 23:04:12.000000000 +0200
+++ linux-2.6.17-mm1-full/drivers/media/video/vivi.c	2006-06-21 23:04:31.000000000 +0200
@@ -1011,7 +1011,7 @@
 }
 #endif
 
-int vidioc_streamon (struct file *file, void *priv, enum v4l2_buf_type i)
+static int vidioc_streamon(struct file *file, void *priv, enum v4l2_buf_type i)
 {
 	struct vivi_fh  *fh=priv;
 	struct vivi_dev *dev    = fh->dev;
@@ -1026,7 +1026,7 @@
 	return (videobuf_streamon(&fh->vb_vidq));
 }
 
-int vidioc_streamoff (struct file *file, void *priv, enum v4l2_buf_type i)
+static int vidioc_streamoff(struct file *file, void *priv, enum v4l2_buf_type i)
 {
 	struct vivi_fh  *fh=priv;
 	struct vivi_dev *dev    = fh->dev;

[-mm patch] gpio: make two mutexes static again

[Adrian Bunk]

On Wed, Jun 21, 2006 at 03:48:57AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.17-rc6-mm2:
>...
> +chardev-gpio-for-scx200-pc-8736x-replace-spinlocks.patch
>...
>  GPIO driver framework.
>...

scx200_gpio_config_lock and pc8736x_gpio_config_lock became global 
without a good reason.
 
Signed-off-by: Adrian Bunk <bunk@stusta.de>

---

 arch/i386/kernel/scx200.c   |    2 +-
 drivers/char/pc8736x_gpio.c |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

--- linux-2.6.17-mm1-full/arch/i386/kernel/scx200.c.old	2006-06-21 22:32:23.000000000 +0200
+++ linux-2.6.17-mm1-full/arch/i386/kernel/scx200.c	2006-06-21 22:32:32.000000000 +0200
@@ -46,7 +46,7 @@
 	.probe = scx200_probe,
 };
 
-DEFINE_MUTEX(scx200_gpio_config_lock);
+static DEFINE_MUTEX(scx200_gpio_config_lock);
 
 static void __devinit scx200_init_shadow(void)
 {
--- linux-2.6.17-mm1-full/drivers/char/pc8736x_gpio.c.old	2006-06-21 22:46:56.000000000 +0200
+++ linux-2.6.17-mm1-full/drivers/char/pc8736x_gpio.c	2006-06-21 22:47:05.000000000 +0200
@@ -32,7 +32,7 @@
 module_param(major, int, 0);
 MODULE_PARM_DESC(major, "Major device number");
 
-DEFINE_MUTEX(pc8736x_gpio_config_lock);
+static DEFINE_MUTEX(pc8736x_gpio_config_lock);
 static unsigned pc8736x_gpio_base;
 static u8 pc8736x_gpio_shadow[4];
 

Re: swsusp regression [Was: 2.6.17-mm1]

[Mattia Dongili]

On Wed, Jun 21, 2006 at 11:47:46PM +0159, Jiri Slaby wrote:
> Andrew Morton napsal(a):
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm1/
> 
> [32512.214000] Suspending device usbdev3.2_ep81
> [32512.214040] Suspending device 3-2:1.0
> [32512.214081] wacom 3-2:1.0: no suspend for driver wacom?
> [32512.214128] Suspending device usbdev3.2_ep00
> [32512.214169] Suspending device 3-2
> [32512.214209] suspend_device(): usb_generic_suspend+0x0/0x128() returns -16
> [32512.214319] Could not suspend device 3-2: error -16
> [32512.214361] wacom 3-2:1.0: no resume for driver wacom?
> [32512.242552] Some devices failed to suspend
> 
> Bus 003 Device 002: ID 056a:0011 Wacom Co., Ltd Graphire 2
> 
> Wacom messages are not new, but it now causes not suspending.

me too (again!)

[   95.408000] Suspending device 3-1
[   95.408000] suspend_device(): usb_generic_suspend+0x0/0x144 [usbcore]() returns -16
[   95.408000] Could not suspend device 3-1: error -16
[   95.412000] Some devices failed to suspend
[   95.412000] Restarting tasks... done

rmmod-ing sd_mod usb_storage usbhid uhci_hcd can finally suspend to disk
and resume (s2ram).
usbcore tells it is in use (count=1) and can't remove it.
The device is a memory stick reader.

I have the same problems also with suspend to disk. BTW I can't resume
from disk since 2.6.17-rc5-mm1, but I'll try to be more precise
tomorrow, as it seems removing the usb stuff makes it do some more steps
toward resumimg (eg: with usb modules this laptop immediately reboots
after reading all pages, without them I can reach "resuming device.."
stage).

-- 
mattia
:wq!

Re: swsusp regression [Was: 2.6.17-mm1]

[Mattia Dongili]

On Thu, Jun 22, 2006 at 12:14:45AM +0200, Mattia Dongili wrote:
[...]
> rmmod-ing sd_mod usb_storage usbhid uhci_hcd can finally suspend to disk
> and resume (s2ram).

doh, sorry. I meant "suspend to ram".

-- 
mattia
:wq!

[-mm patch] drivers/scsi/qla2xxx/: make some functions static

[Adrian Bunk]

On Wed, Jun 21, 2006 at 03:48:57AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.17-rc6-mm2:
>...
>  git-infiniband.patch
>...
>  git trees
>...

This patch makes some needlessly global functions static.

Signed-off-by: Adrian Bunk <bunk@stusta.de>

---

 drivers/scsi/qla2xxx/qla_gbl.h  |    6 ------
 drivers/scsi/qla2xxx/qla_init.c |    8 +++++---
 drivers/scsi/qla2xxx/qla_iocb.c |    3 ++-
 3 files changed, 7 insertions(+), 10 deletions(-)

--- linux-2.6.17-mm1-full/drivers/scsi/qla2xxx/qla_gbl.h.old	2006-06-22 00:48:35.000000000 +0200
+++ linux-2.6.17-mm1-full/drivers/scsi/qla2xxx/qla_gbl.h	2006-06-22 00:50:32.000000000 +0200
@@ -31,13 +31,9 @@
 extern void qla24xx_update_fw_options(scsi_qla_host_t *);
 extern int qla2x00_load_risc(struct scsi_qla_host *, uint32_t *);
 extern int qla24xx_load_risc(scsi_qla_host_t *, uint32_t *);
-extern int qla24xx_load_risc_flash(scsi_qla_host_t *, uint32_t *);
-
-extern fc_port_t *qla2x00_alloc_fcport(scsi_qla_host_t *, gfp_t);
 
 extern int qla2x00_loop_resync(scsi_qla_host_t *);
 
-extern int qla2x00_find_new_loop_id(scsi_qla_host_t *, fc_port_t *);
 extern int qla2x00_fabric_login(scsi_qla_host_t *, fc_port_t *, uint16_t *);
 extern int qla2x00_local_device_login(scsi_qla_host_t *, fc_port_t *);
 
@@ -80,8 +76,6 @@
 /*
  * Global Function Prototypes in qla_iocb.c source file.
  */
-extern void qla2x00_isp_cmd(scsi_qla_host_t *);
-
 extern uint16_t qla2x00_calc_iocbs_32(uint16_t);
 extern uint16_t qla2x00_calc_iocbs_64(uint16_t);
 extern void qla2x00_build_scsi_iocbs_32(srb_t *, cmd_entry_t *, uint16_t);
--- linux-2.6.17-mm1-full/drivers/scsi/qla2xxx/qla_init.c.old	2006-06-22 00:48:58.000000000 +0200
+++ linux-2.6.17-mm1-full/drivers/scsi/qla2xxx/qla_init.c	2006-06-22 00:49:50.000000000 +0200
@@ -39,6 +39,8 @@
 
 static int qla2x00_restart_isp(scsi_qla_host_t *);
 
+static int qla2x00_find_new_loop_id(scsi_qla_host_t *ha, fc_port_t *dev);
+
 /****************************************************************************/
 /*                QLogic ISP2x00 Hardware Support Functions.                */
 /****************************************************************************/
@@ -1701,7 +1703,7 @@
  *
  * Returns a pointer to the allocated fcport, or NULL, if none available.
  */
-fc_port_t *
+static fc_port_t *
 qla2x00_alloc_fcport(scsi_qla_host_t *ha, gfp_t flags)
 {
 	fc_port_t *fcport;
@@ -2497,7 +2499,7 @@
  * Context:
  *	Kernel context.
  */
-int
+static int
 qla2x00_find_new_loop_id(scsi_qla_host_t *ha, fc_port_t *dev)
 {
 	int	rval;
@@ -3472,7 +3474,7 @@
 	return (rval);
 }
 
-int
+static int
 qla24xx_load_risc_flash(scsi_qla_host_t *ha, uint32_t *srisc_addr)
 {
 	int	rval;
--- linux-2.6.17-mm1-full/drivers/scsi/qla2xxx/qla_iocb.c.old	2006-06-22 00:50:42.000000000 +0200
+++ linux-2.6.17-mm1-full/drivers/scsi/qla2xxx/qla_iocb.c	2006-06-22 00:51:00.000000000 +0200
@@ -15,6 +15,7 @@
 static inline cont_entry_t *qla2x00_prep_cont_type0_iocb(scsi_qla_host_t *);
 static inline cont_a64_entry_t *qla2x00_prep_cont_type1_iocb(scsi_qla_host_t *);
 static request_t *qla2x00_req_pkt(scsi_qla_host_t *ha);
+static void qla2x00_isp_cmd(scsi_qla_host_t *ha);
 
 /**
  * qla2x00_get_cmd_direction() - Determine control_flag data direction.
@@ -574,7 +575,7 @@
  *
  * Note: The caller must hold the hardware lock before calling this routine.
  */
-void
+static void
 qla2x00_isp_cmd(scsi_qla_host_t *ha)
 {
 	device_reg_t __iomem *reg = ha->iobase;

[-mm patch] make drivers/scsi/pata_pcmcia.c:pcmcia_remove_one() static

[Adrian Bunk]

On Wed, Jun 21, 2006 at 03:48:57AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.17-rc6-mm2:
>...
>  git-libata-all.patch
>...
>  git trees
>...

This patch makes a needlessly global function static.

Signed-off-by: Adrian Bunk <bunk@stusta.de>

--- linux-2.6.17-mm1-full/drivers/scsi/pata_pcmcia.c.old	2006-06-22 00:43:23.000000000 +0200
+++ linux-2.6.17-mm1-full/drivers/scsi/pata_pcmcia.c	2006-06-22 00:43:33.000000000 +0200
@@ -294,7 +294,7 @@
  *	cleanup. Also called on module unload for any active devices.
  */
 
-void pcmcia_remove_one(struct pcmcia_device *pdev)
+static void pcmcia_remove_one(struct pcmcia_device *pdev)
 {
 	struct ata_pcmcia_info *info = pdev->priv;
 	struct device *dev = &pdev->dev;

[-mm patch] make drivers/usb/misc/cy7c63.c:vendor_command() static

[Adrian Bunk]

On Wed, Jun 21, 2006 at 03:48:57AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.17-rc6-mm2:
>...
> +gregkh-usb-usb-new-driver-for-cypress-cy7c63xxx-mirco-controllers.patch
>...
>  USB tree updates
>...

This patch makes the needlessly global vendor_command() static.

Signed-off-by: Adrian Bunk <bunk@stusta.de>

--- linux-2.6.17-mm1-full/drivers/usb/misc/cy7c63.c.old	2006-06-22 01:25:08.000000000 +0200
+++ linux-2.6.17-mm1-full/drivers/usb/misc/cy7c63.c	2006-06-22 01:25:57.000000000 +0200
@@ -63,8 +63,8 @@
 };
 
 /* used to send usb control messages to device */
-int vendor_command(struct cy7c63 *dev, unsigned char request,
-			 unsigned char address, unsigned char data) {
+static int vendor_command(struct cy7c63 *dev, unsigned char request,
+			  unsigned char address, unsigned char data) {
 
 	int retval = 0;
 	unsigned int pipe;

Re: 2.6.17-mm1 : two PF flags with the same value

[Peter Williams]

Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm1/

Doing my quick review of changes to bits of code that overlap where I 
wish to work I've noticed that PF_SPREAD_SLAB and PF_MUTEX_TESTER have 
the same value.

define PF_SPREAD_SLAB	0x02000000	/* Spread some slab caches over cpuset */
#define PF_MEMPOLICY	0x10000000	/* Non-default NUMA mempolicy */
#define PF_MUTEX_TESTER	0x02000000	/* Thread belongs to the rt mutex 
tester */

This will have interesting consequences in some circumstances, I imagine.

Peter
-- 
Peter Williams                                   pwil3058@bigpond.net.au

"Learning, n. The kind of ignorance distinguishing the studious."
  -- Ambrose Bierce

Re: 2.6.17-mm1 : two PF flags with the same value

[Andrew Morton]

On Thu, 22 Jun 2006 09:39:48 +1000
Peter Williams <pwil3058@bigpond.net.au> wrote:

> Andrew Morton wrote:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm1/
> 
> Doing my quick review of changes to bits of code that overlap where I 
> wish to work I've noticed that PF_SPREAD_SLAB and PF_MUTEX_TESTER have 
> the same value.
> 
> define PF_SPREAD_SLAB	0x02000000	/* Spread some slab caches over cpuset */
> #define PF_MEMPOLICY	0x10000000	/* Non-default NUMA mempolicy */
> #define PF_MUTEX_TESTER	0x02000000	/* Thread belongs to the rt mutex 
> tester */

ahem.   Will fix, thanks.

Re: 2.6.17-mm1 : two PF flags with the same value

[Paul Jackson]

> #define PF_SPREAD_SLAB	0x02000000	/* Spread some slab caches over cpuset */
> ...
> #define PF_MUTEX_TESTER	0x02000000	/* Thread belongs to the rt mutex 

Thanks for noticing, Peter.

> ahem.   Will fix, thanks.

Good - thanks, Andrew.

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.925.600.0401

Re: [linux-pm] swsusp regression [Was: 2.6.17-mm1]

[Greg KH]

On Thu, Jun 22, 2006 at 12:14:45AM +0200, Mattia Dongili wrote:
> On Wed, Jun 21, 2006 at 11:47:46PM +0159, Jiri Slaby wrote:
> > Andrew Morton napsal(a):
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm1/
> > 
> > [32512.214000] Suspending device usbdev3.2_ep81
> > [32512.214040] Suspending device 3-2:1.0
> > [32512.214081] wacom 3-2:1.0: no suspend for driver wacom?
> > [32512.214128] Suspending device usbdev3.2_ep00
> > [32512.214169] Suspending device 3-2
> > [32512.214209] suspend_device(): usb_generic_suspend+0x0/0x128() returns -16
> > [32512.214319] Could not suspend device 3-2: error -16
> > [32512.214361] wacom 3-2:1.0: no resume for driver wacom?
> > [32512.242552] Some devices failed to suspend
> > 
> > Bus 003 Device 002: ID 056a:0011 Wacom Co., Ltd Graphire 2
> > 
> > Wacom messages are not new, but it now causes not suspending.
> 
> me too (again!)
> 
> [   95.408000] Suspending device 3-1
> [   95.408000] suspend_device(): usb_generic_suspend+0x0/0x144 [usbcore]() returns -16
> [   95.408000] Could not suspend device 3-1: error -16
> [   95.412000] Some devices failed to suspend
> [   95.412000] Restarting tasks... done
> 
> rmmod-ing sd_mod usb_storage usbhid uhci_hcd can finally suspend to disk
> and resume (s2ram).
> usbcore tells it is in use (count=1) and can't remove it.
> The device is a memory stick reader.
> 
> I have the same problems also with suspend to disk. BTW I can't resume
> from disk since 2.6.17-rc5-mm1, but I'll try to be more precise
> tomorrow, as it seems removing the usb stuff makes it do some more steps
> toward resumimg (eg: with usb modules this laptop immediately reboots
> after reading all pages, without them I can reach "resuming device.."
> stage).

Removing uhci-hcd causes all USB devices to be removed from the system.

Alan, you've been working in the "generic usb" section lately, any ideas
why we can't suspend that kind of device now?

thanks,

greg k-h

Re: [linux-pm] swsusp regression [Was: 2.6.17-mm1]

[Andrew Morton]

On Wed, 21 Jun 2006 23:19:05 -0700
Greg KH <greg@kroah.com> wrote:

> > I have the same problems also with suspend to disk. BTW I can't resume
> > from disk since 2.6.17-rc5-mm1, but I'll try to be more precise
> > tomorrow, as it seems removing the usb stuff makes it do some more steps
> > toward resumimg (eg: with usb modules this laptop immediately reboots
> > after reading all pages, without them I can reach "resuming device.."
> > stage).
> 
> Removing uhci-hcd causes all USB devices to be removed from the system.
> 
> Alan, you've been working in the "generic usb" section lately, any ideas
> why we can't suspend that kind of device now?

My laptop has the same problem.

This:

--- a/drivers/usb/core/usb.c~usb-more-suspend-debugging
+++ a/drivers/usb/core/usb.c
@@ -991,7 +991,11 @@ void usb_buffer_unmap_sg (struct usb_dev
 
 static int verify_suspended(struct device *dev, void *unused)
 {
-	return (dev->power.power_state.event == PM_EVENT_ON) ? -EBUSY : 0;
+	if (dev->power.power_state.event == PM_EVENT_ON) {
+		dev_printk(KERN_ERR, dev, "not suspended\n");
+		return -EBUSY;
+	}
+	return 0;
 }
 
 static int usb_generic_suspend(struct device *dev, pm_message_t message)
@@ -1005,13 +1009,18 @@ static int usb_generic_suspend(struct de
 	 * But those semantics are useless, so we equate the two (sigh).
 	 */
 	if (dev->driver == &usb_generic_driver) {
+		int ret;
+
 		if (dev->power.power_state.event == message.event)
 			return 0;
 		/* we need to rule out bogus requests through sysfs */
 		status = device_for_each_child(dev, NULL, verify_suspended);
+		suspend_report_result(verify_suspended, status);
 		if (status)
 			return status;
- 		return usb_suspend_device (to_usb_device(dev));
+		ret = usb_suspend_device(to_usb_device(dev));
+		suspend_report_result(usb_suspend_device, ret);
+		return ret;
 	}
 
 	if ((dev->driver == NULL) ||
@@ -1027,6 +1036,7 @@ static int usb_generic_suspend(struct de
 
 	if (driver->suspend && driver->resume) {
 		status = driver->suspend(intf, message);
+		suspend_report_result(driver->suspend, status);
 		if (status)
 			dev_err(dev, "%s error %d\n", "suspend", status);
 		else
diff -puN drivers/usb/core/hub.c~usb-more-suspend-debugging drivers/usb/core/hub.c
--- a/drivers/usb/core/hub.c~usb-more-suspend-debugging
+++ a/drivers/usb/core/hub.c
@@ -1638,6 +1638,7 @@ static int hub_port_suspend(struct usb_h
 				USB_DEVICE_REMOTE_WAKEUP, 0,
 				NULL, 0,
 				USB_CTRL_SET_TIMEOUT);
+		suspend_report_result(usb_control_msg, status);
 		if (status)
 			dev_dbg(&udev->dev,
 				"won't remote wakeup, status %d\n",
@@ -1646,6 +1647,7 @@ static int hub_port_suspend(struct usb_h
 
 	/* see 7.1.7.6 */
 	status = set_port_feature(hub->hdev, port1, USB_PORT_FEAT_SUSPEND);
+	suspend_report_result(set_port_feature, status);
 	if (status) {
 		dev_dbg(hub->intfdev,
 			"can't suspend port %d, status %d\n",
@@ -1706,6 +1708,8 @@ static int __usb_suspend_device (struct 
 			intf = udev->actconfig->interface[i];
 			if (is_active(intf)) {
 				dev_dbg(&intf->dev, "nyet suspended\n");
+				suspend_report_result(__usb_suspend_device,
+							-EBUSY);
 				return -EBUSY;
 			}
 		}
@@ -1714,9 +1718,11 @@ static int __usb_suspend_device (struct 
 	/* we only change a device's upstream USB link.
 	 * root hubs have no upstream USB link.
 	 */
-	if (udev->parent)
+	if (udev->parent) {
 		status = hub_port_suspend(hdev_to_hub(udev->parent), port1,
 				udev);
+		suspend_report_result(hub_port_suspend, status);
+	}
 
 	if (status == 0)
 		udev->dev.power.power_state = PMSG_SUSPEND;
_


Says:

Shrinking memory... done (0 pages freed)
hci_usb 3-1:1.1: no suspend for driver hci_usb?
hci_usb 3-1:1.0: no suspend for driver hci_usb?
 usbdev3.2_ep00: not suspended
usb_generic_suspend(): verify_suspended+0x0/0x3c() returns -16
suspend_device(): usb_generic_suspend+0x0/0x134() returns -16
Could not suspend device 3-1: error -16
hci_usb 3-1:1.0: no resume for driver hci_usb?
hci_usb 3-1:1.1: no resume for driver hci_usb?
Some devices failed to suspend
Restarting tasks... done


What's a usbdev3.2_ep00?

sony:/home/akpm> lsusb
Bus 005 Device 001: ID 0000:0000  
Bus 004 Device 001: ID 0000:0000  
Bus 003 Device 002: ID 044e:300c Alps Electric Co., Ltd 
Bus 003 Device 001: ID 0000:0000  
Bus 002 Device 003: ID 045e:00e1 Microsoft Corp. 
Bus 002 Device 001: ID 0000:0000  
Bus 001 Device 001: ID 0000:0000  

sony:/home/akpm> l /sys/bus/usb/devices
total 0
lrwxrwxrwx 1 root root 0 Jun 22 00:32 1-0:1.0 -> ../../../devices/pci0000:00/0000:00:1d.0/usb1/1-0:1.0
lrwxrwxrwx 1 root root 0 Jun 22 00:32 2-0:1.0 -> ../../../devices/pci0000:00/0000:00:1d.1/usb2/2-0:1.0
lrwxrwxrwx 1 root root 0 Jun 22 00:32 2-1 -> ../../../devices/pci0000:00/0000:00:1d.1/usb2/2-1
lrwxrwxrwx 1 root root 0 Jun 22 00:32 2-1:1.0 -> ../../../devices/pci0000:00/0000:00:1d.1/usb2/2-1/2-1:1.0
lrwxrwxrwx 1 root root 0 Jun 22 00:32 3-0:1.0 -> ../../../devices/pci0000:00/0000:00:1d.2/usb3/3-0:1.0
lrwxrwxrwx 1 root root 0 Jun 22 00:32 3-1 -> ../../../devices/pci0000:00/0000:00:1d.2/usb3/3-1
lrwxrwxrwx 1 root root 0 Jun 22 00:32 3-1:1.0 -> ../../../devices/pci0000:00/0000:00:1d.2/usb3/3-1/3-1:1.0
lrwxrwxrwx 1 root root 0 Jun 22 00:32 3-1:1.1 -> ../../../devices/pci0000:00/0000:00:1d.2/usb3/3-1/3-1:1.1
lrwxrwxrwx 1 root root 0 Jun 22 00:32 3-1:1.2 -> ../../../devices/pci0000:00/0000:00:1d.2/usb3/3-1/3-1:1.2

Seems to be this:

00:1d.2 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #3 (rev 03) (prog-if 00 [UHCI])
        Subsystem: Sony Corporation Unknown device 81b9
        Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 0
        Interrupt: pin C routed to IRQ 16
        Region 4: I/O ports at 1860 [size=32]
00: 86 80 5a 26 05 00 80 02 03 00 03 0c 00 00 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 61 18 00 00 00 00 00 00 00 00 00 00 4d 10 b9 81
30: 00 00 00 00 00 00 00 00 00 00 00 00 0a 03 00 00

I don't see anything in this patchpile which would break the bluetooth driver,
and drivers/usb/core/usb.c is effectively unchanged.

I can bisect it if we're stuck, but that'll require beer or something.

Re: [-mm patch] drivers/net/ni5010.c: fix compile error

[Andreas Mohr]

Hi,

On Wed, Jun 21, 2006 at 05:10:57PM +0200, Adrian Bunk wrote:
> On Wed, Jun 21, 2006 at 03:48:57AM -0700, Andrew Morton wrote:
> >...
> > Changes since 2.6.17-rc6-mm2:
> >...
> > +ni5010-netcard-cleanup.patch
> > 
> >  netdev cleanup
> >...
> 
> This patch fixes the following compile error with CONFIG_NI5010=y:

Doh, thanks!
(that should teach me to do non-module runs, too)

Andreas Mohr

Re: [linux-pm] swsusp regression [Was: 2.6.17-mm1]

[Jeremy Fitzhardinge]

Andrew Morton wrote:
> My laptop has the same problem.
>   
Mine too.  I wonder if its related to the (apparently) bluetooth-caused 
oops I reported earlier today?

Though I'm seeing the suspend problem on a system with no bluetooth 
module loaded; the only USB device on the bus is the fingerprint-reader.

My suspend script removes the uhci_hcd module on suspend.  The device 
complaining EBUSY is the ehci hub, which has nothing hanging off it.

    J

Re: [-mm patch] drivers/net/ni5010.c: fix compile error

[Adrian Bunk]

On Thu, Jun 22, 2006 at 10:13:16AM +0200, Andreas Mohr wrote:
> Hi,
> 
> On Wed, Jun 21, 2006 at 05:10:57PM +0200, Adrian Bunk wrote:
> > On Wed, Jun 21, 2006 at 03:48:57AM -0700, Andrew Morton wrote:
> > >...
> > > Changes since 2.6.17-rc6-mm2:
> > >...
> > > +ni5010-netcard-cleanup.patch
> > > 
> > >  netdev cleanup
> > >...
> > 
> > This patch fixes the following compile error with CONFIG_NI5010=y:
> 
> Doh, thanks!
> (that should teach me to do non-module runs, too)

And change the driver to no longer use Space.c?  ;-)

> Andreas Mohr

cu
Adrian

-- 

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

[-mm patch] #if 0 drivers/usb/input/hid-core.c:hid_find_field_by_usage()

[Adrian Bunk]

This patch #if 0's the no longer used hid_find_field_by_usage().

Signed-off-by: Adrian Bunk <bunk@stusta.de>

---

 drivers/usb/input/hid-core.c |    3 ++-
 drivers/usb/input/hid.h      |    1 -
 2 files changed, 2 insertions(+), 2 deletions(-)

--- linux-2.6.17-mm1-full/drivers/usb/input/hid.h.old	2006-06-22 01:20:25.000000000 +0200
+++ linux-2.6.17-mm1-full/drivers/usb/input/hid.h	2006-06-22 01:20:33.000000000 +0200
@@ -519,7 +519,6 @@
 int hid_set_field(struct hid_field *, unsigned, __s32);
 void hid_submit_report(struct hid_device *, struct hid_report *, unsigned char dir);
 void hid_init_reports(struct hid_device *hid);
-struct hid_field *hid_find_field_by_usage(struct hid_device *hid, __u32 wanted_usage, int type);
 int hid_wait_io(struct hid_device* hid);
 
 
--- linux-2.6.17-mm1-full/drivers/usb/input/hid-core.c.old	2006-06-22 01:20:41.000000000 +0200
+++ linux-2.6.17-mm1-full/drivers/usb/input/hid-core.c	2006-06-22 01:21:00.000000000 +0200
@@ -1108,7 +1108,7 @@
 /*
  * Find a report field with a specified HID usage.
  */
-
+#if 0
 struct hid_field *hid_find_field_by_usage(struct hid_device *hid, __u32 wanted_usage, int type)
 {
 	struct hid_report *report;
@@ -1120,6 +1120,7 @@
 				return report->field[i];
 	return NULL;
 }
+#endif  /*  0  */
 
 static int hid_submit_out(struct hid_device *hid)
 {

[-mm patch] fs/gfs2/: make code static

[Adrian Bunk]

On Wed, Jun 21, 2006 at 03:48:57AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.17-rc6-mm2:
>...
>  git-gfs2.patch
>...
>  git trees
>...

This patch makes the following needlessly global code static:
- eaops.c: struct gfs2_security_eaops
- rgrp.c: gfs2_free_uninit_di()

Signed-off-by: Adrian Bunk <bunk@stusta.de>

---

 fs/gfs2/eaops.c |    2 +-
 fs/gfs2/eaops.h |    2 --
 fs/gfs2/rgrp.c  |    2 +-
 fs/gfs2/rgrp.h  |    1 -
 4 files changed, 2 insertions(+), 5 deletions(-)

--- linux-2.6.17-mm1-full/fs/gfs2/eaops.h.old	2006-06-22 01:39:33.000000000 +0200
+++ linux-2.6.17-mm1-full/fs/gfs2/eaops.h	2006-06-22 01:39:45.000000000 +0200
@@ -23,8 +23,6 @@
 
 extern struct gfs2_eattr_operations gfs2_system_eaops;
 
-extern struct gfs2_eattr_operations gfs2_security_eaops;
-
 extern struct gfs2_eattr_operations *gfs2_ea_ops[];
 
 #endif /* __EAOPS_DOT_H__ */
--- linux-2.6.17-mm1-full/fs/gfs2/eaops.c.old	2006-06-22 01:39:05.000000000 +0200
+++ linux-2.6.17-mm1-full/fs/gfs2/eaops.c	2006-06-22 01:39:40.000000000 +0200
@@ -214,7 +214,7 @@
 	.eo_name = "system",
 };
 
-struct gfs2_eattr_operations gfs2_security_eaops = {
+static struct gfs2_eattr_operations gfs2_security_eaops = {
 	.eo_get = security_eo_get,
 	.eo_set = security_eo_set,
 	.eo_remove = security_eo_remove,
--- linux-2.6.17-mm1-full/fs/gfs2/rgrp.h.old	2006-06-22 01:39:52.000000000 +0200
+++ linux-2.6.17-mm1-full/fs/gfs2/rgrp.h	2006-06-22 01:40:07.000000000 +0200
@@ -43,7 +43,6 @@
 
 void gfs2_free_data(struct gfs2_inode *ip, uint64_t bstart, uint32_t blen);
 void gfs2_free_meta(struct gfs2_inode *ip, uint64_t bstart, uint32_t blen);
-void gfs2_free_uninit_di(struct gfs2_rgrpd *rgd, uint64_t blkno);
 void gfs2_free_di(struct gfs2_rgrpd *rgd, struct gfs2_inode *ip);
 void gfs2_unlink_di(struct inode *inode);
 
--- linux-2.6.17-mm1-full/fs/gfs2/rgrp.c.old	2006-06-22 01:40:15.000000000 +0200
+++ linux-2.6.17-mm1-full/fs/gfs2/rgrp.c	2006-06-22 01:40:20.000000000 +0200
@@ -1401,7 +1401,7 @@
 	gfs2_trans_add_rg(rgd);
 }
 
-void gfs2_free_uninit_di(struct gfs2_rgrpd *rgd, uint64_t blkno)
+static void gfs2_free_uninit_di(struct gfs2_rgrpd *rgd, uint64_t blkno)
 {
 	struct gfs2_sbd *sdp = rgd->rd_sbd;
 	struct gfs2_rgrpd *tmp_rgd;

Re: [-mm patch] fs/gfs2/: make code static

[Steven Whitehouse]

Hi,

On Thu, 2006-06-22 at 12:03 +0200, Adrian Bunk wrote:
> On Wed, Jun 21, 2006 at 03:48:57AM -0700, Andrew Morton wrote:
> >...
> > Changes since 2.6.17-rc6-mm2:
> >...
> >  git-gfs2.patch
> >...
> >  git trees
> >...
> 
> This patch makes the following needlessly global code static:
> - eaops.c: struct gfs2_security_eaops
> - rgrp.c: gfs2_free_uninit_di()
> 
> Signed-off-by: Adrian Bunk <bunk@stusta.de>
> 
Thanks for the patch. I've added it to the git tree:

git://git.kernel.org/pub/scm/linux/kernel/git/steve/gfs2-2.6.git

Steve.

Re: [-mm patch] make drivers/scsi/pata_pcmcia.c:pcmcia_remove_one() static

[Alan Cox]

On Thu, Jun 22, 2006 at 01:20:12AM +0200, Adrian Bunk wrote:
> On Wed, Jun 21, 2006 at 03:48:57AM -0700, Andrew Morton wrote:
> >...
> > Changes since 2.6.17-rc6-mm2:
> >...
> >  git-libata-all.patch
> >...
> >  git trees
> >...
> 
> This patch makes a needlessly global function static.
> 
> Signed-off-by: Adrian Bunk <bunk@stusta.de>

Acked-by: Alan Cox <alan@redhat.com>

> 
> --- linux-2.6.17-mm1-full/drivers/scsi/pata_pcmcia.c.old	2006-06-22 00:43:23.000000000 +0200
> +++ linux-2.6.17-mm1-full/drivers/scsi/pata_pcmcia.c	2006-06-22 00:43:33.000000000 +0200
> @@ -294,7 +294,7 @@
>   *	cleanup. Also called on module unload for any active devices.
>   */
>  
> -void pcmcia_remove_one(struct pcmcia_device *pdev)
> +static void pcmcia_remove_one(struct pcmcia_device *pdev)
>  {
>  	struct ata_pcmcia_info *info = pdev->priv;
>  	struct device *dev = &pdev->dev;

-- 
--
	In Ximian did mad Miguel a mighty mail client decree
	Where Nat the crazy hacker ran
	Through sourcecode measureless to man
	And never coredump free

Re: 2.6.17-mm1

[Franck Bui-Huu]

Andrew,

Andrew Morton wrote:
> 
> 
> All 1738 patches:
> 
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm1/patch-list
> 

Is the following patch really needed ?

flatmem-relax-requirement-for-memory-to-start-at-pfn-0.patch

"""
The FLATMEM memory model assumes that memory is in one contigious area
based at pfn 0.  If we initialise node 0 to start at any other offset we
will incorrectly map pfn's to the wrong struct page *.  The key to the
memory model is the contigious nature of the memory not the location of it.
Relax the requirement for the area to start at 0.
"""

Should ARCH_PFN_OFFSET macro be used instead in order to make pfn/page
convertions work when node 0 start offset do not start at 0 ?

My physical memory start at 0x20000000. So node 0 starts at an offset
different from 0. I setup ARCH_PFN_OFFSET this way

	#define ARCH_PFN_OFFSET    (0x20000000 << PAGE_SHIFT)

Until now (2.6.17), it works well, but this patch breaks my machine.

If you need more details about my memory mapping, feel free to ask.

Thanks

		Franck

Re: 2.6.17-mm1

[Mel Gorman]

On Thu, 22 Jun 2006, Franck Bui-Huu wrote:

> Andrew,
>
> Andrew Morton wrote:
>>
>>
>> All 1738 patches:
>>
>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm1/patch-list
>>
>
> Is the following patch really needed ?
>
> flatmem-relax-requirement-for-memory-to-start-at-pfn-0.patch
>
> """
> The FLATMEM memory model assumes that memory is in one contigious area
> based at pfn 0.  If we initialise node 0 to start at any other offset we
> will incorrectly map pfn's to the wrong struct page *.  The key to the
> memory model is the contigious nature of the memory not the location of it.
> Relax the requirement for the area to start at 0.
> """
>
> Should ARCH_PFN_OFFSET macro be used instead in order to make pfn/page
> convertions work when node 0 start offset do not start at 0 ?
>

What happens if you have ARCH_PFN_OFFSET as

#define ARCH_PFN_OFFSET (0UL)

?

What arch is this?

> My physical memory start at 0x20000000. So node 0 starts at an offset
> different from 0. I setup ARCH_PFN_OFFSET this way
>
> 	#define ARCH_PFN_OFFSET    (0x20000000 << PAGE_SHIFT)
>

If physical memory starts at 0x20000000, why is the PFN not
0x20000000 >> PAGE_SHIFT ?

> Until now (2.6.17), it works well, but this patch breaks my machine.
>
> If you need more details about my memory mapping, feel free to ask.
>
> Thanks
>
> 		Franck
>

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

Re: 2.6.17-mm1

[Franck Bui-Huu]

Mel Gorman wrote:
> On Thu, 22 Jun 2006, Franck Bui-Huu wrote:
>>
>> Should ARCH_PFN_OFFSET macro be used instead in order to make pfn/page
>> convertions work when node 0 start offset do not start at 0 ?
>>
> 
> What happens if you have ARCH_PFN_OFFSET as
> 
> #define ARCH_PFN_OFFSET (0UL)
> 
> ?

It's the default value (see memory_model.h). It means that pfn start
for node 0 is 0, therefore your physical memory address starts at 0.

> 
> What arch is this?
> 

well I'm working on MIPS, but you can take a look at ARM that does the
same thing better...

>> My physical memory start at 0x20000000. So node 0 starts at an offset
>> different from 0. I setup ARCH_PFN_OFFSET this way
>>
>>     #define ARCH_PFN_OFFSET    (0x20000000 << PAGE_SHIFT)
>>
> 
> If physical memory starts at 0x20000000, why is the PFN not
> 0x20000000 >> PAGE_SHIFT ?
> 

It is a typo... 

		Franck

Re: [linux-pm] swsusp regression [Was: 2.6.17-mm1]

[Alan Stern]

On Thu, 22 Jun 2006, Andrew Morton wrote:

> On Wed, 21 Jun 2006 23:19:05 -0700
> Greg KH <greg@kroah.com> wrote:
> 
> > > I have the same problems also with suspend to disk. BTW I can't resume
> > > from disk since 2.6.17-rc5-mm1, but I'll try to be more precise
> > > tomorrow, as it seems removing the usb stuff makes it do some more steps
> > > toward resumimg (eg: with usb modules this laptop immediately reboots
> > > after reading all pages, without them I can reach "resuming device.."
> > > stage).
> > 
> > Removing uhci-hcd causes all USB devices to be removed from the system.
> > 
> > Alan, you've been working in the "generic usb" section lately, any ideas
> > why we can't suspend that kind of device now?

See below...

> My laptop has the same problem.

> Shrinking memory... done (0 pages freed)
> hci_usb 3-1:1.1: no suspend for driver hci_usb?
> hci_usb 3-1:1.0: no suspend for driver hci_usb?
>  usbdev3.2_ep00: not suspended
> usb_generic_suspend(): verify_suspended+0x0/0x3c() returns -16
> suspend_device(): usb_generic_suspend+0x0/0x134() returns -16
> Could not suspend device 3-1: error -16
> hci_usb 3-1:1.0: no resume for driver hci_usb?
> hci_usb 3-1:1.1: no resume for driver hci_usb?
> Some devices failed to suspend
> Restarting tasks... done
> 
> 
> What's a usbdev3.2_ep00?

Evidently the regression was caused by Greg's patch making endpoints into 
real struct devices.  usbdev3.2_ep00 is the device corresponding to 
endpoint 0 on device 2 of USB bus 3.

Is it really true that this patch has been sitting in -mm for several
months (as stated in the cover message to Linus for the new batch of
changes for 2.6.17 sent in yesterday)?

There are several possible ways to fix this.  One is to add suspend and 
resume routines to the endpoint-device driver.  Another is to change the 
code that checks for the children being suspended, to make it check only 
for child USB devices and not child endpoints.

Alan Stern

2.6.17-mm1: kernel/lockdep.c: write-only variables

[Adrian Bunk]

The following variables in kernel/lockdep.c are write-only:
  nr_hardirq_read_safe_locks
  nr_hardirq_read_unsafe_locks
  nr_hardirq_safe_locks
  nr_hardirq_unsafe_locks
  nr_softirq_read_safe_locks
  nr_softirq_read_unsafe_locks
  nr_softirq_safe_locks
  nr_softirq_unsafe_locks

Is a usage pending or should they be removed?

cu
Adrian

-- 

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

Re: 2.6.17-mm1

[Mel Gorman]

On Thu, 22 Jun 2006, Franck Bui-Huu wrote:

> Mel Gorman wrote:
>> On Thu, 22 Jun 2006, Franck Bui-Huu wrote:
>>>
>>> Should ARCH_PFN_OFFSET macro be used instead in order to make pfn/page
>>> convertions work when node 0 start offset do not start at 0 ?
>>>
>>
>> What happens if you have ARCH_PFN_OFFSET as
>>
>> #define ARCH_PFN_OFFSET (0UL)
>>
>> ?
>
> It's the default value (see memory_model.h). It means that pfn start
> for node 0 is 0, therefore your physical memory address starts at 0.
>

I know, but what I'm getting at is that ARCH_PFN_OFFSET may be unnecessary 
with flatmem-relax-requirement-for-memory-to-start-at-pfn-0.patch applied. 
ARCH_PFN_OFFSET is used as

#define page_to_pfn(page)       ((unsigned long)((page) - mem_map) + \
                                  ARCH_PFN_OFFSET)

because it knew that the map may not start at PFN 0. With 
flatmem-relax-requirement-for-memory-to-start-at-pfn-0.patch, the map will 
start at PFN 0 even if physical memory does not start until later.

>>
>> What arch is this?
>>
>
> well I'm working on MIPS, but you can take a look at ARM that does the
> same thing better...
>
>>> My physical memory start at 0x20000000. So node 0 starts at an offset
>>> different from 0. I setup ARCH_PFN_OFFSET this way
>>>
>>>     #define ARCH_PFN_OFFSET    (0x20000000 << PAGE_SHIFT)
>>>
>>
>> If physical memory starts at 0x20000000, why is the PFN not
>> 0x20000000 >> PAGE_SHIFT ?
>>
>
> It is a typo...
>

ok

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

Re: [linux-pm] swsusp regression [Was: 2.6.17-mm1]

[Frederik Deweerdt]

Thu, Jun 22, 2006 at 12:46:48AM -0700, Andrew Morton wrote:
> I can bisect it if we're stuck, but that'll require beer or something.

FWIW, my laptop (Dell D610) gave the following results:
2.6.17-mm1: suspend_device(): usb_generic_suspend+0x0/0x135 [usbcore]() returns -16
2.6.17+origin.patch: suspend_device(): usb_generic_suspend+0x0/0x135 [usbcore]() returns -16
2.6.17: oops
2.6.17.1: oops

2.6.17-rc6-mm2: suspends correctly


Regards,
Frederik

Re: 2.6.17-mm1

[Russell King]

On Thu, Jun 22, 2006 at 04:54:06PM +0100, Mel Gorman wrote:
> On Thu, 22 Jun 2006, Franck Bui-Huu wrote:
> >It's the default value (see memory_model.h). It means that pfn start
> >for node 0 is 0, therefore your physical memory address starts at 0.
> 
> I know, but what I'm getting at is that ARCH_PFN_OFFSET may be unnecessary 
> with flatmem-relax-requirement-for-memory-to-start-at-pfn-0.patch applied. 
> ARCH_PFN_OFFSET is used as
> 
> #define page_to_pfn(page)       ((unsigned long)((page) - mem_map) + \
>                                  ARCH_PFN_OFFSET)
> 
> because it knew that the map may not start at PFN 0. With 
> flatmem-relax-requirement-for-memory-to-start-at-pfn-0.patch, the map will 
> start at PFN 0 even if physical memory does not start until later.

Doesn't that result in a massive array of struct pages if your memory
starts a 3GB physical and has 4K pages?  If you have only 32MB in that
scenario, and that was correct, you'd gobble 25MB of that just to
store that array.  Ouch.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: [linux-pm] swsusp regression [Was: 2.6.17-mm1]

[Andrew Morton]

On Thu, 22 Jun 2006 18:04:03 +0200
Frederik Deweerdt <deweerdt@free.fr> wrote:

> Thu, Jun 22, 2006 at 12:46:48AM -0700, Andrew Morton wrote:
> > I can bisect it if we're stuck, but that'll require beer or something.
> 
> FWIW, my laptop (Dell D610) gave the following results:
> 2.6.17-mm1: suspend_device(): usb_generic_suspend+0x0/0x135 [usbcore]() returns -16
> 2.6.17+origin.patch: suspend_device(): usb_generic_suspend+0x0/0x135 [usbcore]() returns -16

So it's in mainline already - hence it's some recently-written thing which
was not tested in rc6-mm2.

> 2.6.17: oops
> 2.6.17.1: oops

2.6.17 wasn't supposed to oops.  Do you have details on this?

> 2.6.17-rc6-mm2: suspends correctly

Good kernel, that.

Re: 2.6.17-mm1

[Mel Gorman]

On Thu, 22 Jun 2006, Russell King wrote:

> On Thu, Jun 22, 2006 at 04:54:06PM +0100, Mel Gorman wrote:
>> On Thu, 22 Jun 2006, Franck Bui-Huu wrote:
>>> It's the default value (see memory_model.h). It means that pfn start
>>> for node 0 is 0, therefore your physical memory address starts at 0.
>>
>> I know, but what I'm getting at is that ARCH_PFN_OFFSET may be unnecessary
>> with flatmem-relax-requirement-for-memory-to-start-at-pfn-0.patch applied.
>> ARCH_PFN_OFFSET is used as
>>
>> #define page_to_pfn(page)       ((unsigned long)((page) - mem_map) + \
>>                                  ARCH_PFN_OFFSET)
>>
>> because it knew that the map may not start at PFN 0. With
>> flatmem-relax-requirement-for-memory-to-start-at-pfn-0.patch, the map will
>> start at PFN 0 even if physical memory does not start until later.
>
> Doesn't that result in a massive array of struct pages if your memory
> starts a 3GB physical and has 4K pages?

No, I should have been clear. The size of the map remains the same but 
mem_map does not point directly to NODE_DATA(0)->node_mem_map when the PFN 
of node 0 is not 0. Instead mem_map points to

NODE_DATA(0)->node_mem_map - NODE_DATA(0)->node_start_pfn

The relevant bit of code is

 	map = alloc_remap(pgdat->node_id, size);
 	if (!map)
 		map = alloc_bootmem_node(pgdat, size);
 	pgdat->node_mem_map = map + (pgdat->node_start_pfn - start);

 	/*
 	 * With FLATMEM the global mem_map is used.  This is assumed
 	 * to be based at pfn 0 such that 'pfn = page* - mem_map'
 	 * is true. Adjust map relative to node_mem_map to
 	 * maintain this relationship.
 	 */
 	map -= pgdat->node_start_pfn;

and later

 	if (pgdat == NODE_DATA(0))
 		mem_map = map;

So memory is wasted and ARCH_PFN_OFFSET isn't needed in the case where it 
is working around NODE_DATA(0)->node_start_pfn != 0

> If you have only 32MB in that
> scenario, and that was correct, you'd gobble 25MB of that just to
> store that array.  Ouch.
>

It would be a kick in the shins all right if that was the case.

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

Re: [linux-pm] swsusp regression [Was: 2.6.17-mm1]

[Jeremy Fitzhardinge]

Alan Stern wrote:
> Is it really true that this patch has been sitting in -mm for several
> months (as stated in the cover message to Linus for the new batch of
> changes for 2.6.17 sent in yesterday)?
>   
2.6.17-pre6-mm2 works perfectly for me.  17-mm1 has this problem.

    J

Re: 2.6.17-mm1

[Franck Bui-Huu]

2006/6/22, Mel Gorman <mel@csn.ul.ie>:
> On Thu, 22 Jun 2006, Franck Bui-Huu wrote:
>
> > Mel Gorman wrote:
> >> On Thu, 22 Jun 2006, Franck Bui-Huu wrote:
> >>>
> >>> Should ARCH_PFN_OFFSET macro be used instead in order to make pfn/page
> >>> convertions work when node 0 start offset do not start at 0 ?
> >>>
> >>
> >> What happens if you have ARCH_PFN_OFFSET as
> >>
> >> #define ARCH_PFN_OFFSET (0UL)
> >>
> >> ?
> >
> > It's the default value (see memory_model.h). It means that pfn start
> > for node 0 is 0, therefore your physical memory address starts at 0.
> >
>
> I know, but what I'm getting at is that ARCH_PFN_OFFSET may be unnecessary
> with flatmem-relax-requirement-for-memory-to-start-at-pfn-0.patch applied.

yes it seems so. But ARCH_PFN_OFFSET has been used before your patch
has been sent. So your patch seems to be incomplete...

> ARCH_PFN_OFFSET is used as
>
> #define page_to_pfn(page)       ((unsigned long)((page) - mem_map) + \
>                                   ARCH_PFN_OFFSET)
>
> because it knew that the map may not start at PFN 0. With
> flatmem-relax-requirement-for-memory-to-start-at-pfn-0.patch, the map will
> start at PFN 0 even if physical memory does not start until later.
>

well your approach's trick is on the mem_map address whereas
ARCH_PFN_OFFSET's one is on the computation of the index. Your
solution may result in smaller kernel (when ARCH_PFN_OFFSET != 0)
because in your case page/pfn conversion is simpler.

Maybe in your patch instead of doing:

        map -= pgdat->node_start_pfn;

you could do:

        map -= ARCH_OFFSET_PFN;

-- 
               Franck

Re: [linux-pm] swsusp regression [Was: 2.6.17-mm1]

[Greg KH]

On Thu, Jun 22, 2006 at 11:51:18AM -0400, Alan Stern wrote:
> On Thu, 22 Jun 2006, Andrew Morton wrote:
> 
> > On Wed, 21 Jun 2006 23:19:05 -0700
> > Greg KH <greg@kroah.com> wrote:
> > 
> > > > I have the same problems also with suspend to disk. BTW I can't resume
> > > > from disk since 2.6.17-rc5-mm1, but I'll try to be more precise
> > > > tomorrow, as it seems removing the usb stuff makes it do some more steps
> > > > toward resumimg (eg: with usb modules this laptop immediately reboots
> > > > after reading all pages, without them I can reach "resuming device.."
> > > > stage).
> > > 
> > > Removing uhci-hcd causes all USB devices to be removed from the system.
> > > 
> > > Alan, you've been working in the "generic usb" section lately, any ideas
> > > why we can't suspend that kind of device now?
> 
> See below...
> 
> > My laptop has the same problem.
> 
> > Shrinking memory... done (0 pages freed)
> > hci_usb 3-1:1.1: no suspend for driver hci_usb?
> > hci_usb 3-1:1.0: no suspend for driver hci_usb?
> >  usbdev3.2_ep00: not suspended
> > usb_generic_suspend(): verify_suspended+0x0/0x3c() returns -16
> > suspend_device(): usb_generic_suspend+0x0/0x134() returns -16
> > Could not suspend device 3-1: error -16
> > hci_usb 3-1:1.0: no resume for driver hci_usb?
> > hci_usb 3-1:1.1: no resume for driver hci_usb?
> > Some devices failed to suspend
> > Restarting tasks... done
> > 
> > 
> > What's a usbdev3.2_ep00?
> 
> Evidently the regression was caused by Greg's patch making endpoints into 
> real struct devices.  usbdev3.2_ep00 is the device corresponding to 
> endpoint 0 on device 2 of USB bus 3.
> 
> Is it really true that this patch has been sitting in -mm for several
> months (as stated in the cover message to Linus for the new batch of
> changes for 2.6.17 sent in yesterday)?

Ugh, no, you are right, the endpoint change was not in for that long,
sorry.  I thought it did make at least one -mm though.

> There are several possible ways to fix this.  One is to add suspend and 
> resume routines to the endpoint-device driver.  Another is to change the 
> code that checks for the children being suspended, to make it check only 
> for child USB devices and not child endpoints.

I think it needs to check for _USB_ devices, not just any old device
that could possibly be attached to the main USB device (as this one is.)
What's to stop any other struct device to bind here and cause the same
problem?

thanks,

greg k-h

Re: [linux-pm] swsusp regression [Was: 2.6.17-mm1]

[Greg KH]

On Thu, Jun 22, 2006 at 11:46:49AM -0700, Greg KH wrote:
> On Thu, Jun 22, 2006 at 11:51:18AM -0400, Alan Stern wrote:
> > On Thu, 22 Jun 2006, Andrew Morton wrote:
> > 
> > > On Wed, 21 Jun 2006 23:19:05 -0700
> > > Greg KH <greg@kroah.com> wrote:
> > > 
> > > > > I have the same problems also with suspend to disk. BTW I can't resume
> > > > > from disk since 2.6.17-rc5-mm1, but I'll try to be more precise
> > > > > tomorrow, as it seems removing the usb stuff makes it do some more steps
> > > > > toward resumimg (eg: with usb modules this laptop immediately reboots
> > > > > after reading all pages, without them I can reach "resuming device.."
> > > > > stage).
> > > > 
> > > > Removing uhci-hcd causes all USB devices to be removed from the system.
> > > > 
> > > > Alan, you've been working in the "generic usb" section lately, any ideas
> > > > why we can't suspend that kind of device now?
> > 
> > See below...
> > 
> > > My laptop has the same problem.
> > 
> > > Shrinking memory... done (0 pages freed)
> > > hci_usb 3-1:1.1: no suspend for driver hci_usb?
> > > hci_usb 3-1:1.0: no suspend for driver hci_usb?
> > >  usbdev3.2_ep00: not suspended
> > > usb_generic_suspend(): verify_suspended+0x0/0x3c() returns -16
> > > suspend_device(): usb_generic_suspend+0x0/0x134() returns -16
> > > Could not suspend device 3-1: error -16
> > > hci_usb 3-1:1.0: no resume for driver hci_usb?
> > > hci_usb 3-1:1.1: no resume for driver hci_usb?
> > > Some devices failed to suspend
> > > Restarting tasks... done
> > > 
> > > 
> > > What's a usbdev3.2_ep00?
> > 
> > Evidently the regression was caused by Greg's patch making endpoints into 
> > real struct devices.  usbdev3.2_ep00 is the device corresponding to 
> > endpoint 0 on device 2 of USB bus 3.
> > 
> > Is it really true that this patch has been sitting in -mm for several
> > months (as stated in the cover message to Linus for the new batch of
> > changes for 2.6.17 sent in yesterday)?
> 
> Ugh, no, you are right, the endpoint change was not in for that long,
> sorry.  I thought it did make at least one -mm though.
> 
> > There are several possible ways to fix this.  One is to add suspend and 
> > resume routines to the endpoint-device driver.  Another is to change the 
> > code that checks for the children being suspended, to make it check only 
> > for child USB devices and not child endpoints.
> 
> I think it needs to check for _USB_ devices, not just any old device
> that could possibly be attached to the main USB device (as this one is.)
> What's to stop any other struct device to bind here and cause the same
> problem?

Ok, the problem is in verify_suspended(), we are not detecting what type
of device this is.

Alan, what are you trying to check for here?  What "bogus requests" were
you seeing from sysfs that you are trying to filter out?

thanks,

greg k-h

Re: [linux-pm] swsusp regression [Was: 2.6.17-mm1]

[Frederik Deweerdt]

On Thu, Jun 22, 2006 at 09:25:06AM -0700, Andrew Morton wrote:
> On Thu, 22 Jun 2006 18:04:03 +0200
> Frederik Deweerdt <deweerdt@free.fr> wrote:
> > 2.6.17: oops
> > 2.6.17.1: oops
> 
> 2.6.17 wasn't supposed to oops.  Do you have details on this?
> 
No, sorry I didn't have a serial cable handy. I'll post the 
.config and the oops tomorrow.

Regards,
Frederik

Re: [linux-pm] swsusp regression [Was: 2.6.17-mm1]

[Alan Stern]

On Thu, 22 Jun 2006, Greg KH wrote:

> > There are several possible ways to fix this.  One is to add suspend and 
> > resume routines to the endpoint-device driver.  Another is to change the 
> > code that checks for the children being suspended, to make it check only 
> > for child USB devices and not child endpoints.
> 
> I think it needs to check for _USB_ devices, not just any old device
> that could possibly be attached to the main USB device (as this one is.)
> What's to stop any other struct device to bind here and cause the same
> problem?

In my upcoming patches for USB core suspend improvements, one of the 
changes affects this very piece of code.  Instead of looping over all 
child devices in the driver-model sense, it loops over all interfaces in 
the active configuration, which is all we care about right here.

> Ok, the problem is in verify_suspended(), we are not detecting what type
> of device this is.
> 
> Alan, what are you trying to check for here?  What "bogus requests" were
> you seeing from sysfs that you are trying to filter out?

I didn't write that routine, Dave Brownell did.  It has been there for
ages.  The "bogus requests" are attempts by the user to suspend a USB
device (by writing to /sys/devices/.../power/state) without first
suspending all its children and interfaces.

(This can't happen when doing a global suspend because the PM core 
iterates through the entire device tree.  It matters only for "runtime" or 
"selective" suspend.)

The two easiest ways to fix the problem are:

	Change the code to look through the interfaces in the active
	configuration instead of using device_for_each_child;

or

	Revert your "endpoints are devices" patch until my upcoming
	changes are in place.

Alan Stern

Re: [linux-pm] swsusp regression [Was: 2.6.17-mm1]

[Greg KH]

On Thu, Jun 22, 2006 at 03:57:24PM -0400, Alan Stern wrote:
> On Thu, 22 Jun 2006, Greg KH wrote:
> 
> > > There are several possible ways to fix this.  One is to add suspend and 
> > > resume routines to the endpoint-device driver.  Another is to change the 
> > > code that checks for the children being suspended, to make it check only 
> > > for child USB devices and not child endpoints.
> > 
> > I think it needs to check for _USB_ devices, not just any old device
> > that could possibly be attached to the main USB device (as this one is.)
> > What's to stop any other struct device to bind here and cause the same
> > problem?
> 
> In my upcoming patches for USB core suspend improvements, one of the 
> changes affects this very piece of code.  Instead of looping over all 
> child devices in the driver-model sense, it loops over all interfaces in 
> the active configuration, which is all we care about right here.
> 
> > Ok, the problem is in verify_suspended(), we are not detecting what type
> > of device this is.
> > 
> > Alan, what are you trying to check for here?  What "bogus requests" were
> > you seeing from sysfs that you are trying to filter out?
> 
> I didn't write that routine, Dave Brownell did.  It has been there for
> ages.

Sorry for the misattribution, I should have checked closer.

> The "bogus requests" are attempts by the user to suspend a USB
> device (by writing to /sys/devices/.../power/state) without first
> suspending all its children and interfaces.
> 
> (This can't happen when doing a global suspend because the PM core 
> iterates through the entire device tree.  It matters only for "runtime" or 
> "selective" suspend.)

Then why is people hitting this now?  I guess no one had hooked a struct
device to a struct usb_device before, only interfaces.

> The two easiest ways to fix the problem are:
> 
> 	Change the code to look through the interfaces in the active
> 	configuration instead of using device_for_each_child;

Or at least verify that they are looking at an interface, just blindly
poking at a child device isn't very nice :(

> or
> 
> 	Revert your "endpoints are devices" patch until my upcoming
> 	changes are in place.

I'll work on a fix-up patch based on the first option :)

thanks,

greg k-h

Re: [linux-pm] swsusp regression [Was: 2.6.17-mm1]

[Jiri Slaby]

Alan Stern napsal(a):
>> Ok, the problem is in verify_suspended(), we are not detecting what type
>> of device this is.
>>
>> Alan, what are you trying to check for here?  What "bogus requests" were
>> you seeing from sysfs that you are trying to filter out?
> 
> I didn't write that routine, Dave Brownell did.  It has been there for
> ages.  The "bogus requests" are attempts by the user to suspend a USB
> device (by writing to /sys/devices/.../power/state) without first
> suspending all its children and interfaces.
> 
> (This can't happen when doing a global suspend because the PM core 
> iterates through the entire device tree.  It matters only for "runtime" or 
> "selective" suspend.)

But everything I did is:
echo reboot > /sys/power/disk
echo disk > /sys/power/state

No writing anywhere else.

regards,
-- 
Jiri Slaby         www.fi.muni.cz/~xslaby
\_.-^-._   jirislaby@gmail.com   _.-^-._/
B67499670407CE62ACC8 22A032CC55C339D47A7E

Re: [linux-pm] swsusp regression [Was: 2.6.17-mm1]

[Alan Stern]

On Thu, 22 Jun 2006, Jiri Slaby wrote:

> > ages.  The "bogus requests" are attempts by the user to suspend a USB
> > device (by writing to /sys/devices/.../power/state) without first
> > suspending all its children and interfaces.
> > 
> > (This can't happen when doing a global suspend because the PM core 
> > iterates through the entire device tree.  It matters only for "runtime" or 
> > "selective" suspend.)
> 
> But everything I did is:
> echo reboot > /sys/power/disk
> echo disk > /sys/power/state
> 
> No writing anywhere else.

You misunderstood.  I meant that attempts to suspend a USB device without 
first suspending all its children and interfaces can't happen when doing a 
global suspend.  That's still true.

Your problem occurred because even though the PM core did _attempt_ to 
suspend the new children added by Greg's patch, it didn't _succeed_ 
because the patch did not provide suspend or resume methods.

Alan Stern

Re: [linux-pm] swsusp regression [Was: 2.6.17-mm1]

[Greg KH]

On Thu, Jun 22, 2006 at 05:09:43PM -0400, Alan Stern wrote:
> On Thu, 22 Jun 2006, Jiri Slaby wrote:
> 
> > > ages.  The "bogus requests" are attempts by the user to suspend a USB
> > > device (by writing to /sys/devices/.../power/state) without first
> > > suspending all its children and interfaces.
> > > 
> > > (This can't happen when doing a global suspend because the PM core 
> > > iterates through the entire device tree.  It matters only for "runtime" or 
> > > "selective" suspend.)
> > 
> > But everything I did is:
> > echo reboot > /sys/power/disk
> > echo disk > /sys/power/state
> > 
> > No writing anywhere else.
> 
> You misunderstood.  I meant that attempts to suspend a USB device without 
> first suspending all its children and interfaces can't happen when doing a 
> global suspend.  That's still true.
> 
> Your problem occurred because even though the PM core did _attempt_ to 
> suspend the new children added by Greg's patch, it didn't _succeed_ 
> because the patch did not provide suspend or resume methods.

Which because they are virtual "devices" they do not need a suspend or
resume method, so not having any is just fine.  If we abort because of
something like this, the core logic is quite broken...

thanks,

greg k-h

2.6.17-mm1: UML failing w/o SKAS enabled

[Theodore Tso]

[-- Attachment #1: Type: text/plain, Size: 1028 bytes --]

When I tried compiling 2.6.17-mm1 without SKAS support, it failed to
link:

arch/um/sys-i386/built-in.o: In function `__setup_host_supports_tls':tls.c:(.init.text+0x14): undefined reference to `check_host_supports_tls'
collect2: ld returned 1 exit status

This can fixed be addressed with the attached patch, but it the
resulting kernel still doesn't boot:

<tytso@candygram>       {/usr/projects/uml/linux-2.6.17-mm1}
35% ./linux
Checking that ptrace can change system call numbers...OK
Checking syscall emulation patch for ptrace...OK
Checking advanced syscall emulation patch for ptrace...OK
Checking for tmpfs mount on /dev/shm...OK
Checking PROT_EXEC mmap in /dev/shm/...OK
UML running in TT mode
tracing thread pid = 25812
Checking that ptrace can change system call numbers...OK
Checking syscall emulation patch for ptrace...OK
Checking advanced syscall emulation patch for ptrace...OK

<tytso@candygram>       {/usr/projects/uml/linux-2.6.17-mm1}
36%

If anyone has any suggestions, I'd appreciate them.

							- Ted



[-- Attachment #2: fix-uml-no-skas --]
[-- Type: text/plain, Size: 489 bytes --]

Index: linux-2.6.17-mm1/arch/um/os-Linux/sys-i386/Makefile
===================================================================
--- linux-2.6.17-mm1.orig/arch/um/os-Linux/sys-i386/Makefile	2006-06-17 21:49:35.000000000 -0400
+++ linux-2.6.17-mm1/arch/um/os-Linux/sys-i386/Makefile	2006-06-22 17:28:59.000000000 -0400
@@ -3,7 +3,8 @@
 # Licensed under the GPL
 #
 
-obj-$(CONFIG_MODE_SKAS) = registers.o tls.o
+obj-$(CONFIG_MODE_SKAS) = registers.o
+obj-y = tls.o
 
 USER_OBJS := $(obj-y)
 

Re: 2.6.17-mm1: UML failing w/o SKAS enabled

[Andrew Morton]

Theodore Tso <tytso@mit.edu> wrote:
>
> When I tried compiling 2.6.17-mm1 without SKAS support, it failed to
> link:
> 
> arch/um/sys-i386/built-in.o: In function `__setup_host_supports_tls':tls.c:(.init.text+0x14): undefined reference to `check_host_supports_tls'
> collect2: ld returned 1 exit status
> 
> This can fixed be addressed with the attached patch,

--- linux-2.6.17-mm1.orig/arch/um/os-Linux/sys-i386/Makefile	2006-06-17 21:49:35.000000000 -0400
+++ linux-2.6.17-mm1/arch/um/os-Linux/sys-i386/Makefile	2006-06-22 17:28:59.000000000 -0400
@@ -3,7 +3,8 @@
 # Licensed under the GPL
 #
 
-obj-$(CONFIG_MODE_SKAS) = registers.o tls.o
+obj-$(CONFIG_MODE_SKAS) = registers.o
+obj-y = tls.o
 
 USER_OBJS := $(obj-y)
 


hm, I don't see anything in -mm which could cause this.

> but it the
> resulting kernel still doesn't boot:
> 
> <tytso@candygram>       {/usr/projects/uml/linux-2.6.17-mm1}
> 35% ./linux
> Checking that ptrace can change system call numbers...OK
> Checking syscall emulation patch for ptrace...OK
> Checking advanced syscall emulation patch for ptrace...OK
> Checking for tmpfs mount on /dev/shm...OK
> Checking PROT_EXEC mmap in /dev/shm/...OK
> UML running in TT mode
> tracing thread pid = 25812
> Checking that ptrace can change system call numbers...OK
> Checking syscall emulation patch for ptrace...OK
> Checking advanced syscall emulation patch for ptrace...OK
> 
> <tytso@candygram>       {/usr/projects/uml/linux-2.6.17-mm1}
> 36%
> 
> If anyone has any suggestions, I'd appreciate them.
> 

It's not clear what actually happened - did it quietly exit, or what?

I haven't run UML in several years, alas.  I should work out how to do it
(again).   Links to any uml-for-dummies site would be appreciated ;)

Re: 2.6.17-mm1: UML failing w/o SKAS enabled

[Jeff Dike]

On Thu, Jun 22, 2006 at 05:34:43PM -0400, Theodore Tso wrote:
> When I tried compiling 2.6.17-mm1 without SKAS support, it failed to
> link:

Why are you trying to do that?  tt mode is bitrotting - the only
reason it is still there is that skas mode doesn't fully support SMP
yet.  If SMP is the reason, then I'll add the necessary support and
send in the patch.

				Jeff

Re: 2.6.17-mm1: UML failing w/o SKAS enabled

[Jeff Dike]

On Thu, Jun 22, 2006 at 02:57:43PM -0700, Andrew Morton wrote:
> I haven't run UML in several years, alas.  I should work out how to do it
> (again).   Links to any uml-for-dummies site would be appreciated ;)

http://user-mode-linux.sourceforge.net/new/index.html

Scroll down to the "Getting Started" section.  You download two files,
uncompress them, and run UML.  The only way I can think to make it
easier would be to make it one file by sticking the filesystem in an
initramfs :-)

For building UML, see
	http://user-mode-linux.sourceforge.net/new/source.html

The important thing is to start with a defconfig in order to avoid
config grabbing the host's config from /boot.

				Jeff

Re: 2.6.17-mm1: kernel/lockdep.c: write-only variables

[Ingo Molnar]

* Adrian Bunk <bunk@stusta.de> wrote:

> The following variables in kernel/lockdep.c are write-only:
>   nr_hardirq_read_safe_locks
>   nr_hardirq_read_unsafe_locks
>   nr_hardirq_safe_locks
>   nr_hardirq_unsafe_locks
>   nr_softirq_read_safe_locks
>   nr_softirq_read_unsafe_locks
>   nr_softirq_safe_locks
>   nr_softirq_unsafe_locks
> 
> Is a usage pending or should they be removed?

they are stale - i'll remove them. (there's a new calculation method for 
them)

	Ingo

Re: 2.6.17-mm1: kernel/lockdep.c: write-only variables

[Ingo Molnar]

* Ingo Molnar <mingo@elte.hu> wrote:

> 
> * Adrian Bunk <bunk@stusta.de> wrote:
> 
> > The following variables in kernel/lockdep.c are write-only:
> >   nr_hardirq_read_safe_locks
> >   nr_hardirq_read_unsafe_locks
> >   nr_hardirq_safe_locks
> >   nr_hardirq_unsafe_locks
> >   nr_softirq_read_safe_locks
> >   nr_softirq_read_unsafe_locks
> >   nr_softirq_safe_locks
> >   nr_softirq_unsafe_locks
> > 
> > Is a usage pending or should they be removed?
> 
> they are stale - i'll remove them. (there's a new calculation method 
> for them)

the patch is below. (Andrew, please dont apply this one - will be part 
of another patchset)

	Ingo

---
 kernel/lockdep.c           |   16 ----------------
 kernel/lockdep_internals.h |    8 --------
 2 files changed, 24 deletions(-)

Index: linux/kernel/lockdep.c
===================================================================
--- linux.orig/kernel/lockdep.c
+++ linux/kernel/lockdep.c
@@ -271,14 +271,6 @@ atomic_t softirqs_off_events;
 atomic_t redundant_softirqs_on;
 atomic_t redundant_softirqs_off;
 atomic_t nr_unused_locks;
-atomic_t nr_hardirq_safe_locks;
-atomic_t nr_softirq_safe_locks;
-atomic_t nr_hardirq_unsafe_locks;
-atomic_t nr_softirq_unsafe_locks;
-atomic_t nr_hardirq_read_safe_locks;
-atomic_t nr_softirq_read_safe_locks;
-atomic_t nr_hardirq_read_unsafe_locks;
-atomic_t nr_softirq_read_unsafe_locks;
 atomic_t nr_cyclic_checks;
 atomic_t nr_cyclic_check_recursions;
 atomic_t nr_find_usage_forwards_checks;
@@ -1640,7 +1632,6 @@ static int mark_lock(struct task_struct 
 				LOCK_ENABLED_HARDIRQS_READ, "hard-read"))
 			return 0;
 #endif
-		debug_atomic_inc(&nr_hardirq_safe_locks);
 		if (hardirq_verbose(this->type))
 			ret = 2;
 		break;
@@ -1666,7 +1657,6 @@ static int mark_lock(struct task_struct 
 				LOCK_ENABLED_SOFTIRQS_READ, "soft-read"))
 			return 0;
 #endif
-		debug_atomic_inc(&nr_softirq_safe_locks);
 		if (softirq_verbose(this->type))
 			ret = 2;
 		break;
@@ -1680,7 +1670,6 @@ static int mark_lock(struct task_struct 
 		if (!check_usage_forwards(curr, this,
 					  LOCK_ENABLED_HARDIRQS, "hard"))
 			return 0;
-		debug_atomic_inc(&nr_hardirq_read_safe_locks);
 		if (hardirq_verbose(this->type))
 			ret = 2;
 		break;
@@ -1694,7 +1683,6 @@ static int mark_lock(struct task_struct 
 		if (!check_usage_forwards(curr, this,
 					  LOCK_ENABLED_SOFTIRQS, "soft"))
 			return 0;
-		debug_atomic_inc(&nr_softirq_read_safe_locks);
 		if (softirq_verbose(this->type))
 			ret = 2;
 		break;
@@ -1721,7 +1709,6 @@ static int mark_lock(struct task_struct 
 				   LOCK_USED_IN_HARDIRQ_READ, "hard-read"))
 			return 0;
 #endif
-		debug_atomic_inc(&nr_hardirq_unsafe_locks);
 		if (hardirq_verbose(this->type))
 			ret = 2;
 		break;
@@ -1748,7 +1735,6 @@ static int mark_lock(struct task_struct 
 				   LOCK_USED_IN_SOFTIRQ_READ, "soft-read"))
 			return 0;
 #endif
-		debug_atomic_inc(&nr_softirq_unsafe_locks);
 		if (softirq_verbose(this->type))
 			ret = 2;
 		break;
@@ -1764,7 +1750,6 @@ static int mark_lock(struct task_struct 
 					   LOCK_USED_IN_HARDIRQ, "hard"))
 			return 0;
 #endif
-		debug_atomic_inc(&nr_hardirq_read_unsafe_locks);
 		if (hardirq_verbose(this->type))
 			ret = 2;
 		break;
@@ -1780,7 +1765,6 @@ static int mark_lock(struct task_struct 
 					   LOCK_USED_IN_SOFTIRQ, "soft"))
 			return 0;
 #endif
-		debug_atomic_inc(&nr_softirq_read_unsafe_locks);
 		if (softirq_verbose(this->type))
 			ret = 2;
 		break;
Index: linux/kernel/lockdep_internals.h
===================================================================
--- linux.orig/kernel/lockdep_internals.h
+++ linux/kernel/lockdep_internals.h
@@ -69,14 +69,6 @@ extern atomic_t softirqs_off_events;
 extern atomic_t redundant_softirqs_on;
 extern atomic_t redundant_softirqs_off;
 extern atomic_t nr_unused_locks;
-extern atomic_t nr_hardirq_safe_locks;
-extern atomic_t nr_softirq_safe_locks;
-extern atomic_t nr_hardirq_unsafe_locks;
-extern atomic_t nr_softirq_unsafe_locks;
-extern atomic_t nr_hardirq_read_safe_locks;
-extern atomic_t nr_softirq_read_safe_locks;
-extern atomic_t nr_hardirq_read_unsafe_locks;
-extern atomic_t nr_softirq_read_unsafe_locks;
 extern atomic_t nr_cyclic_checks;
 extern atomic_t nr_cyclic_check_recursions;
 extern atomic_t nr_find_usage_forwards_checks;

Re: [linux-pm] swsusp regression [Was: 2.6.17-mm1]

[Frederik Deweerdt]

On Thu, Jun 22, 2006 at 09:25:06AM -0700, Andrew Morton wrote:
> On Thu, 22 Jun 2006 18:04:03 +0200
> Frederik Deweerdt <deweerdt@free.fr> wrote:
> 
> > Thu, Jun 22, 2006 at 12:46:48AM -0700, Andrew Morton wrote:
> > > I can bisect it if we're stuck, but that'll require beer or something.
> > 
> > FWIW, my laptop (Dell D610) gave the following results:
> > 2.6.17-mm1: suspend_device(): usb_generic_suspend+0x0/0x135 [usbcore]() returns -16
> > 2.6.17+origin.patch: suspend_device(): usb_generic_suspend+0x0/0x135 [usbcore]() returns -16
> 
> So it's in mainline already - hence it's some recently-written thing which
> was not tested in rc6-mm2.
> 
> > 2.6.17: oops
> > 2.6.17.1: oops
> 
> 2.6.17 wasn't supposed to oops.  Do you have details on this?
> 
For some reason, unknown to me, the oops won't display on the serial link :(.

Here's what I could hand copy (I've suppressed printk timing information):
x1b9/0x1be
<c0166e6b> sys_write+0x4b/0x75  <c010300f> sysenter_past_esp+0x54/0x75
Code: 05 c4 52 43 c0 31 53 43 c0 c3 8b 2d 68 6e 54 c0 8b 1d 60
6e 54 c0 8b 35 6c 6e 54 c0 8b 3d 70 6e 54 c0 ff 35 74 6e 54 c0 9d c3 90 <e8>
9d 2c ea ff e8 a2 ff ff ff 6a 03 e8 4c ab de ff 83 c4 04 c3
EIP: [<c043531c>] do_suspend_lowlevel+0x0/0x15 SS:ESP 0068:f7a0fea4
<3>BUG: sleeping function called from invalid context at include/linux/rwsem.h:43
in_atomic():0, irqs_disabled():1
 <c0103e56> show_trace+0x20/0x22  <c0103f5b> dump_stack+0x1e/0x20
 <c011aec7> __might_sleep+0x9e/0xa6  <c012b0cf> blocking_notifier_call_chain+0x1e/0x5b
 <c011f091> profile_task_exit+0x21/0x23  <c0120946> do_exit+0x1d/0x483
 <c0104432> do_divide_error+0x0/0xbf  <c0362c76> do_page_fault+0x3c4/0x752
 <c0103b2f> error_code+0x4f/0x54  <c013b33a> suspend_enter+0x2f/0x52
 <c013b3e0> enter_state+0x4b/0x8d  <c013b579> state_store+0xa0/0xa2
 <c01a54f1> subsys_attr_store+0x37/0x41  <c01a5772> flush_write_buffer+0x3c/046
 <c01a57e3> sysfs_write_file+0x67/0x8b  <c0166da6> vfs_write+0x1b9/0x1be
 <c0166e6b> sys_write+0x4b/0x75  <c010300f> sysenter_past_esp+0x54/0x75

This is triggered on a 2.6.17.1 kernel by:
echo mem > /sys/power/state

.config and dmesg are here:
http://fdeweerdt.free.fr/suspend_oops/

Regards,
Frederik

Re: [linux-pm] swsusp regression [Was: 2.6.17-mm1]

[Pavel Machek]

Hi!

> > Frederik Deweerdt <deweerdt@free.fr> wrote:
> > 
> > > Thu, Jun 22, 2006 at 12:46:48AM -0700, Andrew Morton wrote:
> > > > I can bisect it if we're stuck, but that'll require beer or something.
> > > 
> > > FWIW, my laptop (Dell D610) gave the following results:
> > > 2.6.17-mm1: suspend_device(): usb_generic_suspend+0x0/0x135 [usbcore]() returns -16
> > > 2.6.17+origin.patch: suspend_device(): usb_generic_suspend+0x0/0x135 [usbcore]() returns -16
> > 
> > So it's in mainline already - hence it's some recently-written thing which
> > was not tested in rc6-mm2.
> > 
> > > 2.6.17: oops
> > > 2.6.17.1: oops
> > 
> > 2.6.17 wasn't supposed to oops.  Do you have details on this?
> > 
> For some reason, unknown to me, the oops won't display on the serial
> link :(.

Serial console is currently broken by suspend, resume. _But_ I have a
patch I'd like you to try.... pretty please?

> Here's what I could hand copy (I've suppressed printk timing information):
> x1b9/0x1be
> <c0166e6b> sys_write+0x4b/0x75  <c010300f> sysenter_past_esp+0x54/0x75
> Code: 05 c4 52 43 c0 31 53 43 c0 c3 8b 2d 68 6e 54 c0 8b 1d 60
> 6e 54 c0 8b 35 6c 6e 54 c0 8b 3d 70 6e 54 c0 ff 35 74 6e 54 c0 9d c3 90 <e8>
> 9d 2c ea ff e8 a2 ff ff ff 6a 03 e8 4c ab de ff 83 c4 04 c3
> EIP: [<c043531c>] do_suspend_lowlevel+0x0/0x15 SS:ESP 0068:f7a0fea4
> <3>BUG: sleeping function called from invalid context at include/linux/rwsem.h:43
> in_atomic():0, irqs_disabled():1
>  <c0103e56> show_trace+0x20/0x22  <c0103f5b> dump_stack+0x1e/0x20
>  <c011aec7> __might_sleep+0x9e/0xa6  <c012b0cf> blocking_notifier_call_chain+0x1e/0x5b
>  <c011f091> profile_task_exit+0x21/0x23  <c0120946> do_exit+0x1d/0x483
>  <c0104432> do_divide_error+0x0/0xbf  <c0362c76> do_page_fault+0x3c4/0x752
>  <c0103b2f> error_code+0x4f/0x54  <c013b33a> suspend_enter+0x2f/0x52
>  <c013b3e0> enter_state+0x4b/0x8d  <c013b579> state_store+0xa0/0xa2
>  <c01a54f1> subsys_attr_store+0x37/0x41  <c01a5772> flush_write_buffer+0x3c/046
>  <c01a57e3> sysfs_write_file+0x67/0x8b  <c0166da6> vfs_write+0x1b9/0x1be
>  <c0166e6b> sys_write+0x4b/0x75  <c010300f> sysenter_past_esp+0x54/0x75

That is not an oops, rather a kernel BUG(). Can you just remove
might_sleep line and see what happens?

Unfortunately, backtrace does not tell me which notifier chain did
that :-(. Are you using audit or something like that?

/*
 * lock for reading
 */
static inline void down_read(struct rw_semaphore *sem)
{
        might_sleep();
~~~~~~~~~~~~~~~~~~~~~~
        rwsemtrace(sem,"Entering down_read");
        __down_read(sem);
        rwsemtrace(sem,"Leaving down_read");
}

										Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [linux-pm] swsusp regression [Was: 2.6.17-mm1]

[Andrew Morton]

On Fri, 23 Jun 2006 11:10:21 +0200
Pavel Machek <pavel@ucw.cz> wrote:

> > Here's what I could hand copy (I've suppressed printk timing information):
> > x1b9/0x1be
> > <c0166e6b> sys_write+0x4b/0x75  <c010300f> sysenter_past_esp+0x54/0x75
> > Code: 05 c4 52 43 c0 31 53 43 c0 c3 8b 2d 68 6e 54 c0 8b 1d 60
> > 6e 54 c0 8b 35 6c 6e 54 c0 8b 3d 70 6e 54 c0 ff 35 74 6e 54 c0 9d c3 90 <e8>
> > 9d 2c ea ff e8 a2 ff ff ff 6a 03 e8 4c ab de ff 83 c4 04 c3
> > EIP: [<c043531c>] do_suspend_lowlevel+0x0/0x15 SS:ESP 0068:f7a0fea4
> > <3>BUG: sleeping function called from invalid context at include/linux/rwsem.h:43
> > in_atomic():0, irqs_disabled():1
> >  <c0103e56> show_trace+0x20/0x22  <c0103f5b> dump_stack+0x1e/0x20
> >  <c011aec7> __might_sleep+0x9e/0xa6  <c012b0cf> blocking_notifier_call_chain+0x1e/0x5b
> >  <c011f091> profile_task_exit+0x21/0x23  <c0120946> do_exit+0x1d/0x483
> >  <c0104432> do_divide_error+0x0/0xbf  <c0362c76> do_page_fault+0x3c4/0x752
> >  <c0103b2f> error_code+0x4f/0x54  <c013b33a> suspend_enter+0x2f/0x52
> >  <c013b3e0> enter_state+0x4b/0x8d  <c013b579> state_store+0xa0/0xa2
> >  <c01a54f1> subsys_attr_store+0x37/0x41  <c01a5772> flush_write_buffer+0x3c/046
> >  <c01a57e3> sysfs_write_file+0x67/0x8b  <c0166da6> vfs_write+0x1b9/0x1be
> >  <c0166e6b> sys_write+0x4b/0x75  <c010300f> sysenter_past_esp+0x54/0x75
> 
> That is not an oops, rather a kernel BUG().

It's not a BUG().  It's a BUG.

IOW, it's just a WARN_ON().  Ingo decided all the scary messages should
start with the text "BUG".  That doesn't correlate with BUG().  Confused
yet?

That trace is odd.  It kinda looks like we got a segfault when entering the
do_suspend_lowlevel() assembly.  Or something.

> Can you just remove
> might_sleep line and see what happens?
> 
> Unfortunately, backtrace does not tell me which notifier chain did
> that :-(. Are you using audit or something like that?

No, that's all a consequence of something which happened earlier.

Re: 2.6.17-mm1: UML failing w/o SKAS enabled

[Roman Zippel]

Hi,

On Thu, 22 Jun 2006, Jeff Dike wrote:

> The important thing is to start with a defconfig in order to avoid
> config grabbing the host's config from /boot.

BTW this can be now configured. Check DEFCONFIG_LIST in init/Kconfig in 
-mm.

bye, Roman

Re: 2.6.17-mm1

[Mel Gorman]

On (22/06/06 19:25), Franck Bui-Huu didst pronounce:
> 2006/6/22, Mel Gorman <mel@csn.ul.ie>:
> >On Thu, 22 Jun 2006, Franck Bui-Huu wrote:
> >
> >> Mel Gorman wrote:
> >>> On Thu, 22 Jun 2006, Franck Bui-Huu wrote:
> >>>>
> >>>> Should ARCH_PFN_OFFSET macro be used instead in order to make pfn/page
> >>>> convertions work when node 0 start offset do not start at 0 ?
> >>>>
> >>>
> >>> What happens if you have ARCH_PFN_OFFSET as
> >>>
> >>> #define ARCH_PFN_OFFSET (0UL)
> >>>
> >>> ?
> >>
> >> It's the default value (see memory_model.h). It means that pfn start
> >> for node 0 is 0, therefore your physical memory address starts at 0.
> >>
> >
> >I know, but what I'm getting at is that ARCH_PFN_OFFSET may be unnecessary
> >with flatmem-relax-requirement-for-memory-to-start-at-pfn-0.patch applied.
> 
> yes it seems so. But ARCH_PFN_OFFSET has been used before your patch
> has been sent. So your patch seems to be incomplete...

Difficult to argue with that logic.

> 
> >ARCH_PFN_OFFSET is used as
> >
> >#define page_to_pfn(page)       ((unsigned long)((page) - mem_map) + \
> >                                  ARCH_PFN_OFFSET)
> >
> >because it knew that the map may not start at PFN 0. With
> >flatmem-relax-requirement-for-memory-to-start-at-pfn-0.patch, the map will
> >start at PFN 0 even if physical memory does not start until later.
> >
> 
> well your approach's trick is on the mem_map address whereas
> ARCH_PFN_OFFSET's one is on the computation of the index. Your
> solution may result in smaller kernel (when ARCH_PFN_OFFSET != 0)
> because in your case page/pfn conversion is simpler.
> 
> Maybe in your patch instead of doing:
> 
>        map -= pgdat->node_start_pfn;
> 
> you could do:
> 
>        map -= ARCH_OFFSET_PFN;
> 

That will assume that ARCH_OFFSET_PFN is always equal to
NODE_DATA(0)->node_start_pfn which may cause other breakage further down
the line. How about something like this? (boot tested on x86 only)


>>> Begin patch

The FLATMEM memory model assumes that memory is
on contiguous area starting from PFN 0.  The patch
flatmem-relax-requirement-for-memory-to-start-at-pfn-0.patch relaxed
this assumption by offsetting mem_map from NODE_DATA(0)->node_mem_map
by NODE_DATA(0)->node_start_pfn. However, some architectures are using
ARCH_OFFSET_PFN to do a similar job at a runtime cost which causes the map
to get offset twice.

This patch catches the situation where ARCH_OFFSET_PFN was being used to
workaround NODE_DATA(0)->node_start_pfn != 0 and prints a message letting
the arch maintainer know that ARCH_OFFSET_PFN may be safe to remove.
Once the message appears on no architectures, it may be safe to remove
ARCH_OFFSET_PFN totally.

diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.17-mm1-clean/include/asm-generic/memory_model.h linux-2.6.17-mm1-archpfnfix/include/asm-generic/memory_model.h
--- linux-2.6.17-mm1-clean/include/asm-generic/memory_model.h	2006-06-23 09:26:15.000000000 +0100
+++ linux-2.6.17-mm1-archpfnfix/include/asm-generic/memory_model.h	2006-06-23 10:44:18.000000000 +0100
@@ -28,9 +28,8 @@
  */
 #if defined(CONFIG_FLATMEM)
 
-#define __pfn_to_page(pfn)	(mem_map + ((pfn) - ARCH_PFN_OFFSET))
-#define __page_to_pfn(page)	((unsigned long)((page) - mem_map) + \
-				 ARCH_PFN_OFFSET)
+#define __pfn_to_page(pfn)	(mem_map + (pfn))
+#define __page_to_pfn(page)	((unsigned long)((page) - mem_map))
 #elif defined(CONFIG_DISCONTIGMEM)
 
 #define __pfn_to_page(pfn)			\
diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.17-mm1-clean/mm/page_alloc.c linux-2.6.17-mm1-archpfnfix/mm/page_alloc.c
--- linux-2.6.17-mm1-clean/mm/page_alloc.c	2006-06-23 09:26:15.000000000 +0100
+++ linux-2.6.17-mm1-archpfnfix/mm/page_alloc.c	2006-06-23 10:49:01.000000000 +0100
@@ -2316,7 +2316,22 @@ static void __init alloc_node_mem_map(st
 		 * is true. Adjust map relative to node_mem_map to
 		 * maintain this relationship.
 		 */
-		map -= pgdat->node_start_pfn;
+		if (ARCH_PFN_OFFSET == 0)
+			map -= pgdat->node_start_pfn;
+		else {
+			/*
+			 * If ARCH_PFN_OFFSET is being used to to workaround
+			 * old assumptions of the FLATMEM memory model, print
+			 * a message so that ARCH_PFN_OFFSET can be safely
+			 * removed. If there are no remaining users of
+			 * ARCH_PFN_OFFSET after this message no longer
+			 * shows up, it'll be safe to remove this else block
+			 */
+			if (ARCH_PFN_OFFSET == pgdat->node_start_pfn)
+				printk("ARCH_PFN_OFFSET not necessary\n");
+
+			map -= ARCH_PFN_OFFSET;
+		}
 	}
 #ifdef CONFIG_FLATMEM
 	/*

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

[-mm patch] fs/reiser4/: possible cleanups

[Adrian Bunk]

This patch contains the following possible cleanups:
- make needlessly global code static
- proper prototype for the following function:
  - plugin/file/file.c: init_uf_coord()
- "extern inline" -> "static inline"
- #if 0/comment out the following unused functions:
  - plugin/file/cryptcompress.c: jnode_of_cluster()
  - plugin/plugin.c: force_plugin()
  - plugin/plugin_set.c: plugin_set_compression()
- remove the following unused variable:
  - plugin/file/file.c: xversion

Signed-off-by: Adrian Bunk <bunk@stusta.de>

---

 fs/reiser4/block_alloc.c                 |   10 +++++-----
 fs/reiser4/flush_queue.c                 |    2 +-
 fs/reiser4/jnode.c                       |    7 ++++---
 fs/reiser4/jnode.h                       |    4 ----
 fs/reiser4/plugin/cluster.h              |    1 -
 fs/reiser4/plugin/file/cryptcompress.c   |    6 ++++--
 fs/reiser4/plugin/file/cryptcompress.h   |    2 --
 fs/reiser4/plugin/file/file.c            |    4 +---
 fs/reiser4/plugin/file/file.h            |    4 ++--
 fs/reiser4/plugin/item/extent_file_ops.c |    2 --
 fs/reiser4/plugin/plugin.c               |    2 ++
 fs/reiser4/plugin/plugin.h               |    1 -
 fs/reiser4/plugin/plugin_set.c           |    2 +-
 fs/reiser4/plugin/plugin_set.h           |    1 -
 fs/reiser4/super.h                       |    1 -
 fs/reiser4/super_ops.c                   |    4 ++--
 fs/reiser4/txnmgr.h                      |    1 -
 17 files changed, 22 insertions(+), 32 deletions(-)

--- linux-2.6.17-mm1-full/fs/reiser4/block_alloc.c.old	2006-06-22 16:00:18.000000000 +0200
+++ linux-2.6.17-mm1-full/fs/reiser4/block_alloc.c	2006-06-22 16:02:35.000000000 +0200
@@ -554,8 +554,8 @@
 
 /* adjust sb block counters, if real (on-disk) block allocation immediately
    follows grabbing of free disk space. */
-void grabbed2used(reiser4_context *ctx, reiser4_super_info_data *sbinfo,
-		  __u64 count)
+static void grabbed2used(reiser4_context *ctx, reiser4_super_info_data *sbinfo,
+			 __u64 count)
 {
 	sub_from_ctx_grabbed(ctx, count);
 
@@ -570,8 +570,8 @@
 }
 
 /* adjust sb block counters when @count unallocated blocks get mapped to disk */
-void fake_allocated2used(reiser4_super_info_data *sbinfo, __u64 count,
-			 reiser4_ba_flags_t flags)
+static void fake_allocated2used(reiser4_super_info_data *sbinfo, __u64 count,
+				reiser4_ba_flags_t flags)
 {
 	spin_lock_reiser4_super(sbinfo);
 
@@ -583,7 +583,7 @@
 	spin_unlock_reiser4_super(sbinfo);
 }
 
-void flush_reserved2used(txn_atom * atom, __u64 count)
+static void flush_reserved2used(txn_atom * atom, __u64 count)
 {
 	reiser4_super_info_data *sbinfo;
 
--- linux-2.6.17-mm1-full/fs/reiser4/txnmgr.h.old	2006-06-22 16:02:59.000000000 +0200
+++ linux-2.6.17-mm1-full/fs/reiser4/txnmgr.h	2006-06-22 16:03:04.000000000 +0200
@@ -661,7 +661,6 @@
 extern void fq_put(flush_queue_t *);
 extern void fuse_fq(txn_atom * to, txn_atom * from);
 extern void queue_jnode(flush_queue_t *, jnode *);
-extern void mark_jnode_queued(flush_queue_t *, jnode *);
 
 extern int write_fq(flush_queue_t *, long *, int);
 extern int current_atom_finish_all_fq(void);
--- linux-2.6.17-mm1-full/fs/reiser4/flush_queue.c.old	2006-06-22 16:03:13.000000000 +0200
+++ linux-2.6.17-mm1-full/fs/reiser4/flush_queue.c	2006-06-22 16:03:20.000000000 +0200
@@ -191,7 +191,7 @@
 }
 
 /* */
-void mark_jnode_queued(flush_queue_t * fq, jnode * node)
+static void mark_jnode_queued(flush_queue_t * fq, jnode * node)
 {
 	JF_SET(node, JNODE_FLUSH_QUEUED);
 	count_enqueued_node(fq);
--- linux-2.6.17-mm1-full/fs/reiser4/jnode.h.old	2006-06-22 16:04:24.000000000 +0200
+++ linux-2.6.17-mm1-full/fs/reiser4/jnode.h	2006-06-22 16:05:25.000000000 +0200
@@ -349,12 +349,8 @@
 extern jnode *jnode_by_page(struct page *pg) NONNULL;
 extern jnode *jnode_of_page(struct page *pg) NONNULL;
 void jnode_attach_page(jnode * node, struct page *pg);
-jnode *find_get_jnode(reiser4_tree * tree,
-		      struct address_space *mapping, oid_t oid,
-		      unsigned long index);
 
 void unhash_unformatted_jnode(jnode *);
-struct page *jnode_get_page_locked(jnode *, gfp_t gfp_flags);
 extern jnode *page_next_jnode(jnode * node) NONNULL;
 extern void jnode_init(jnode * node, reiser4_tree * tree, jnode_type) NONNULL;
 extern void jnode_make_dirty(jnode * node) NONNULL;
--- linux-2.6.17-mm1-full/fs/reiser4/jnode.c.old	2006-06-22 16:04:40.000000000 +0200
+++ linux-2.6.17-mm1-full/fs/reiser4/jnode.c	2006-06-22 16:05:34.000000000 +0200
@@ -537,8 +537,9 @@
  * allocate new jnode, insert it, and also insert into radix tree for the
  * given inode/mapping.
  */
-jnode *find_get_jnode(reiser4_tree * tree, struct address_space *mapping,
-		      oid_t oid, unsigned long index)
+static jnode *find_get_jnode(reiser4_tree * tree,
+			     struct address_space *mapping,
+			     oid_t oid, unsigned long index)
 {
 	jnode *result;
 	jnode *shadow;
@@ -786,7 +787,7 @@
 
 /* Lock a page attached to jnode, create and attach page to jnode if it had no
  * one. */
-struct page *jnode_get_page_locked(jnode * node, gfp_t gfp_flags)
+static struct page *jnode_get_page_locked(jnode * node, gfp_t gfp_flags)
 {
 	struct page *page;
 
--- linux-2.6.17-mm1-full/fs/reiser4/plugin/file/cryptcompress.h.old	2006-06-22 16:06:08.000000000 +0200
+++ linux-2.6.17-mm1-full/fs/reiser4/plugin/file/cryptcompress.h	2006-06-22 16:07:20.000000000 +0200
@@ -459,7 +459,6 @@
 void save_file_hint(struct file *, const hint_t *);
 void hint_init_zero(hint_t *);
 int crc_inode_ok(struct inode *inode);
-int jnode_of_cluster(const jnode * node, struct page * page);
 extern int ctail_read_disk_cluster (reiser4_cluster_t *, struct inode *, int);
 extern int do_readpage_ctail(struct inode *, reiser4_cluster_t *,
 			     struct page * page);
@@ -472,7 +471,6 @@
 				int (*can_inherit)(struct inode * child,
 						   struct inode * parent));
 void attach_crypto_stat(struct inode * inode, crypto_stat_t * info);
-void detach_crypto_stat(struct inode * inode);
 void change_crypto_stat(struct inode * inode, crypto_stat_t * new);
 crypto_stat_t * alloc_crypto_stat (struct inode * inode);
 
--- linux-2.6.17-mm1-full/fs/reiser4/plugin/cluster.h.old	2006-06-22 16:06:47.000000000 +0200
+++ linux-2.6.17-mm1-full/fs/reiser4/plugin/cluster.h	2006-06-22 16:06:53.000000000 +0200
@@ -240,7 +240,6 @@
 
 int inflate_cluster(reiser4_cluster_t *, struct inode *);
 int find_cluster(reiser4_cluster_t *, struct inode *, int read, int write);
-void forget_cluster_pages(struct page **page, int nrpages);
 int flush_cluster_pages(reiser4_cluster_t *, jnode *, struct inode *);
 int deflate_cluster(reiser4_cluster_t *, struct inode *);
 void truncate_page_cluster(struct inode *inode, cloff_t start);
--- linux-2.6.17-mm1-full/fs/reiser4/plugin/file/cryptcompress.c.old	2006-06-22 16:06:19.000000000 +0200
+++ linux-2.6.17-mm1-full/fs/reiser4/plugin/file/cryptcompress.c	2006-06-22 16:07:39.000000000 +0200
@@ -380,7 +380,7 @@
 }
 #endif  /*  REISER4_DEBUG  */
 
-void detach_crypto_stat(struct inode * inode)
+static void detach_crypto_stat(struct inode * inode)
 {
 	assert("edward-1385", inode != NULL);
 	assert("edward-1386", host_allows_crypto_stat(inode));
@@ -1574,6 +1574,7 @@
    understand that pages of cryptcompress files are not
    flushable.
 */
+#if 0
 int jnode_of_cluster(const jnode * node, struct page * page)
 {
 	assert("edward-1339", node != NULL);
@@ -1597,6 +1598,7 @@
 	}
 	return 0;
 }
+#endif  /*  0  */
 
 /* put cluster pages */
 void release_cluster_pages(reiser4_cluster_t * clust)
@@ -1751,7 +1753,7 @@
 	jput(node);
 }
 
-void forget_cluster_pages(struct page **pages, int nr)
+static void forget_cluster_pages(struct page **pages, int nr)
 {
 	int i;
 	for (i = 0; i < nr; i++) {
--- linux-2.6.17-mm1-full/fs/reiser4/plugin/file/file.h.old	2006-06-22 16:07:55.000000000 +0200
+++ linux-2.6.17-mm1-full/fs/reiser4/plugin/file/file.h	2006-06-22 16:18:08.000000000 +0200
@@ -114,7 +114,6 @@
 			  const reiser4_key *, znode_lock_mode,
 			  struct inode *);
 
-void validate_extended_coord(uf_coord_t *, loff_t offset);
 int load_file_hint(struct file *, hint_t *);
 void save_file_hint(struct file *, const hint_t *);
 
@@ -235,8 +234,9 @@
 int find_or_create_extent(struct page *);
 int equal_to_ldk(znode *, const reiser4_key *);
 
+void init_uf_coord(uf_coord_t *uf_coord, lock_handle *lh);
 
-extern inline int cbk_errored(int cbk_result)
+static inline int cbk_errored(int cbk_result)
 {
 	return (cbk_result != CBK_COORD_NOTFOUND
 		&& cbk_result != CBK_COORD_FOUND);
--- linux-2.6.17-mm1-full/fs/reiser4/plugin/item/extent_file_ops.c.old	2006-06-22 16:49:24.000000000 +0200
+++ linux-2.6.17-mm1-full/fs/reiser4/plugin/item/extent_file_ops.c	2006-06-22 16:49:51.000000000 +0200
@@ -734,8 +734,6 @@
 	return count;
 }
 
-void init_uf_coord(uf_coord_t *uf_coord, lock_handle *lh);
-
 /**
  * update_extent
  * @file:
--- linux-2.6.17-mm1-full/fs/reiser4/plugin/file/file.c.old	2006-06-22 16:08:12.000000000 +0200
+++ linux-2.6.17-mm1-full/fs/reiser4/plugin/file/file.c	2006-06-22 16:08:37.000000000 +0200
@@ -103,7 +103,7 @@
 	uf_coord->valid = 0;
 }
 
-void validate_extended_coord(uf_coord_t *uf_coord, loff_t offset)
+static void validate_extended_coord(uf_coord_t *uf_coord, loff_t offset)
 {
 	assert("vs-1333", uf_coord->valid == 0);
 
@@ -760,8 +760,6 @@
 			     hint->ext_coord.lh, lock_mode, ZNODE_LOCK_LOPRI);
 }
 
-int xversion;
-
 /**
  * find_or_create_extent -
  * @page:
--- linux-2.6.17-mm1-full/fs/reiser4/plugin/plugin.h.old	2006-06-22 16:09:55.000000000 +0200
+++ linux-2.6.17-mm1-full/fs/reiser4/plugin/plugin.h	2006-06-22 16:10:05.000000000 +0200
@@ -886,7 +886,6 @@
 int grab_plugin(struct inode *self, struct inode *ancestor, pset_member memb);
 int grab_plugin_from(struct inode *self, pset_member memb,
 		     reiser4_plugin * plug);
-int force_plugin(struct inode *self, pset_member memb, reiser4_plugin * plug);
 
 /* defined in fs/reiser4/plugin/object.c */
 extern file_plugin file_plugins[LAST_FILE_PLUGIN_ID];
--- linux-2.6.17-mm1-full/fs/reiser4/plugin/plugin.c.old	2006-06-22 16:10:12.000000000 +0200
+++ linux-2.6.17-mm1-full/fs/reiser4/plugin/plugin.c	2006-06-22 16:11:03.000000000 +0200
@@ -348,6 +348,7 @@
 	return result;
 }
 
+#if 0
 int force_plugin(struct inode *self, pset_member memb, reiser4_plugin * plug)
 {
 	reiser4_inode *info;
@@ -362,6 +363,7 @@
 		update_plugin_mask(info, memb);
 	return result;
 }
+#endif  /*  0  */
 
 reiser4_plugin_type_data plugins[REISER4_PLUGIN_TYPES] = {
 	/* C90 initializers */
--- linux-2.6.17-mm1-full/fs/reiser4/plugin/plugin_set.h.old	2006-06-22 16:11:33.000000000 +0200
+++ linux-2.6.17-mm1-full/fs/reiser4/plugin/plugin_set.h	2006-06-22 16:11:42.000000000 +0200
@@ -57,7 +57,6 @@
 extern int plugin_set_hash(plugin_set ** set, hash_plugin * plug);
 extern int plugin_set_fibration(plugin_set ** set, fibration_plugin * plug);
 extern int plugin_set_sd(plugin_set ** set, item_plugin * plug);
-extern int plugin_set_compression(plugin_set ** set, compression_plugin * plug);
 extern int plugin_set_cluster(plugin_set ** set, cluster_plugin * plug);
 
 extern int init_plugin_set(void);
--- linux-2.6.17-mm1-full/fs/reiser4/plugin/plugin_set.c.old	2006-06-22 16:11:54.000000000 +0200
+++ linux-2.6.17-mm1-full/fs/reiser4/plugin/plugin_set.c	2006-06-22 16:12:25.000000000 +0200
@@ -322,7 +322,7 @@
     DEFINE_PLUGIN_SET(item_plugin, sd)
     /* DEFINE_PLUGIN_SET(cipher_plugin, cipher) */
     /* DEFINE_PLUGIN_SET(digest_plugin, digest) */
-    DEFINE_PLUGIN_SET(compression_plugin, compression)
+    /* DEFINE_PLUGIN_SET(compression_plugin, compression) */
     /* DEFINE_PLUGIN_SET(compression_mode_plugin, compression_mode) */
     DEFINE_PLUGIN_SET(cluster_plugin, cluster)
     /* DEFINE_PLUGIN_SET(regular_plugin, regular_entry) */
--- linux-2.6.17-mm1-full/fs/reiser4/super.h.old	2006-06-22 16:12:41.000000000 +0200
+++ linux-2.6.17-mm1-full/fs/reiser4/super.h	2006-06-22 16:12:46.000000000 +0200
@@ -452,7 +452,6 @@
 extern struct super_operations reiser4_super_operations;
 extern struct export_operations reiser4_export_operations;
 extern struct dentry_operations reiser4_dentry_operations;
-extern struct dentry *reiser4_debugfs_root;
 
 /* __REISER4_SUPER_H__ */
 #endif
--- linux-2.6.17-mm1-full/fs/reiser4/super_ops.c.old	2006-06-22 16:12:55.000000000 +0200
+++ linux-2.6.17-mm1-full/fs/reiser4/super_ops.c	2006-06-22 16:13:16.000000000 +0200
@@ -16,6 +16,8 @@
 /* slab cache for inodes */
 static kmem_cache_t *inode_cache;
 
+static struct dentry *reiser4_debugfs_root = NULL;
+
 /**
  * init_once - constructor for reiser4 inodes
  * @obj: inode to be initialized
@@ -593,8 +595,6 @@
 	*cachep = NULL;
 }
 
-struct dentry *reiser4_debugfs_root = NULL;
-
 /**
  * init_reiser4 - reiser4 initialization entry point
  *

[-mm patch] fs/ufs/inode.c: make 2 functions static

[Adrian Bunk]

This patch makes two needlessly global functions static.

Signed-off-by: Adrian Bunk <bunk@stusta.de>

---

 fs/ufs/inode.c         |    9 ++++++---
 include/linux/ufs_fs.h |    2 --
 2 files changed, 6 insertions(+), 5 deletions(-)

--- linux-2.6.17-mm1-full/include/linux/ufs_fs.h.old	2006-06-22 16:52:18.000000000 +0200
+++ linux-2.6.17-mm1-full/include/linux/ufs_fs.h	2006-06-22 16:53:11.000000000 +0200
@@ -973,13 +973,11 @@
 extern struct inode * ufs_new_inode (struct inode *, int);
 
 /* inode.c */
-extern u64  ufs_frag_map (struct inode *, sector_t);
 extern void ufs_read_inode (struct inode *);
 extern void ufs_put_inode (struct inode *);
 extern int ufs_write_inode (struct inode *, int);
 extern int ufs_sync_inode (struct inode *);
 extern void ufs_delete_inode (struct inode *);
-extern struct buffer_head * ufs_getfrag (struct inode *, unsigned, int, int *);
 extern struct buffer_head * ufs_bread (struct inode *, unsigned, int, int *);
 extern int ufs_getfrag_block (struct inode *inode, sector_t fragment, struct buffer_head *bh_result, int create);
 
--- linux-2.6.17-mm1-full/fs/ufs/inode.c.old	2006-06-22 16:52:31.000000000 +0200
+++ linux-2.6.17-mm1-full/fs/ufs/inode.c	2006-06-22 16:55:15.000000000 +0200
@@ -41,6 +41,8 @@
 #include "swab.h"
 #include "util.h"
 
+static u64 ufs_frag_map(struct inode *inode, sector_t frag);
+
 static int ufs_block_to_path(struct inode *inode, sector_t i_block, sector_t offsets[4])
 {
 	struct ufs_sb_private_info *uspi = UFS_SB(inode->i_sb)->s_uspi;
@@ -80,7 +82,7 @@
  * the begining of the filesystem.
  */
 
-u64  ufs_frag_map(struct inode *inode, sector_t frag)
+static u64 ufs_frag_map(struct inode *inode, sector_t frag)
 {
 	struct ufs_inode_info *ufsi = UFS_I(inode);
 	struct super_block *sb = inode->i_sb;
@@ -514,8 +516,9 @@
 	goto abort;
 }
 
-struct buffer_head *ufs_getfrag(struct inode *inode, unsigned int fragment,
-				int create, int *err)
+static struct buffer_head *ufs_getfrag(struct inode *inode,
+				       unsigned int fragment,
+				       int create, int *err)
 {
 	struct buffer_head dummy;
 	int error;

[-mm patch] make ipc/sem.c:exit_sem() static

[Adrian Bunk]

On Wed, Jun 21, 2006 at 03:48:57AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.17-rc6-mm2:
>...
> +task-watchers-register-semundo-task-watcher.patch
>...
>  API for registering against task lifecycle events.
>...

exit_sem() can now become static.

Signed-off-by: Adrian Bunk <bunk@stusta.de>

---

 include/linux/sem.h |    5 -----
 ipc/sem.c           |    3 ++-
 2 files changed, 2 insertions(+), 6 deletions(-)

--- linux-2.6.17-mm1-full/include/linux/sem.h.old	2006-06-22 17:10:52.000000000 +0200
+++ linux-2.6.17-mm1-full/include/linux/sem.h	2006-06-22 17:11:02.000000000 +0200
@@ -141,7 +141,6 @@
 #ifdef CONFIG_SYSVIPC
 
 extern int copy_semundo(unsigned long clone_flags, struct task_struct *tsk);
-extern void exit_sem(struct task_struct *tsk);
 
 #else
 static inline int copy_semundo(unsigned long clone_flags, struct task_struct *tsk)
@@ -149,10 +148,6 @@
 	return 0;
 }
 
-static inline void exit_sem(struct task_struct *tsk)
-{
-	return;
-}
 #endif
 
 #endif /* __KERNEL__ */
--- linux-2.6.17-mm1-full/ipc/sem.c.old	2006-06-22 17:11:17.000000000 +0200
+++ linux-2.6.17-mm1-full/ipc/sem.c	2006-06-22 17:12:16.000000000 +0200
@@ -103,6 +103,7 @@
 
 static int newary (struct ipc_namespace *, key_t, int, int);
 static void freeary (struct ipc_namespace *ns, struct sem_array *sma, int id);
+static void exit_sem(struct task_struct *tsk);
 #ifdef CONFIG_PROC_FS
 static int sysvipc_sem_proc_show(struct seq_file *s, void *it);
 #endif
@@ -1350,7 +1351,7 @@
  * The current implementation does not do so. The POSIX standard
  * and SVID should be consulted to determine what behavior is mandated.
  */
-void exit_sem(struct task_struct *tsk)
+static void exit_sem(struct task_struct *tsk)
 {
 	struct sem_undo_list *undo_list;
 	struct sem_undo *u, **up;

[-mm patch] kernel/lockdep.c: make 3 functions static

[Adrian Bunk]

This patch makes three needlessly global functions static.

Signed-off-by: Adrian Bunk <bunk@stusta.de>

---

 kernel/lockdep.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

--- linux-2.6.17-mm1-full/kernel/lockdep.c.old	2006-06-22 17:39:33.000000000 +0200
+++ linux-2.6.17-mm1-full/kernel/lockdep.c	2006-06-22 17:48:58.000000000 +0200
@@ -444,7 +444,7 @@
 		printk("  ");
 }
 
-void print_lock_type_header(struct lock_type *type, int depth)
+static void print_lock_type_header(struct lock_type *type, int depth)
 {
 	int bit;
 
@@ -516,7 +516,7 @@
 	printk(" } [%d]", nr);
 }
 
-void print_lock_type(struct lock_type *type)
+static void print_lock_type(struct lock_type *type)
 {
 	print_lock_type_header(type, 0);
 	if (!list_empty(&type->locks_after))
@@ -1177,7 +1177,7 @@
  * To make lock name printouts unique, we calculate a unique
  * type->name_version generation counter:
  */
-int count_matching_names(struct lock_type *new_type)
+static int count_matching_names(struct lock_type *new_type)
 {
 	struct lock_type *type;
 	int count = 0;

[-mm patch] drivers/char/agp/nvidia-agp.c: remove unused variable

[Adrian Bunk]

On Wed, Jun 21, 2006 at 03:48:57AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.17-rc6-mm2:
>...
>  git-agpgart.patch
>...
>  git trees
>...

This patch removes an unused variable.

Signed-off-by: Adrian Bunk <bunk@stusta.de>

--- linux-2.6.17-mm1-full/drivers/char/agp/nvidia-agp.c.old	2006-06-22 18:31:18.000000000 +0200
+++ linux-2.6.17-mm1-full/drivers/char/agp/nvidia-agp.c	2006-06-22 18:31:39.000000000 +0200
@@ -387,8 +387,6 @@
 
 static int agp_nvidia_resume(struct pci_dev *pdev)
 {
-	struct agp_bridge_data *bridge = pci_get_drvdata(pdev);
-
 	/* set power state 0 and restore PCI space */
 	pci_set_power_state (pdev, 0);
 	pci_restore_state(pdev);

[-mm patch] make kernel/sysctl.c:_proc_do_string() static

[Adrian Bunk]

This patch makes the needlessly global _proc_do_string() static.

Signed-off-by: Adrian Bunk <bunk@stusta.de>

--- linux-2.6.17-mm1-full/kernel/sysctl.c.old	2006-06-22 20:50:08.000000000 +0200
+++ linux-2.6.17-mm1-full/kernel/sysctl.c	2006-06-22 20:50:39.000000000 +0200
@@ -1706,8 +1706,9 @@
 	return do_rw_proc(1, file, (char __user *) buf, count, ppos);
 }
 
-int _proc_do_string(void* data, int maxlen, int write, struct file *filp,
-		    void __user *buffer, size_t *lenp, loff_t *ppos)
+static int _proc_do_string(void* data, int maxlen, int write,
+			   struct file *filp, void __user *buffer,
+			   size_t *lenp, loff_t *ppos)
 {
 	size_t len;
 	char __user *p;

[-mm patch] make kernel/utsname.c:clone_uts_ns()

[Adrian Bunk]

This patch makes the needlessly global clone_uts_ns() static.

Signed-off-by: Adrian Bunk <bunk@stusta.de>

--- linux-2.6.17-mm1-full/kernel/utsname.c.old	2006-06-22 20:53:20.000000000 +0200
+++ linux-2.6.17-mm1-full/kernel/utsname.c	2006-06-22 20:53:31.000000000 +0200
@@ -19,7 +19,7 @@
  * @old_ns: namespace to clone
  * Return NULL on error (failure to kmalloc), new ns otherwise
  */
-struct uts_namespace *clone_uts_ns(struct uts_namespace *old_ns)
+static struct uts_namespace *clone_uts_ns(struct uts_namespace *old_ns)
 {
 	struct uts_namespace *ns;
 

[-mm patch] mm/readahead.c: cleanups

[Adrian Bunk]

This patch contains the following cleanups:
- make needlessly global code static
- rename the global variable debug_level (sic) to readahead_debug_level
- proper extern declaration for readahead_debug_level in 
  include/linux/mm.h

Signed-off-by: Adrian Bunk <bunk@stusta.de>

---

 include/linux/mm.h |    6 ++++++
 mm/filemap.c       |   12 +++---------
 mm/readahead.c     |   19 +++++++++----------
 3 files changed, 18 insertions(+), 19 deletions(-)

--- linux-2.6.17-mm1-full/include/linux/mm.h.old	2006-06-22 22:04:21.000000000 +0200
+++ linux-2.6.17-mm1-full/include/linux/mm.h	2006-06-22 22:09:13.000000000 +0200
@@ -1062,6 +1062,12 @@
 #endif
 }
 
+#ifdef CONFIG_DEBUG_READAHEAD
+extern u32 readahead_debug_level;
+#else
+#define readahead_debug_level 0
+#endif /* CONFIG_DEBUG_READAHEAD */
+
 /* Do stack extension */
 extern int expand_stack(struct vm_area_struct *vma, unsigned long address);
 #ifdef CONFIG_IA64
--- linux-2.6.17-mm1-full/mm/readahead.c.old	2006-06-22 20:57:07.000000000 +0200
+++ linux-2.6.17-mm1-full/mm/readahead.c	2006-06-23 00:31:25.000000000 +0200
@@ -102,10 +102,10 @@
 };
 
 #ifdef CONFIG_DEBUG_READAHEAD
-u32 initial_ra_hit;
-u32 initial_ra_miss;
-u32 debug_level = 1;
-u32 disable_stateful_method = 0;
+static u32 initial_ra_hit;
+static u32 initial_ra_miss;
+u32 readahead_debug_level = 1;
+static u32 disable_stateful_method = 0;
 static const char * const ra_class_name[];
 static void ra_account(struct file_ra_state *ra, enum ra_event e, int pages);
 #  define debug_inc(var)		do { var++; } while (0)
@@ -114,13 +114,12 @@
 #  define ra_account(ra, e, pages)	do { } while (0)
 #  define debug_inc(var)		do { } while (0)
 #  define debug_option(o)		(0)
-#  define debug_level 			(0)
 #endif /* CONFIG_DEBUG_READAHEAD */
 
 #define dprintk(args...) \
-	do { if (debug_level >= 2) printk(KERN_DEBUG args); } while(0)
+	do { if (readahead_debug_level >= 2) printk(KERN_DEBUG args); } while(0)
 #define ddprintk(args...) \
-	do { if (debug_level >= 3) printk(KERN_DEBUG args); } while(0)
+	do { if (readahead_debug_level >= 3) printk(KERN_DEBUG args); } while(0)
 
 void default_unplug_io_fn(struct backing_dev_info *bdi, struct page *page)
 {
@@ -2011,7 +2010,7 @@
 {
 	enum ra_class c;
 
-	if (!debug_level)
+	if (!readahead_debug_level)
 		return;
 
 	if (e == RA_EVENT_READAHEAD_HIT && pages < 0) {
@@ -2142,7 +2141,7 @@
 	return 1;
 }
 
-struct file_operations ra_events_fops = {
+static struct file_operations ra_events_fops = {
 	.owner		= THIS_MODULE,
 	.open		= ra_events_open,
 	.write		= ra_events_write,
@@ -2168,7 +2167,7 @@
 	READAHEAD_DEBUGFS_ENTRY_U32(initial_ra_hit);
 	READAHEAD_DEBUGFS_ENTRY_U32(initial_ra_miss);
 
-	READAHEAD_DEBUGFS_ENTRY_U32(debug_level);
+	debugfs_create_u32("debug_level", 0644, root, &readahead_debug_level);
 	READAHEAD_DEBUGFS_ENTRY_BOOL(disable_stateful_method);
 
 	return 0;
--- linux-2.6.17-mm1-full/mm/filemap.c.old	2006-06-22 22:03:34.000000000 +0200
+++ linux-2.6.17-mm1-full/mm/filemap.c	2006-06-22 22:06:37.000000000 +0200
@@ -45,12 +45,6 @@
 generic_file_direct_IO(int rw, struct kiocb *iocb, const struct iovec *iov,
 	loff_t offset, unsigned long nr_segs);
 
-#ifdef CONFIG_DEBUG_READAHEAD
-extern u32 debug_level;
-#else
-#define debug_level 0
-#endif /* CONFIG_DEBUG_READAHEAD */
-
 /*
  * Shared mappings implemented 30.11.1994. It's not fully working yet,
  * though.
@@ -937,7 +931,7 @@
 	if (!isize)
 		goto out;
 
-	if (debug_level >= 5)
+	if (readahead_debug_level >= 5)
 		printk(KERN_DEBUG "read-file(ino=%lu, req=%lu+%lu)\n",
 			inode->i_ino, index, last_index - index);
 
@@ -995,7 +989,7 @@
 		if (prefer_adaptive_readahead())
 			readahead_cache_hit(&ra, page);
 
-		if (debug_level >= 7)
+		if (readahead_debug_level >= 7)
 			printk(KERN_DEBUG "read-page(ino=%lu, idx=%lu, io=%s)\n",
 				inode->i_ino, index,
 				PageUptodate(page) ? "hit" : "miss");
@@ -1524,7 +1518,7 @@
 	if (prefer_adaptive_readahead())
 		readahead_cache_hit(ra, page);
 
-	if (debug_level >= 6)
+	if (readahead_debug_level >= 6)
 		printk(KERN_DEBUG "read-mmap(ino=%lu, idx=%lu, hint=%s, io=%s)\n",
 			inode->i_ino, pgoff,
 			VM_RandomReadHint(area) ? "random" :

Re: [-mm patch] kernel/lockdep.c: make 3 functions static

[Ingo Molnar]

* Adrian Bunk <bunk@stusta.de> wrote:

> This patch makes three needlessly global functions static.

thanks, i've added this to my lock validator tree.

	Ingo

Re: [linux-pm] swsusp regression [Was: 2.6.17-mm1]

[Frederik Deweerdt]

On Fri, Jun 23, 2006 at 11:10:21AM +0200, Pavel Machek wrote:
> Hi!
> 
> > > Frederik Deweerdt <deweerdt@free.fr> wrote:
> > > 
> > > > Thu, Jun 22, 2006 at 12:46:48AM -0700, Andrew Morton wrote:
> > > > > I can bisect it if we're stuck, but that'll require beer or something.
> > > > 
> > > > FWIW, my laptop (Dell D610) gave the following results:
> > > > 2.6.17-mm1: suspend_device(): usb_generic_suspend+0x0/0x135 [usbcore]() returns -16
> > > > 2.6.17+origin.patch: suspend_device(): usb_generic_suspend+0x0/0x135 [usbcore]() returns -16
> > > 
> > > So it's in mainline already - hence it's some recently-written thing which
> > > was not tested in rc6-mm2.
> > > 
> > > > 2.6.17: oops
> > > > 2.6.17.1: oops
> > > 
> > > 2.6.17 wasn't supposed to oops.  Do you have details on this?
> > > 
> > For some reason, unknown to me, the oops won't display on the serial
> > link :(.
> 
> Serial console is currently broken by suspend, resume. _But_ I have a
> patch I'd like you to try.... pretty please?
> 
Sure :)... I applied it but the output went to the laptop's screen anyway...
 
> That is not an oops, rather a kernel BUG(). Can you just remove
> might_sleep line and see what happens?
> 
> Unfortunately, backtrace does not tell me which notifier chain did
> that :-(. Are you using audit or something like that?
> 
> /*
>  * lock for reading
>  */
> static inline void down_read(struct rw_semaphore *sem)
> {
>         might_sleep();
> ~~~~~~~~~~~~~~~~~~~~~~
>         rwsemtrace(sem,"Entering down_read");
>         __down_read(sem);
>         rwsemtrace(sem,"Leaving down_read");
> }
> 
Here's the (hand copied) dump when the might_sleep is removed:

esi: 00000003  edit: 00000000 ebp: f6cb9eb8  esp: f6cb9ea4
ds: 007b  es: 007b  ss: 0068
Process bash (pid: 9402, threadinfo=f6cb8000 task=f7a5c570)
Stack: c0229b71 00000046 00000000 00000286 c0383ca7 f6cb9ecc c013b242 00000003
        00000000 00000003 f6cb9ee0 c013b2e8 00000003 c0436890 f6c9a003 f6cb9f08
        c013b481 00000003 00000003 00000246 c1788b00 00000003 c04368a0 c043692c
Call Trace:
 <c0103eea> show_stack_log_lvl+0x92/0xb7  <c0104100> show_registers+0x1a3/0x21b
 <c0104319> die+0x117/0x230  <c03627a6> do_page_fault+0x39c/0x72a
 <c0103b2f> error_code+0x4f/0x54  <c013b242> suspend_enter+0x2f/0x52
 <c013b2e8> enter_state+0x4b/0x8d  <c013b481> state_store+0xa0/0xa2
 <c01a5151> subsys_attr_store+0x37/0x41  <c01a53d2> flush_write_buffer+0x3c/0x46
 <c01a5443> sysfs_write_file+0x67/0x8b  <c0166bb6> vfs_write+0x1b9/0x1be
 <c0166c7b> sys_write+0x4b/0x75  <c010300f> sysenter_past_esp+0x54/0x75

Code: 05 c4 42 43 c0 31 43 43 c0 c3 8b 2d 68 6e 54 c0 8b 1d 60 6e 54 c0 8b 35 6c 6e 54 c0 8b 3d 70 6d 54 c0 ff 35 74 6e 54 c0 9d c3 90 <e8> 6d 38 ea ff e8 a2 ff ff ff 6a 03 e8 ec b6 de ff 83 c4 04 c3
EIP: [c043431c>] do_suspend_lowlevel+0x0/0x15 SS:ESP 0068:f6cb6ea4

Regards,
Frederik

Re: 2.6.17-mm1

[Franck Bui-Huu]

Mel Gorman wrote:
> On (22/06/06 19:25), Franck Bui-Huu didst pronounce:
>>>>
>>> I know, but what I'm getting at is that ARCH_PFN_OFFSET may be unnecessary
>>> with flatmem-relax-requirement-for-memory-to-start-at-pfn-0.patch applied.
>> yes it seems so. But ARCH_PFN_OFFSET has been used before your patch
>> has been sent. So your patch seems to be incomplete...
> 
> Difficult to argue with that logic.
> 

sorry, I was just meaning that ARCH_PFN_OFFSET had been introduced to
solve this before your patch has been sent. So the requirement for
memory to start at pfn 0 is already solved.

Your patch solves the problem in a different way, but it's
incompatible with the current one (ARCH_PFN_OFFSET).

IMHO the question is now, which method is the best one ? If it's yours
the we probably need to get ride of the previous method and add yours
(but don't forget to modify arch such ARM which are currently using
ARCH_PFN_OFFSET).

		Franck

Re: 2.6.17-mm1

[Michal Piotrowski]

Hi,

On 21/06/06, Andrew Morton <akpm@osdl.org> wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm1/
>

Firefox 2 - a new testing tool for bug hunters.

Jun 23 11:03:48 ltg01-fedora kernel: =======================================
Jun 23 11:03:48 ltg01-fedora kernel: [ INFO: out of order unlock detected. ]
Jun 23 11:03:48 ltg01-fedora kernel: ---------------------------------------
Jun 23 11:03:48 ltg01-fedora kernel: The code is fine but needs lock
validator annotation.
Jun 23 11:03:48 ltg01-fedora kernel: firefox-bin/25734 is trying to
release lock (tasklist_lock) at:
Jun 23 11:03:48 ltg01-fedora kernel:  [<c017b02c>] flush_old_exec+0x12f/0xa5f
Jun 23 11:03:48 ltg01-fedora kernel: but the next lock to release is:
Jun 23 11:03:48 ltg01-fedora kernel:  (&sighand->siglock){++..}, at:
[<c017afab>] flush_old_exec+0xae/0xa5f
Jun 23 11:03:48 ltg01-fedora kernel:
Jun 23 11:03:48 ltg01-fedora kernel: other info that might help us debug this:
Jun 23 11:03:48 ltg01-fedora kernel: 2 locks held by firefox-bin/25734:
Jun 23 11:03:48 ltg01-fedora kernel:  #0:  (tasklist_lock){..??}, at:
[<c017afa4>] flush_old_exec+0xa7/0xa5f
Jun 23 11:03:48 ltg01-fedora kernel:  #1:  (&sighand->siglock){++..},
at: [<c017afab>] flush_old_exec+0xae/0xa5f
Jun 23 11:03:48 ltg01-fedora kernel:
Jun 23 11:03:48 ltg01-fedora kernel: stack backtrace:
Jun 23 11:03:48 ltg01-fedora kernel:  [<c0103e89>] show_trace+0xd/0x10
Jun 23 11:03:48 ltg01-fedora kernel:  [<c0104483>] dump_stack+0x19/0x1b
Jun 23 11:03:48 ltg01-fedora kernel:  [<c0139c52>] lock_release+0x19a/0x371
Jun 23 11:03:48 ltg01-fedora kernel:  [<c02f1148>] _read_unlock+0x16/0x46
Jun 23 11:03:48 ltg01-fedora kernel:  [<c017b02c>] flush_old_exec+0x12f/0xa5f
Jun 23 11:03:48 ltg01-fedora kernel:  [<c019b698>] load_elf_binary+0x4c8/0x15f4
Jun 23 11:03:48 ltg01-fedora kernel:  [<c017a8e1>]
search_binary_handler+0xfc/0x32b
Jun 23 11:03:48 ltg01-fedora kernel:  [<c017c533>] do_execve+0x16c/0x225
Jun 23 11:03:48 ltg01-fedora kernel:  [<c01016e1>] sys_execve+0x3a/0x8b
Jun 23 11:03:48 ltg01-fedora kernel:  [<c02f157d>] sysenter_past_esp+0x56/0x8d

Here is a config file
http://www.stardust.webpages.pl/files/mm/2.6.17-mm1/mm-config

Regards,
Michal

-- 
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)

Re: 2.6.17-mm1

[Franck Bui-Huu]

Franck Bui-Huu wrote:
> Mel Gorman wrote:
>> On (22/06/06 19:25), Franck Bui-Huu didst pronounce:
>>>> I know, but what I'm getting at is that ARCH_PFN_OFFSET may be unnecessary
>>>> with flatmem-relax-requirement-for-memory-to-start-at-pfn-0.patch applied.
>>> yes it seems so. But ARCH_PFN_OFFSET has been used before your patch
>>> has been sent. So your patch seems to be incomplete...
>> Difficult to argue with that logic.
>>
> 
> sorry, I was just meaning that ARCH_PFN_OFFSET had been introduced to
> solve this before your patch has been sent. So the requirement for
> memory to start at pfn 0 is already solved.
> 
> Your patch solves the problem in a different way, but it's
> incompatible with the current one (ARCH_PFN_OFFSET).
> 
> IMHO the question is now, which method is the best one ? If it's yours
> the we probably need to get ride of the previous method and add yours
> (but don't forget to modify arch such ARM which are currently using
> ARCH_PFN_OFFSET).
> 

maybe these figures can help to make our choice:

   text    data     bss     dec     hex filename
2226384  223824  110624 2560832  271340 vmlinux-arch-pfn-offset-0
2228488  223824  110624 2562936  271b78 vmlinux-arch-pfn-offset-not-0
2226964  223856  110624 2561444  2715a4 vmlinux-out-of-line-pfn-to-page

Arch is MIPS and I used gcc 3.4.4

So your solution gives the smallest kernel with my config although the win
is only 0.1%. Maybe it would be good to have ARM figures/opinion too.

		Franck

Re: [linux-pm] swsusp regression [Was: 2.6.17-mm1]

[Pavel Machek]

Hi!

> > > > 2.6.17 wasn't supposed to oops.  Do you have details on this?
> > > > 
> > > For some reason, unknown to me, the oops won't display on the serial
> > > link :(.
> > 
> > Serial console is currently broken by suspend, resume. _But_ I have a
> > patch I'd like you to try.... pretty please?
> > 
> Sure :)... I applied it but the output went to the laptop's screen anyway...

Do you need some kernel command line options? This is s2ram, do I
recall it correctly?

> > That is not an oops, rather a kernel BUG(). Can you just remove
> > might_sleep line and see what happens?
> > 
> > Unfortunately, backtrace does not tell me which notifier chain did
> > that :-(. Are you using audit or something like that?
> > 
> > /*
> >  * lock for reading
> >  */
> > static inline void down_read(struct rw_semaphore *sem)
> > {
> >         might_sleep();
> > ~~~~~~~~~~~~~~~~~~~~~~
> >         rwsemtrace(sem,"Entering down_read");
> >         __down_read(sem);
> >         rwsemtrace(sem,"Leaving down_read");
> > }
> > 
> Here's the (hand copied) dump when the might_sleep is removed:
> 
> esi: 00000003  edit: 00000000 ebp: f6cb9eb8  esp: f6cb9ea4
> ds: 007b  es: 007b  ss: 0068
> Process bash (pid: 9402, threadinfo=f6cb8000 task=f7a5c570)

This stack lines are not really interesting (can you comment them from
sources?) and they make interesting info scroll away :-(. Or maybe
vga=1 can help?

> Stack: c0229b71 00000046 00000000 00000286 c0383ca7 f6cb9ecc c013b242 00000003
>         00000000 00000003 f6cb9ee0 c013b2e8 00000003 c0436890 f6c9a003 f6cb9f08
>         c013b481 00000003 00000003 00000246 c1788b00 00000003 c04368a0 c043692c
> Call Trace:
>  <c0103eea> show_stack_log_lvl+0x92/0xb7  <c0104100> show_registers+0x1a3/0x21b
>  <c0104319> die+0x117/0x230  <c03627a6> do_page_fault+0x39c/0x72a
>  <c0103b2f> error_code+0x4f/0x54  <c013b242> suspend_enter+0x2f/0x52
>  <c013b2e8> enter_state+0x4b/0x8d  <c013b481> state_store+0xa0/0xa2
>  <c01a5151> subsys_attr_store+0x37/0x41  <c01a53d2> flush_write_buffer+0x3c/0x46
>  <c01a5443> sysfs_write_file+0x67/0x8b  <c0166bb6> vfs_write+0x1b9/0x1be
>  <c0166c7b> sys_write+0x4b/0x75  <c010300f> sysenter_past_esp+0x54/0x75
> 
> Code: 05 c4 42 43 c0 31 43 43 c0 c3 8b 2d 68 6e 54 c0 8b 1d 60 6e 54 c0 8b 35 6c 6e 54 c0 8b 3d 70 6d 54 c0 ff 35 74 6e 54 c0 9d c3 90 <e8> 6d 38 ea ff e8 a2 ff ff ff 6a 03 e8 ec b6 de ff 83 c4 04 c3
> EIP: [c043431c>] do_suspend_lowlevel+0x0/0x15 SS:ESP 0068:f6cb6ea4
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Ha, wait a moment, this is interesting line. Can you trace down which
instruction causes this?

We recently changed pagetable handling during swsusp, perhaps thats
it? It went to Linus few minutes ago...
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: 2.6.17-mm1

[Mel Gorman]

On (23/06/06 14:22), Franck Bui-Huu didst pronounce:
> Mel Gorman wrote:
> > On (22/06/06 19:25), Franck Bui-Huu didst pronounce:
> >>>>
> >>> I know, but what I'm getting at is that ARCH_PFN_OFFSET may be unnecessary
> >>> with flatmem-relax-requirement-for-memory-to-start-at-pfn-0.patch applied.
> >> yes it seems so. But ARCH_PFN_OFFSET has been used before your patch
> >> has been sent. So your patch seems to be incomplete...
> > 
> > Difficult to argue with that logic.
> > 
> 
> sorry, I was just meaning that ARCH_PFN_OFFSET had been introduced to
> solve this before your patch has been sent. So the requirement for
> memory to start at pfn 0 is already solved.
> 

In that case, the patch is as simple as you suggested earlier (patch
below). The only downside is that we hold onto ARCH_PFN_OFFSET which is a
bit of an obscure #define if you ask me. The obscurity can be lived with of
course, but it'd be nice to kick away ARCH_PFN_OFFSET if possible.

> IMHO the question is now, which method is the best one ?

My method should very slightly reduce the size of the kernel and have a
very minor performance improvement. How measurable it is depends on how
often page_to_pfn and pfn_to_page are called.

> the we probably need to get ride of the previous method and add yours
> (but don't forget to modify arch such ARM which are currently using
> ARCH_PFN_OFFSET).
> 

If we decide to simply hold onto ARCH_PFN_OFFSET, the fix is simply;

diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.17-mm1-clean/include/asm-generic/memory_model.h linux-2.6.17-mm1-archpfnfix/include/asm-generic/memory_model.h
--- linux-2.6.17-mm1-clean/include/asm-generic/memory_model.h	2006-06-23 09:26:15.000000000 +0100
+++ linux-2.6.17-mm1-archpfnfix/include/asm-generic/memory_model.h	2006-06-23 10:44:18.000000000 +0100
@@ -28,9 +28,8 @@
  */
 #if defined(CONFIG_FLATMEM)
 
-#define __pfn_to_page(pfn)	(mem_map + ((pfn) - ARCH_PFN_OFFSET))
-#define __page_to_pfn(page)	((unsigned long)((page) - mem_map) + \
-				 ARCH_PFN_OFFSET)
+#define __pfn_to_page(pfn)	(mem_map + (pfn))
+#define __page_to_pfn(page)	((unsigned long)((page) - mem_map))
 #elif defined(CONFIG_DISCONTIGMEM)
 
 #define __pfn_to_page(pfn)			\
diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.17-mm1-clean/mm/page_alloc.c linux-2.6.17-mm1-archpfnfix/mm/page_alloc.c
--- linux-2.6.17-mm1-clean/mm/page_alloc.c	2006-06-23 09:26:15.000000000 +0100
+++ linux-2.6.17-mm1-archpfnfix/mm/page_alloc.c	2006-06-23 14:00:11.000000000 +0100
@@ -2316,7 +2316,7 @@ static void __init alloc_node_mem_map(st
 		 * is true. Adjust map relative to node_mem_map to
 		 * maintain this relationship.
 		 */
-		map -= pgdat->node_start_pfn;
+		map -= ARCH_PFN_OFFSET;
 	}
 #ifdef CONFIG_FLATMEM
 	/*

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

Re: [linux-pm] swsusp regression [Was: 2.6.17-mm1]

[Frederik Deweerdt]

On Fri, Jun 23, 2006 at 02:57:01PM +0200, Pavel Machek wrote:
> Hi!
> 
> > > > > 2.6.17 wasn't supposed to oops.  Do you have details on this?
> > > > > 
> > > > For some reason, unknown to me, the oops won't display on the serial
> > > > link :(.
> > > 
> > > Serial console is currently broken by suspend, resume. _But_ I have a
> > > patch I'd like you to try.... pretty please?
> > > 
> > Sure :)... I applied it but the output went to the laptop's screen anyway...
> 
> Do you need some kernel command line options? This is s2ram, do I
> recall it correctly?
I think the options are ok: I'm passing console=tty0 console=ttyS0,9600 and
everything works fine in cu(1). Until the 'echo mem > /sys/power/state', that is :)
> > esi: 00000003  edit: 00000000 ebp: f6cb9eb8  esp: f6cb9ea4
> > ds: 007b  es: 007b  ss: 0068
> > Process bash (pid: 9402, threadinfo=f6cb8000 task=f7a5c570)
> 
> This stack lines are not really interesting (can you comment them from
> sources?) and they make interesting info scroll away :-(. 
I'll comment them out and send you the trace, but I won't get the time to
do it today, I'll try to get it done by monday.
> Or maybe vga=1 can help?
I've tried it. But somehow, the suspend process resets the resolution to the
lowest one.
> 
> > Stack: c0229b71 00000046 00000000 00000286 c0383ca7 f6cb9ecc c013b242 00000003
> >         00000000 00000003 f6cb9ee0 c013b2e8 00000003 c0436890 f6c9a003 f6cb9f08
> >         c013b481 00000003 00000003 00000246 c1788b00 00000003 c04368a0 c043692c
c0229b71 is in acpi_pm_enter:
        case PM_SUSPEND_MEM:
-->             do_suspend_lowlevel();
                break;

c013b242 is in suspend_enter:
	}
-->     error = pm_ops->enter(state);
	device_power_up();


c013b2e8 is in enter_state
        pr_debug("PM: Entering %s sleep\n", pm_states[state]);
-->     error = suspend_enter(state);


c013b481 is in state_store
        if (state < PM_SUSPEND_MAX && *s)
-->            error = enter_state(state);
        else


> > Call Trace:
> >  <c0103eea> show_stack_log_lvl+0x92/0xb7  <c0104100> show_registers+0x1a3/0x21b
> >  <c0104319> die+0x117/0x230  <c03627a6> do_page_fault+0x39c/0x72a
> >  <c0103b2f> error_code+0x4f/0x54  <c013b242> suspend_enter+0x2f/0x52
> >  <c013b2e8> enter_state+0x4b/0x8d  <c013b481> state_store+0xa0/0xa2
> >  <c01a5151> subsys_attr_store+0x37/0x41  <c01a53d2> flush_write_buffer+0x3c/0x46
> >  <c01a5443> sysfs_write_file+0x67/0x8b  <c0166bb6> vfs_write+0x1b9/0x1be
> >  <c0166c7b> sys_write+0x4b/0x75  <c010300f> sysenter_past_esp+0x54/0x75
> > 
> > Code: 05 c4 42 43 c0 31 43 43 c0 c3 8b 2d 68 6e 54 c0 8b 1d 60 6e 54 c0 8b 35 6c 6e 54 c0 8b 3d 70 6d 54 c0 ff 35 74 6e 54 c0 9d c3 90 <e8> 6d 38 ea ff e8 a2 ff ff ff 6a 03 e8 ec b6 de ff 83 c4 04 c3
> > EIP: [c043431c>] do_suspend_lowlevel+0x0/0x15 SS:ESP 0068:f6cb6ea4
>   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> Ha, wait a moment, this is interesting line. Can you trace down which
> instruction causes this?
This disassembles as follows:
c043431c <do_suspend_lowlevel>:
c043431c:       e8 6d 38 ea ff          call   c02d7b8e <save_processor_state>
c0434321:       e8 a2 ff ff ff          call   c04342c8 <save_registers>
c0434326:       6a 03                   push   $0x3
c0434328:       e8 ec b6 de ff          call   c021fa19 <acpi_enter_sleep_state>
c043432d:       83 c4 04                add    $0x4,%esp
c0434330:       c3                      ret
So it looks like where crashing when calling save_processor_state. 
> We recently changed pagetable handling during swsusp, perhaps thats
> it? It went to Linus few minutes ago...
Sorry, I don't understand what you mean: do you want me to try the latest git?

Regards,
Frederik

Re: 2.6.17-mm1: UML failing w/o SKAS enabled

[Jeff Dike]

On Fri, Jun 23, 2006 at 12:10:35PM +0200, Roman Zippel wrote:
> BTW this can be now configured. Check DEFCONFIG_LIST in init/Kconfig in 
> -mm.

So, something like this would be OK in order to have the UML build
just use its own defconfig?

				Jeff

Make the UML build ignore the host configs in /boot, /lib, and /etc
and just use its own defconfig.

Signed-off-by: Jeff Dike <jdike@addtoit.com>

Index: linux-2.6.17/arch/um/Kconfig
===================================================================
--- linux-2.6.17.orig/arch/um/Kconfig	2006-06-20 17:24:29.000000000 -0400
+++ linux-2.6.17/arch/um/Kconfig	2006-06-23 10:20:27.000000000 -0400
@@ -1,3 +1,8 @@
+config DEFCONFIG_LIST
+	string
+	option defconfig_list
+	default "arch/um/defconfig"
+
 # UML uses the generic IRQ sugsystem
 config GENERIC_HARDIRQS
 	bool

Re: 2.6.17-mm1

[Franck Bui-Huu]

Mel Gorman wrote:
> On (23/06/06 14:22), Franck Bui-Huu didst pronounce:
>> Mel Gorman wrote:
>>> On (22/06/06 19:25), Franck Bui-Huu didst pronounce:
>>>>> I know, but what I'm getting at is that ARCH_PFN_OFFSET may be unnecessary
>>>>> with flatmem-relax-requirement-for-memory-to-start-at-pfn-0.patch applied.
>>>> yes it seems so. But ARCH_PFN_OFFSET has been used before your patch
>>>> has been sent. So your patch seems to be incomplete...
>>> Difficult to argue with that logic.
>>>
>> sorry, I was just meaning that ARCH_PFN_OFFSET had been introduced to
>> solve this before your patch has been sent. So the requirement for
>> memory to start at pfn 0 is already solved.
>>
> 
> In that case, the patch is as simple as you suggested earlier (patch
> below). The only downside is that we hold onto ARCH_PFN_OFFSET which is a
> bit of an obscure #define if you ask me. The obscurity can be lived with of
> course, but it'd be nice to kick away ARCH_PFN_OFFSET if possible.
> 

yes with the patch below it seems useless. But it's also a good way
for all arch to use the same name for defining the start of the
memory.

>> IMHO the question is now, which method is the best one ?
> 
> My method should very slightly reduce the size of the kernel and have a
> very minor performance improvement. How measurable it is depends on how
> often page_to_pfn and pfn_to_page are called.
> 
>> the we probably need to get ride of the previous method and add yours
>> (but don't forget to modify arch such ARM which are currently using
>> ARCH_PFN_OFFSET).
>>
> 
> If we decide to simply hold onto ARCH_PFN_OFFSET, the fix is simply;

here is the patch I'm using, which is mainly yours.

-- >8 --
[PATCH] flatmem: tiny optimisation when memory do not start at 0

The FLATMEM memory model assumes that memory is in one contigious area
based at pfn 0. Some archictectures, like ARM, use ARCH_PFN_OFFSET to
relax this requirement. This involves one more operation during
page/pfn conversions.

Instead this patch modifies the address of mem_map to make
mem_map[ARCH_PFN_OFFSET] pointing at NODE_DATA(0)->node_mem_map.
This results in a slight gain on kernel code size.

---
 include/asm-generic/memory_model.h |    6 +++---
 mm/page_alloc.c                    |   15 +++++++++++----
 2 files changed, 14 insertions(+), 7 deletions(-)

diff --git a/include/asm-generic/memory_model.h b/include/asm-generic/memory_model.h
index 0cfb086..2faa12f 100644
--- a/include/asm-generic/memory_model.h
+++ b/include/asm-generic/memory_model.h
@@ -34,9 +34,9 @@ #else
  */
 #if defined(CONFIG_FLATMEM)
 
-#define pfn_to_page(pfn)	(mem_map + ((pfn) - ARCH_PFN_OFFSET))
-#define page_to_pfn(page)	((unsigned long)((page) - mem_map) + \
-				 ARCH_PFN_OFFSET)
+#define pfn_to_page(pfn)	(mem_map + (pfn))
+#define page_to_pfn(page)	((unsigned long)((page) - mem_map))
+
 #elif defined(CONFIG_DISCONTIGMEM)
 
 #define pfn_to_page(pfn)			\
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 253a450..ed6a40f 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -2118,15 +2118,16 @@ static void __init free_area_init_core(s
 
 static void __init alloc_node_mem_map(struct pglist_data *pgdat)
 {
+#ifdef CONFIG_FLAT_NODE_MEM_MAP
+	struct page *map = pgdat->node_mem_map;
+
 	/* Skip empty nodes */
 	if (!pgdat->node_spanned_pages)
 		return;
 
-#ifdef CONFIG_FLAT_NODE_MEM_MAP
 	/* ia64 gets its own node_mem_map, before this, without bootmem */
-	if (!pgdat->node_mem_map) {
+	if (!map) {
 		unsigned long size, start, end;
-		struct page *map;
 
 		/*
 		 * The zone's endpoints aren't required to be MAX_ORDER
@@ -2147,7 +2148,13 @@ #ifdef CONFIG_FLATMEM
 	 * With no DISCONTIG, the global mem_map is just set as node 0's
 	 */
 	if (pgdat == NODE_DATA(0))
-		mem_map = NODE_DATA(0)->node_mem_map;
+		/*
+		 * mem_map is assumed to be based at pfn 0 such that
+		 * 'pfn = page* - mem_map' is true. Adjust map
+		 * relative to node_mem_map to maintain this
+		 * relationship.
+		 */
+		mem_map = map - ARCH_PFN_OFFSET;
 #endif
 #endif /* CONFIG_FLAT_NODE_MEM_MAP */
 }
-- 
1.4.0.g64e8

Re: 2.6.17-mm1

[Franck Bui-Huu]

Mel Gorman wrote:
> On (23/06/06 14:22), Franck Bui-Huu didst pronounce:
>> Mel Gorman wrote:
>>> On (22/06/06 19:25), Franck Bui-Huu didst pronounce:
>>>>> I know, but what I'm getting at is that ARCH_PFN_OFFSET may be unnecessary
>>>>> with flatmem-relax-requirement-for-memory-to-start-at-pfn-0.patch applied.
>>>> yes it seems so. But ARCH_PFN_OFFSET has been used before your patch
>>>> has been sent. So your patch seems to be incomplete...
>>> Difficult to argue with that logic.
>>>
>> sorry, I was just meaning that ARCH_PFN_OFFSET had been introduced to
>> solve this before your patch has been sent. So the requirement for
>> memory to start at pfn 0 is already solved.
>>
> 
> In that case, the patch is as simple as you suggested earlier (patch
> below). The only downside is that we hold onto ARCH_PFN_OFFSET which is a
> bit of an obscure #define if you ask me. The obscurity can be lived with of
> course, but it'd be nice to kick away ARCH_PFN_OFFSET if possible.
> 

what do you think about this use of ARCH_PFN_OFFSET ?

diff --git a/mm/bootmem.c b/mm/bootmem.c
index d213fed..fd28eed 100644
--- a/mm/bootmem.c
+++ b/mm/bootmem.c
@@ -377,11 +377,11 @@ unsigned long __init free_all_bootmem_no
 	return(free_all_bootmem_core(pgdat));
 }
 
-unsigned long __init init_bootmem (unsigned long start, unsigned long pages)
+unsigned long __init init_bootmem(unsigned long start, unsigned long pages)
 {
 	max_low_pfn = pages;
 	min_low_pfn = start;
-	return(init_bootmem_core(NODE_DATA(0), start, 0, pages));
+	return init_bootmem_core(NODE_DATA(0), start, ARCH_PFN_OFFSET, pages);
 }
 
 #ifndef CONFIG_HAVE_ARCH_BOOTMEM_NODE
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index ed6a40f..43abaeb 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -2154,7 +2154,7 @@ #ifdef CONFIG_FLATMEM
 		 * relative to node_mem_map to maintain this
 		 * relationship.
 		 */
-		mem_map = map - ARCH_PFN_OFFSET;
+		mem_map = map - pgdat->node_start_pfn;
 #endif
 #endif /* CONFIG_FLAT_NODE_MEM_MAP */
 }
@@ -2181,8 +2181,7 @@ #endif
 
 void __init free_area_init(unsigned long *zones_size)
 {
-	free_area_init_node(0, NODE_DATA(0), zones_size,
-			__pa(PAGE_OFFSET) >> PAGE_SHIFT, NULL);
+	free_area_init_node(0, NODE_DATA(0), zones_size, ARCH_PFN_OFFSET, NULL);
 }
 
 #ifdef CONFIG_PROC_FS

Re: 2.6.17-mm1

[Mel Gorman]

On (23/06/06 17:06), Franck Bui-Huu didst pronounce:
> Mel Gorman wrote:
> > On (23/06/06 14:22), Franck Bui-Huu didst pronounce:
> >> Mel Gorman wrote:
> >>> On (22/06/06 19:25), Franck Bui-Huu didst pronounce:
> >>>>> I know, but what I'm getting at is that ARCH_PFN_OFFSET may be unnecessary
> >>>>> with flatmem-relax-requirement-for-memory-to-start-at-pfn-0.patch applied.
> >>>> yes it seems so. But ARCH_PFN_OFFSET has been used before your patch
> >>>> has been sent. So your patch seems to be incomplete...
> >>> Difficult to argue with that logic.
> >>>
> >> sorry, I was just meaning that ARCH_PFN_OFFSET had been introduced to
> >> solve this before your patch has been sent. So the requirement for
> >> memory to start at pfn 0 is already solved.
> >>
> > 
> > In that case, the patch is as simple as you suggested earlier (patch
> > below). The only downside is that we hold onto ARCH_PFN_OFFSET which is a
> > bit of an obscure #define if you ask me. The obscurity can be lived with of
> > course, but it'd be nice to kick away ARCH_PFN_OFFSET if possible.
> > 
> 
> what do you think about this use of ARCH_PFN_OFFSET ?
> 

I believe that arches calling free_area_init_node() directly, but using
CONFIG_FLAT_NODE_MEM_MAP will have problems with this. There is no
guarantee that pgdat->node_start_pfn will have any relation to
ARCH_PFN_OFFSET. It is why in an earlier patch, I made a check for
ARCH_PFN_OFFSET == pgdat->node_start_pfn and only then printed a message
saying that ARCH_PFN_OFFSET was unnecessary.

> diff --git a/mm/bootmem.c b/mm/bootmem.c
> index d213fed..fd28eed 100644
> --- a/mm/bootmem.c
> +++ b/mm/bootmem.c
> @@ -377,11 +377,11 @@ unsigned long __init free_all_bootmem_no
>  	return(free_all_bootmem_core(pgdat));
>  }
>  
> -unsigned long __init init_bootmem (unsigned long start, unsigned long pages)
> +unsigned long __init init_bootmem(unsigned long start, unsigned long pages)
>  {
>  	max_low_pfn = pages;
>  	min_low_pfn = start;
> -	return(init_bootmem_core(NODE_DATA(0), start, 0, pages));
> +	return init_bootmem_core(NODE_DATA(0), start, ARCH_PFN_OFFSET, pages);
>  }
>  
>  #ifndef CONFIG_HAVE_ARCH_BOOTMEM_NODE
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index ed6a40f..43abaeb 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -2154,7 +2154,7 @@ #ifdef CONFIG_FLATMEM
>  		 * relative to node_mem_map to maintain this
>  		 * relationship.
>  		 */
> -		mem_map = map - ARCH_PFN_OFFSET;
> +		mem_map = map - pgdat->node_start_pfn;
>  #endif
>  #endif /* CONFIG_FLAT_NODE_MEM_MAP */
>  }
> @@ -2181,8 +2181,7 @@ #endif
>  
>  void __init free_area_init(unsigned long *zones_size)
>  {
> -	free_area_init_node(0, NODE_DATA(0), zones_size,
> -			__pa(PAGE_OFFSET) >> PAGE_SHIFT, NULL);
> +	free_area_init_node(0, NODE_DATA(0), zones_size, ARCH_PFN_OFFSET, NULL);
>  }
>  
>  #ifdef CONFIG_PROC_FS

-- 
-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

Re: 2.6.17-mm1

[Franck Bui-Huu]

Franck Bui-Huu wrote:
> 
> what do you think about this use of ARCH_PFN_OFFSET ?
> 
> diff --git a/mm/bootmem.c b/mm/bootmem.c
> index d213fed..fd28eed 100644
> --- a/mm/bootmem.c
> +++ b/mm/bootmem.c
> @@ -377,11 +377,11 @@ unsigned long __init free_all_bootmem_no
>  	return(free_all_bootmem_core(pgdat));
>  }
>  
> -unsigned long __init init_bootmem (unsigned long start, unsigned long pages)
> +unsigned long __init init_bootmem(unsigned long start, unsigned long pages)
>  {
>  	max_low_pfn = pages;
>  	min_low_pfn = start;
> -	return(init_bootmem_core(NODE_DATA(0), start, 0, pages));
> +	return init_bootmem_core(NODE_DATA(0), start, ARCH_PFN_OFFSET, pages);
>  }
>  
>  #ifndef CONFIG_HAVE_ARCH_BOOTMEM_NODE
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index ed6a40f..43abaeb 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -2154,7 +2154,7 @@ #ifdef CONFIG_FLATMEM
>  		 * relative to node_mem_map to maintain this
>  		 * relationship.
>  		 */
> -		mem_map = map - ARCH_PFN_OFFSET;
> +		mem_map = map - pgdat->node_start_pfn;
>  #endif
>  #endif /* CONFIG_FLAT_NODE_MEM_MAP */
>  }
> @@ -2181,8 +2181,7 @@ #endif
>  
>  void __init free_area_init(unsigned long *zones_size)
>  {
> -	free_area_init_node(0, NODE_DATA(0), zones_size,
> -			__pa(PAGE_OFFSET) >> PAGE_SHIFT, NULL);

I'm wondering why using "__pa(PAGE_OFFSET) >> PAGE_SHIFT" to compute the start
of memory. That should always result in 0, shouldn't it ?

		Franck

Re: 2.6.17-mm1

[Eduard Bloch]

#include <hallo.h>
* Andrew Morton [Wed, Jun 21 2006, 03:48:57AM]:
> 
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm1/

Cannot build it. Looks like the build system is looping over:

  GEN     usr/klibc/syscalls/typesize.c
  KLIBCCC usr/klibc/syscalls/typesize.o
  OBJCOPY usr/klibc/syscalls/typesize.bin
  GEN     usr/klibc/syscalls/syscalls.mk
  GEN     usr/klibc/syscalls/typesize.c
  KLIBCCC usr/klibc/syscalls/typesize.o
  OBJCOPY usr/klibc/syscalls/typesize.bin
  GEN     usr/klibc/syscalls/syscalls.mk
  GEN     usr/klibc/syscalls/typesize.c
  KLIBCCC usr/klibc/syscalls/typesize.o
  OBJCOPY usr/klibc/syscalls/typesize.bin
  GEN     usr/klibc/syscalls/syscalls.mk
  GEN     usr/klibc/syscalls/typesize.c
  KLIBCCC usr/klibc/syscalls/typesize.o
  OBJCOPY usr/klibc/syscalls/typesize.bin
  GEN     usr/klibc/syscalls/syscalls.mk

No matter whether executed as user or as root. Setting KBUILD_VERBOSE
does not help much, for the log see http://people.debian.org/~blade/log .

Eduard.

Re: 2.6.17-mm1

[Franck Bui-Huu]

Mel Gorman wrote:
> On (23/06/06 17:06), Franck Bui-Huu didst pronounce:
>> what do you think about this use of ARCH_PFN_OFFSET ?
>>
> 
> I believe that arches calling free_area_init_node() directly, but using
> CONFIG_FLAT_NODE_MEM_MAP will have problems with this. There is no
> guarantee that pgdat->node_start_pfn will have any relation to
> ARCH_PFN_OFFSET. 

I agree we shouldn't make this assumption.

what about this ?

-- >8 --
[PATCH] flatmem: tiny optimisation when memory do not start at 0

The FLATMEM memory model assumes that memory is in one
contigious area based at pfn 0. Some archictectures, like
ARM, use ARCH_PFN_OFFSET to relax this requirement but it
involves one more operation during page/pfn conversion.

Instead this patch modifies the address of mem_map to make
mem_map[ARCH_PFN_OFFSET] pointing at NODE_DATA(0)->node_mem_map.
The result is a slight gain on kernel code size.

It also relaxes this requirement in two more places:
	free_area_init(...)
	init_bootmem(...)

---
 include/asm-generic/memory_model.h |    6 +++---
 mm/bootmem.c                       |    4 ++--
 mm/page_alloc.c                    |   18 ++++++++++++------
 3 files changed, 17 insertions(+), 11 deletions(-)

diff --git a/include/asm-generic/memory_model.h b/include/asm-generic/memory_model.h
index 0cfb086..2faa12f 100644
--- a/include/asm-generic/memory_model.h
+++ b/include/asm-generic/memory_model.h
@@ -34,9 +34,9 @@ #else
  */
 #if defined(CONFIG_FLATMEM)
 
-#define pfn_to_page(pfn)	(mem_map + ((pfn) - ARCH_PFN_OFFSET))
-#define page_to_pfn(page)	((unsigned long)((page) - mem_map) + \
-				 ARCH_PFN_OFFSET)
+#define pfn_to_page(pfn)	(mem_map + (pfn))
+#define page_to_pfn(page)	((unsigned long)((page) - mem_map))
+
 #elif defined(CONFIG_DISCONTIGMEM)
 
 #define pfn_to_page(pfn)			\
diff --git a/mm/bootmem.c b/mm/bootmem.c
index d213fed..fd28eed 100644
--- a/mm/bootmem.c
+++ b/mm/bootmem.c
@@ -377,11 +377,11 @@ unsigned long __init free_all_bootmem_no
 	return(free_all_bootmem_core(pgdat));
 }
 
-unsigned long __init init_bootmem (unsigned long start, unsigned long pages)
+unsigned long __init init_bootmem(unsigned long start, unsigned long pages)
 {
 	max_low_pfn = pages;
 	min_low_pfn = start;
-	return(init_bootmem_core(NODE_DATA(0), start, 0, pages));
+	return init_bootmem_core(NODE_DATA(0), start, ARCH_PFN_OFFSET, pages);
 }
 
 #ifndef CONFIG_HAVE_ARCH_BOOTMEM_NODE
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 253a450..3e97bc3 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -2118,15 +2118,16 @@ static void __init free_area_init_core(s
 
 static void __init alloc_node_mem_map(struct pglist_data *pgdat)
 {
+#ifdef CONFIG_FLAT_NODE_MEM_MAP
+	struct page *map = pgdat->node_mem_map;
+
 	/* Skip empty nodes */
 	if (!pgdat->node_spanned_pages)
 		return;
 
-#ifdef CONFIG_FLAT_NODE_MEM_MAP
 	/* ia64 gets its own node_mem_map, before this, without bootmem */
-	if (!pgdat->node_mem_map) {
+	if (!map) {
 		unsigned long size, start, end;
-		struct page *map;
 
 		/*
 		 * The zone's endpoints aren't required to be MAX_ORDER
@@ -2147,7 +2148,13 @@ #ifdef CONFIG_FLATMEM
 	 * With no DISCONTIG, the global mem_map is just set as node 0's
 	 */
 	if (pgdat == NODE_DATA(0))
-		mem_map = NODE_DATA(0)->node_mem_map;
+		/*
+		 * mem_map is assumed to be based at pfn 0 such that
+		 * 'pfn = page* - mem_map' is true. Adjust map
+		 * relative to node_mem_map to maintain this
+		 * relationship.
+		 */
+		mem_map = map - ARCH_PFN_OFFSET;
 #endif
 #endif /* CONFIG_FLAT_NODE_MEM_MAP */
 }
@@ -2174,8 +2181,7 @@ #endif
 
 void __init free_area_init(unsigned long *zones_size)
 {
-	free_area_init_node(0, NODE_DATA(0), zones_size,
-			__pa(PAGE_OFFSET) >> PAGE_SHIFT, NULL);
+	free_area_init_node(0, NODE_DATA(0), zones_size, ARCH_PFN_OFFSET, NULL);
 }
 
 #ifdef CONFIG_PROC_FS
-- 
1.4.0.g64e8

Re: [-mm patch] fs/reiser4/: possible cleanups

[Hans Reiser]

Thanks Adrian.

Re: [-mm patch] make kernel/utsname.c:clone_uts_ns()

[Serge E. Hallyn]

True.

Acked-by: Serge Hallyn <serue@us.ibm.com>

thanks,
-serge

Quoting Adrian Bunk (bunk@stusta.de):
> This patch makes the needlessly global clone_uts_ns() static.
> 
> Signed-off-by: Adrian Bunk <bunk@stusta.de>
> 
> --- linux-2.6.17-mm1-full/kernel/utsname.c.old	2006-06-22 20:53:20.000000000 +0200
> +++ linux-2.6.17-mm1-full/kernel/utsname.c	2006-06-22 20:53:31.000000000 +0200
> @@ -19,7 +19,7 @@
>   * @old_ns: namespace to clone
>   * Return NULL on error (failure to kmalloc), new ns otherwise
>   */
> -struct uts_namespace *clone_uts_ns(struct uts_namespace *old_ns)
> +static struct uts_namespace *clone_uts_ns(struct uts_namespace *old_ns)
>  {
>  	struct uts_namespace *ns;
>  

Re: 2.6.17-mm1

[Mel Gorman]

On Fri, 23 Jun 2006, Franck Bui-Huu wrote:

> Mel Gorman wrote:
>> On (23/06/06 17:06), Franck Bui-Huu didst pronounce:
>>> what do you think about this use of ARCH_PFN_OFFSET ?
>>>
>>
>> I believe that arches calling free_area_init_node() directly, but using
>> CONFIG_FLAT_NODE_MEM_MAP will have problems with this. There is no
>> guarantee that pgdat->node_start_pfn will have any relation to
>> ARCH_PFN_OFFSET.
>
> I agree we shouldn't make this assumption.
>
> what about this ?
>
> -- >8 --
> [PATCH] flatmem: tiny optimisation when memory do not start at 0
>
> The FLATMEM memory model assumes that memory is in one
> contigious area based at pfn 0. Some archictectures, like
> ARM, use ARCH_PFN_OFFSET to relax this requirement but it
> involves one more operation during page/pfn conversion.
>
> Instead this patch modifies the address of mem_map to make
> mem_map[ARCH_PFN_OFFSET] pointing at NODE_DATA(0)->node_mem_map.
> The result is a slight gain on kernel code size.
>
> It also relaxes this requirement in two more places:
> 	free_area_init(...)
> 	init_bootmem(...)
>
> ---
> include/asm-generic/memory_model.h |    6 +++---
> mm/bootmem.c                       |    4 ++--
> mm/page_alloc.c                    |   18 ++++++++++++------
> 3 files changed, 17 insertions(+), 11 deletions(-)
>
> diff --git a/include/asm-generic/memory_model.h b/include/asm-generic/memory_model.h
> index 0cfb086..2faa12f 100644
> --- a/include/asm-generic/memory_model.h
> +++ b/include/asm-generic/memory_model.h
> @@ -34,9 +34,9 @@ #else
>  */
> #if defined(CONFIG_FLATMEM)
>
> -#define pfn_to_page(pfn)	(mem_map + ((pfn) - ARCH_PFN_OFFSET))
> -#define page_to_pfn(page)	((unsigned long)((page) - mem_map) + \
> -				 ARCH_PFN_OFFSET)
> +#define pfn_to_page(pfn)	(mem_map + (pfn))
> +#define page_to_pfn(page)	((unsigned long)((page) - mem_map))
> +
> #elif defined(CONFIG_DISCONTIGMEM)
>
> #define pfn_to_page(pfn)			\
> diff --git a/mm/bootmem.c b/mm/bootmem.c
> index d213fed..fd28eed 100644
> --- a/mm/bootmem.c
> +++ b/mm/bootmem.c
> @@ -377,11 +377,11 @@ unsigned long __init free_all_bootmem_no
> 	return(free_all_bootmem_core(pgdat));
> }
>
> -unsigned long __init init_bootmem (unsigned long start, unsigned long pages)
> +unsigned long __init init_bootmem(unsigned long start, unsigned long pages)
> {
> 	max_low_pfn = pages;
> 	min_low_pfn = start;
> -	return(init_bootmem_core(NODE_DATA(0), start, 0, pages));
> +	return init_bootmem_core(NODE_DATA(0), start, ARCH_PFN_OFFSET, pages);
> }
>

Not all arches will use init_bootmem(). Arm for example uses 
init_bootmem_node(). ARCH_PFN_OFFSET is only meant to affect mem_map, not 
any node attribute. I suspect (but don't know for a fact) that if we try 
and change node attributes with ARCH_PFN_OFFSET, we'll shoot ourselves in 
the foot.

> #ifndef CONFIG_HAVE_ARCH_BOOTMEM_NODE
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 253a450..3e97bc3 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -2118,15 +2118,16 @@ static void __init free_area_init_core(s
>
> static void __init alloc_node_mem_map(struct pglist_data *pgdat)
> {
> +#ifdef CONFIG_FLAT_NODE_MEM_MAP
> +	struct page *map = pgdat->node_mem_map;
> +
> 	/* Skip empty nodes */
> 	if (!pgdat->node_spanned_pages)
> 		return;
>
> -#ifdef CONFIG_FLAT_NODE_MEM_MAP
> 	/* ia64 gets its own node_mem_map, before this, without bootmem */
> -	if (!pgdat->node_mem_map) {
> +	if (!map) {
> 		unsigned long size, start, end;
> -		struct page *map;
>
> 		/*
> 		 * The zone's endpoints aren't required to be MAX_ORDER
> @@ -2147,7 +2148,13 @@ #ifdef CONFIG_FLATMEM
> 	 * With no DISCONTIG, the global mem_map is just set as node 0's
> 	 */
> 	if (pgdat == NODE_DATA(0))
> -		mem_map = NODE_DATA(0)->node_mem_map;
> +		/*
> +		 * mem_map is assumed to be based at pfn 0 such that
> +		 * 'pfn = page* - mem_map' is true. Adjust map
> +		 * relative to node_mem_map to maintain this
> +		 * relationship.
> +		 */
> +		mem_map = map - ARCH_PFN_OFFSET;

This part is fine.

> #endif
> #endif /* CONFIG_FLAT_NODE_MEM_MAP */
> }
> @@ -2174,8 +2181,7 @@ #endif
>
> void __init free_area_init(unsigned long *zones_size)
> {
> -	free_area_init_node(0, NODE_DATA(0), zones_size,
> -			__pa(PAGE_OFFSET) >> PAGE_SHIFT, NULL);
> +	free_area_init_node(0, NODE_DATA(0), zones_size, ARCH_PFN_OFFSET, NULL);
> }
>

Same comment applies as for init_bootmem(). I can't be sure it's a good 
idea.

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

Re: 2.6.17-mm1

[Jiri Slaby]

Eduard Bloch napsal(a):
> #include <hallo.h>
> * Andrew Morton [Wed, Jun 21 2006, 03:48:57AM]:
>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm1/
> 
> Cannot build it. Looks like the build system is looping over:
> 
>   GEN     usr/klibc/syscalls/typesize.c
>   KLIBCCC usr/klibc/syscalls/typesize.o
>   OBJCOPY usr/klibc/syscalls/typesize.bin
>   GEN     usr/klibc/syscalls/syscalls.mk
>   GEN     usr/klibc/syscalls/typesize.c
>   KLIBCCC usr/klibc/syscalls/typesize.o
>   OBJCOPY usr/klibc/syscalls/typesize.bin
>   GEN     usr/klibc/syscalls/syscalls.mk
>   GEN     usr/klibc/syscalls/typesize.c
>   KLIBCCC usr/klibc/syscalls/typesize.o
>   OBJCOPY usr/klibc/syscalls/typesize.bin
>   GEN     usr/klibc/syscalls/syscalls.mk
>   GEN     usr/klibc/syscalls/typesize.c
>   KLIBCCC usr/klibc/syscalls/typesize.o
>   OBJCOPY usr/klibc/syscalls/typesize.bin
>   GEN     usr/klibc/syscalls/syscalls.mk
> 
> No matter whether executed as user or as root. Setting KBUILD_VERBOSE
> does not help much, for the log see http://people.debian.org/~blade/log .

Should be fixed already:
http://marc.theaimsgroup.com/?l=linux-kernel&m=115091547426482&w=2

regards,
-- 
Jiri Slaby         www.fi.muni.cz/~xslaby
\_.-^-._   jirislaby@gmail.com   _.-^-._/
B67499670407CE62ACC8 22A032CC55C339D47A7E

Re: [linux-pm] swsusp regression [Was: 2.6.17-mm1]

[Russell King]

On Fri, Jun 23, 2006 at 11:10:21AM +0200, Pavel Machek wrote:
> Serial console is currently broken by suspend, resume. _But_ I have a
> patch I'd like you to try.... pretty please?

Did you bother trying my patch, which was done the Right(tm) way?
There wasn't any feedback on it so I can only assume not.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: 2.6.17-mm1

[Russell King]

On Fri, Jun 23, 2006 at 05:14:23PM +0200, Franck Bui-Huu wrote:
> Franck Bui-Huu wrote:
> > -	free_area_init_node(0, NODE_DATA(0), zones_size,
> > -			__pa(PAGE_OFFSET) >> PAGE_SHIFT, NULL);
> 
> I'm wondering why using "__pa(PAGE_OFFSET) >> PAGE_SHIFT" to compute the start
> of memory. That should always result in 0, shouldn't it ?

No.  There are platforms where memory starts at about 3GB physical,
so __pa(PAGE_OFFSET) = 0xc0000000, which most definitely isn't zero
when shifted right by PAGE_SHIFT.

The world is not a PC.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: [linux-pm] swsusp regression [Was: 2.6.17-mm1]

[Andrew Morton]

On Fri, 23 Jun 2006 14:57:01 +0200
Pavel Machek <pavel@ucw.cz> wrote:

> > Stack: c0229b71 00000046 00000000 00000286 c0383ca7 f6cb9ecc c013b242 00000003
> >         00000000 00000003 f6cb9ee0 c013b2e8 00000003 c0436890 f6c9a003 f6cb9f08
> >         c013b481 00000003 00000003 00000246 c1788b00 00000003 c04368a0 c043692c
> > Call Trace:
> >  <c0103eea> show_stack_log_lvl+0x92/0xb7  <c0104100> show_registers+0x1a3/0x21b
> >  <c0104319> die+0x117/0x230  <c03627a6> do_page_fault+0x39c/0x72a
> >  <c0103b2f> error_code+0x4f/0x54  <c013b242> suspend_enter+0x2f/0x52
> >  <c013b2e8> enter_state+0x4b/0x8d  <c013b481> state_store+0xa0/0xa2
> >  <c01a5151> subsys_attr_store+0x37/0x41  <c01a53d2> flush_write_buffer+0x3c/0x46
> >  <c01a5443> sysfs_write_file+0x67/0x8b  <c0166bb6> vfs_write+0x1b9/0x1be
> >  <c0166c7b> sys_write+0x4b/0x75  <c010300f> sysenter_past_esp+0x54/0x75
> > 
> > Code: 05 c4 42 43 c0 31 43 43 c0 c3 8b 2d 68 6e 54 c0 8b 1d 60 6e 54 c0 8b 35 6c 6e 54 c0 8b 3d 70 6d 54 c0 ff 35 74 6e 54 c0 9d c3 90 <e8> 6d 38 ea ff e8 a2 ff ff ff 6a 03 e8 ec b6 de ff 83 c4 04 c3
> > EIP: [c043431c>] do_suspend_lowlevel+0x0/0x15 SS:ESP 0068:f6cb6ea4
>   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> Ha, wait a moment, this is interesting line. Can you trace down which
> instruction causes this?
> 
> We recently changed pagetable handling during swsusp, perhaps thats
> it? It went to Linus few minutes ago...

That's a good possibility.  It does appear to be oopsing at the first
instruction of arch/i386/kernel/acpi/wakeup.S:do_suspend_lowlevel(). 
Perhaps there's enough info in that oops trace to tell us whether it was
the instruction fetch which oopsed.

One wonders whether this will help...

--- a/arch/i386/kernel/acpi/wakeup.S~a
+++ a/arch/i386/kernel/acpi/wakeup.S
@@ -270,6 +270,7 @@ ALIGN
 ENTRY(saved_magic)	.long	0
 ENTRY(saved_eip)	.long	0
 
+.text
 save_registers:
 	leal	4(%esp), %eax
 	movl	%eax, saved_context_esp
@@ -304,6 +305,7 @@ ret_point:
 	call	restore_processor_state
 	ret
 
+.data
 ALIGN
 # saved registers
 saved_gdt:	.long	0,0
_

Re: [linux-pm] swsusp regression [Was: 2.6.17-mm1]

[Dave Jones]

On Fri, Jun 23, 2006 at 08:41:01PM +0100, Russell King wrote:
 > On Fri, Jun 23, 2006 at 11:10:21AM +0200, Pavel Machek wrote:
 > > Serial console is currently broken by suspend, resume. _But_ I have a
 > > patch I'd like you to try.... pretty please?
 > 
 > Did you bother trying my patch, which was done the Right(tm) way?
 > There wasn't any feedback on it so I can only assume not.

I thought I had replied to that.   It didn't make any difference for me.
I recall seeing a posting from someone else saying the same thing.

		Dave


-- 
http://www.codemonkey.org.uk

Re: 2.6.17-mm1

[Keith Mannthey]

Andrew,
  When I make mrproper to clean the kernel tree with the -mm trees (at
least the last few releases) I end up having to remove
/include/linux/dwarf2-defs.h myself.  This file is generated at build
time but mrproper isn't cleaning it up.   This file is always present
in a tree that has been built but not in the origninal tree so a diff
of the tree picks it up.

Is this expected?

Thanks,
  Keith

Re: 2.6.17-mm1

[Andrew Morton]

On Fri, 23 Jun 2006 14:33:27 +0200
"Michal Piotrowski" <michal.k.k.piotrowski@gmail.com> wrote:

> Hi,
> 
> On 21/06/06, Andrew Morton <akpm@osdl.org> wrote:
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm1/
> >
> 
> Firefox 2 - a new testing tool for bug hunters.

Thanks.

> Jun 23 11:03:48 ltg01-fedora kernel: =======================================
> Jun 23 11:03:48 ltg01-fedora kernel: [ INFO: out of order unlock detected. ]
> Jun 23 11:03:48 ltg01-fedora kernel: ---------------------------------------

This test is a bit of a nuisance.

> Jun 23 11:03:48 ltg01-fedora kernel: The code is fine but needs lock
> validator annotation.
> Jun 23 11:03:48 ltg01-fedora kernel: firefox-bin/25734 is trying to
> release lock (tasklist_lock) at:
> Jun 23 11:03:48 ltg01-fedora kernel:  [<c017b02c>] flush_old_exec+0x12f/0xa5f
> Jun 23 11:03:48 ltg01-fedora kernel: but the next lock to release is:
> Jun 23 11:03:48 ltg01-fedora kernel:  (&sighand->siglock){++..}, at:
> [<c017afab>] flush_old_exec+0xae/0xa5f
> Jun 23 11:03:48 ltg01-fedora kernel:
> Jun 23 11:03:48 ltg01-fedora kernel: other info that might help us debug this:
> Jun 23 11:03:48 ltg01-fedora kernel: 2 locks held by firefox-bin/25734:
> Jun 23 11:03:48 ltg01-fedora kernel:  #0:  (tasklist_lock){..??}, at:
> [<c017afa4>] flush_old_exec+0xa7/0xa5f
> Jun 23 11:03:48 ltg01-fedora kernel:  #1:  (&sighand->siglock){++..},
> at: [<c017afab>] flush_old_exec+0xae/0xa5f

This is de_thread().  It's deliberate.

Re: 2.6.17-mm1: UML failing w/o SKAS enabled

[Theodore Tso]

On Thu, Jun 22, 2006 at 10:42:22PM -0400, Jeff Dike wrote:
> On Thu, Jun 22, 2006 at 05:34:43PM -0400, Theodore Tso wrote:
> > When I tried compiling 2.6.17-mm1 without SKAS support, it failed to
> > link:
> 
> Why are you trying to do that?  tt mode is bitrotting - the only
> reason it is still there is that skas mode doesn't fully support SMP
> yet.  If SMP is the reason, then I'll add the necessary support and
> send in the patch.

Well, because my host kernel is running a completely stock 2.6.17
kernel and so I don't have the SKAS patch applied.  If the goal is to
abandon tt mode, it would be really nice if the SKAS patch gets
integrated into mainline first....

						- Ted

Re: [linux-pm] swsusp regression [Was: 2.6.17-mm1]

[Rafael J. Wysocki]

Hi,

On Friday 23 June 2006 21:41, Russell King wrote:
> On Fri, Jun 23, 2006 at 11:10:21AM +0200, Pavel Machek wrote:
> > Serial console is currently broken by suspend, resume. _But_ I have a
> > patch I'd like you to try.... pretty please?
> 
> Did you bother trying my patch, which was done the Right(tm) way?
> There wasn't any feedback on it so I can only assume not.

Sorry for that, I just couldn't test it earlier.  Works for me. :-)

Thanks,
Rafael

Re: 2.6.17-mm1

[Andrew Morton]

On Fri, 23 Jun 2006 13:39:01 -0700
"Keith Mannthey" <kmannth@gmail.com> wrote:

> Andrew,
>   When I make mrproper to clean the kernel tree with the -mm trees (at
> least the last few releases) I end up having to remove
> /include/linux/dwarf2-defs.h myself.  This file is generated at build
> time but mrproper isn't cleaning it up.   This file is always present
> in a tree that has been built but not in the origninal tree so a diff
> of the tree picks it up.
> 
> Is this expected?
> 

No, it's not expected.  That's due to the kgdb patches.

Sam, what should we be doing here?

Thanks.

Re: 2.6.17-mm1: UML failing w/o SKAS enabled

[Jeff Dike]

On Fri, Jun 23, 2006 at 05:07:14PM -0400, Theodore Tso wrote:
> Well, because my host kernel is running a completely stock 2.6.17
> kernel and so I don't have the SKAS patch applied.  If the goal is to
> abandon tt mode, it would be really nice if the SKAS patch gets
> integrated into mainline first....

UML has a form of skas which runs on stock hosts.  defconfig will give
you a CONFIG_MODE_SKAS, !CONFIG_MODE_TT UML which will run on an
unmodified host.

				Jeff

Re: [linux-pm] swsusp regression [Was: 2.6.17-mm1]

[Pavel Machek]

On Fri 2006-06-23 20:41:01, Russell King wrote:
> On Fri, Jun 23, 2006 at 11:10:21AM +0200, Pavel Machek wrote:
> > Serial console is currently broken by suspend, resume. _But_ I have a
> > patch I'd like you to try.... pretty please?
> 
> Did you bother trying my patch, which was done the Right(tm) way?
> There wasn't any feedback on it so I can only assume not.

(I actually forwarded him your patch in private email).
									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [linux-pm] swsusp regression [Was: 2.6.17-mm1]

[Frederik Deweerdt]

On Sat, Jun 24, 2006 at 12:11:18AM +0200, Pavel Machek wrote:
> On Fri 2006-06-23 20:41:01, Russell King wrote:
> > On Fri, Jun 23, 2006 at 11:10:21AM +0200, Pavel Machek wrote:
> > > Serial console is currently broken by suspend, resume. _But_ I have a
> > > patch I'd like you to try.... pretty please?
> > 
> > Did you bother trying my patch, which was done the Right(tm) way?
> > There wasn't any feedback on it so I can only assume not.
> 
> (I actually forwarded him your patch in private email).
And I did try it, but it make no difference: the output would still
appear on the laptop.

Regards,
Frederik

Re: [-mm patch] mm/readahead.c: cleanups

[Andrew Morton]

On Fri, 23 Jun 2006 12:56:17 +0200
Adrian Bunk <bunk@stusta.de> wrote:

> This patch contains the following cleanups:
> - make needlessly global code static
> - rename the global variable debug_level (sic) to readahead_debug_level
> - proper extern declaration for readahead_debug_level in 
>   include/linux/mm.h
> 

I can't really use this, since it sprinkles changes all over the patch
series.  Three separate patches would have been better, although even that
would be a hassle.

Anyway, I just edited the diffs, got most of it.

What does this

-	READAHEAD_DEBUGFS_ENTRY_U32(debug_level);
+	debugfs_create_u32("debug_level", 0644, root, &readahead_debug_level);

do?

Re: 2.6.17-mm1: UML failing w/o SKAS enabled

[Theodore Tso]

On Fri, Jun 23, 2006 at 05:46:23PM -0400, Jeff Dike wrote:
> On Fri, Jun 23, 2006 at 05:07:14PM -0400, Theodore Tso wrote:
> > Well, because my host kernel is running a completely stock 2.6.17
> > kernel and so I don't have the SKAS patch applied.  If the goal is to
> > abandon tt mode, it would be really nice if the SKAS patch gets
> > integrated into mainline first....
> 
> UML has a form of skas which runs on stock hosts.  defconfig will give
> you a CONFIG_MODE_SKAS, !CONFIG_MODE_TT UML which will run on an
> unmodified host.

It might be good to explicitly state that in the Kconfig
documentation, in particular in the documentation for CONFIG_MODE_TT.
Note that the entry for CONFIG_MODE_SKAS still mentions the need for
an external patch, and I tried searching 2.6.17-mm1's x86 config
options to see if the SKAS patch had been applied, and I couldn't find
anything, so I assumed that SKAS still required the out-of-tree patch.
If the situation is changed, 

config MODE_SKAS
        bool "Separate Kernel Address Space support" if MODE_TT
        default y
        help
        This option controls whether skas (separate kernel address space)
        support is compiled in.  If you have applied the skas patch to the
        host, then you certainly want to say Y here (and consider saying N
        to CONFIG_MODE_TT).  Otherwise, it is safe to say Y.  Disabling this
        option will shrink the UML binary slightly.

Also, just as a suggestion, it might be a good idea to update the UML
HOWTO in Documentation/uml/UserModeLinux-HOWTO.txt (or at least the
November 18, 2002 date), and also the SKAS page at:

	http://user-mode-linux.sourceforge.net/skas.html

Regards,

							- Ted

Re: 2.6.17-mm1: UML failing w/o SKAS enabled

[Theodore Tso]

[-- Attachment #1: Type: text/plain, Size: 1515 bytes --]

On Fri, Jun 23, 2006 at 05:46:23PM -0400, Jeff Dike wrote:
> On Fri, Jun 23, 2006 at 05:07:14PM -0400, Theodore Tso wrote:
> > Well, because my host kernel is running a completely stock 2.6.17
> > kernel and so I don't have the SKAS patch applied.  If the goal is to
> > abandon tt mode, it would be really nice if the SKAS patch gets
> > integrated into mainline first....
> 
> UML has a form of skas which runs on stock hosts.  defconfig will give
> you a CONFIG_MODE_SKAS, !CONFIG_MODE_TT UML which will run on an
> unmodified host.

OK, so now what did I do wrong?  Host is 2.6.17; running on a
dual-core Pentium M.   UML is 2.6.17-mm1 without any patches:

<tytso@candygram>       {/usr/projects/uml/linux-2.6.17-mm1}
32% ./linux
Checking that ptrace can change system call numbers...OK
Checking syscall emulation patch for ptrace...OK
Checking advanced syscall emulation patch for ptrace...OK
Checking for tmpfs mount on /dev/shm...OK
Checking PROT_EXEC mmap in /dev/shm/...OK
Checking for the skas3 patch in the host:
  - /proc/mm...not found
  - PTRACE_FAULTINFO...not found
  - PTRACE_LDT...not found
UML running in SKAS0 mode
Checking that ptrace can change system call numbers...OK
Checking syscall emulation patch for ptrace...OK
Checking advanced syscall emulation patch for ptrace...OK

<tytso@candygram>       {/usr/projects/uml/linux-2.6.17-mm1}
33%

Looks like UML just crashed (tm), without any explanation.  Kconfig
attached.  Suggestions on how to debug this would be appreciated.

						- Ted


[-- Attachment #2: .config --]
[-- Type: text/plain, Size: 14066 bytes --]

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.17-mm1
# Sat Jun 24 09:50:33 2006
#
CONFIG_GENERIC_HARDIRQS=y
CONFIG_UML=y
CONFIG_MMU=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_IRQ_RELEASE_METHOD=y

#
# UML-specific options
#
# CONFIG_MODE_TT is not set
# CONFIG_STATIC_LINK is not set
CONFIG_MODE_SKAS=y

#
# Host processor type and features
#
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMII is not set
# CONFIG_MPENTIUMIII is not set
CONFIG_MPENTIUMM=y
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MEFFICEON is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MGEODEGX1 is not set
# CONFIG_MGEODE_LX is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
CONFIG_X86_GENERIC=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_L1_CACHE_SHIFT=7
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_CMPXCHG64=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_TSC=y
CONFIG_UML_X86=y
# CONFIG_64BIT is not set
CONFIG_SEMAPHORE_SLEEPERS=y
# CONFIG_HOST_2G_2G is not set
CONFIG_TOP_ADDR=0xc0000000
# CONFIG_3_LEVEL_PGTABLES is not set
CONFIG_STUB_CODE=0xbfffe000
CONFIG_STUB_DATA=0xbffff000
CONFIG_STUB_START=0xbfffe000
CONFIG_ARCH_HAS_SC_SIGNALS=y
CONFIG_ARCH_REUSE_HOST_VSYSCALL_AREA=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y
# CONFIG_DISCONTIGMEM_MANUAL is not set
# CONFIG_SPARSEMEM_MANUAL is not set
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
# CONFIG_SPARSEMEM_STATIC is not set
CONFIG_SPLIT_PTLOCK_CPUS=4
CONFIG_ADAPTIVE_READAHEAD=y
CONFIG_DEBUG_READAHEAD=y
CONFIG_READAHEAD_SMOOTH_AGING=y
CONFIG_LD_SCRIPT_DYN=y
CONFIG_NET=y
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_MISC=y
CONFIG_HOSTFS=y
# CONFIG_HPPFS is not set
CONFIG_MCONSOLE=y
CONFIG_MAGIC_SYSRQ=y
CONFIG_NEST_LEVEL=0
CONFIG_HIGHMEM=y
CONFIG_KERNEL_STACK_ORDER=2
CONFIG_UML_REAL_TIME_CLOCK=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32

#
# General setup
#
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_SWAP=y
CONFIG_SWAP_PREFETCH=y
CONFIG_SYSVIPC=y
# CONFIG_IPC_NS is not set
CONFIG_POSIX_MQUEUE=y
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
# CONFIG_TASKSTATS is not set
CONFIG_SYSCTL=y
# CONFIG_UTS_NS is not set
CONFIG_AUDIT=y
CONFIG_AUDITSYSCALL=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_RELAY=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_KLIBC_ERRLIST=y
CONFIG_KLIBC_ZLIB=y
CONFIG_UID16=y
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
# CONFIG_EMBEDDED is not set
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_RT_MUTEXES=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SHMEM=y
CONFIG_SLAB=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
# CONFIG_SLOB is not set

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
CONFIG_MODVERSIONS=y
CONFIG_MODULE_SRCVERSION_ALL=y
CONFIG_KMOD=y

#
# Block layer
#
# CONFIG_LBD is not set
CONFIG_BLK_DEV_IO_TRACE=y
CONFIG_LSF=y

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

#
# Block devices
#
# CONFIG_BLK_DEV_UBD is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
# CONFIG_MMAPPER is not set
CONFIG_BLK_DEV_LOOP=y
# CONFIG_BLK_DEV_CRYPTOLOOP is not set
# CONFIG_BLK_DEV_NBD is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=4096
CONFIG_BLK_DEV_INITRD=y
# CONFIG_ATA_OVER_ETH is not set

#
# Character Devices
#
CONFIG_STDERR_CONSOLE=y
CONFIG_STDIO_CONSOLE=y
CONFIG_SSL=y
CONFIG_NULL_CHAN=y
CONFIG_PORT_CHAN=y
CONFIG_PTY_CHAN=y
CONFIG_TTY_CHAN=y
CONFIG_XTERM_CHAN=y
# CONFIG_NOCONFIG_CHAN is not set
CONFIG_CON_ZERO_CHAN="fd:0,fd:1"
CONFIG_CON_CHAN="xterm"
CONFIG_SSL_CHAN="pty"
CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256
CONFIG_WATCHDOG=y
# CONFIG_WATCHDOG_NOWAYOUT is not set
CONFIG_SOFT_WATCHDOG=m
# CONFIG_UML_WATCHDOG is not set
CONFIG_UML_SOUND=y
CONFIG_SOUND=y
CONFIG_HOSTAUDIO=y
CONFIG_UML_RANDOM=y

#
# Generic Driver Options
#
# CONFIG_STANDALONE is not set
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
# CONFIG_DEBUG_DRIVER is not set
# CONFIG_SYS_HYPERVISOR is not set

#
# Networking
#

#
# Networking options
#
# CONFIG_NETDEBUG is not set
CONFIG_PACKET=y
# CONFIG_PACKET_MMAP is not set
CONFIG_UNIX=y
CONFIG_XFRM=y
CONFIG_XFRM_USER=y
CONFIG_NET_KEY=y
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_ADVANCED_ROUTER=y
CONFIG_ASK_IP_FIB_HASH=y
# CONFIG_IP_FIB_TRIE is not set
CONFIG_IP_FIB_HASH=y
CONFIG_IP_MULTIPLE_TABLES=y
CONFIG_IP_ROUTE_MULTIPATH=y
# CONFIG_IP_ROUTE_MULTIPATH_CACHED is not set
# CONFIG_IP_ROUTE_VERBOSE is not set
# CONFIG_IP_PNP is not set
CONFIG_NET_IPIP=m
CONFIG_NET_IPGRE=m
# CONFIG_NET_IPGRE_BROADCAST is not set
# CONFIG_IP_MROUTE is not set
# CONFIG_ARPD is not set
CONFIG_SYN_COOKIES=y
CONFIG_INET_AH=y
CONFIG_INET_ESP=y
# CONFIG_INET_IPCOMP is not set
# CONFIG_INET_XFRM_TUNNEL is not set
CONFIG_INET_TUNNEL=m
# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
# CONFIG_INET_XFRM_MODE_TUNNEL is not set
CONFIG_INET_DIAG=y
CONFIG_INET_TCP_DIAG=y
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_BIC=y
CONFIG_IPV6=y
CONFIG_IPV6_PRIVACY=y
# CONFIG_IPV6_ROUTER_PREF is not set
# CONFIG_INET6_AH is not set
# CONFIG_INET6_ESP is not set
# CONFIG_INET6_IPCOMP is not set
# CONFIG_INET6_XFRM_TUNNEL is not set
# CONFIG_INET6_TUNNEL is not set
# CONFIG_INET6_XFRM_MODE_TRANSPORT is not set
# CONFIG_INET6_XFRM_MODE_TUNNEL is not set
# CONFIG_IPV6_TUNNEL is not set
# CONFIG_NETWORK_SECMARK is not set
# CONFIG_NETFILTER is not set

#
# DCCP Configuration (EXPERIMENTAL)
#
# CONFIG_IP_DCCP is not set

#
# SCTP Configuration (EXPERIMENTAL)
#
# CONFIG_IP_SCTP is not set

#
# TIPC Configuration (EXPERIMENTAL)
#
# CONFIG_TIPC is not set
# CONFIG_ATM is not set
# CONFIG_BRIDGE is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
CONFIG_NET_DIVERT=y
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set

#
# QoS and/or fair queueing
#
# CONFIG_NET_SCHED is not set

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_HAMRADIO is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
CONFIG_IEEE80211=m
# CONFIG_IEEE80211_DEBUG is not set
CONFIG_IEEE80211_CRYPT_WEP=m
# CONFIG_IEEE80211_CRYPT_CCMP is not set
# CONFIG_IEEE80211_CRYPT_TKIP is not set
# CONFIG_IEEE80211_SOFTMAC is not set
CONFIG_WIRELESS_EXT=y

#
# UML Network Devices
#
CONFIG_UML_NET=y
# CONFIG_UML_NET_ETHERTAP is not set
CONFIG_UML_NET_TUNTAP=y
# CONFIG_UML_NET_SLIP is not set
CONFIG_UML_NET_DAEMON=y
# CONFIG_UML_NET_MCAST is not set
# CONFIG_UML_NET_PCAP is not set
# CONFIG_UML_NET_SLIRP is not set

#
# Network device support
#
CONFIG_NETDEVICES=y
# CONFIG_DUMMY is not set
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
CONFIG_TUN=y

#
# PHY device support
#

#
# Wireless LAN (non-hamradio)
#
CONFIG_NET_RADIO=y
CONFIG_NET_WIRELESS_RTNETLINK=y

#
# Obsolete Wireless cards support (pre-802.11)
#
# CONFIG_STRIP is not set
CONFIG_HOSTAP=m
CONFIG_HOSTAP_FIRMWARE=y
CONFIG_HOSTAP_FIRMWARE_NVRAM=y

#
# Wan interfaces
#
# CONFIG_WAN is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set
# CONFIG_SHAPER is not set
# CONFIG_NETCONSOLE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set

#
# Connector - unified userspace <-> kernelspace linker
#
CONFIG_CONNECTOR=m
CONFIG_PROC_EVENTS=m

#
# File systems
#
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
CONFIG_EXT2_FS_SECURITY=y
# CONFIG_EXT2_FS_XIP is not set
CONFIG_EXT3_FS=y
CONFIG_EXT3_FS_XATTR=y
CONFIG_EXT3_FS_POSIX_ACL=y
CONFIG_EXT3_FS_SECURITY=y
CONFIG_JBD=y
CONFIG_JBD_DEBUG=y
CONFIG_FS_MBCACHE=y
# CONFIG_REISER4_FS is not set
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
CONFIG_FS_POSIX_ACL=y
# CONFIG_XFS_FS is not set
# CONFIG_GFS2_FS is not set
# CONFIG_OCFS2_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_ROMFS_FS is not set
# CONFIG_INOTIFY is not set
# CONFIG_QUOTA is not set
CONFIG_DNOTIFY=y
# CONFIG_AUTOFS_FS is not set
# CONFIG_AUTOFS4_FS is not set
# CONFIG_FUSE_FS is not set

#
# CD-ROM/DVD Filesystems
#
# CONFIG_ISO9660_FS is not set
# CONFIG_UDF_FS is not set

#
# DOS/FAT/NT Filesystems
#
# CONFIG_MSDOS_FS is not set
# CONFIG_VFAT_FS is not set
# CONFIG_NTFS_FS is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y
CONFIG_CONFIGFS_FS=m

#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
CONFIG_CRAMFS=y
# CONFIG_VXFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set

#
# Network File Systems
#
# CONFIG_NFS_FS is not set
# CONFIG_NFSD is not set
# CONFIG_SMB_FS is not set
# CONFIG_CIFS is not set
# CONFIG_CIFS_DEBUG2 is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set
# CONFIG_9P_FS is not set

#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
# CONFIG_ACORN_PARTITION is not set
# CONFIG_OSF_PARTITION is not set
# CONFIG_AMIGA_PARTITION is not set
# CONFIG_ATARI_PARTITION is not set
# CONFIG_MAC_PARTITION is not set
CONFIG_MSDOS_PARTITION=y
# CONFIG_BSD_DISKLABEL is not set
# CONFIG_MINIX_SUBPARTITION is not set
# CONFIG_SOLARIS_X86_PARTITION is not set
# CONFIG_UNIXWARE_DISKLABEL is not set
# CONFIG_LDM_PARTITION is not set
# CONFIG_SGI_PARTITION is not set
# CONFIG_ULTRIX_PARTITION is not set
# CONFIG_SUN_PARTITION is not set
# CONFIG_KARMA_PARTITION is not set
# CONFIG_EFI_PARTITION is not set

#
# Native Language Support
#
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-15"
CONFIG_NLS_CODEPAGE_437=y
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
# CONFIG_NLS_CODEPAGE_850 is not set
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
CONFIG_NLS_ASCII=y
# CONFIG_NLS_ISO8859_1 is not set
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
# CONFIG_NLS_ISO8859_15 is not set
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
# CONFIG_NLS_UTF8 is not set

#
# Distributed Lock Manager
#

#
# Security options
#
# CONFIG_KEYS is not set
# CONFIG_SECURITY is not set

#
# Cryptographic options
#
CONFIG_CRYPTO=y
CONFIG_CRYPTO_HMAC=y
CONFIG_CRYPTO_NULL=y
# CONFIG_CRYPTO_MD4 is not set
CONFIG_CRYPTO_MD5=y
CONFIG_CRYPTO_SHA1=y
# CONFIG_CRYPTO_SHA256 is not set
# CONFIG_CRYPTO_SHA512 is not set
# CONFIG_CRYPTO_WP512 is not set
# CONFIG_CRYPTO_TGR192 is not set
CONFIG_CRYPTO_DES=y
# CONFIG_CRYPTO_BLOWFISH is not set
# CONFIG_CRYPTO_TWOFISH is not set
# CONFIG_CRYPTO_TWOFISH_586 is not set
# CONFIG_CRYPTO_SERPENT is not set
# CONFIG_CRYPTO_AES is not set
# CONFIG_CRYPTO_AES_586 is not set
# CONFIG_CRYPTO_CAST5 is not set
# CONFIG_CRYPTO_CAST6 is not set
# CONFIG_CRYPTO_TEA is not set
CONFIG_CRYPTO_ARC4=y
# CONFIG_CRYPTO_KHAZAD is not set
# CONFIG_CRYPTO_ANUBIS is not set
# CONFIG_CRYPTO_DEFLATE is not set
# CONFIG_CRYPTO_MICHAEL_MIC is not set
# CONFIG_CRYPTO_CRC32C is not set
# CONFIG_CRYPTO_TEST is not set

#
# Hardware crypto devices
#

#
# Library routines
#
CONFIG_CRC_CCITT=y
# CONFIG_CRC16 is not set
CONFIG_CRC32=y
# CONFIG_LIBCRC32C is not set
CONFIG_ZLIB_INFLATE=y
CONFIG_PLIST=y

#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set
# CONFIG_INPUT is not set

#
# Kernel hacking
#
CONFIG_PRINTK_TIME=y
CONFIG_UNUSED_SYMBOLS=y
# CONFIG_DEBUG_SHIRQ is not set
CONFIG_DEBUG_KERNEL=y
CONFIG_LOG_BUF_SHIFT=17
CONFIG_DETECT_SOFTLOCKUP=y
CONFIG_SCHEDSTATS=y
# CONFIG_DEBUG_SLAB is not set
# CONFIG_DEBUG_RT_MUTEXES is not set
# CONFIG_RT_MUTEX_TESTER is not set
CONFIG_DEBUG_SPINLOCK=y
CONFIG_DEBUG_MUTEXES=y
# CONFIG_DEBUG_RWSEMS is not set
CONFIG_DEBUG_SPINLOCK_SLEEP=y
CONFIG_DEBUG_LOCKING_API_SELFTESTS=y
# CONFIG_DEBUG_KOBJECT is not set
# CONFIG_DEBUG_HIGHMEM is not set
CONFIG_DEBUG_INFO=y
CONFIG_DEBUG_FS=y
# CONFIG_DEBUG_VM is not set
CONFIG_FRAME_POINTER=y
CONFIG_UNWIND_INFO=y
CONFIG_FORCED_INLINING=y
# CONFIG_DEBUG_SYNCHRO_TEST is not set
# CONFIG_RCU_TORTURE_TEST is not set
# CONFIG_PROFILE_LIKELY is not set
# CONFIG_WANT_EXTRA_DEBUG_INFORMATION is not set
# CONFIG_GPROF is not set
# CONFIG_GCOV is not set
# CONFIG_SYSCALL_DEBUG is not set

Re: 2.6.17-mm1: UML failing w/o SKAS enabled

[Jeff Dike]

On Sat, Jun 24, 2006 at 08:43:54AM -0400, Theodore Tso wrote:
> It might be good to explicitly state that in the Kconfig
> documentation, in particular in the documentation for CONFIG_MODE_TT.

I'll fix those.

> Also, just as a suggestion, it might be a good idea to update the UML
> HOWTO in Documentation/uml/UserModeLinux-HOWTO.txt (or at least the
> November 18, 2002 date), and also the SKAS page at:
> 
> 	http://user-mode-linux.sourceforge.net/skas.html

Yeah, I'm working on updating the site - see 
	http://user-mode-linux.sourceforge.net/new/index.html
for what I have so far.
				Jeff

Re: 2.6.17-mm1: UML failing w/o SKAS enabled

[Jeff Dike]

On Sat, Jun 24, 2006 at 10:00:01AM -0400, Theodore Tso wrote:
> 32% ./linux
> Checking that ptrace can change system call numbers...OK
> Checking syscall emulation patch for ptrace...OK
> Checking advanced syscall emulation patch for ptrace...OK
> Checking for tmpfs mount on /dev/shm...OK
> Checking PROT_EXEC mmap in /dev/shm/...OK
> Checking for the skas3 patch in the host:
>   - /proc/mm...not found
>   - PTRACE_FAULTINFO...not found
>   - PTRACE_LDT...not found
> UML running in SKAS0 mode
> Checking that ptrace can change system call numbers...OK
> Checking syscall emulation patch for ptrace...OK
> Checking advanced syscall emulation patch for ptrace...OK
> 
> <tytso@candygram>       {/usr/projects/uml/linux-2.6.17-mm1}
> 33%
> 
> Looks like UML just crashed (tm), without any explanation.  Kconfig
> attached.  Suggestions on how to debug this would be appreciated.

I'm working on this - the genirq stuff in -mm broke UML.  Add stderr=1
to the command line to see the actual crash.  2.6.17 is fine, except
you need a klibc patch for O= builds.

				Jeff

Re: 2.6.17-mm1: UML failing w/o SKAS enabled

[Theodore Tso]

On Sat, Jun 24, 2006 at 11:22:35AM -0400, Jeff Dike wrote:
> I'm working on this - the genirq stuff in -mm broke UML.  Add stderr=1
> to the command line to see the actual crash.  2.6.17 is fine, except
> you need a klibc patch for O= builds.

Yeah, I was using CONFIG_MODE_TT with 2.6.17 to test the inode
slimming patches, mainly because it was a lot easier to test each
patch one at a time, and UML was working just fine for me.  The only
reason I was using TT was because it had always worked before, so I
just carried over the .config file and I didn't know that TT mode was
getting deprecated.  (I was using UML with 2.6.17-mm1 to port the
patches to the -mm tree so they could get wider testing.)

					- Ted

Re: 2.6.17-mm1: UML failing w/o SKAS enabled

[Thomas Gleixner]

On Sat, 2006-06-24 at 11:22 -0400, Jeff Dike wrote:
> On Sat, Jun 24, 2006 at 10:00:01AM -0400, Theodore Tso wrote:
> > Looks like UML just crashed (tm), without any explanation.  Kconfig
> > attached.  Suggestions on how to debug this would be appreciated.
> 
> I'm working on this - the genirq stuff in -mm broke UML.  Add stderr=1
> to the command line to see the actual crash.  2.6.17 is fine, except
> you need a klibc patch for O= builds.

Jeff, its the following patch:

http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm1/broken-out/genirq-allow-usage-of-no_irq_chip.patch

It was a brown paperbag thinko. Back it out or use -mm2

	tglx

Re: [linux-pm] swsusp regression [Was: 2.6.17-mm1]

[Rafael J. Wysocki]

On Saturday 24 June 2006 01:53, Frederik Deweerdt wrote:
> On Sat, Jun 24, 2006 at 12:11:18AM +0200, Pavel Machek wrote:
> > On Fri 2006-06-23 20:41:01, Russell King wrote:
> > > On Fri, Jun 23, 2006 at 11:10:21AM +0200, Pavel Machek wrote:
> > > > Serial console is currently broken by suspend, resume. _But_ I have a
> > > > patch I'd like you to try.... pretty please?
> > > 
> > > Did you bother trying my patch, which was done the Right(tm) way?
> > > There wasn't any feedback on it so I can only assume not.
> > 
> > (I actually forwarded him your patch in private email).
> And I did try it, but it make no difference: the output would still
> appear on the laptop.

You can try to use the hack at
http://www.sisk.pl/kernel/patches/2.6.17-mm1/hack-serial-suspend.patch
and see if that makes the messages get to the serial console.

Greetings,
Rafael

Re: 2.6.17-mm1

[Sam Ravnborg]

On Fri, Jun 23, 2006 at 02:32:05PM -0700, Andrew Morton wrote:
> On Fri, 23 Jun 2006 13:39:01 -0700
> "Keith Mannthey" <kmannth@gmail.com> wrote:
> 
> > Andrew,
> >   When I make mrproper to clean the kernel tree with the -mm trees (at
> > least the last few releases) I end up having to remove
> > /include/linux/dwarf2-defs.h myself.  This file is generated at build
> > time but mrproper isn't cleaning it up.   This file is always present
> > in a tree that has been built but not in the origninal tree so a diff
> > of the tree picks it up.
> > 
> > Is this expected?
> > 
> 
> No, it's not expected.  That's due to the kgdb patches.
> 
> Sam, what should we be doing here?

The dwarf2-defs.h file is similar to the asm-offsets.h file. We need it
before starting to build the kernel.
So the only same solution would be to move it all to the Kbuild file in
the top-level directory. Then we should also let same Kbuild file take
care of cleaning up.

I noticed that kgdb patches was dropped in -mm this time.
Shall I try to cook up a patch next time you include kgdb?

	Sam

Re: 2.6.17-mm1

[Andrew Morton]

On Sat, 24 Jun 2006 23:27:06 +0200
Sam Ravnborg <sam@ravnborg.org> wrote:

> On Fri, Jun 23, 2006 at 02:32:05PM -0700, Andrew Morton wrote:
> > On Fri, 23 Jun 2006 13:39:01 -0700
> > "Keith Mannthey" <kmannth@gmail.com> wrote:
> > 
> > > Andrew,
> > >   When I make mrproper to clean the kernel tree with the -mm trees (at
> > > least the last few releases) I end up having to remove
> > > /include/linux/dwarf2-defs.h myself.  This file is generated at build
> > > time but mrproper isn't cleaning it up.   This file is always present
> > > in a tree that has been built but not in the origninal tree so a diff
> > > of the tree picks it up.
> > > 
> > > Is this expected?
> > > 
> > 
> > No, it's not expected.  That's due to the kgdb patches.
> > 
> > Sam, what should we be doing here?
> 
> The dwarf2-defs.h file is similar to the asm-offsets.h file. We need it
> before starting to build the kernel.
> So the only same solution would be to move it all to the Kbuild file in
> the top-level directory. Then we should also let same Kbuild file take
> care of cleaning up.
> 
> I noticed that kgdb patches was dropped in -mm this time.
> Shall I try to cook up a patch next time you include kgdb?
> 

I wouldn't bother, really - we have bigger fish to fry.

I cc'ed Tom, who might care to take a look at it sometime.

Re: 2.6.17-mm1: UML failing w/o SKAS enabled

[Jeff Dike]

On Sat, Jun 24, 2006 at 06:06:50PM +0200, Thomas Gleixner wrote:
> Jeff, its the following patch:
> 
> http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm1/broken-out/genirq-allow-usage-of-no_irq_chip.patch
> 
> It was a brown paperbag thinko. Back it out or use -mm2

OK, thanks for letting me know.

				Jeff

Re: 2.6.17-mm1

[Franck Bui-Huu]

Hi Mel

Mel Gorman wrote:
> On Fri, 23 Jun 2006, Franck Bui-Huu wrote:
> 

[snip]

>>
>> -unsigned long __init init_bootmem (unsigned long start, unsigned long
>> pages)
>> +unsigned long __init init_bootmem(unsigned long start, unsigned long
>> pages)
>> {
>>     max_low_pfn = pages;
>>     min_low_pfn = start;
>> -    return(init_bootmem_core(NODE_DATA(0), start, 0, pages));
>> +    return init_bootmem_core(NODE_DATA(0), start, ARCH_PFN_OFFSET,
>> pages);
>> }
>>
> 
> Not all arches will use init_bootmem(). Arm for example uses
> init_bootmem_node(). ARCH_PFN_OFFSET is only meant to affect mem_map,

well, I don't agree here. ARCH_PFN_OFFSET is used to save the first
page number that has physical memory. I don't see why we couldn't use
it to correctly initialise the memory system...

If we don't change init_bootmem() to use ARCH_PFN_OFFSET, then the
kernel will initialise the start of memory to 0 which is boggus. IOW,
we can't use this function without this change (except if your memory
start at 0 of course). And I think that init_bootmem() has been
implemented for systems which have only one node _whatever_ memory
start value...

>> #ifndef CONFIG_HAVE_ARCH_BOOTMEM_NODE
>> diff --git a/mm/page_alloc.c b/mm/page_alloc.c

[snip]

>> @@ -2174,8 +2181,7 @@ #endif
>>
>> void __init free_area_init(unsigned long *zones_size)
>> {
>> -    free_area_init_node(0, NODE_DATA(0), zones_size,
>> -            __pa(PAGE_OFFSET) >> PAGE_SHIFT, NULL);
>> +    free_area_init_node(0, NODE_DATA(0), zones_size, ARCH_PFN_OFFSET,
>> NULL);
>> }
>>
> 
> Same comment applies as for init_bootmem(). I can't be sure it's a good
> idea.
> 

same comment as for init_bootmem()


		Franck

Re: [linux-pm] swsusp regression [Was: 2.6.17-mm1]

[Frederik Deweerdt]

On Fri, Jun 23, 2006 at 12:57:06PM -0700, Andrew Morton wrote:
> On Fri, 23 Jun 2006 14:57:01 +0200
> Pavel Machek <pavel@ucw.cz> wrote:
> 
> > > Stack: c0229b71 00000046 00000000 00000286 c0383ca7 f6cb9ecc c013b242 00000003
> > >         00000000 00000003 f6cb9ee0 c013b2e8 00000003 c0436890 f6c9a003 f6cb9f08
> > >         c013b481 00000003 00000003 00000246 c1788b00 00000003 c04368a0 c043692c
> > > Call Trace:
> > >  <c0103eea> show_stack_log_lvl+0x92/0xb7  <c0104100> show_registers+0x1a3/0x21b
> > >  <c0104319> die+0x117/0x230  <c03627a6> do_page_fault+0x39c/0x72a
> > >  <c0103b2f> error_code+0x4f/0x54  <c013b242> suspend_enter+0x2f/0x52
> > >  <c013b2e8> enter_state+0x4b/0x8d  <c013b481> state_store+0xa0/0xa2
> > >  <c01a5151> subsys_attr_store+0x37/0x41  <c01a53d2> flush_write_buffer+0x3c/0x46
> > >  <c01a5443> sysfs_write_file+0x67/0x8b  <c0166bb6> vfs_write+0x1b9/0x1be
> > >  <c0166c7b> sys_write+0x4b/0x75  <c010300f> sysenter_past_esp+0x54/0x75
> > > 
> > > Code: 05 c4 42 43 c0 31 43 43 c0 c3 8b 2d 68 6e 54 c0 8b 1d 60 6e 54 c0 8b 35 6c 6e 54 c0 8b 3d 70 6d 54 c0 ff 35 74 6e 54 c0 9d c3 90 <e8> 6d 38 ea ff e8 a2 ff ff ff 6a 03 e8 ec b6 de ff 83 c4 04 c3
> > > EIP: [c043431c>] do_suspend_lowlevel+0x0/0x15 SS:ESP 0068:f6cb6ea4
> >   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > 
> > Ha, wait a moment, this is interesting line. Can you trace down which
> > instruction causes this?
> > 
> > We recently changed pagetable handling during swsusp, perhaps thats
> > it? It went to Linus few minutes ago...
> 
> That's a good possibility.  It does appear to be oopsing at the first
> instruction of arch/i386/kernel/acpi/wakeup.S:do_suspend_lowlevel(). 
> Perhaps there's enough info in that oops trace to tell us whether it was
> the instruction fetch which oopsed.
> 
> One wonders whether this will help...
> 
I've tried 2.6.17-git10 which appears to have the fix and the laptop 
suspends correctly. Looks like that was it :).

Thanks,
Frederik

Re: 2.6.17-mm1

[Mel Gorman]

On Mon, 26 Jun 2006, Franck Bui-Huu wrote:

> Hi Mel
>
> Mel Gorman wrote:
>> On Fri, 23 Jun 2006, Franck Bui-Huu wrote:
>>
>
> [snip]
>
>>>
>>> -unsigned long __init init_bootmem (unsigned long start, unsigned long
>>> pages)
>>> +unsigned long __init init_bootmem(unsigned long start, unsigned long
>>> pages)
>>> {
>>>     max_low_pfn = pages;
>>>     min_low_pfn = start;
>>> -    return(init_bootmem_core(NODE_DATA(0), start, 0, pages));
>>> +    return init_bootmem_core(NODE_DATA(0), start, ARCH_PFN_OFFSET,
>>> pages);
>>> }
>>>
>>
>> Not all arches will use init_bootmem(). Arm for example uses
>> init_bootmem_node(). ARCH_PFN_OFFSET is only meant to affect mem_map,
>
> well, I don't agree here. ARCH_PFN_OFFSET is used to save the first
> page number that has physical memory. I don't see why we couldn't use
> it to correctly initialise the memory system...
>

Architectures will not always have a known fixed start of physical memory. 
On IA64 at least, they initialise memory as if it starts at 0 but on my 
one test machine, the beginning part is always a memory hole. I've seen 
nothing to indicate that this hole will be the same size on all IA64 
machines but I kinda doubt it. Also, arches that use init_bootmem() do not 
necessary use free_area_init().

> If we don't change init_bootmem() to use ARCH_PFN_OFFSET, then the
> kernel will initialise the start of memory to 0 which is boggus.
> IOW,
> we can't use this function without this change (except if your memory
> start at 0 of course). And I think that init_bootmem() has been
> implemented for systems which have only one node _whatever_ memory
> start value...
>

While you may be right, it'll only fix the problem for arches with 
ARCH_PFN_OFFSET and using init_bootmem (which is the case of MIPS I 
guess). But arches using init_bootmem_node or not using free_area_init() 
may still get kicked.

>>> #ifndef CONFIG_HAVE_ARCH_BOOTMEM_NODE
>>> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
>
> [snip]
>
>>> @@ -2174,8 +2181,7 @@ #endif
>>>
>>> void __init free_area_init(unsigned long *zones_size)
>>> {
>>> -    free_area_init_node(0, NODE_DATA(0), zones_size,
>>> -            __pa(PAGE_OFFSET) >> PAGE_SHIFT, NULL);
>>> +    free_area_init_node(0, NODE_DATA(0), zones_size, ARCH_PFN_OFFSET,
>>> NULL);
>>> }
>>>
>>
>> Same comment applies as for init_bootmem(). I can't be sure it's a good
>> idea.
>>
>
> same comment as for init_bootmem()
>
>
> 		Franck
>

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

Re: 2.6.17-mm1

[Franck Bui-Huu]

Mel Gorman wrote:
> 
> Architectures will not always have a known fixed start of physical
> memory. On IA64 at least, they initialise memory as if it starts at 0
> but on my one test machine, the beginning part is always a memory hole.

in that case ARCH_PFN_OFFSET is 0 which is the old behaviour, nothing
change...

> I've seen nothing to indicate that this hole will be the same size on
> all IA64 machines but I kinda doubt it. Also, arches that use
> init_bootmem() do not necessary use free_area_init().
> 

but in that case do they use ARCH_PFN_OFFSET != 0 ? if so that would be
very surprising. That would meand "I have a hole a the start of my mem,
I don't know at compile time where it starts, but I state that my physical
mem start at ARCH_PFN_OFFSET anyways"

>> If we don't change init_bootmem() to use ARCH_PFN_OFFSET, then the
>> kernel will initialise the start of memory to 0 which is boggus.
>> IOW,
>> we can't use this function without this change (except if your memory
>> start at 0 of course). And I think that init_bootmem() has been
>> implemented for systems which have only one node _whatever_ memory
>> start value...
>>
> 
> While you may be right, it'll only fix the problem for arches with
> ARCH_PFN_OFFSET and using init_bootmem (which is the case of MIPS I
> guess). But arches using init_bootmem_node or not using free_area_init()
> may still get kicked.
> 

Again in these cases, I doubt that they will setup ARCH_PFN_OFFSET...

		Franck

Re: 2.6.17-mm1: UML failing w/o SKAS enabled

[Roman Zippel]

Hi,

On Fri, 23 Jun 2006, Jeff Dike wrote:

> Index: linux-2.6.17/arch/um/Kconfig
> ===================================================================
> --- linux-2.6.17.orig/arch/um/Kconfig	2006-06-20 17:24:29.000000000 -0400
> +++ linux-2.6.17/arch/um/Kconfig	2006-06-23 10:20:27.000000000 -0400
> @@ -1,3 +1,8 @@
> +config DEFCONFIG_LIST
> +	string
> +	option defconfig_list
> +	default "arch/um/defconfig"
> +
>  # UML uses the generic IRQ sugsystem
>  config GENERIC_HARDIRQS
>  	bool

That would work too, but what I had in mind was to customize the entry in 
init/Kconfig, e.g.

config DEFCONFIG_LIST
	string
	option defconfig_list
	default "/lib/modules/$UNAME_RELEASE/.config"
	default "/etc/kernel-config"
	default "/boot/config-$UNAME_RELEASE"
	depends on !UML

config DEFCONFIG_LIST
	default "arch/$ARCH/defconfig"

This way the last entry is always the same for all archs and the rest can 
be customized.

bye, Roman

Re: 2.6.17-mm1

[Mel Gorman]

On Mon, 26 Jun 2006, Franck Bui-Huu wrote:

> Mel Gorman wrote:

>>>> Not all arches will use init_bootmem(). Arm for example uses
>>>> init_bootmem_node(). ARCH_PFN_OFFSET is only meant to affect mem_map,
>>>>
>>> well, I don't agree here. ARCH_PFN_OFFSET is used to save the first
>>> page number that has physical memory. I don't see why we couldn't 
>>> useit to correctly initialise the memory system...
>>
>> Architectures will not always have a known fixed start of physical
>> memory. On IA64 at least, they initialise memory as if it starts at 0
>> but on my one test machine, the beginning part is always a memory hole.
>
> in that case ARCH_PFN_OFFSET is 0 which is the old behaviour, nothing
> change...
>

The change is that ARCH_PFN_OFFSET has a slightly different meaning when 
you alter those two initialisation functions. Currently it is used to 
offset memmap from NODE_DATA(0)->node_start_pfn. By changing 
free_area_init() and init_bootmem(), it changes to altering the value of 
NODE_DATA(0)->node_start_pfn but only when memory is initialised in a 
particular way. I believe it makes ARCH_PFN_OFFSET even more obscure than 
it currently is.

I think we should just fix the problem at hand now for which two simple 
patches have been posted and consider making further changes to 
free_area_init() and init_bootmem() as a separate issue.

>> I've seen nothing to indicate that this hole will be the same size on
>> all IA64 machines but I kinda doubt it. Also, arches that use
>> init_bootmem() do not necessary use free_area_init().
>>
>
> but in that case do they use ARCH_PFN_OFFSET != 0 ?

IA64 do not and I didn't check all arches.

> if so that would be
> very surprising. That would meand "I have a hole a the start of my mem,
> I don't know at compile time where it starts, but I state that my physical
> mem start at ARCH_PFN_OFFSET anyways"
>
>>> If we don't change init_bootmem() to use ARCH_PFN_OFFSET, then the
>>> kernel will initialise the start of memory to 0 which is boggus.
>>> IOW,
>>> we can't use this function without this change (except if your memory
>>> start at 0 of course). And I think that init_bootmem() has been
>>> implemented for systems which have only one node _whatever_ memory
>>> start value...
>>>
>>
>> While you may be right, it'll only fix the problem for arches with
>> ARCH_PFN_OFFSET and using init_bootmem (which is the case of MIPS I
>> guess). But arches using init_bootmem_node or not using free_area_init()
>> may still get kicked.
>>
>
> Again in these cases, I doubt that they will setup ARCH_PFN_OFFSET...
>

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

Re: 2.6.17-mm1

[Franck Bui-Huu]

Mel Gorman wrote:
> On Mon, 26 Jun 2006, Franck Bui-Huu wrote:
> 
>> Mel Gorman wrote:
> 
>>>>> Not all arches will use init_bootmem(). Arm for example uses
>>>>> init_bootmem_node(). ARCH_PFN_OFFSET is only meant to affect mem_map,
>>>>>
>>>> well, I don't agree here. ARCH_PFN_OFFSET is used to save the first
>>>> page number that has physical memory. I don't see why we couldn't
>>>> useit to correctly initialise the memory system...
>>>
>>> Architectures will not always have a known fixed start of physical
>>> memory. On IA64 at least, they initialise memory as if it starts at 0
>>> but on my one test machine, the beginning part is always a memory hole.
>>
>> in that case ARCH_PFN_OFFSET is 0 which is the old behaviour, nothing
>> change...
>>
> 
> The change is that ARCH_PFN_OFFSET has a slightly different meaning when
> you alter those two initialisation functions. Currently it is used to
> offset memmap from NODE_DATA(0)->node_start_pfn. By changing
> free_area_init() and init_bootmem(), it changes to altering the value of
> NODE_DATA(0)->node_start_pfn but only when memory is initialised in a
> particular way. 

well I don't see your point there. Is ARCH_PFN_OFFSET != 0 supposed to work
with free_area_init() and init_bootmem() ? If so, there is a bug since
NODE_DATA(0)->node_start_pfn is not setup correctly...

> I think we should just fix the problem at hand now for which two simple
> patches have been posted and consider making further changes to
> free_area_init() and init_bootmem() as a separate issue.
> 

I agree this is a separate issue. We should resolve it in a different thread.
Mind to start a new one that involve people who can shed some light here ?

Thanks

		Franck

Re: 2.6.17-mm1

[Mel Gorman]

On (26/06/06 15:49), Franck Bui-Huu didst pronounce:
> Mel Gorman wrote:
> > On Mon, 26 Jun 2006, Franck Bui-Huu wrote:
> > 
> >> Mel Gorman wrote:
> > 
> >>>>> Not all arches will use init_bootmem(). Arm for example uses
> >>>>> init_bootmem_node(). ARCH_PFN_OFFSET is only meant to affect mem_map,
> >>>>>
> >>>> well, I don't agree here. ARCH_PFN_OFFSET is used to save the first
> >>>> page number that has physical memory. I don't see why we couldn't
> >>>> useit to correctly initialise the memory system...
> >>>
> >>> Architectures will not always have a known fixed start of physical
> >>> memory. On IA64 at least, they initialise memory as if it starts at 0
> >>> but on my one test machine, the beginning part is always a memory hole.
> >>
> >> in that case ARCH_PFN_OFFSET is 0 which is the old behaviour, nothing
> >> change...
> >>
> > 
> > The change is that ARCH_PFN_OFFSET has a slightly different meaning when
> > you alter those two initialisation functions. Currently it is used to
> > offset memmap from NODE_DATA(0)->node_start_pfn. By changing
> > free_area_init() and init_bootmem(), it changes to altering the value of
> > NODE_DATA(0)->node_start_pfn but only when memory is initialised in a
> > particular way. 
> 
> well I don't see your point there. Is ARCH_PFN_OFFSET != 0 supposed to work
> with free_area_init() and init_bootmem() ?

I don't know for sure and for that reason alone, I'd rather not change
the meaning of ARCH_PFN_OFFSET as part of a "fix".

> If so, there is a bug since
> NODE_DATA(0)->node_start_pfn is not setup correctly...
> 
> > I think we should just fix the problem at hand now for which two simple
> > patches have been posted and consider making further changes to
> > free_area_init() and init_bootmem() as a separate issue.
> > 
> 
> I agree this is a separate issue. We should resolve it in a different thread.
> Mind to start a new one that involve people who can shed some light here ?
> 

Lets close this out first and then figure out where to go next.  The following
patch should fix the problem where mem_map is offset twice when ARCH_PFN_OFFSET
!= 0 and documents what ARCH_PFN_OFFSET is for.

Signed-off-by: Mel Gorman <mel@csn.ul.ie>
diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.17-mm2-clean/include/asm-generic/memory_model.h linux-2.6.17-mm2-archpfnfix/include/asm-generic/memory_model.h
--- linux-2.6.17-mm2-clean/include/asm-generic/memory_model.h	2006-06-26 11:38:21.000000000 +0100
+++ linux-2.6.17-mm2-archpfnfix/include/asm-generic/memory_model.h	2006-06-26 15:22:19.000000000 +0100
@@ -6,6 +6,20 @@
 
 #if defined(CONFIG_FLATMEM)
 
+/*
+ * With FLATMEM, the mem_map on node 0 is used as the global mem_map.
+ * This implicitly assumes that NODE_DATA(0)->node_start_pfn == 0 and
+ * represents the first physical page frame in the system. This is not
+ * always the case as an architecture may start physical memory at 3GB
+ * for example. Rather than allocating an empty mem_map to represent
+ * the non-existent memory, ARCH_PFN_OFFSET is subtracted from
+ * NODE_DATA(0)->node_mem_map such that;
+ *
+ * PFN 0 = mem_map = NODE_DATA(0)->node_mem_map - ARCH_PFN_OFFSET
+ *
+ * One would expect NODE_DATA(0)->node_start_pfn == ARCH_PFN_OFFSET but
+ * depending on how memory is initialised, this is not always the case.
+ */
 #ifndef ARCH_PFN_OFFSET
 #define ARCH_PFN_OFFSET		(0UL)
 #endif
@@ -28,9 +42,8 @@
  */
 #if defined(CONFIG_FLATMEM)
 
-#define __pfn_to_page(pfn)	(mem_map + ((pfn) - ARCH_PFN_OFFSET))
-#define __page_to_pfn(page)	((unsigned long)((page) - mem_map) + \
-				 ARCH_PFN_OFFSET)
+#define __pfn_to_page(pfn)	(mem_map + (pfn))
+#define __page_to_pfn(page)	((unsigned long)((page) - mem_map))
 #elif defined(CONFIG_DISCONTIGMEM)
 
 #define __pfn_to_page(pfn)			\
diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.17-mm2-clean/mm/page_alloc.c linux-2.6.17-mm2-archpfnfix/mm/page_alloc.c
--- linux-2.6.17-mm2-clean/mm/page_alloc.c	2006-06-26 11:38:21.000000000 +0100
+++ linux-2.6.17-mm2-archpfnfix/mm/page_alloc.c	2006-06-26 15:11:29.000000000 +0100
@@ -2103,7 +2103,7 @@ static void __init alloc_node_mem_map(st
 		 * is true. Adjust map relative to node_mem_map to
 		 * maintain this relationship.
 		 */
-		map -= pgdat->node_start_pfn;
+		map -= ARCH_PFN_OFFSET;
 	}
 #ifdef CONFIG_FLATMEM
 	/*

-- 
-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

Re: 2.6.17-mm1

[Franck Bui-Huu]

Mel Gorman wrote:
> 
> Lets close this out first and then figure out where to go next.  The following
> patch should fix the problem where mem_map is offset twice when ARCH_PFN_OFFSET
> != 0 and documents what ARCH_PFN_OFFSET is for.
> 

why not dropping the initial patch, and resubmit the whole thing that
can be called an optimization rather than a fix ?

> Signed-off-by: Mel Gorman <mel@csn.ul.ie>
> diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.17-mm2-clean/include/asm-generic/memory_model.h linux-2.6.17-mm2-archpfnfix/include/asm-generic/memory_model.h
> --- linux-2.6.17-mm2-clean/include/asm-generic/memory_model.h	2006-06-26 11:38:21.000000000 +0100
> +++ linux-2.6.17-mm2-archpfnfix/include/asm-generic/memory_model.h	2006-06-26 15:22:19.000000000 +0100
> @@ -6,6 +6,20 @@
>  
>  #if defined(CONFIG_FLATMEM)
>  
> +/*
> + * With FLATMEM, the mem_map on node 0 is used as the global mem_map.
> + * This implicitly assumes that NODE_DATA(0)->node_start_pfn == 0 and
> + * represents the first physical page frame in the system. This is not
> + * always the case as an architecture may start physical memory at 3GB
> + * for example. Rather than allocating an empty mem_map to represent
> + * the non-existent memory, ARCH_PFN_OFFSET is subtracted from
> + * NODE_DATA(0)->node_mem_map such that;
> + *
> + * PFN 0 = mem_map = NODE_DATA(0)->node_mem_map - ARCH_PFN_OFFSET
> + *
> + * One would expect NODE_DATA(0)->node_start_pfn == ARCH_PFN_OFFSET but
> + * depending on how memory is initialised, this is not always the case.
> + */
>  #ifndef ARCH_PFN_OFFSET
>  #define ARCH_PFN_OFFSET		(0UL)
>  #endif
> @@ -28,9 +42,8 @@
>   */
>  #if defined(CONFIG_FLATMEM)
>  
> -#define __pfn_to_page(pfn)	(mem_map + ((pfn) - ARCH_PFN_OFFSET))
> -#define __page_to_pfn(page)	((unsigned long)((page) - mem_map) + \
> -				 ARCH_PFN_OFFSET)
> +#define __pfn_to_page(pfn)	(mem_map + (pfn))
> +#define __page_to_pfn(page)	((unsigned long)((page) - mem_map))
>  #elif defined(CONFIG_DISCONTIGMEM)
>  
>  #define __pfn_to_page(pfn)			\
> diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.17-mm2-clean/mm/page_alloc.c linux-2.6.17-mm2-archpfnfix/mm/page_alloc.c
> --- linux-2.6.17-mm2-clean/mm/page_alloc.c	2006-06-26 11:38:21.000000000 +0100
> +++ linux-2.6.17-mm2-archpfnfix/mm/page_alloc.c	2006-06-26 15:11:29.000000000 +0100
> @@ -2103,7 +2103,7 @@ static void __init alloc_node_mem_map(st
>  		 * is true. Adjust map relative to node_mem_map to
>  		 * maintain this relationship.
>  		 */
> -		map -= pgdat->node_start_pfn;
> +		map -= ARCH_PFN_OFFSET;

why not moving this inside the if statement below ?

>  	}
>  #ifdef CONFIG_FLATMEM
>  	/*
> 

Re: 2.6.17-mm1

[Mel Gorman]

On Mon, 26 Jun 2006, Franck Bui-Huu wrote:

> Mel Gorman wrote:
>>
>> Lets close this out first and then figure out where to go next.  The following
>> patch should fix the problem where mem_map is offset twice when ARCH_PFN_OFFSET
>> != 0 and documents what ARCH_PFN_OFFSET is for.
>>
>
> why not dropping the initial patch, and resubmit the whole thing that
> can be called an optimization rather than a fix ?
>

Also works. I note that the patch has been dropped from -mm so I'll 
revisit it after the next -mm release.

> <snipped>

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

Re: 2.6.17-mm1: UML failing w/o SKAS enabled

[Jeff Dike]

On Mon, Jun 26, 2006 at 01:52:54PM +0200, Roman Zippel wrote:
> That would work too, but what I had in mind was to customize the entry in 
> init/Kconfig, e.g.
> 
> config DEFCONFIG_LIST
> 	string
> 	option defconfig_list
> 	default "/lib/modules/$UNAME_RELEASE/.config"
> 	default "/etc/kernel-config"
> 	default "/boot/config-$UNAME_RELEASE"
> 	depends on !UML
> 
> config DEFCONFIG_LIST
> 	default "arch/$ARCH/defconfig"
> 
> This way the last entry is always the same for all archs and the rest can 
> be customized.

Fine by me, are you going to send that in, or should I?

				Jeff

Re: 2.6.17-mm1

[Tom Rini]

On Sat, Jun 24, 2006 at 02:53:05PM -0700, Andrew Morton wrote:
> On Sat, 24 Jun 2006 23:27:06 +0200
> Sam Ravnborg <sam@ravnborg.org> wrote:
> 
> > On Fri, Jun 23, 2006 at 02:32:05PM -0700, Andrew Morton wrote:
> > > On Fri, 23 Jun 2006 13:39:01 -0700
> > > "Keith Mannthey" <kmannth@gmail.com> wrote:
> > > 
> > > > Andrew,
> > > >   When I make mrproper to clean the kernel tree with the -mm trees (at
> > > > least the last few releases) I end up having to remove
> > > > /include/linux/dwarf2-defs.h myself.  This file is generated at build
> > > > time but mrproper isn't cleaning it up.   This file is always present
> > > > in a tree that has been built but not in the origninal tree so a diff
> > > > of the tree picks it up.
> > > > 
> > > > Is this expected?
> > > > 
> > > 
> > > No, it's not expected.  That's due to the kgdb patches.
> > > 
> > > Sam, what should we be doing here?
> > 
> > The dwarf2-defs.h file is similar to the asm-offsets.h file. We need it
> > before starting to build the kernel.
> > So the only same solution would be to move it all to the Kbuild file in
> > the top-level directory. Then we should also let same Kbuild file take
> > care of cleaning up.
> > 
> > I noticed that kgdb patches was dropped in -mm this time.
> > Shall I try to cook up a patch next time you include kgdb?
> > 
> 
> I wouldn't bother, really - we have bigger fish to fry.

Just got back from a holiday, catching up on things now.

I _thought_ this had been fixed, but it may have been after Andrew
grabbed the patches last, I'll double check soon.

-- 
Tom Rini

Re: 2.6.17-mm1

[Paulo Marques]

Andrew Morton wrote:
> And that's LIST_POISON1.
> 
> The only s_show()s I can see are in slab and in kallsyms.
>
> It would help if you could gdb these guys, work out file-n-line.

I just checked s_show in kernel/kallsyms.c and I can not see how it 
could BUG without BUG'ing in s_next first, because that function only 
formats the information that has been gathered by s_next.

> And it would be super-good if you could revert
> slab-stop-using-list_for_each.patch and retest.  

My bet goes to slab's s_show, too. Besides, that code in kallsyms has 
been like that for a very long time, IIRC.

-- 
Paulo Marques - www.grupopie.com

Pointy-Haired Boss: I don't see anything that could stand in our way.
            Dilbert: Sanity? Reality? The laws of physics?

Re: 2.6.17-mm1

[Chuck Ebbert]

In-Reply-To: <20060623143004.6af78d68.akpm@osdl.org>

On Fri, 23 Jun 2006 14:30:04 -0700, Andrew Morton wrote:

> On Fri, 23 Jun 2006 12:23:54 -0700
> Martin Bligh <mbligh@mbligh.org> wrote:
> 
> > On 16x NUMA-Q, got a panic running dbench across different fs's.

> > Got a very similar panic on a flat SMP box too:
> > 
> > BUG: unable to handle kernel paging request at virtual address 00100100

> And that's LIST_POISON1.
> 
> The only s_show()s I can see are in slab and in kallsyms.
> 
> It would help if you could gdb these guys, work out file-n-line.

It's definitely in slab, in one of the loops walking the full, partial
and free chains.

> 
> And it would be super-good if you could revert
> slab-stop-using-list_for_each.patch and retest.  

I don't think that's the problem.  It really looks like a corrupted list.

How does this keep showing up in slab all the time?  Broken locking?

And also, looking at the prefetching in the list macros, it can have the
same effect as list_for_each_safe -- _if_ the compiler decides to save
the pointer it passed to prefetch().  In this case it didn't...

-- 
Chuck
 "You can't read a newspaper if you can't read."  --George W. Bush

Re: 2.6.17-mm1

[Andrew Morton]

On Fri, 23 Jun 2006 12:23:54 -0700
Martin Bligh <mbligh@mbligh.org> wrote:

> On 16x NUMA-Q, got a panic running dbench across different fs's.
> 
> 
> BUG: unable to handle kernel NULL pointer dereference at virtual address 
> 00000000
>   printing eip:
> c0154030
> *pde = 2589f001
> *pte = 00000000
> Oops: 0000 [#1]
> 8K_STACKS SMP
> last sysfs file: /devices/pci0000:00/0000:00:0a.0/resource
> Modules linked in:
> CPU:    1
> EIP:    0060:[<c0154030>]    Not tainted VLI
> EFLAGS: 00010006   (2.6.17-mm1-autokern1 #1)
> EIP is at s_show+0xe5/0x28e
> eax: c038efe0   ebx: e744ef60   ecx: 00000000   edx: 00000000
> esi: c038efe0   edi: 00000000   ebp: e744b2c0   esp: e67aff14
> ds: 007b   es: 007b   ss: 0068
> Process cp (pid: 7295, ti=e67ae000 task=e1521570 task.ti=e67ae000)
> Stack: 00000000 00000000 00000000 00000072 00000c66 e64a78c0 e744b2c0 
> 00000000
>         00001000 c01724e5 e64a78c0 e744b2c0 0000087e 00000000 0000005c 
> 00000000
>         0000005b 00000000 e6754720 bfc8afa0 e67affa4 00001000 c0156e80 
> e6754720
> Call Trace:
>   [<c01724e5>] seq_read+0x195/0x262
>   [<c0156e80>] vfs_read+0x88/0x11e
>   [<c0157160>] sys_read+0x3b/0x63
>   [<c036d07f>] syscall_call+0x7/0xb
> Code: 10 3b 8d d4 00 00 00 75 0a 85 f6 b8 a0 ef 38 c0 0f 44 f0 85 c9 75 
> 0a 85 f6 b8 e0 ef 38 c0 0f 44 f0 01 4c 24 10 ff 44 24 0c 8b 12 <8b> 02 
> 0f 18 00 90 39 da 75 c9 8b 53 10 8b 02 0f 18 00 90 8d 43
> EIP: [<c0154030>] s_show+0xe5/0x28e SS:ESP 0068:e67aff14

That's a null-pointer deref

> Got a very similar panic on a flat SMP box too:
> 
> BUG: unable to handle kernel paging request at virtual address 00100100
>   printing eip:
> c0154030
> *pde = 2f2fa001
> *pte = 00000000
> Oops: 0000 [#1]
> 8K_STACKS SMP
> last sysfs file: /devices/pci0000:00/0000:00:0a.0/resource
> Modules linked in:
> CPU:    1
> EIP:    0060:[<c0154030>]    Not tainted VLI
> EFLAGS: 00010006   (2.6.17-mm1-autokern1 #1)
> EIP is at s_show+0xe5/0x28e
> eax: c038efe0   ebx: dffead60   ecx: 00000000   edx: 00100100
> esi: c038efe0   edi: 00000000   ebp: dffe7660   esp: f69a7f14
> ds: 007b   es: 007b   ss: 0068
> Process cp (pid: 7190, ti=f69a6000 task=f64dc570 task.ti=f69a6000)
> Stack: 00000000 00000000 00000000 0000003f 00000328 f650a620 dffe7660 
> 00000000
>         00001000 c01724e5 f650a620 dffe7660 00000909 00000000 0000005d 
> 00000000
>         0000005c 00000000 ed4d3200 bff47a70 f69a7fa4 00001000 c0156e80 
> ed4d3200
> Call Trace:
>   [<c01724e5>] seq_read+0x195/0x262
>   [<c0156e80>] vfs_read+0x88/0x11e
>   [<c0157160>] sys_read+0x3b/0x63
>   [<c036d07f>] syscall_call+0x7/0xb
> Code: 10 3b 8d d4 00 00 00 75 0a 85 f6 b8 a0 ef 38 c0 0f 44 f0 85 c9 75 
> 0a 85 f6 b8 e0 ef 38 c0 0f 44 f0 01 4c 24 10 ff 44 24 0c 8b 12 <8b> 02 
> 8d 74 26 00 39 da 75 c9 8b 53 10 8b 02 8d 74 26 00 8d 43
> EIP: [<c0154030>] s_show+0xe5/0x28e SS:ESP 0068:f69a7f14

And that's LIST_POISON1.

The only s_show()s I can see are in slab and in kallsyms.

It would help if you could gdb these guys, work out file-n-line.

And it would be super-good if you could revert
slab-stop-using-list_for_each.patch and retest.  

Re: 2.6.17-mm1

[Martin Bligh]

On 16x NUMA-Q, got a panic running dbench across different fs's.


BUG: unable to handle kernel NULL pointer dereference at virtual address 
00000000
  printing eip:
c0154030
*pde = 2589f001
*pte = 00000000
Oops: 0000 [#1]
8K_STACKS SMP
last sysfs file: /devices/pci0000:00/0000:00:0a.0/resource
Modules linked in:
CPU:    1
EIP:    0060:[<c0154030>]    Not tainted VLI
EFLAGS: 00010006   (2.6.17-mm1-autokern1 #1)
EIP is at s_show+0xe5/0x28e
eax: c038efe0   ebx: e744ef60   ecx: 00000000   edx: 00000000
esi: c038efe0   edi: 00000000   ebp: e744b2c0   esp: e67aff14
ds: 007b   es: 007b   ss: 0068
Process cp (pid: 7295, ti=e67ae000 task=e1521570 task.ti=e67ae000)
Stack: 00000000 00000000 00000000 00000072 00000c66 e64a78c0 e744b2c0 
00000000
        00001000 c01724e5 e64a78c0 e744b2c0 0000087e 00000000 0000005c 
00000000
        0000005b 00000000 e6754720 bfc8afa0 e67affa4 00001000 c0156e80 
e6754720
Call Trace:
  [<c01724e5>] seq_read+0x195/0x262
  [<c0156e80>] vfs_read+0x88/0x11e
  [<c0157160>] sys_read+0x3b/0x63
  [<c036d07f>] syscall_call+0x7/0xb
Code: 10 3b 8d d4 00 00 00 75 0a 85 f6 b8 a0 ef 38 c0 0f 44 f0 85 c9 75 
0a 85 f6 b8 e0 ef 38 c0 0f 44 f0 01 4c 24 10 ff 44 24 0c 8b 12 <8b> 02 
0f 18 00 90 39 da 75 c9 8b 53 10 8b 02 0f 18 00 90 8d 43
EIP: [<c0154030>] s_show+0xe5/0x28e SS:ESP 0068:e67aff14

Got a very similar panic on a flat SMP box too:

BUG: unable to handle kernel paging request at virtual address 00100100
  printing eip:
c0154030
*pde = 2f2fa001
*pte = 00000000
Oops: 0000 [#1]
8K_STACKS SMP
last sysfs file: /devices/pci0000:00/0000:00:0a.0/resource
Modules linked in:
CPU:    1
EIP:    0060:[<c0154030>]    Not tainted VLI
EFLAGS: 00010006   (2.6.17-mm1-autokern1 #1)
EIP is at s_show+0xe5/0x28e
eax: c038efe0   ebx: dffead60   ecx: 00000000   edx: 00100100
esi: c038efe0   edi: 00000000   ebp: dffe7660   esp: f69a7f14
ds: 007b   es: 007b   ss: 0068
Process cp (pid: 7190, ti=f69a6000 task=f64dc570 task.ti=f69a6000)
Stack: 00000000 00000000 00000000 0000003f 00000328 f650a620 dffe7660 
00000000
        00001000 c01724e5 f650a620 dffe7660 00000909 00000000 0000005d 
00000000
        0000005c 00000000 ed4d3200 bff47a70 f69a7fa4 00001000 c0156e80 
ed4d3200
Call Trace:
  [<c01724e5>] seq_read+0x195/0x262
  [<c0156e80>] vfs_read+0x88/0x11e
  [<c0157160>] sys_read+0x3b/0x63
  [<c036d07f>] syscall_call+0x7/0xb
Code: 10 3b 8d d4 00 00 00 75 0a 85 f6 b8 a0 ef 38 c0 0f 44 f0 85 c9 75 
0a 85 f6 b8 e0 ef 38 c0 0f 44 f0 01 4c 24 10 ff 44 24 0c 8b 12 <8b> 02 
8d 74 26 00 39 da 75 c9 8b 53 10 8b 02 8d 74 26 00 8d 43
EIP: [<c0154030>] s_show+0xe5/0x28e SS:ESP 0068:f69a7f14

Re: 2.6.17-mm1

[H. Peter Anvin]

Mattia Dongili wrote:
> On Wed, Jun 21, 2006 at 11:19:55AM -0700, Martin Bligh wrote:
>> Seems to dive into an endless loop in compile.
>>
>> http://test.kernel.org/abat/37068/debug/test.log.0
>>
>>   CHK     include/linux/compile.h
>>   UPD     include/linux/compile.h
>>   CC      init/version.o
>>   CC      init/initramfs.o
>>   CC      init/calibrate.o
>>   LD      init/built-in.o
>>   HOSTCC  usr/gen_init_cpio
>>   SYMLINK usr/include/asm -> include/asm-x86_64
>>   GEN     usr/klibc/syscalls/SYSCALLS.i
>>   GEN     usr/klibc/syscalls/syscalls.nrs
>>   GEN     usr/klibc/syscalls/typesize.c
>>   KLIBCCC usr/klibc/syscalls/typesize.o
>>   OBJCOPY usr/klibc/syscalls/typesize.bin
> [...]
>> etc etc. for ever.
>>
>> On both x86_64 and ppc64.
> 
> me too, on 586
> 
> .config is here: http://oioio.altervista.org/linux/config-2.6.17-mm1

I've uploaded the patch for this to:

http://www.kernel.org/pub/linux/kernel/people/hpa/klibc-2.6.17-mm1-circdep.patch

The klibc tree has additional fixes in it.

	-hpa

Re: 2.6.17-mm1

[Mattia Dongili]

On Wed, Jun 21, 2006 at 11:19:55AM -0700, Martin Bligh wrote:
> Seems to dive into an endless loop in compile.
> 
> http://test.kernel.org/abat/37068/debug/test.log.0
> 
>   CHK     include/linux/compile.h
>   UPD     include/linux/compile.h
>   CC      init/version.o
>   CC      init/initramfs.o
>   CC      init/calibrate.o
>   LD      init/built-in.o
>   HOSTCC  usr/gen_init_cpio
>   SYMLINK usr/include/asm -> include/asm-x86_64
>   GEN     usr/klibc/syscalls/SYSCALLS.i
>   GEN     usr/klibc/syscalls/syscalls.nrs
>   GEN     usr/klibc/syscalls/typesize.c
>   KLIBCCC usr/klibc/syscalls/typesize.o
>   OBJCOPY usr/klibc/syscalls/typesize.bin
[...]
> etc etc. for ever.
> 
> On both x86_64 and ppc64.

me too, on 586

.config is here: http://oioio.altervista.org/linux/config-2.6.17-mm1
-- 
mattia
:wq!

Re: 2.6.17-mm1

[Martin Bligh]

Seems to dive into an endless loop in compile.

http://test.kernel.org/abat/37068/debug/test.log.0

   CHK     include/linux/compile.h
   UPD     include/linux/compile.h
   CC      init/version.o
   CC      init/initramfs.o
   CC      init/calibrate.o
   LD      init/built-in.o
   HOSTCC  usr/gen_init_cpio
   SYMLINK usr/include/asm -> include/asm-x86_64
   GEN     usr/klibc/syscalls/SYSCALLS.i
   GEN     usr/klibc/syscalls/syscalls.nrs
   GEN     usr/klibc/syscalls/typesize.c
   KLIBCCC usr/klibc/syscalls/typesize.o
   OBJCOPY usr/klibc/syscalls/typesize.bin
   GEN     usr/klibc/syscalls/syscalls.mk
   GEN     usr/klibc/syscalls/typesize.c
   KLIBCCC usr/klibc/syscalls/typesize.o
   OBJCOPY usr/klibc/syscalls/typesize.bin
   GEN     usr/klibc/syscalls/syscalls.mk
   GEN     usr/klibc/syscalls/typesize.c
   KLIBCCC usr/klibc/syscalls/typesize.o
   OBJCOPY usr/klibc/syscalls/typesize.bin
   GEN     usr/klibc/syscalls/syscalls.mk
   GEN     usr/klibc/syscalls/typesize.c
   KLIBCCC usr/klibc/syscalls/typesize.o
   OBJCOPY usr/klibc/syscalls/typesize.bin
   GEN     usr/klibc/syscalls/syscalls.mk
   GEN     usr/klibc/syscalls/typesize.c
   KLIBCCC usr/klibc/syscalls/typesize.o
   OBJCOPY usr/klibc/syscalls/typesize.bin
   GEN     usr/klibc/syscalls/syscalls.mk

etc etc. for ever.

On both x86_64 and ppc64.

M.