2.6.18-rc5-mm1

2.6.18-rc5-mm1

[Andrew Morton]

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


- CONFIG_BLOCK=n is bust due to
  writeback_congestion_end()/blk_congestion_end() snafu.  We'll fix it later.

- nfs automounts of subdirectories of exported directories are still
  broken.

- drivers/iio/iio_dummy.c causes a depmod failure.  It isn't supposed to
  be here - please ignore it.

- sparc32 doesn't build.




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.

- Semi-daily snapshots of the -mm lineup are uploaded to
  ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/mm/ and are announced on
  the mm-commits list.



Changes since 2.6.18-rc4-mm3:

 origin.patch
 git-acpi.patch
 git-alsa.patch
 git-agpgart.patch
 git-arm.patch
 git-block.patch
 git-cpufreq.patch
 git-drm.patch
 git-dvb.patch
 git-geode.patch
 git-gfs2.patch
 git-ia64.patch
 git-ieee1394.patch
 git-infiniband.patch
 git-input.patch
 git-intelfb.patch
 git-kbuild.patch
 git-libata-all.patch
 git-lxdialog.patch
 git-mtd.patch
 git-net.patch
 git-nfs.patch
 git-ocfs2.patch
 git-parisc.patch
 git-pcmcia.patch
 git-powerpc.patch
 git-r8169.patch
 git-serial.patch
 git-s390.patch
 git-scsi-misc.patch
 git-scsi-target.patch
 git-supertrak.patch
 git-watchdog.patch
 git-xfs.patch
 git-cryptodev.patch

 git trees.

-oops-on-boot-fix-for-ide.patch
-drivers-rtc-fix-rtc-s3cc.patch
-dm-fix-deadlock-under-high-i-o-load-in-raid1-setup.patch
-revert-input-wistron-fix-section-reference-mismatches.patch
-swsusp-fix-swap_type_of.patch
-rtc-s3cc-fix-time-setting-checks.patch
-tty-remove-bogus-call-to-cdev_del.patch
-fix-docs-for-fssuid_dumpable-6145.patch
-fix-for-recently-added-firewire-patch-that-breaks-things-on-ppc.patch
-lockdep-fix-blkdev_open-warning.patch
-lockdep-fix-blkdev_open-warning-fix.patch
-mtd-corruption-fix.patch
-x86-fix-dmi-detection-of-macbookpro-and-imac.patch
-for-2618-revert-drop-tasklist-lock-in-do_sched_setscheduler.patch
-cpufreq-acpi-cpufreq-ignore-failure-from-acpi_cpufreq_early_init_acpi.patch
-char-moxac-fix-endianess-and-multiple-card-issues.patch
-char-moxac-fix-endianess-and-multiple-card-issues-tidy.patch
-matroxfb-fix-jittery-display-on-non-ppc-systems.patch
-vcsa-attribute-bits-ioctlvt_gethifontmask.patch
-futex_find_get_task-remove-an-obscure-exit_zombie-check.patch
-mtd-nand-fix-ams-delta-after-core-conversion.patch
-fix-for-minix-crash.patch
-ext2-prevent-div-by-zero-on-corrupted-fs.patch
-spectrum_cs-fix-firmware-uploading-errors.patch
-ext3-filesystem-bogus-enospc-with-reservation-fix.patch
-ufs-write-to-hole-in-big-file.patch
-ufs-truncate-correction.patch
-remove-redundent-up-in-stop_machine.patch
-documentation-update-for-relay-interface.patch
-eventpollc-compile-fix.patch
-md-avoid-backward-event-updates-in-md-superblock-when-degraded.patch
-md-fix-recent-breakage-of-md-raid1-array-checking.patch
-cpuset-top_cpuset-tracks-hotplug-changes-to-cpu_online_map.patch
-manage-jbd-allocations-from-its-own-slabs.patch
-manage-jbd-allocations-from-its-own-slabs-tidy.patch
-register_one_node-compile-fix.patch
-cpuset-oom-panic-fix.patch
-sun-disk-label-fix-signed-int-usage-for-sector-count.patch
-sun-disk-label-fix-signed-int-usage-for-sector-count-fix.patch
-config_acpi_srat-numa-build-fix.patch
-lockdep-annotate-idescsi_pc_intr.patch
-lockdep-annotate-reiserfs.patch
-fix-up-lockdep-trace-in-fs-execc.patch
-proc-meminfo-dont-put-spaces-in-names.patch
-x86-numaq-kconfig-fix.patch
-cdrom-gdsc-fix-printk-format-warning.patch
-tty-layer-comment-the-locking-assumptions-and-functions.patch
-fix-tty-layer-dos-and-comment-relevant-code.patch
-drivers-media-video-bt866c-array-overflows.patch
-gregkh-i2c-i2c-tps65010-build-fixes.patch
-gregkh-i2c-hwmon-abituguru-timeout-fixes.patch
-ia64-panic-if-topology_init-kzalloc-fails.patch
-e1000-ring-buffers-resources-cleanup.patch
-e1000-irq-resources-cleanup.patch
-e1000-e1000_probe-resources-cleanup.patch
-ixgb-add-pci-error-recovery-callbacks.patch
-e100-disable-device-on-pci-error.patch
-powerpc-hugepage-bug-fix.patch
-gregkh-pci-pci-use-pcbios-as-last-fallback.patch
-gregkh-pci-pci-i386-mmconfig-don-t-forget-bus-number-when-setting-fallback_slots-bits.patch
-gregkh-pci-pci-fix-ich6-quirks.patch
-gregkh-pci-cpci-hotplug-fix-resource-assignment.patch
-gregkh-pci-pci-kerneldoc-correction-in-pci-driver.patch
-fix-gregkh-pci-pci-express-aer-implemetation-aer-core-and-aerdriver-on-powerpc.patch
-gregkh-pci-acpiphp-configure-_prt-v3-cleanup.patch
-scsi-target-printk-format-warnings.patch
-gregkh-usb-usb-cypress-bugfix.patch
-gregkh-usb-usb-pl2303-removed-support-for-oti-s-dku-5-clone-cable.patch
-gregkh-usb-unusual_devs-update-for-ucr-61s2b.patch
-usb-hub-driver-improve-use-of-ifdef-fix.patch
-fix-broken-dubious-driver-suspend-methods.patch
-pm-define-pm_event_prethaw.patch
-pm-pci-and-ide-handle-pm_event_prethaw.patch
-pm-video-drivers-and-pm_event_prethaw.patch
-pm-usb-hcds-use-pm_event_prethaw.patch
-pm-usb-hcds-use-pm_event_prethaw-fix.patch
-pm-issue-pm_event_prethaw.patch
-rtl8150_disconnect-needs-tasklet_kill.patch
-turn-usb_resume_both-into-static-inline.patch
-signedness-issue-in-drivers-usb-gadget-etherc.patch
-adutux-fix-printk-format-warnings.patch
-aircable-fix-printk-format-warnings.patch
-x86_64-mm-defconfig-update.patch
-x86_64-mm-rwlock-lock-prefix.patch
-x86_64-mm-i386-remove-const-rwlock.patch
-x86_64-mm-i386-unwind-termination.patch
-x86_64-mm-unwind-termination.patch
-x86_64-mm-unwinder-fallback.patch
-x86_64-mm-fix-x86-cpuid-keys-used-in-alternative_smp.patch
-x86_64-mm-disable-mmconfig-e820-heuristic.patch
-x86_64-mm-recover-1mb.patch
-x86_64-mm-spin-irqs-enabled.patch
-x86_64-mm-remove-alternative-smp.patch
-x86_64-mm-i386-remove-alternative-smp.patch
-x86_64-mm-dmi-mmconfig-intel-sdv.patch
-hdaps-handle-errors-from-input_register_device.patch
-fix-possible-udf-deadlock-and-memory-corruption.patch
-ide-support-for-via-8237a-southbridge.patch

 Merged into mainline or a subsystem tree.
 
+zvc-overstep-counters.patch
+zvc-scale-thresholds-depending-on-the-size-of-the-system.patch
+md-fix-issues-with-referencing-rdev-in-md-raid1.patch
+synclink_gt-fix-receive-tty-error-handling.patch
+fix-faulty-hpet-clocksource-usage-fix-for-bug-7062.patch
+task-delay-accounting-fixes.patch
+xtensa-ptrace-exit_zombie-fix.patch
+x86-increase-max_mp_busses-on-default-arch.patch
+exit-early-in-floppy_init-when-no-floppy-exists.patch
+sbc8360-module_param-permission-fixes.patch
+kerneldoc-for-handle_bad_irq.patch
+ipmi-fix-occasional-oops-on-module-unload.patch
+schedule-obsolete-oss-drivers-for-removal-2nd-round.patch
+md-work-around-mempool_alloc-bio_alloc_bioset-deadlocks.patch
+powerpc-more-via-pmu-backlight-fixes.patch
+powerpc-fix-powermac-irq-handling-bug.patch
+alsa-ac97-correct-some-mic-mixer-elements.patch
+sgiioc4-fixup-use-of-mmio-ops.patch
+fix-numa-interleaving-for-huge-pages.patch
+manage-jbd-its-own-slab-fix.patch
+backlight-last-round-of-fixes.patch

 2.6.18 queue.

+scsi-improve-endian-handling-in-lsi-fusion-firmware-mpt_downloadboot.patch

 MPT fusion fix

+allow-file-systems-to-manually-d_move-inside-of-rename.patch

 Infrastructure for OCFS.

+acpi-mwait-c-state-fixes.patch

 ACPI fix/feature

+git-block-hack.patch

 Make git-block pretend to compile.

+fs-bioc-tweaks.patch

 bio.c cleanup.

+gregkh-driver-fix-broken-dubious-driver-suspend-methods.patch
+gregkh-driver-pm-define-pm_event_prethaw.patch
+gregkh-driver-pm-pci-and-ide-handle-pm_event_prethaw.patch
+gregkh-driver-pm-video-drivers-and-pm_event_prethaw.patch
+gregkh-driver-pm-usb-hcds-use-pm_event_prethaw.patch
+gregkh-driver-pm-issue-pm_event_prethaw.patch
+gregkh-driver-iio.patch

 driver tree updates

+git-dvb-fixup.patch

 Fix rejects in git-dvb.patch

+gregkh-i2c-hwmon-atxp1-signed-unsigned-char-bug.patch
+gregkh-i2c-hwmon-hdaps-handle-errors-from-input-register-device.patch
+gregkh-i2c-hwmon-smsc47m1-fix-dev-message.patch
+gregkh-i2c-hwmon-it87-it8716f-support.patch
+gregkh-i2c-hwmon-it87-disabled-fans.patch
+gregkh-i2c-hwmon-it87-div-to-reg-overflow.patch
+gregkh-i2c-hwmon-it87-in8-no-limits.patch
+gregkh-i2c-hwmon-it87-set-fan-div.patch
+gregkh-i2c-hwmon-it87-it8718f-support.patch
+gregkh-i2c-hwmon-it87-sane-limit-defaults.patch
+gregkh-i2c-hwmon-it87-copyright-update.patch
+gregkh-i2c-hwmon-k8temp-new-driver.patch
+gregkh-i2c-hwmon-k8temp-autoload.patch
+gregkh-i2c-hwmon-abituguru-suspend-resume.patch

 I2C tree updates.

-ieee1394-sbp2-select-scsi-in-kconfig.patch
+ieee1394-sbp2-more-help-in-kconfig.patch

 Updated.

+amso1100-build-fix.patch

 Fix git-infiniband.patch

+drivers-input-misc-wistron_btnsc-fix-section-mismatch.patch

 Input driver section fix.

+8139cp-trim-ring_info.patch
+8139cp-remove-gratuitous-indirection.patch
+8139cp-ring_info-removal-for-the-receive-path.patch
+8139cp-sync-the-device-private-data-with-its-r8169-counterpart.patch
+8139cp-removal-of-useless-bug_on-check.patch
+8139cp-pci_get_drvdatapdev-can-not-be-null-in-suspend-handler.patch
+8139cp-use-pci_device-to-shorten-the-pci-device-table.patch

 net driver updates.

+dev_change_name-debug.patch
+bluetooth-small-cleanups.patch
+add-netpoll-netconsole-support-to-vlan-devices.patch

 net stuff.

-libsas-externs-not-needed.patch

 Dropped due to droppage of git-sas.patch.

+magic-sysrq-sak-does-nothing-on-serial-consoles.patch

 Fix SAK-on-serial.

+gregkh-pci-shpchp-must_check-fixes.patch
+gregkh-pci-pci-hotplug-must_check-fixes.patch
+gregkh-pci-pci-must_check-fixes.patch
+gregkh-pci-pci-multiprobe-sanitizer.patch
+gregkh-pci-pci-drivers-pci-hotplug-acpiphp_glue.c-make-a-function-static.patch
+gregkh-pci-pci-restore-pci-express-capability-registers-after-pm-event.patch

 PCI tree updates.

+git-scsi-misc-fixup.patch

 Fix rejects in git-scsi-misc.patch

+git-block-vs-git-sas.patch

 Fix build

+gregkh-usb-samsung-unusual-floppy.patch
+gregkh-usb-hid-core.c-adds-all-gtco-calcomp-digitizers-and-interwrite-school-products-to-blacklist.patch
+gregkh-usb-usb-gadget-g_ether-spinlock-recursion-fix.patch
+gregkh-usb-uhci-don-t-stop-at-an-iso-error.patch
+gregkh-usb-usb-storage-remove-the-finecam3-unusual_devs-entry.patch
+gregkh-usb-usb-storage-unusual_devs.h-for-sony-ericsson-m600i.patch
+gregkh-usb-usb-rtl8150_disconnect-needs-tasklet_kill.patch
+gregkh-usb-usb-support-for-elecom-ld-usb20-in-pegasus.patch
+gregkh-usb-uhci-hcd-fix-list-access-bug.patch
+gregkh-usb-usb-doc-patch-1.patch
+gregkh-usb-usb-doc-patch-2.patch
+gregkh-usb-usb-must_check-fixes.patch
+gregkh-usb-usb-deal-with-broken-config-descriptors.patch
+gregkh-usb-wusb-hub-recognizes-wusb-ports.patch
+gregkh-usb-wusb-handle-wusb-device-ep0-speed-settings.patch
+gregkh-usb-wusb-pretty-print-new-devices.patch
+gregkh-usb-usb-core-use-const-where-possible.patch
+gregkh-usb-usb-fix-signedness-issue-in-drivers-usb-gadget-ether.c.patch
+gregkh-usb-usb-fix-typo-in-drivers-usb-gadget-kconfig.patch
+gregkh-usb-usb-storage-fix-for-ufi-lun-detection.patch
+gregkh-usb-usbcore-help-drivers-to-change-device-configs.patch
+gregkh-usb-usb-turn-usb_resume_both-into-static-inline.patch
+gregkh-usb-usb-usb-hub-driver-improve-use-of-ifdef-fix.patch
+gregkh-usb-cypress_m8-use-appropriate-urb-polling-interval.patch
+gregkh-usb-cypress_m8-use-usb_fill_int_urb-where-appropriate.patch
+gregkh-usb-cypress_m8-improve-control-endpoint-error-handling.patch
+gregkh-usb-cypress_m8-implement-graceful-failure-handling.patch
+gregkh-usb-aircable-fix-printk-format-warnings.patch
+gregkh-usb-adutux-fix-printk-format-warnings.patch
+gregkh-usb-usb-add-playstation-2-trance-vibrator-driver.patch

 USB tree updates.

+x86_64-mm-proxy-pda.patch
+x86_64-mm-fix-the-edd-code-misparsing-the-command-line.patch
+x86_64-mm-remove-most-of-the-special-cases-for-the-debug-ist-stack.patch
+x86_64-mm-kexec-dont-overwrite-pgd.patch
+x86_64-mm-i386-kexec-dont-overwrite-pgd.patch
+x86_64-mm-i386-early-exception.patch
+x86_64-mm-trace-kernel-text-address.patch
+x86_64-mm-document-tree.patch
+x86_64-mm-rwlock-cleanup-fix.patch
+x86_64-mm-remove-e820-fallback-fix.patch

 x86_64 tree updates.

-fstack-protector-feature-annotate-the-pda-offsets.patch
-fstack-protector-feature-add-the-kconfig-option.patch
-fstack-protector-feature-add-the-canary-field-to-the.patch
-fstack-protector-feature-add-the-__stack_chk_fail.patch
-fstack-protector-feature-enable-the-compiler-flags.patch

 Collateral damaged by x86-64 tree udpates.

+unwinder-warning-fixes.patch

 Fix warnings in x86_64 tree.

+have-ia64-use-add_active_range-and-free_area_init_nodes-fix.patch

 Fix have-ia64-use-add_active_range-and-free_area_init_nodes.patch

+zone-reclaim-with-slab-avoid-unecessary-off-node-allocations.patch
+oom-kill-update-comments-to-reflect-current-code.patch

 MM updates.

+selinux-enable-configuration-of-max-policy-version-improve-security_selinux_policydb_version_max_value-help-texts.patch

 Fix selinux-enable-configuration-of-max-policy-version.patch

-selinux-2-3-change-isec-semaphore-to-a-mutex-vs-git-net.patch

 Fix selinux-2-3-change-isec-semaphore-to-a-mutex.patch

+nommu-check-that-access_process_vm-has-a-valid-target.patch
+nommu-set-bdi-capabilities-for-dev-mem-and-dev-kmem.patch
+nommu-set-bdi-capabilities-for-dev-mem-and-dev-kmem-tidy.patch
+nommu-use-find_vma-rather-than-reimplementing-a-vma-search.patch
+check-if-start-address-is-in-vma-region-in-nommu-function-get_user_pages.patch
+nommu-permit-ptrace-to-ignore-non-prot_write-vmas-in-nommu-mode.patch
+nommu-implement-proc-pid-maps-for-nommu.patch
+nommu-order-the-per-mm_struct-vma-list.patch
+nommu-make-mremap-partially-work-for-nommu-kernels.patch
+nommu-add-docs-about-shared-memory.patch

 nommu stuff.

-i386-early-fault-handler.patch

 Dropped due to merge of similar patch.

+x86-use-asm-offsets-for-offsets-into-struct-pt_regs.patch

 x86 cleanup.

+make-it-possible-to-disable-serial-console-suspend.patch
+pm-add-pm_trace-switch.patch
+pm-add-pm_trace-switch-doc.patch
+pm-add-sys-power-documentation-to-documentation-abi.patch
+device_suspend-resume-may-sleep.patch

 suspend/power-management updates.

-sysctl-scream-if-someone-uses-sys_sysctl.patch
+sysctl-allow-proc-sys-without-sys_sysctl-fix.patch

 Updated.

+fix-ext3-mounts-at-16t-fix.patch

 Fix fix-ext3-mounts-at-16t.patch

+fix-ext2-mounts-at-16t-fix.patch

 Fix fix-ext2-mounts-at-16t.patch

+more-ext3-16t-overflow-fixes-fix.patch

 Fix more-ext3-16t-overflow-fixes.patch

+select_bad_process-kill-a-bogus-pf_dead-task_dead-check.patch
+select_bad_process-cleanup-releasing-check.patch
+oom_kill_task-cleanup-mm-checks.patch
+cpuset-top_cpuset-tracks-hotplug-changes-to-node_online_map.patch
+cpuset-top_cpuset-tracks-hotplug-changes-to-node_online_map-fix.patch
+cpuset-hotunplug-cpus-and-mems-in-all-cpusets.patch
+remove-sound-oss-copying.patch
+fs-partitions-conversion-to-generic-boolean.patch
+loop-forward-port-resource-leak-checks-from-solar.patch
+maximum-latency-tracking-infrastructure.patch
+maximum-latency-tracking-infrastructure-tidy.patch
+maximum-latency-tracking-alsa-support.patch
+add-to-maintainers-file.patch
+lib-rwsemc-un-inline-rwsem_down_failed_common.patch
+add-section-on-function-return-values-to-codingstyle.patch
+fs-nameic-replace-multiple-current-fs-by-shortcut-variable.patch
+fs-nameic-replace-multiple-current-fs-by-shortcut-variable-tidy.patch
+superh-maintainership-change.patch
+mem-driver-fix-conditional-on-isa-i-o-support.patch
+remove-static-variable-mm-page-writebackctotal_pages.patch
+call-mm-page-writebackcset_ratelimit-when-new-pages.patch
+call-mm-page-writebackcset_ratelimit-when-new-pages-tidy.patch
+valid_swaphandles-fix.patch
+mention-documenation-abi-requirements-in-documentation-submitchecklist.patch
+rate-limiting-for-the-ldisc-open-failure-messages.patch
+lib-ts_fsmc-constify-structs.patch
+submittingpatches-cleanups.patch
+ibm-acpi-documentation-delete-irrelevant-how-to-compile-external-module.patch
+network-block-device-is-mostly-known-as-nbd.patch
+superh-list-is-moderated.patch
+sys-modules-patch-allow-full-length-section-names.patch
+uninitialized-variable-in-drivers-net-wan-syncpppc.patch

 Misc.

+kill-wall_jiffies-fix.patch
+mips-moved-to-generic_time.patch

 Fix kill-wall_jiffies.patch

+fs-cache-cachefiles-a-cache-that-backs-onto-a-mounted-filesystem-cachefiles-cachefiles_write_page-shouldnt-indicate-error-twice.patch
+fs-cache-cachefiles-a-cache-that-backs-onto-a-mounted-filesystem-cachefiles-handle-enospc-on-create-mkdir-better.patch
+fs-cache-cachefiles-a-cache-that-backs-onto-a-mounted-filesystem-inode-count-maintenance.patch

 Fix fs-cache-cachefiles-a-cache-that-backs-onto-a-mounted-filesystem-warning-fixes.patch

+knfsd-hide-use-of-lockds-h_monitored-flag.patch
+knfsd-consolidate-common-code-for-statd-lockd-notification.patch
+knfsd-when-looking-up-a-lockd-host-pass-hostname-length.patch
+knfsd-lockd-introduce-nsm_handle.patch
+knfsd-misc-minor-fixes-indentation-changes.patch
+knfsd-lockd-make-nlm_host_rebooted-use-the-nsm_handle.patch
+knfsd-lockd-make-the-nsm-upcalls-use-the-nsm_handle.patch
+knfsd-lockd-make-the-hash-chains-use-a-hlist_node.patch
+knfsd-lockd-change-list-of-blocked-list-to-list_node.patch
+knfsd-change-nlm_file-to-use-a-hlist.patch
+knfsd-lockd-make-nlm_traverse_-more-flexible.patch
+knfsd-lockd-add-nlm_destroy_host.patch
+knfsd-simplify-nlmsvc_invalidate_all.patch
+knfsd-lockd-optionally-use-hostnames-for-identifying-peers.patch
+knfsd-make-nlmclnt_next_cookie-smp-safe.patch
+knfsd-match-granted_res-replies-using-cookies.patch
+knfsd-export-nsm_local_state-to-user-space-via-sysctl.patch
+knfsd-lockd-fix-use-of-h_nextrebind.patch
+knfsd-register-all-rpc-programs-with-portmapper-by-default.patch

 nfsd updates.

+ecryptfs-remove-lock-propagation.patch

 ecryptfs fix.

-namespaces-add-nsproxy-avr32-fix.patch

 Dropped, wrong.

+ipc-namespace-fix.patch

 Fix refcountng in namespace patches.

+introduce-kernel_execve.patch
+rename-the-provided-execve-functions-to-kernel_execve.patch
+provide-kernel_execve-on-all-architectures.patch
+provide-kernel_execve-on-all-architectures-fix.patch
+provide-kernel_execve-on-all-architectures-mips-fix.patch
+remove-the-use-of-_syscallx-macros-in-uml.patch
+sh64-remove-the-use-of-kernel-syscalls.patch
+remove-remaining-errno-and-__kernel_syscalls__-references.patch

 kernel syscalls cleanup

+reiser4-decribe-new-atom-locking-and-nested-atom-locks-to-lock-validator.patch
+reiser4-use-generic-file-read.patch
+reiser4-simplify-reading-of-partially-converted-files.patch
+reiser4-use-page_offset.patch
+reiser4-use-reiser4_gfp_mask_get-in-reiser4-inode-allocation.patch
+reiser4-re-add-page_count-check-to-reiser4_releasepage.patch
+reiser4-restore-fibmap-ioctl-support-for-packed-files.patch

 reiser4 updates.

-asus-mv-ide-device-ids.patch

 Dropped.

+ide-hpa-resume-fix.patch

 IDE fix.

+md-define-backing_dev_infocongested_fn-for-raid0-and-linear.patch
+md-define-congested_fn-for-raid1-raid10-and-multipath.patch
+md-add-a-congested_fn-function-for-raid5-6.patch
+md-make-messages-about-resync-recovery-etc-more-specific.patch

 RAID updates.

+srcu-3-rcu-variant-permitting-read-side-blocking-comments.patch
+rcu-refactor-srcu_torture_deferred_free-to-work-for.patch
+rcu-add-rcu_sync-torture-type-to-rcutorture.patch
+rcu-add-rcu_bh_sync-torture-type-to-rcutorture.patch
+rcu-add-sched-torture-type-to-rcutorture.patch

 RCU updates.

-fs-kconfig-split-ext2.patch
-fs-kconfig-split-ext3.patch
-fs-kconfig-split-jbd.patch
-fs-kconfig-split-reiserfs.patch
-fs-kconfig-split-jfs.patch
-fs-kconfig-split-ocfs2.patch
-fs-kconfig-split-minix.patch
-fs-kconfig-split-romfs.patch
-fs-kconfig-split-autofs.patch
-fs-kconfig-split-autofs4.patch
-fs-kconfig-split-fuse.patch
-fs-kconfig-split-isofs.patch
-fs-kconfig-split-udf.patch
-fs-kconfig-split-fat.patch
-fs-kconfig-split-msdos.patch
-fs-kconfig-split-vfat.patch
-fs-kconfig-split-ntfs.patch
-fs-kconfig-split-proc.patch
-fs-kconfig-split-sysfs.patch
-fs-kconfig-split-hugetlbfs.patch
-fs-kconfig-split-ramfs.patch
-fs-kconfig-split-configfs.patch
-fs-kconfig-split-adfs.patch
-fs-kconfig-split-affs.patch
-fs-kconfig-split-ecryptfs.patch
-fs-kconfig-split-hfs.patch
-fs-kconfig-split-hfsplus.patch
-fs-kconfig-split-befs.patch
-fs-kconfig-split-bfs.patch
-fs-kconfig-split-efs.patch
-fs-kconfig-split-jffs.patch
-fs-kconfig-split-jffs2.patch
-fs-kconfig-split-cramfs.patch
-fs-kconfig-split-freevxfs.patch
-fs-kconfig-split-hpfs.patch
-fs-kconfig-split-qnx4.patch
-fs-kconfig-split-sysv.patch
-fs-kconfig-split-ufs.patch
-fs-kconfig-split-smbfs.patch
-fs-kconfig-split-cifs.patch
-fs-kconfig-split-ncpfs.patch
-fs-kconfig-split-coda.patch
-fs-kconfig-split-afs.patch
-fs-kconfig-split-9p.patch

 The CONFIG_BLOCK changes wrecked these.



All 1713 patches:

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

Re: 2.6.18-rc5-mm1

[Manuel Lauss]

I need the following patch to make it build.

__NR_execve is undeclared.


--- a/arch/i386/kernel/sys_i386.c~      2006-09-01 11:48:45.000000000 +0200
+++ b/arch/i386/kernel/sys_i386.c       2006-09-01 11:48:45.000000000 +0200
@@ -22,6 +22,7 @@

 #include <asm/uaccess.h>
 #include <asm/ipc.h>
+#include <asm/unistd.h>

 /*
  * sys_pipe() is the normal C calling standard for creating

Re: 2.6.18-rc5-mm1

[Grant Wilson]

Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc5/2.6.18-rc5-mm1/
[snip]
>  The CONFIG_BLOCK changes wrecked these.

The CONFIG_BLOCK changes also seem to prevent the selection of any RAID
or LVM drivers...

Cheers,
Grant

[-mm patch] drivers/md/Kconfig: fix BLOCK dependency

[Adrian Bunk]

On Fri, Sep 01, 2006 at 11:44:29AM +0100, Grant Wilson wrote:
> Andrew Morton wrote:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc5/2.6.18-rc5-mm1/
> [snip]
> >  The CONFIG_BLOCK changes wrecked these.
> 
> The CONFIG_BLOCK changes also seem to prevent the selection of any RAID
> or LVM drivers...

Thanks for the bug report, patch below.

> Cheers,
> Grant

cu
Adrian


<--  snip  -->


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

--- linux-2.6.18-rc5-mm1/drivers/md/Kconfig.old	2006-09-01 15:47:10.000000000 +0200
+++ linux-2.6.18-rc5-mm1/drivers/md/Kconfig	2006-09-01 15:47:16.000000000 +0200
@@ -2,7 +2,7 @@
 # Block device driver configuration
 #
 
-if CONFIG_BLOCK
+if BLOCK
 
 menu "Multi-device support (RAID and LVM)"
 

[-mm patch] drivers/md/Kconfig: fix BLOCK dependency

[Adrian Bunk]

On Fri, Sep 01, 2006 at 11:44:29AM +0100, Grant Wilson wrote:
> Andrew Morton wrote:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc5/2.6.18-rc5-mm1/
> [snip]
> >  The CONFIG_BLOCK changes wrecked these.
> 
> The CONFIG_BLOCK changes also seem to prevent the selection of any RAID
> or LVM drivers...

Thanks for the bug report, patch below.

> Cheers,
> Grant

cu
Adrian


<--  snip  -->


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

--- linux-2.6.18-rc5-mm1/drivers/md/Kconfig.old	2006-09-01 15:47:10.000000000 +0200
+++ linux-2.6.18-rc5-mm1/drivers/md/Kconfig	2006-09-01 15:47:16.000000000 +0200
@@ -2,7 +2,7 @@
 # Block device driver configuration
 #
 
-if CONFIG_BLOCK
+if BLOCK
 
 menu "Multi-device support (RAID and LVM)"
 

Re: [-mm patch] drivers/md/Kconfig: fix BLOCK dependency

[David Howells]

Adrian Bunk <bunk@stusta.de> wrote:

> -if CONFIG_BLOCK
> +if BLOCK

Oops.

Acked-By: David Howells <dhowells@redhat.com>

Re: [-mm patch] drivers/md/Kconfig: fix BLOCK dependency

[Jens Axboe]

On Fri, Sep 01 2006, David Howells wrote:
> Adrian Bunk <bunk@stusta.de> wrote:
> 
> > -if CONFIG_BLOCK
> > +if BLOCK
> 
> Oops.
> 
> Acked-By: David Howells <dhowells@redhat.com>

Merged.

-- 
Jens Axboe

2.6.18-rc5-mm1: drivers/infiniband/hw/amso1100/c2.c compile error

[Adrian Bunk]

On Fri, Sep 01, 2006 at 01:58:18AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.18-rc4-mm3:
>...
> +amso1100-build-fix.patch
> 
>  Fix git-infiniband.patch
>...

This causes the following compile error on i386:

<--  snip  -->

...
  CC      drivers/infiniband/hw/amso1100/c2.o
/home/bunk/linux/kernel-2.6/linux-2.6.18-rc5-mm1/drivers/infiniband/hw/amso1100/c2.c: In function ‘c2_tx_ring_alloc’:
/home/bunk/linux/kernel-2.6/linux-2.6.18-rc5-mm1/drivers/infiniband/hw/amso1100/c2.c:133: error: implicit declaration of function ‘__raw_writeq’
make[4]: *** [drivers/infiniband/hw/amso1100/c2.o] Error 1

<--  snip  -->

There seems to be some confusion regarding whether __raw_writeq() is 
considered a platform independent API.

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.18-rc5-mm1

[Maciej Rutecki]

[-- Attachment #1.1: Type: text/plain, Size: 2374 bytes --]

Andrew Morton napisał(a):
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc5/2.6.18-rc5-mm1/
> 

ACPI error (similar like in 2.6.18-rc4-mm3):

[   23.790140] ACPI Error (utglobal-0125): Unknown exception code:
0xFFFFFFEA [20060707]
[   23.790318]  [<c0221ba9>] acpi_format_exception+0x9f/0xa9
[   23.790445]  [<c021edf9>] acpi_ut_status_exit+0x2e/0x56
[   23.790554]  [<c021b3ac>] acpi_walk_resources+0x103/0x10d
[   23.790661]  [<c022901c>] acpi_reserve_io_ranges+0x0/0xfc
[   23.790774]  [<c022900f>] acpi_motherboard_add+0x1f/0x2c
[   23.790880]  [<c0228154>] acpi_bus_driver_init+0x2c/0x78
[   23.790987]  [<c02285b0>] acpi_bus_register_driver+0x60/0xb1
[   23.791094]  [<c038a8da>] acpi_motherboard_init+0xa/0xf5
[   23.791205]  [<c01002b0>] init+0x70/0x280
[   23.791309]  [<c0102db2>] ret_from_fork+0x6/0x14
[   23.791420]  [<c0100240>] init+0x0/0x280
[   23.791520]  [<c0100240>] init+0x0/0x280
[   23.791621]  [<c0103997>] kernel_thread_helper+0x7/0x10
[   23.791728]  =======================
[   23.791844] ACPI Error (utglobal-0125): Unknown exception code:
0xFFFFFFEA [20060707]
[   23.792004]  [<c0221ba9>] acpi_format_exception+0x9f/0xa9
[   23.792112]  [<c021edf9>] acpi_ut_status_exit+0x2e/0x56
[   23.792218]  [<c021b3ac>] acpi_walk_resources+0x103/0x10d
[   23.792325]  [<c022901c>] acpi_reserve_io_ranges+0x0/0xfc
[   23.792432]  [<c022900f>] acpi_motherboard_add+0x1f/0x2c
[   23.792538]  [<c0228154>] acpi_bus_driver_init+0x2c/0x78
[   23.792644]  [<c02285b0>] acpi_bus_register_driver+0x60/0xb1
[   23.792751]  [<c038a8e4>] acpi_motherboard_init+0x14/0xf5
[   23.792857]  [<c01002b0>] init+0x70/0x280
[   23.792959]  [<c0102db2>] ret_from_fork+0x6/0x14
[   23.793062]  [<c0100240>] init+0x0/0x280
[   23.793162]  [<c0100240>] init+0x0/0x280
[   23.793262]  [<c0103997>] kernel_thread_helper+0x7/0x10
[   23.793367]  =======================

Also when I try:

echo standby > /sys/power/state,

I got this message on display:

Sep  1 18:03:02 maciek kernel: [  189.192822] Stopping tasks:
==========================|
Sep  1 18:03:02 maciek kernel: [  189.465008] Suspending console(s)
Sep  1 18:03:02 maciek kernel: [  191.466946] Suspending device vcsa9

But display don't want go standby.


-- 
Maciej Rutecki <maciej.rutecki@gmail.com>
http://www.unixy.pl
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)

[-- Attachment #1.2: config-2.6.18-rc5-mm1.gz --]
[-- Type: application/x-gzip, Size: 14631 bytes --]

[-- Attachment #1.3: dmesg.gz --]
[-- Type: application/x-gzip, Size: 9641 bytes --]

[-- Attachment #1.4: lsmod_output.txt.gz --]
[-- Type: application/x-gzip, Size: 810 bytes --]

[-- Attachment #1.5: syslog.txt.gz --]
[-- Type: application/x-gzip, Size: 2546 bytes --]

[-- Attachment #1.6: ver_linux.txt.gz --]
[-- Type: application/x-gzip, Size: 650 bytes --]

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3265 bytes --]

Re: 2.6.18-rc5-mm1: drivers/infiniband/hw/amso1100/c2.c compile error

[Andrew Morton]

On Fri, 1 Sep 2006 18:00:23 +0200
Adrian Bunk <bunk@stusta.de> wrote:

> On Fri, Sep 01, 2006 at 01:58:18AM -0700, Andrew Morton wrote:
> >...
> > Changes since 2.6.18-rc4-mm3:
> >...
> > +amso1100-build-fix.patch
> > 
> >  Fix git-infiniband.patch
> >...
> 
> This causes the following compile error on i386:
> 
> <--  snip  -->
> 
> ...
>   CC      drivers/infiniband/hw/amso1100/c2.o
> /home/bunk/linux/kernel-2.6/linux-2.6.18-rc5-mm1/drivers/infiniband/hw/amso1100/c2.c: In function ‘c2_tx_ring_alloc’:
> /home/bunk/linux/kernel-2.6/linux-2.6.18-rc5-mm1/drivers/infiniband/hw/amso1100/c2.c:133: error: implicit declaration of function ‘__raw_writeq’
> make[4]: *** [drivers/infiniband/hw/amso1100/c2.o] Error 1
> 

That would have been me cheerfully deleting stuff because it didn't build
on powerpc.

> 
> There seems to be some confusion regarding whether __raw_writeq() is 
> considered a platform independent API.
> 

It appears to be undocumented and uncommented hence it's not an API
_at all_, is it?

What's __raw_writeq() supposed to do, anyway?  On alpha it's writeq()
without an mb().  On parisc it's writeq() only the data is byte-reversed. 
On sparc64() it's incomprehensible.  On everything else it's writeq().

What a crock.

Re: 2.6.18-rc5-mm1: drivers/infiniband/hw/amso1100/c2.c compile error

[Roland Dreier]

    Andrew> What's __raw_writeq() supposed to do, anyway?  On alpha
    Andrew> it's writeq() without an mb().  On parisc it's writeq()
    Andrew> only the data is byte-reversed.  On sparc64() it's
    Andrew> incomprehensible.  On everything else it's writeq().

My understanding is that __raw_writeq() is like writeq() except not
strongly ordered and without the byte-swap on big-endian
architectures.  The __raw_writeX() variants are convenient to avoid
having to write inefficient code like writel(swab32(foo), ...) when
talking to a PCI device that wants big-endian data.  Without the raw
variant, you end up with a double swap on big-endian architectures.

sparc64 looks wrong, since __raw_writeq() seems identical to writeq(),
which seems to imply it's going to swab what is stores.

 - R.

Re: 2.6.18-rc5-mm1: drivers/infiniband/hw/amso1100/c2.c compile error

[Andrew Morton]

On Fri, 01 Sep 2006 10:34:24 -0700
Roland Dreier <rdreier@cisco.com> wrote:

>     Andrew> What's __raw_writeq() supposed to do, anyway?  On alpha
>     Andrew> it's writeq() without an mb().  On parisc it's writeq()
>     Andrew> only the data is byte-reversed.  On sparc64() it's
>     Andrew> incomprehensible.  On everything else it's writeq().
> 
> My understanding is that __raw_writeq() is like writeq() except not
> strongly ordered and without the byte-swap on big-endian
> architectures.  The __raw_writeX() variants are convenient to avoid
> having to write inefficient code like writel(swab32(foo), ...) when
> talking to a PCI device that wants big-endian data.  Without the raw
> variant, you end up with a double swap on big-endian architectures.
> 
> sparc64 looks wrong, since __raw_writeq() seems identical to writeq(),
> which seems to imply it's going to swab what is stores.
> 

OK.  Can we please stop hacking around this in drivers and

a) work out what it's supposed to do

b) document that (Documentation/DocBook/deviceiobook.tmpl or code
   comment or whatever)

c) tell arch maintainers?

Re: 2.6.18-rc5-mm1: drivers/infiniband/hw/amso1100/c2.c compile error

[Roland Dreier]

    Roland> My understanding is that __raw_writeq() is like writeq()
    Roland> except not strongly ordered and without the byte-swap on
    Roland> big-endian architectures.  The __raw_writeX() variants are
    Roland> convenient to avoid having to write inefficient code like
    Roland> writel(swab32(foo), ...) when talking to a PCI device that
    Roland> wants big-endian data.  Without the raw variant, you end
    Roland> up with a double swap on big-endian architectures.

Oh, I left one other thing out: writeq() and __raw_writeq() shold be
atomic in the sense that no other transactions should be able to get
onto the IO bus in the middle -- so implementing writeq() as two
writel()s in a row is not allowed

    Andrew> OK.  Can we please stop hacking around this in drivers and

    Andrew> a) work out what it's supposed to do

    Andrew> b) document that (Documentation/DocBook/deviceiobook.tmpl
    Andrew> or code comment or whatever)

    Andrew> c) tell arch maintainers?

Yes, I agree that's a good plan, especially the documentation part.
However I would argue that what's in drivers/infiniband/hw/mthca/mthca_doorbell.h 
is legitimate: the driver uses __raw_writeq() when it exists and uses
two __raw_writel()s properly serialized with a device-specific lock to
get exactly the atomicity it needs on 32-bit archs.

It's an open question what drivers that don't actually need atomicity
but just want a convenient way to write 64 bits at time should do.

 - R.

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

[Adrian Bunk]

This patch contains the following possible cleanups:
- make the following needlessly global function static:
  - plugin/file/file.c: hint_validate()
- #if 0 the following unused global function:
  - jnode.c: page_detach_jnode()

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

---

 fs/reiser4/jnode.c            |    2 ++
 fs/reiser4/jnode.h            |    3 ---
 fs/reiser4/plugin/file/file.c |    4 +++-
 fs/reiser4/plugin/file/file.h |    2 --
 4 files changed, 5 insertions(+), 6 deletions(-)

--- linux-2.6.18-rc5-mm1/fs/reiser4/plugin/file/file.h.old	2006-09-01 20:54:04.000000000 +0200
+++ linux-2.6.18-rc5-mm1/fs/reiser4/plugin/file/file.h	2006-09-01 20:54:09.000000000 +0200
@@ -157,8 +157,6 @@
 void reiser4_set_hint(hint_t *, const reiser4_key *, znode_lock_mode);
 int hint_is_set(const hint_t *);
 void reiser4_unset_hint(hint_t *);
-int hint_validate(hint_t *, const reiser4_key *, int check_key,
-		  znode_lock_mode);
 void hint_init_zero(hint_t *);
 
 int reiser4_update_file_size(struct inode *, reiser4_key *, int update_sd);
--- linux-2.6.18-rc5-mm1/fs/reiser4/plugin/file/file.c.old	2006-09-01 20:54:17.000000000 +0200
+++ linux-2.6.18-rc5-mm1/fs/reiser4/plugin/file/file.c	2006-09-01 20:55:08.000000000 +0200
@@ -26,6 +26,8 @@
 
 static int unpack(struct file *file, struct inode *inode, int forever);
 static void drop_access(unix_file_info_t *);
+static int hint_validate(hint_t * hint, const reiser4_key * key, int check_key,
+			 znode_lock_mode lock_mode);
 
 /* get unix file plugin specific portion of inode */
 unix_file_info_t *unix_file_inode_data(const struct inode *inode)
@@ -747,7 +749,7 @@
 }
 #endif
 
-int
+static int
 hint_validate(hint_t * hint, const reiser4_key * key, int check_key,
 	      znode_lock_mode lock_mode)
 {
--- linux-2.6.18-rc5-mm1/fs/reiser4/jnode.h.old	2006-09-01 20:55:19.000000000 +0200
+++ linux-2.6.18-rc5-mm1/fs/reiser4/jnode.h	2006-09-01 20:55:27.000000000 +0200
@@ -486,9 +486,6 @@
 	return atomic_read(&node->d_count) > 0;
 }
 
-extern void page_detach_jnode(struct page *page,
-			      struct address_space *mapping,
-			      unsigned long index) NONNULL;
 extern void page_clear_jnode(struct page *page, jnode * node) NONNULL;
 
 static inline void jnode_set_reloc(jnode * node)
--- linux-2.6.18-rc5-mm1/fs/reiser4/jnode.c.old	2006-09-01 20:55:33.000000000 +0200
+++ linux-2.6.18-rc5-mm1/fs/reiser4/jnode.c	2006-09-01 20:55:47.000000000 +0200
@@ -697,6 +697,7 @@
 	page_cache_release(page);
 }
 
+#if 0
 /* it is only used in one place to handle error */
 void
 page_detach_jnode(struct page *page, struct address_space *mapping,
@@ -716,6 +717,7 @@
 	}
 	unlock_page(page);
 }
+#endif  /*  0  */
 
 /* return @node page locked.
 

Re: 2.6.18-rc5-mm1: drivers/infiniband/hw/amso1100/c2.c compile error

[Andrew Morton]

On Fri, 01 Sep 2006 12:53:47 -0700
Roland Dreier <rdreier@cisco.com> wrote:

>     Roland> My understanding is that __raw_writeq() is like writeq()
>     Roland> except not strongly ordered and without the byte-swap on
>     Roland> big-endian architectures.  The __raw_writeX() variants are
>     Roland> convenient to avoid having to write inefficient code like
>     Roland> writel(swab32(foo), ...) when talking to a PCI device that
>     Roland> wants big-endian data.  Without the raw variant, you end
>     Roland> up with a double swap on big-endian architectures.
> 
> Oh, I left one other thing out: writeq() and __raw_writeq() shold be
> atomic in the sense that no other transactions should be able to get
> onto the IO bus in the middle -- so implementing writeq() as two
> writel()s in a row is not allowed
> 
>     Andrew> OK.  Can we please stop hacking around this in drivers and
> 
>     Andrew> a) work out what it's supposed to do
> 
>     Andrew> b) document that (Documentation/DocBook/deviceiobook.tmpl
>     Andrew> or code comment or whatever)
> 
>     Andrew> c) tell arch maintainers?
> 
> Yes, I agree that's a good plan, especially the documentation part.
> However I would argue that what's in drivers/infiniband/hw/mthca/mthca_doorbell.h 
> is legitimate: the driver uses __raw_writeq() when it exists and uses
> two __raw_writel()s properly serialized with a device-specific lock to
> get exactly the atomicity it needs on 32-bit archs.

No, driver-specific workarounds are not legitimate, sorry.

The driver should simply fail to compile on architectures which do not
implement __raw_writeq().

We can speed up the process by sending helpful emails to architecture
maintainers, but they'll notice either way.

Let's fix it once, and in the correct place.

> It's an open question what drivers that don't actually need atomicity
> but just want a convenient way to write 64 bits at time should do.

Well yeah.  We should sort out the design issues before implementing
things ;)

Re: 2.6.18-rc5-mm1: drivers/infiniband/hw/amso1100/c2.c compile error

[Tom Tucker]

So to make sure I understand all this...

The purpose of these services is to provide a platform independent API
for reading and writing 16, 32 and 64b values to MMIO devices. The
rationale for needing these services is that there is currently no
platform independent API for efficiently reading and writing these
values to BE devices on MMIO PCI devices. Examples are the mthca and
amso1100 devices.

Two classes of service are needed, atomic services that are interrupt
safe and services that either don't require atomicity or are called with
a suitable lock already held.

Does the API look something like this?

void mmio_wr_be16(__be16 val, void __iomem *addr);
void mmio_wr_be32(__be32 val, void __iomem *addr);
void mmio_wr_be64(__be64 val, void __iomem *addr);

void mmio_atomic_wr_be16(__be16 val, void __iomem *addr);
void mmio_atomic_wr_be32(__be32 val, void __iomem *addr);
void mmio_atomic_wr_be64(__be64 val, void __iomem *addr);

__be16 mmio_rd_be16(void __iomem *addr);
__be32 mmio_rd_be32(void __iomem *addr);
__be64 mmio_rd_be64(void __iomem *addr);

__be16 mmio_atomic_wr_be16(void __iomem *addr);
__be32 mmio_atomic_wr_be32(void __iomem *addr);
__be64 mmio_atomic_wr_be64(void __iomem *addr);


On Fri, 2006-09-01 at 13:04 -0700, Andrew Morton wrote:
> On Fri, 01 Sep 2006 12:53:47 -0700
> Roland Dreier <rdreier@cisco.com> wrote:
> 
> >     Roland> My understanding is that __raw_writeq() is like writeq()
> >     Roland> except not strongly ordered and without the byte-swap on
> >     Roland> big-endian architectures.  The __raw_writeX() variants are
> >     Roland> convenient to avoid having to write inefficient code like
> >     Roland> writel(swab32(foo), ...) when talking to a PCI device that
> >     Roland> wants big-endian data.  Without the raw variant, you end
> >     Roland> up with a double swap on big-endian architectures.
> > 
> > Oh, I left one other thing out: writeq() and __raw_writeq() shold be
> > atomic in the sense that no other transactions should be able to get
> > onto the IO bus in the middle -- so implementing writeq() as two
> > writel()s in a row is not allowed
> > 
> >     Andrew> OK.  Can we please stop hacking around this in drivers and
> > 
> >     Andrew> a) work out what it's supposed to do
> > 
> >     Andrew> b) document that (Documentation/DocBook/deviceiobook.tmpl
> >     Andrew> or code comment or whatever)
> > 
> >     Andrew> c) tell arch maintainers?
> > 
> > Yes, I agree that's a good plan, especially the documentation part.
> > However I would argue that what's in drivers/infiniband/hw/mthca/mthca_doorbell.h 
> > is legitimate: the driver uses __raw_writeq() when it exists and uses
> > two __raw_writel()s properly serialized with a device-specific lock to
> > get exactly the atomicity it needs on 32-bit archs.
> 
> No, driver-specific workarounds are not legitimate, sorry.
> 
> The driver should simply fail to compile on architectures which do not
> implement __raw_writeq().
> 
> We can speed up the process by sending helpful emails to architecture
> maintainers, but they'll notice either way.
> 
> Let's fix it once, and in the correct place.
> 
> > It's an open question what drivers that don't actually need atomicity
> > but just want a convenient way to write 64 bits at time should do.
> 
> Well yeah.  We should sort out the design issues before implementing
> things ;)
> 


-- 
VGER BF report: H 0

Re: 2.6.18-rc5-mm1: drivers/infiniband/hw/amso1100/c2.c compile error

[Russell King]

On Fri, Sep 01, 2006 at 01:04:44PM -0700, Andrew Morton wrote:
> On Fri, 01 Sep 2006 12:53:47 -0700
> Roland Dreier <rdreier@cisco.com> wrote:
> > Yes, I agree that's a good plan, especially the documentation part.
> > However I would argue that what's in drivers/infiniband/hw/mthca/mthca_doorbell.h 
> > is legitimate: the driver uses __raw_writeq() when it exists and uses
> > two __raw_writel()s properly serialized with a device-specific lock to
> > get exactly the atomicity it needs on 32-bit archs.
> 
> No, driver-specific workarounds are not legitimate, sorry.
> 
> The driver should simply fail to compile on architectures which do not
> implement __raw_writeq().

So, what you're basically saying is that on architectures which can _NOT_
implement an atomic __raw_writeq(), certain drivers simply will not be
available?

> We can speed up the process by sending helpful emails to architecture
> maintainers, but they'll notice either way.

I think you're completely wrong in the context of the message you're
replying to - it's talking about an _atomic_ 64-bit write.

Sure, if you want a _non-atomic_ 64-bit write then that's possible,
but many 32-bit architectures can't do a 64-bit atomic IO write and
that isn't something they can "fix".

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

-- 
VGER BF report: H 5.55112e-17

Re: [openib-general] 2.6.18-rc5-mm1: drivers/infiniband/hw/amso1100/c2.c compile error

[Bryan O'Sullivan]

On Fri, 2006-09-01 at 12:53 -0700, Roland Dreier wrote:

> Yes, I agree that's a good plan, especially the documentation part.
> However I would argue that what's in drivers/infiniband/hw/mthca/mthca_doorbell.h 
> is legitimate: the driver uses __raw_writeq() when it exists and uses
> two __raw_writel()s properly serialized with a device-specific lock to
> get exactly the atomicity it needs on 32-bit archs.

On the off chance that you might be arguing that mthca_write64 could be
a candidate drop-in for writeq on 32-bit arches:

That approach might work on mthca hardware, but it's not safe in
general.  The ipath driver requires a proper writeq(), for example,
because the hardware will quite legitimately treat 32-bit writes to some
registers as separate accesses, and screw things up royally.

You get atomicity from the perspective of software with this approach,
but you can do exciting and bad things to hardware.

	<b


-- 
VGER BF report: H 3.23386e-12

Re: 2.6.18-rc5-mm1: drivers/infiniband/hw/amso1100/c2.c compile error

[Roland Dreier]

    Andrew> No, driver-specific workarounds are not legitimate, sorry.

    Andrew> The driver should simply fail to compile on architectures
    Andrew> which do not implement __raw_writeq().

But how should i386 (say) implement __raw_writeq()?  As two
__raw_writel()s protected by a spinlock (that serializes all IO
transactions)?  That seems rather ugly.

 - R.

-- 
VGER BF report: H 0

Re: 2.6.18-rc5-mm1: drivers/infiniband/hw/amso1100/c2.c compile error

[Roland Dreier]

    Russell> Sure, if you want a _non-atomic_ 64-bit write then that's
    Russell> possible, but many 32-bit architectures can't do a 64-bit
    Russell> atomic IO write and that isn't something they can "fix".

I agree completely.  And going one step further: if an architecture
cannot implement a 64-bit write atomically, then the precise
serialization that is required is device-specific knowledge that
belongs in the device driver.

(For example, in the mthca case, the only serialization required is
that no writes go to the same page of MMIO space between the two
32-bit halves of the 64-bit write)

 - R.

-- 
VGER BF report: H 0

Re: 2.6.18-rc5-mm1: drivers/infiniband/hw/amso1100/c2.c compile error

[Andrew Morton]

On Fri, 1 Sep 2006 21:43:43 +0100
Russell King <rmk+lkml@arm.linux.org.uk> wrote:

> On Fri, Sep 01, 2006 at 01:04:44PM -0700, Andrew Morton wrote:
> > On Fri, 01 Sep 2006 12:53:47 -0700
> > Roland Dreier <rdreier@cisco.com> wrote:
> > > Yes, I agree that's a good plan, especially the documentation part.
> > > However I would argue that what's in drivers/infiniband/hw/mthca/mthca_doorbell.h 
> > > is legitimate: the driver uses __raw_writeq() when it exists and uses
> > > two __raw_writel()s properly serialized with a device-specific lock to
> > > get exactly the atomicity it needs on 32-bit archs.
> > 
> > No, driver-specific workarounds are not legitimate, sorry.
> > 
> > The driver should simply fail to compile on architectures which do not
> > implement __raw_writeq().
> 
> So, what you're basically saying is that on architectures which can _NOT_
> implement an atomic __raw_writeq(), certain drivers simply will not be
> available?

If the driver *requires* an atomic __raw_writeq(), then yes.  The driver
cannot work correctly on that machine.

If, however, there is some way in which we can make the hardware work on
that machine (say, with other locking) then we got the __raw_writeq()
interface design (whatever that is) wrong.

IOW, the best way of tackling this is to work out what we're trying to do,
design an interface, then implement it.

Doing funny workarounds within individual drivers isn't the way to address
this.  In fact it's an indication that something is wrong.

> > We can speed up the process by sending helpful emails to architecture
> > maintainers, but they'll notice either way.
> 
> I think you're completely wrong in the context of the message you're
> replying to - it's talking about an _atomic_ 64-bit write.
> 
> Sure, if you want a _non-atomic_ 64-bit write then that's possible,
> but many 32-bit architectures can't do a 64-bit atomic IO write and
> that isn't something they can "fix".

If the hardware/driver absolutely requires that the 64-bit write be atomic
on-the-bus then sure, the fix is to disable that driver on that
architecture in Kconfig.

If, however, the atomicity requirement is a software thing (we need to be
atomic against other CPU reads and writes) then that can be solved with
locking, and we can design APIs for this which can be implemented
efficiently on all architectures.


-- 
VGER BF report: H 0

Re: [openib-general] 2.6.18-rc5-mm1: drivers/infiniband/hw/amso1100/c2.c compile error

[Roland Dreier]

    Roland> Yes, I agree that's a good plan, especially the
    Roland> documentation part.  However I would argue that what's in
    Roland> drivers/infiniband/hw/mthca/mthca_doorbell.h is
    Roland> legitimate: the driver uses __raw_writeq() when it exists
    Roland> and uses two __raw_writel()s properly serialized with a
    Roland> device-specific lock to get exactly the atomicity it needs
    Roland> on 32-bit archs.

    Bryan> On the off chance that you might be arguing that
    Bryan> mthca_write64 could be a candidate drop-in for writeq on
    Bryan> 32-bit arches:

No, quite the opposite.  I'm arguing that the wrappers in mthca do
legitimately belong in a device driver, since they encapsulate
device-specific knowledge about what serialization suffices when an
atomic __raw_writeq() is not available.

    Bryan> That approach might work on mthca hardware, but it's not
    Bryan> safe in general.  The ipath driver requires a proper
    Bryan> writeq(), for example, because the hardware will quite
    Bryan> legitimately treat 32-bit writes to some registers as
    Bryan> separate accesses, and screw things up royally.

Yes, that's an unfortunate feature of the ipath hardware that
apparently makes it impossible to drive on a generic 32-bit architecture.

So perhaps writeq()/__raw_writeq() need to be defined to generate a
single bus cycle to the extent that makes sense.  Which would mean
that it's not possible to implement on all architectures.

 - R.

-- 
VGER BF report: H 0

Re: [openib-general] 2.6.18-rc5-mm1: drivers/infiniband/hw/amso1100/c2.c compile error

[Bryan O'Sullivan]

On Fri, 2006-09-01 at 13:54 -0700, Roland Dreier wrote:

> I agree completely.  And going one step further: if an architecture
> cannot implement a 64-bit write atomically, then the precise
> serialization that is required is device-specific knowledge that
> belongs in the device driver.

Absolutely.

	<b


-- 
VGER BF report: H 0

Re: 2.6.18-rc5-mm1: drivers/infiniband/hw/amso1100/c2.c compile error

[Andrew Morton]

On Fri, 01 Sep 2006 13:51:32 -0700
Roland Dreier <rdreier@cisco.com> wrote:

>     Andrew> No, driver-specific workarounds are not legitimate, sorry.
> 
>     Andrew> The driver should simply fail to compile on architectures
>     Andrew> which do not implement __raw_writeq().
> 
> But how should i386 (say) implement __raw_writeq()?  As two
> __raw_writel()s protected by a spinlock (that serializes all IO
> transactions)?  That seems rather ugly.
> 

If it's a choice between "ugly" and "doesn't work on x86", we'll take
"ugly" ;)

-- 
VGER BF report: H 0

Re: [openib-general] 2.6.18-rc5-mm1: drivers/infiniband/hw/amso1100/c2.c compile error

[Bryan O'Sullivan]

On Fri, 2006-09-01 at 13:59 -0700, Roland Dreier wrote:

> No, quite the opposite.  I'm arguing that the wrappers in mthca do
> legitimately belong in a device driver, since they encapsulate
> device-specific knowledge about what serialization suffices when an
> atomic __raw_writeq() is not available.

Yes, I figured that out from some later messages.  I think we're
violently in agreement, in that case.

	<b


-- 
VGER BF report: H 0

Re: 2.6.18-rc5-mm1: drivers/infiniband/hw/amso1100/c2.c compile error

[Roland Dreier]

    Andrew> If the hardware/driver absolutely requires that the 64-bit
    Andrew> write be atomic on-the-bus then sure, the fix is to
    Andrew> disable that driver on that architecture in Kconfig.

    Andrew> If, however, the atomicity requirement is a software thing
    Andrew> (we need to be atomic against other CPU reads and writes)
    Andrew> then that can be solved with locking, and we can design
    Andrew> APIs for this which can be implemented efficiently on all
    Andrew> architectures.

It seems that there are cases of both.  ipath needs actual 64-bit bus
transactions to work properly.  mthca needs to make sure that if
doorbell writes are split into two 32-bit halves, then no other writes
go to the same MMIO page in between the halves.

What do you think the API would look like?  Something along the lines
of mthca_doorbell.h, where we have macros for

DECLARE_WRITEQ_LOCK()
INIT_WRITEQ_LOCK()
GET_WRITEQ_LOCK()

which get stubbed out on architectures where writeq is already atomic,
and then pass the lock into writeq()?

But then you probably need some Kconfig symbol to say if writeq() is
really atomic or just software atomic (for ipath et al to depend on).

 - R.

-- 
VGER BF report: H 0

Re: 2.6.18-rc5-mm1: drivers/infiniband/hw/amso1100/c2.c compile error

[Andrew Morton]

On Fri, 01 Sep 2006 14:05:36 -0700
Roland Dreier <rdreier@cisco.com> wrote:

>     Andrew> If the hardware/driver absolutely requires that the 64-bit
>     Andrew> write be atomic on-the-bus then sure, the fix is to
>     Andrew> disable that driver on that architecture in Kconfig.
> 
>     Andrew> If, however, the atomicity requirement is a software thing
>     Andrew> (we need to be atomic against other CPU reads and writes)
>     Andrew> then that can be solved with locking, and we can design
>     Andrew> APIs for this which can be implemented efficiently on all
>     Andrew> architectures.
> 
> It seems that there are cases of both.  ipath needs actual 64-bit bus
> transactions to work properly.

If we define __raw_writeq() to be 64-bit-atomic-on-the-bus then an
appropriate solution for ipath would be to call __raw_writeq() directly. 
If the arch cannot implement __raw_write() then build error -> Kconfig fix.

>  mthca needs to make sure that if
> doorbell writes are split into two 32-bit halves, then no other writes
> go to the same MMIO page in between the halves.
> 
> What do you think the API would look like?  Something along the lines
> of mthca_doorbell.h, where we have macros for
> 
> DECLARE_WRITEQ_LOCK()
> INIT_WRITEQ_LOCK()
> GET_WRITEQ_LOCK()
> 
> which get stubbed out on architectures where writeq is already atomic,
> and then pass the lock into writeq()?
> 
> But then you probably need some Kconfig symbol to say if writeq() is
> really atomic or just software atomic (for ipath et al to depend on).
> 

It depends on how many other devices have (or are expected to have)
mthca-like requirements.  If the answer is "very few, maybe none" then
perhaps we don't need to go designing generic interfaces to support such
things.

As for interfaces, umm, something like

#ifdef CONFIG_ARCH_HAS_64BIT_ATOMIC_MMIO_WRITES

struct be64_port {
	void __iomem *addr;
};

static inline void atomic_be64_mmio_write(u64 v, struct be64_port *port)
{
	__raw_writeq(v, port->addr);
}

#define be64_port_init(port, addr)
	port->addr = addr;

#define be64_port_init_external_locking(port, addr, lockp)
	be64_port_init(port, addr)


#else


struct be64_port {
	void __iomem *addr;
	spinlock_t lock;
	spinlock_t *lockp;
};

static inline void atomic_be64_mmio_write(u64 v, struct be64_port *port)
{
	unsigned long flags;
	
	spin_lock_irqsave(port->lockp, flags);
	__raw_writel(...);
	__raw_writel(...);
	spin_unlock_irqrestore(port->lockp, flags);
}

#define be64_port_init(port, addr)
	spin_lock_init(&port->lock);
	port->lockp = &port->lock;
	port->addr = addr;

#define be64_port_init_external_locking(port, addr, lockp)
	port->lockp = lockp;
	port->addr = addr;

#endif

perhaps?

btw, 32-bit mthca_write64() is downright scary from an endianness POV.  I
guess it's right, but I wouldn't label it "obviously correct" ;)


-- 
VGER BF report: H 0

Re: 2.6.18-rc5-mm1: drivers/infiniband/hw/amso1100/c2.c compile error

[Roland Dreier]

    Andrew> It depends on how many other devices have (or are expected
    Andrew> to have) mthca-like requirements.  If the answer is "very
    Andrew> few, maybe none" then perhaps we don't need to go
    Andrew> designing generic interfaces to support such things.

I actually don't know of any others -- not that I'm an expert on the
range of devices that exist...

What's your feeling about drivers like amso1100, which don't
particularly care about atomicity, but just want to write a 64-bit
quantity conveniently?  Should we require writeq()/__raw_writeq() for
all archs, and then define CONFIG_ARCH_HAS_64BIT_ATOMIC_MMIO_WRITES as
appropriate?

I see stuff like this is drivers/dma/ioatdma.c:

#if (BITS_PER_LONG == 64)
	ioatdma_chan_write64(ioat_chan, IOAT_CHAINADDR_OFFSET, desc->phys);
#else
	ioatdma_chan_write32(ioat_chan,
	                     IOAT_CHAINADDR_OFFSET_LOW,
	                     (u32) desc->phys);
	ioatdma_chan_write32(ioat_chan, IOAT_CHAINADDR_OFFSET_HIGH, 0);
#endif

and drivers/char/hpet.c:

#ifndef readq
static inline unsigned long long readq(void __iomem *addr)
{
	return readl(addr) | (((unsigned long long)readl(addr + 4)) << 32LL);
}
#endif

#ifndef writeq
static inline void writeq(unsigned long long v, void __iomem *addr)
{
	writel(v & 0xffffffff, addr);
	writel(v >> 32, addr + 4);
}
#endif

and so on...

 - R.

-- 
VGER BF report: H 0

Re: 2.6.18-rc5-mm1 (IDE resume regression)

[Rafael J. Wysocki]

On Friday 01 September 2006 10:58, Andrew Morton wrote:
> 
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc5/2.6.18-rc5-mm1/
> 
> 
> - CONFIG_BLOCK=n is bust due to
>   writeback_congestion_end()/blk_congestion_end() snafu.  We'll fix it later.

I need the appended patch to prevent my box from crashing during suspend to
disk (in the resume-during-suspend phase).

Apparently, the pointer returned by to_ide_driver() in generic_ide_resume()
is completely bogous, although it's nonzero, and a NULL pointer dereference
occurs when drv->resume is evaluated (100% of the time on my box).

---
 drivers/ide/ide.c |    9 +--------
 1 files changed, 1 insertion(+), 8 deletions(-)

Index: linux-2.6.18-rc5-mm1/drivers/ide/ide.c
===================================================================
--- linux-2.6.18-rc5-mm1.orig/drivers/ide/ide.c
+++ linux-2.6.18-rc5-mm1/drivers/ide/ide.c
@@ -1235,11 +1235,9 @@ static int generic_ide_suspend(struct de
 static int generic_ide_resume(struct device *dev)
 {
 	ide_drive_t *drive = dev->driver_data;
-	ide_driver_t *drv = to_ide_driver(dev->driver);
 	struct request rq;
 	struct request_pm_state rqpm;
 	ide_task_t args;
-	int err;
 
 	memset(&rq, 0, sizeof(rq));
 	memset(&rqpm, 0, sizeof(rqpm));
@@ -1250,12 +1248,7 @@ static int generic_ide_resume(struct dev
 	rqpm.pm_step = ide_pm_state_start_resume;
 	rqpm.pm_state = PM_EVENT_ON;
 
-	err = ide_do_drive_cmd(drive, &rq, ide_head_wait);
-
-	if (err == 0 && drv->resume)
-		drv->resume(drive);
-
-	return err;
+	return ide_do_drive_cmd(drive, &rq, ide_head_wait);
 }
 
 int generic_ide_ioctl(ide_drive_t *drive, struct file *file, struct block_device *bdev,

-- 
VGER BF report: H 0.0771048

Re: 2.6.18-rc5-mm1 (IDE resume regression)

[Andrew Morton]

On Sat, 2 Sep 2006 01:13:23 +0200
"Rafael J. Wysocki" <rjw@sisk.pl> wrote:

> On Friday 01 September 2006 10:58, Andrew Morton wrote:
> > 
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc5/2.6.18-rc5-mm1/
> > 
> > 
> > - CONFIG_BLOCK=n is bust due to
> >   writeback_congestion_end()/blk_congestion_end() snafu.  We'll fix it later.
> 
> I need the appended patch to prevent my box from crashing during suspend to
> disk (in the resume-during-suspend phase).
> 
> Apparently, the pointer returned by to_ide_driver() in generic_ide_resume()
> is completely bogous, although it's nonzero, and a NULL pointer dereference
> occurs when drv->resume is evaluated (100% of the time on my box).
> 

OK, thanks.  That's ide-hpa-resume-fix.patch

> Index: linux-2.6.18-rc5-mm1/drivers/ide/ide.c
> ===================================================================
> --- linux-2.6.18-rc5-mm1.orig/drivers/ide/ide.c
> +++ linux-2.6.18-rc5-mm1/drivers/ide/ide.c
> @@ -1235,11 +1235,9 @@ static int generic_ide_suspend(struct de
>  static int generic_ide_resume(struct device *dev)
>  {
>  	ide_drive_t *drive = dev->driver_data;
> -	ide_driver_t *drv = to_ide_driver(dev->driver);
>  	struct request rq;
>  	struct request_pm_state rqpm;
>  	ide_task_t args;
> -	int err;
>  
>  	memset(&rq, 0, sizeof(rq));
>  	memset(&rqpm, 0, sizeof(rqpm));
> @@ -1250,12 +1248,7 @@ static int generic_ide_resume(struct dev
>  	rqpm.pm_step = ide_pm_state_start_resume;
>  	rqpm.pm_state = PM_EVENT_ON;
>  
> -	err = ide_do_drive_cmd(drive, &rq, ide_head_wait);
> -
> -	if (err == 0 && drv->resume)
> -		drv->resume(drive);
> -
> -	return err;
> +	return ide_do_drive_cmd(drive, &rq, ide_head_wait);
>  }
>  
>  int generic_ide_ioctl(ide_drive_t *drive, struct file *file, struct block_device *bdev,


And the above reverts most of it.  It looks like we'll need to
have another go at that one.  I'll drop it.

-- 
VGER BF report: H 0

Re: 2.6.18-rc5-mm1

[Matthias Hentges]

[-- Attachment #1.1: Type: text/plain, Size: 1969 bytes --]

Hi,

2.6.18-rc5-mm1 oopses on an Asus P5W DH Deluxe board, full dmesg
attached.
This did not happen in 2.6.18-rc4-mm3.


BUG: unable to handle kernel NULL pointer dereference at virtual address
00000000
 printing eip:
00000000
*pde = 00000000
Oops: 0000 [#1]
4K_STACKS SMP 
last sysfs file: 
Modules linked in:
CPU:    0
EIP:    0060:[<00000000>]    Not tainted VLI
EFLAGS: 00010087   (2.6.18-rc5-mm1 #1) 
EIP is at rest_init+0x3feffd78/0x20
eax: 000000da   ebx: c04d5f78   ecx: c04d5f94   edx: c04d2f00
esi: 000000da   edi: 00000000   ebp: c04d2f00   esp: c0516ffc
ds: 007b   es: 007b   ss: 0068
Process swapper (pid: 0, ti=c0516000 task=c045c200 task.ti=c04d5000)
Stack: c0105027 
Call Trace:
 [<c0105027>] do_IRQ+0x8a/0xac
 [<c01035a6>] common_interrupt+0x1a/0x20
 [<c0101a72>] mwait_idle_with_hints+0x36/0x3b
 [<c0101a83>] mwait_idle+0xc/0x1b
 [<c0101a26>] cpu_idle+0x5e/0x74
 [<c04db6fa>] start_kernel+0x363/0x36a
 =======================
Code:  Bad EIP value.
EIP: [<00000000>] rest_init+0x3feffd78/0x20 SS:ESP 0068:c0516ffc
 <0>Kernel panic - not syncing: Fatal exception in interrupt
 BUG: warning at arch/i386/kernel/smp.c:547/smp_call_function()
 [<c010ca45>] smp_call_function+0x54/0xff
 [<c011a270>] printk+0x12/0x16
 [<c010cb03>] smp_send_stop+0x13/0x1c
 [<c0119480>] panic+0x49/0xd3
 [<c010410c>] die+0x273/0x28a
 [<c01126d4>] do_page_fault+0x40d/0x4db
 [<c01122c7>] do_page_fault+0x0/0x4db
 [<c03d1231>] error_code+0x39/0x40
 [<c013007b>] free_module+0x89/0xc3
 [<c0105027>] do_IRQ+0x8a/0xac
 [<c01035a6>] common_interrupt+0x1a/0x20
 [<c0101a72>] mwait_idle_with_hints+0x36/0x3b
 [<c0101a83>] mwait_idle+0xc/0x1b
 [<c0101a26>] cpu_idle+0x5e/0x74
 [<c04db6fa>] start_kernel+0x363/0x36a
 =======================

-- 
Matthias 'CoreDump' Hentges 

Webmaster of hentges.net and OpenZaurus developer.
You can reach me in #openzaurus on Freenode.

My OS: Debian SID. Geek by Nature, Linux by Choice

[-- Attachment #1.2: dmesg.txt.gz --]
[-- Type: application/x-gzip, Size: 5023 bytes --]

[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: 2.6.18-rc5-mm1

[Grant Coady]

On Fri, 1 Sep 2006 01:58:18 -0700, Andrew Morton <akpm@osdl.org> wrote:

>
>ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc5/2.6.18-rc5-mm1/
...
>- See the `hot-fixes' directory for any important updates to this patchset.
>
Okay, I applied hotfixes and it crashed on boot, keyboard LEDs flashing:

Repeating message, hand copied:
atkbd.c: Spurious ACK in isa0060/serio0. Some program might be trying access 
hardware directly.

Thing is, I've been getting this similar message once in dmesg for ages:

<http://bugsplatter.mine.nu/test/boxen/sempro/dmesg-2.6.14.7a.gz>:
atkbd.c: Spurious ACK on isa0060/serio0. Some program, like XFree86, might be trying access hardware directly.
<http://bugsplatter.mine.nu/test/boxen/sempro/dmesg-2.6.15.7a.gz>:
atkbd.c: Spurious ACK on isa0060/serio0. Some program, like XFree86, might be trying access hardware directly.
<http://bugsplatter.mine.nu/test/boxen/sempro/dmesg-2.6.16.27a.gz>:
atkbd.c: Spurious ACK on isa0060/serio0. Some program, like XFree86, might be trying access hardware directly.
<http://bugsplatter.mine.nu/test/boxen/sempro/dmesg-2.6.16.28a.gz>:
atkbd.c: Spurious ACK on isa0060/serio0. Some program, like XFree86, might be trying access hardware directly.
<http://bugsplatter.mine.nu/test/boxen/sempro/dmesg-2.6.17.11a.gz>:
atkbd.c: Spurious ACK on isa0060/serio0. Some program, like XFree86, might be trying access hardware directly.

<http://bugsplatter.mine.nu/test/boxen/sempro/dmesg-2.6.18-rc3-mm2a.gz>:
<no mention>

<http://bugsplatter.mine.nu/test/boxen/sempro/dmesg-2.6.18-rc4a.gz>:
atkbd.c: Spurious ACK on isa0060/serio0. Some program might be trying access hardware directly.
<http://bugsplatter.mine.nu/test/boxen/sempro/dmesg-2.6.18-rc5-git4b>:
atkbd.c: Spurious ACK on isa0060/serio0. Some program might be trying access hardware directly.

<http://bugsplatter.mine.nu/test/boxen/sempro/> for more info on hardware

This is MSI KM4M-V <http://tinyurl.com/64cfd> AMD Sempron SktA 32-bit CPU, I 
don't see the error on Intel CPU boxen, nor on an AMD K6-2/500 CPU (2.6.15.6)

Grant.

-- 
VGER BF report: U 0.480374

Re: 2.6.18-rc5-mm1

[Dmitry Torokhov]

On Friday 01 September 2006 21:06, Grant Coady wrote:
> On Fri, 1 Sep 2006 01:58:18 -0700, Andrew Morton <akpm@osdl.org> wrote:
> 
> >
> >ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc5/2.6.18-rc5-mm1/
> ...
> >- See the `hot-fixes' directory for any important updates to this patchset.
> >
> Okay, I applied hotfixes and it crashed on boot, keyboard LEDs flashing:
> 
> Repeating message, hand copied:
> atkbd.c: Spurious ACK in isa0060/serio0. Some program might be trying access 
> hardware directly.
> 

Please try booting with i8042.panicblink=0 to see the real oops (important
data). We should probably disable blinking if X is not active...

-- 
Dmitry

-- 
VGER BF report: H 2.32592e-14

Re: 2.6.18-rc5-mm1

[Andrew Morton]

On Sat, 02 Sep 2006 03:00:47 +0200
Matthias Hentges <oe@hentges.net> wrote:

> 2.6.18-rc5-mm1 oopses on an Asus P5W DH Deluxe board, full dmesg
> attached.
> This did not happen in 2.6.18-rc4-mm3.
> 
> 
> BUG: unable to handle kernel NULL pointer dereference at virtual address
> 00000000
>  printing eip:
> 00000000
> *pde = 00000000
> Oops: 0000 [#1]
> 4K_STACKS SMP 
> last sysfs file: 
> Modules linked in:
> CPU:    0
> EIP:    0060:[<00000000>]    Not tainted VLI
> EFLAGS: 00010087   (2.6.18-rc5-mm1 #1) 
> EIP is at rest_init+0x3feffd78/0x20
> eax: 000000da   ebx: c04d5f78   ecx: c04d5f94   edx: c04d2f00
> esi: 000000da   edi: 00000000   ebp: c04d2f00   esp: c0516ffc
> ds: 007b   es: 007b   ss: 0068
> Process swapper (pid: 0, ti=c0516000 task=c045c200 task.ti=c04d5000)
> Stack: c0105027 
> Call Trace:
>  [<c0105027>] do_IRQ+0x8a/0xac
>  [<c01035a6>] common_interrupt+0x1a/0x20
>  [<c0101a72>] mwait_idle_with_hints+0x36/0x3b
>  [<c0101a83>] mwait_idle+0xc/0x1b
>  [<c0101a26>] cpu_idle+0x5e/0x74
>  [<c04db6fa>] start_kernel+0x363/0x36a
>  =======================
> Code:  Bad EIP value.
> EIP: [<00000000>] rest_init+0x3feffd78/0x20 SS:ESP 0068:c0516ffc
>  <0>Kernel panic - not syncing: Fatal exception in interrupt
>  BUG: warning at arch/i386/kernel/smp.c:547/smp_call_function()
>  [<c010ca45>] smp_call_function+0x54/0xff
>  [<c011a270>] printk+0x12/0x16
>  [<c010cb03>] smp_send_stop+0x13/0x1c
>  [<c0119480>] panic+0x49/0xd3
>  [<c010410c>] die+0x273/0x28a
>  [<c01126d4>] do_page_fault+0x40d/0x4db
>  [<c01122c7>] do_page_fault+0x0/0x4db
>  [<c03d1231>] error_code+0x39/0x40
>  [<c013007b>] free_module+0x89/0xc3
>  [<c0105027>] do_IRQ+0x8a/0xac
>  [<c01035a6>] common_interrupt+0x1a/0x20
>  [<c0101a72>] mwait_idle_with_hints+0x36/0x3b
>  [<c0101a83>] mwait_idle+0xc/0x1b
>  [<c0101a26>] cpu_idle+0x5e/0x74
>  [<c04db6fa>] start_kernel+0x363/0x36a
>  =======================

OK, thanks.  That'll be acpi-mwait-c-state-fixes.patch.  I've uploaded the
below revert patch to
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc5/2.6.18-rc5-mm1/hot-fixes/


diff -puN arch/i386/kernel/acpi/cstate.c~revert-acpi-mwait-c-state-fixes arch/i386/kernel/acpi/cstate.c
--- a/arch/i386/kernel/acpi/cstate.c~revert-acpi-mwait-c-state-fixes
+++ a/arch/i386/kernel/acpi/cstate.c
@@ -10,7 +10,6 @@
 #include <linux/module.h>
 #include <linux/init.h>
 #include <linux/acpi.h>
-#include <linux/cpu.h>
 
 #include <acpi/processor.h>
 #include <asm/acpi.h>
@@ -42,124 +41,5 @@ void acpi_processor_power_init_bm_check(
 		flags->bm_check = 1;
 	}
 }
-EXPORT_SYMBOL(acpi_processor_power_init_bm_check);
-
-/* The code below handles cstate entry with monitor-mwait pair on Intel*/
-
-struct cstate_entry_s {
-	struct {
-		unsigned int eax;
-		unsigned int ecx;
-	} states[ACPI_PROCESSOR_MAX_POWER];
-};
-static struct cstate_entry_s *cpu_cstate_entry;	/* per CPU ptr */
-
-static short mwait_supported[ACPI_PROCESSOR_MAX_POWER];
-
-#define MWAIT_SUBSTATE_MASK	(0xf)
-#define MWAIT_SUBSTATE_SIZE	(4)
-
-#define CPUID_MWAIT_LEAF (5)
-#define CPUID5_ECX_EXTENSIONS_SUPPORTED (0x1)
-#define CPUID5_ECX_INTERRUPT_BREAK	(0x2)
-
-#define MWAIT_ECX_INTERRUPT_BREAK	(0x1)
-
-#define NATIVE_CSTATE_BEYOND_HALT	(2)
-
-int acpi_processor_ffh_cstate_probe(unsigned int cpu,
-		struct acpi_processor_cx *cx, struct acpi_power_register *reg)
-{
-	struct cstate_entry_s *percpu_entry;
-	struct cpuinfo_x86 *c = cpu_data + cpu;
-
-	cpumask_t saved_mask;
-	int retval;
-	unsigned int eax, ebx, ecx, edx;
-	unsigned int edx_part;
-	unsigned int cstate_type; /* C-state type and not ACPI C-state type */
-	unsigned int num_cstate_subtype;
-
-	if (!cpu_cstate_entry || c->cpuid_level < CPUID_MWAIT_LEAF )
-		return -1;
-
-	if (reg->bit_offset != NATIVE_CSTATE_BEYOND_HALT)
-		return -1;
-
-	percpu_entry = per_cpu_ptr(cpu_cstate_entry, cpu);
-	percpu_entry->states[cx->index].eax = 0;
-	percpu_entry->states[cx->index].ecx = 0;
-
-	/* Make sure we are running on right CPU */
-	saved_mask = current->cpus_allowed;
-	retval = set_cpus_allowed(current, cpumask_of_cpu(cpu));
-	if (retval)
-		return -1;
-
-	cpuid(CPUID_MWAIT_LEAF, &eax, &ebx, &ecx, &edx);
-
-	/* Check whether this particular cx_type (in CST) is supported or not */
-	cstate_type = (cx->address >> MWAIT_SUBSTATE_SIZE) + 1;
-	edx_part = edx >> (cstate_type * MWAIT_SUBSTATE_SIZE);
-	num_cstate_subtype = edx_part & MWAIT_SUBSTATE_MASK;
-
-	retval = 0;
-	if (num_cstate_subtype < (cx->address & MWAIT_SUBSTATE_MASK)) {
-		retval = -1;
-		goto out;
-	}
 
-	/* mwait ecx extensions INTERRUPT_BREAK should be supported for C2/C3 */
-	if (!(ecx & CPUID5_ECX_EXTENSIONS_SUPPORTED) ||
-	    !(ecx & CPUID5_ECX_INTERRUPT_BREAK)) {
-		retval = -1;
-		goto out;
-	}
-	percpu_entry->states[cx->index].ecx = MWAIT_ECX_INTERRUPT_BREAK;
-
-	/* Use the hint in CST */
-	percpu_entry->states[cx->index].eax = cx->address;
-
-	if (!mwait_supported[cstate_type]) {
-		mwait_supported[cstate_type] = 1;
-		printk(KERN_DEBUG "Monitor-Mwait will be used to enter C-%d "
-		       "state\n", cx->type);
-	}
-
-out:
-	set_cpus_allowed(current, saved_mask);
-	return retval;
-}
-EXPORT_SYMBOL_GPL(acpi_processor_ffh_cstate_probe);
-
-void acpi_processor_ffh_cstate_enter(struct acpi_processor_cx *cx)
-{
-	unsigned int cpu = smp_processor_id();
-	struct cstate_entry_s *percpu_entry;
-
-	percpu_entry = per_cpu_ptr(cpu_cstate_entry, cpu);
-	mwait_idle_with_hints(percpu_entry->states[cx->index].eax,
-	                      percpu_entry->states[cx->index].ecx);
-}
-EXPORT_SYMBOL_GPL(acpi_processor_ffh_cstate_enter);
-
-static int __init ffh_cstate_init(void)
-{
-	struct cpuinfo_x86 *c = &boot_cpu_data;
-	if (c->x86_vendor != X86_VENDOR_INTEL)
-		return -1;
-
-	cpu_cstate_entry = alloc_percpu(struct cstate_entry_s);
-	return 0;
-}
-
-static void __exit ffh_cstate_exit(void)
-{
-	if (cpu_cstate_entry) {
-		free_percpu(cpu_cstate_entry);
-		cpu_cstate_entry = NULL;
-	}
-}
-
-arch_initcall(ffh_cstate_init);
-__exitcall(ffh_cstate_exit);
+EXPORT_SYMBOL(acpi_processor_power_init_bm_check);
diff -puN arch/i386/kernel/process.c~revert-acpi-mwait-c-state-fixes arch/i386/kernel/process.c
--- a/arch/i386/kernel/process.c~revert-acpi-mwait-c-state-fixes
+++ a/arch/i386/kernel/process.c
@@ -236,28 +236,20 @@ EXPORT_SYMBOL_GPL(cpu_idle_wait);
  * We execute MONITOR against need_resched and enter optimized wait state
  * through MWAIT. Whenever someone changes need_resched, we would be woken
  * up from MWAIT (without an IPI).
- *
- * New with Core Duo processors, MWAIT can take some hints based on CPU
- * capability.
  */
-void mwait_idle_with_hints(unsigned long eax, unsigned long ecx)
+static void mwait_idle(void)
 {
-	if (!need_resched()) {
+	local_irq_enable();
+
+	while (!need_resched()) {
 		__monitor((void *)&current_thread_info()->flags, 0, 0);
 		smp_mb();
-		if (!need_resched())
-			__mwait(eax, ecx);
+		if (need_resched())
+			break;
+		__mwait(0, 0);
 	}
 }
 
-/* Default MONITOR/MWAIT with no hints, used for default C1 state */
-static void mwait_idle(void)
-{
-	local_irq_enable();
-	while (!need_resched())
-		mwait_idle_with_hints(0, 0);
-}
-
 void __devinit select_idle_routine(const struct cpuinfo_x86 *c)
 {
 	if (cpu_has(c, X86_FEATURE_MWAIT)) {
diff -puN arch/x86_64/kernel/process.c~revert-acpi-mwait-c-state-fixes arch/x86_64/kernel/process.c
--- a/arch/x86_64/kernel/process.c~revert-acpi-mwait-c-state-fixes
+++ a/arch/x86_64/kernel/process.c
@@ -235,28 +235,20 @@ void cpu_idle (void)
  * We execute MONITOR against need_resched and enter optimized wait state
  * through MWAIT. Whenever someone changes need_resched, we would be woken
  * up from MWAIT (without an IPI).
- *
- * New with Core Duo processors, MWAIT can take some hints based on CPU
- * capability.
  */
-void mwait_idle_with_hints(unsigned long eax, unsigned long ecx)
+static void mwait_idle(void)
 {
-	if (!need_resched()) {
+	local_irq_enable();
+
+	while (!need_resched()) {
 		__monitor((void *)&current_thread_info()->flags, 0, 0);
 		smp_mb();
-		if (!need_resched())
-			__mwait(eax, ecx);
+		if (need_resched())
+			break;
+		__mwait(0, 0);
 	}
 }
 
-/* Default MONITOR/MWAIT with no hints, used for default C1 state */
-static void mwait_idle(void)
-{
-	local_irq_enable();
-	while (!need_resched())
-		mwait_idle_with_hints(0,0);
-}
-
 void __cpuinit select_idle_routine(const struct cpuinfo_x86 *c)
 {
 	static int printed;
diff -puN drivers/acpi/processor_idle.c~revert-acpi-mwait-c-state-fixes drivers/acpi/processor_idle.c
--- a/drivers/acpi/processor_idle.c~revert-acpi-mwait-c-state-fixes
+++ a/drivers/acpi/processor_idle.c
@@ -219,23 +219,6 @@ static void acpi_safe_halt(void)
 
 static atomic_t c3_cpu_count;
 
-/* Common C-state entry for C2, C3, .. */
-static void acpi_cstate_enter(struct acpi_processor_cx *cstate)
-{
-	if (cstate->space_id == ACPI_CSTATE_FFH) {
-		/* Call into architectural FFH based C-state */
-		acpi_processor_ffh_cstate_enter(cstate);
-	} else {
-		int unused;
-		/* IO port based C-state */
-		inb(cstate->address);
-		/* Dummy wait op - must do something useless after P_LVL2 read
-		   because chipsets cannot guarantee that STPCLK# signal
-		   gets asserted in time to freeze execution properly. */
-		unused = inl(acpi_fadt.xpm_tmr_blk.address);
-	}
-}
-
 static void acpi_processor_idle(void)
 {
 	struct acpi_processor *pr = NULL;
@@ -378,7 +361,11 @@ static void acpi_processor_idle(void)
 		/* Get start time (ticks) */
 		t1 = inl(acpi_fadt.xpm_tmr_blk.address);
 		/* Invoke C2 */
-		acpi_cstate_enter(cx);
+		inb(cx->address);
+		/* Dummy wait op - must do something useless after P_LVL2 read
+		   because chipsets cannot guarantee that STPCLK# signal
+		   gets asserted in time to freeze execution properly. */
+		t2 = inl(acpi_fadt.xpm_tmr_blk.address);
 		/* Get end time (ticks) */
 		t2 = inl(acpi_fadt.xpm_tmr_blk.address);
 
@@ -414,7 +401,9 @@ static void acpi_processor_idle(void)
 		/* Get start time (ticks) */
 		t1 = inl(acpi_fadt.xpm_tmr_blk.address);
 		/* Invoke C3 */
-		acpi_cstate_enter(cx);
+		inb(cx->address);
+		/* Dummy wait op (see above) */
+		t2 = inl(acpi_fadt.xpm_tmr_blk.address);
 		/* Get end time (ticks) */
 		t2 = inl(acpi_fadt.xpm_tmr_blk.address);
 		if (pr->flags.bm_check) {
@@ -639,16 +628,20 @@ static int acpi_processor_get_power_info
 	return 0;
 }
 
-static int acpi_processor_get_power_info_default(struct acpi_processor *pr)
+static int acpi_processor_get_power_info_default_c1(struct acpi_processor *pr)
 {
-	if (!pr->power.states[ACPI_STATE_C1].valid) {
-		/* set the first C-State to C1 */
-		/* all processors need to support C1 */
-		pr->power.states[ACPI_STATE_C1].type = ACPI_STATE_C1;
-		pr->power.states[ACPI_STATE_C1].valid = 1;
-	}
-	/* the C0 state only exists as a filler in our array */
+
+	/* Zero initialize all the C-states info. */
+	memset(pr->power.states, 0, sizeof(pr->power.states));
+
+	/* set the first C-State to C1 */
+	pr->power.states[ACPI_STATE_C1].type = ACPI_STATE_C1;
+
+	/* the C0 state only exists as a filler in our array,
+	 * and all processors need to support C1 */
 	pr->power.states[ACPI_STATE_C0].valid = 1;
+	pr->power.states[ACPI_STATE_C1].valid = 1;
+
 	return 0;
 }
 
@@ -665,7 +658,12 @@ static int acpi_processor_get_power_info
 	if (nocst)
 		return -ENODEV;
 
-	current_count = 0;
+	current_count = 1;
+
+	/* Zero initialize C2 onwards and prepare for fresh CST lookup */
+	for (i = 2; i < ACPI_PROCESSOR_MAX_POWER; i++)
+		memset(&(pr->power.states[i]), 0, 
+				sizeof(struct acpi_processor_cx));
 
 	status = acpi_evaluate_object(pr->handle, "_CST", NULL, &buffer);
 	if (ACPI_FAILURE(status)) {
@@ -720,39 +718,22 @@ static int acpi_processor_get_power_info
 		    (reg->space_id != ACPI_ADR_SPACE_FIXED_HARDWARE))
 			continue;
 
+		cx.address = (reg->space_id == ACPI_ADR_SPACE_FIXED_HARDWARE) ?
+		    0 : reg->address;
+
 		/* There should be an easy way to extract an integer... */
 		obj = (union acpi_object *)&(element->package.elements[1]);
 		if (obj->type != ACPI_TYPE_INTEGER)
 			continue;
 
 		cx.type = obj->integer.value;
-		/*
-		 * Some buggy BIOSes won't list C1 in _CST -
-		 * Let acpi_processor_get_power_info_default() handle them later
-		 */
-		if (i == 1 && cx.type != ACPI_STATE_C1)
-			current_count++;
 
-		cx.address = reg->address;
-		cx.index = current_count + 1;
+		if ((cx.type != ACPI_STATE_C1) &&
+		    (reg->space_id != ACPI_ADR_SPACE_SYSTEM_IO))
+			continue;
 
-		cx.space_id = ACPI_CSTATE_SYSTEMIO;
-		if (reg->space_id == ACPI_ADR_SPACE_FIXED_HARDWARE) {
-			if (acpi_processor_ffh_cstate_probe
-					(pr->id, &cx, reg) == 0) {
-				cx.space_id = ACPI_CSTATE_FFH;
-			} else if (cx.type != ACPI_STATE_C1) {
-				/*
-				 * C1 is a special case where FIXED_HARDWARE
-				 * can be handled in non-MWAIT way as well.
-				 * In that case, save this _CST entry info.
-				 * That is, we retain space_id of SYSTEM_IO for
-				 * halt based C1.
-				 * Otherwise, ignore this info and continue.
-				 */
-				continue;
-			}
-		}
+		if ((cx.type < ACPI_STATE_C2) || (cx.type > ACPI_STATE_C3))
+			continue;
 
 		obj = (union acpi_object *)&(element->package.elements[2]);
 		if (obj->type != ACPI_TYPE_INTEGER)
@@ -957,18 +938,12 @@ static int acpi_processor_get_power_info
 	/* NOTE: the idle thread may not be running while calling
 	 * this function */
 
-	/* Zero initialize all the C-states info. */
-	memset(pr->power.states, 0, sizeof(pr->power.states));
-
+	/* Adding C1 state */
+	acpi_processor_get_power_info_default_c1(pr);
 	result = acpi_processor_get_power_info_cst(pr);
 	if (result == -ENODEV)
 		acpi_processor_get_power_info_fadt(pr);
 
-	if (result)
-		return result;
-
-	acpi_processor_get_power_info_default(pr);
-
 	pr->power.count = acpi_processor_power_verify(pr);
 
 	/*
diff -puN include/acpi/pdc_intel.h~revert-acpi-mwait-c-state-fixes include/acpi/pdc_intel.h
--- a/include/acpi/pdc_intel.h~revert-acpi-mwait-c-state-fixes
+++ a/include/acpi/pdc_intel.h
@@ -13,7 +13,6 @@
 #define ACPI_PDC_SMP_C_SWCOORD		(0x0040)
 #define ACPI_PDC_SMP_T_SWCOORD		(0x0080)
 #define ACPI_PDC_C_C1_FFH		(0x0100)
-#define ACPI_PDC_C_C2C3_FFH		(0x0200)
 
 #define ACPI_PDC_EST_CAPABILITY_SMP	(ACPI_PDC_SMP_C1PT | \
 					 ACPI_PDC_C_C1_HALT | \
@@ -24,10 +23,8 @@
 					 ACPI_PDC_SMP_P_SWCOORD | \
 					 ACPI_PDC_P_FFH)
 
-#define ACPI_PDC_C_CAPABILITY_SMP	(ACPI_PDC_SMP_C2C3  | \
-					 ACPI_PDC_SMP_C1PT  | \
-					 ACPI_PDC_C_C1_HALT | \
-					 ACPI_PDC_C_C1_FFH  | \
-					 ACPI_PDC_C_C2C3_FFH)
+#define ACPI_PDC_C_CAPABILITY_SMP	(ACPI_PDC_SMP_C2C3 | \
+					 ACPI_PDC_SMP_C1PT | \
+					 ACPI_PDC_C_C1_HALT)
 
 #endif				/* __PDC_INTEL_H__ */
diff -puN include/acpi/processor.h~revert-acpi-mwait-c-state-fixes include/acpi/processor.h
--- a/include/acpi/processor.h~revert-acpi-mwait-c-state-fixes
+++ a/include/acpi/processor.h
@@ -29,9 +29,6 @@
 #define DOMAIN_COORD_TYPE_SW_ANY	0xfd
 #define DOMAIN_COORD_TYPE_HW_ALL	0xfe
 
-#define ACPI_CSTATE_SYSTEMIO	(0)
-#define ACPI_CSTATE_FFH		(1)
-
 /* Power Management */
 
 struct acpi_processor_cx;
@@ -61,8 +58,6 @@ struct acpi_processor_cx {
 	u8 valid;
 	u8 type;
 	u32 address;
-	u8 space_id;
-	u8 index;
 	u32 latency;
 	u32 latency_ticks;
 	u32 power;
@@ -211,9 +206,6 @@ void arch_acpi_processor_init_pdc(struct
 #ifdef ARCH_HAS_POWER_INIT
 void acpi_processor_power_init_bm_check(struct acpi_processor_flags *flags,
 					unsigned int cpu);
-int acpi_processor_ffh_cstate_probe(unsigned int cpu,
-		struct acpi_processor_cx *cx, struct acpi_power_register *reg);
-void acpi_processor_ffh_cstate_enter(struct acpi_processor_cx *cstate);
 #else
 static inline void acpi_processor_power_init_bm_check(struct
 						      acpi_processor_flags
@@ -222,16 +214,6 @@ static inline void acpi_processor_power_
 	flags->bm_check = 1;
 	return;
 }
-static inline int acpi_processor_ffh_cstate_probe(unsigned int cpu,
-		struct acpi_processor_cx *cx, struct acpi_power_register *reg)
-{
-	return -1;
-}
-static inline void acpi_processor_ffh_cstate_enter(
-		struct acpi_processor_cx *cstate)
-{
-	return;
-}
 #endif
 
 /* in processor_perflib.c */
diff -puN include/asm-i386/processor.h~revert-acpi-mwait-c-state-fixes include/asm-i386/processor.h
--- a/include/asm-i386/processor.h~revert-acpi-mwait-c-state-fixes
+++ a/include/asm-i386/processor.h
@@ -306,8 +306,6 @@ static inline void __mwait(unsigned long
 		: :"a" (eax), "c" (ecx));
 }
 
-extern void mwait_idle_with_hints(unsigned long eax, unsigned long ecx);
-
 /* from system description table in BIOS.  Mostly for MCA use, but
 others may find it useful. */
 extern unsigned int machine_id;
diff -puN include/asm-x86_64/processor.h~revert-acpi-mwait-c-state-fixes include/asm-x86_64/processor.h
--- a/include/asm-x86_64/processor.h~revert-acpi-mwait-c-state-fixes
+++ a/include/asm-x86_64/processor.h
@@ -475,8 +475,6 @@ static inline void __mwait(unsigned long
 		: :"a" (eax), "c" (ecx));
 }
 
-extern void mwait_idle_with_hints(unsigned long eax, unsigned long ecx);
-
 #define stack_current() \
 ({								\
 	struct thread_info *ti;					\
_


-- 
VGER BF report: H 0

Re: 2.6.18-rc5-mm1

[Dmitry Torokhov]

On Friday 01 September 2006 21:12, Dmitry Torokhov wrote:
> On Friday 01 September 2006 21:06, Grant Coady wrote:
> > On Fri, 1 Sep 2006 01:58:18 -0700, Andrew Morton <akpm@osdl.org> wrote:
> > 
> > >
> > >ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc5/2.6.18-rc5-mm1/
> > ...
> > >- See the `hot-fixes' directory for any important updates to this patchset.
> > >
> > Okay, I applied hotfixes and it crashed on boot, keyboard LEDs flashing:
> > 
> > Repeating message, hand copied:
> > atkbd.c: Spurious ACK in isa0060/serio0. Some program might be trying access 
> > hardware directly.
> > 
> 
> Please try booting with i8042.panicblink=0 to see the real oops (important
> data).

.. or try the patch below.

-- 
Dmitry


Input: i8042 - disable keyboard port when panicking and blinking

This should get rid of "spurious ACK" messages from atkbd driver
during panic.

Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
---

 drivers/input/serio/i8042.c |    7 +++++++
 1 files changed, 7 insertions(+)

Index: work/drivers/input/serio/i8042.c
===================================================================
--- work.orig/drivers/input/serio/i8042.c
+++ work/drivers/input/serio/i8042.c
@@ -836,9 +836,16 @@ static long i8042_panic_blink(long count
 	 */
 	if (!i8042_blink_frequency)
 		return 0;
+
 	if (count - last_blink < i8042_blink_frequency)
 		return 0;
 
+	/*
+	 * Disable keyboard port so ATKBD won't fill logs with
+	 * "spurious ACK" messages
+	 */
+	i8042_ports[I8042_KBD_PORT_NO].exists = 0;
+
 	led ^= 0x01 | 0x04;
 	while (i8042_read_status() & I8042_STR_IBF)
 		DELAY;

-- 
VGER BF report: H 0

Re: 2.6.18-rc5-mm1

[Andrew Morton]

On Sat, 02 Sep 2006 11:06:15 +1000
Grant Coady <gcoady.lk@gmail.com> wrote:

> On Fri, 1 Sep 2006 01:58:18 -0700, Andrew Morton <akpm@osdl.org> wrote:
> 
> >
> >ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc5/2.6.18-rc5-mm1/
> ...
> >- See the `hot-fixes' directory for any important updates to this patchset.
> >
> Okay, I applied hotfixes and it crashed on boot,

There's another hotfix there now:  

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc5/2.6.18-rc5-mm1/hot-fixes/revert-acpi-mwait-c-state-fixes.patch

If that doesn't prevent the crash, please try to get a trace out of it
somehow?

> keyboard LEDs flashing: Repeating message, hand copied:
> atkbd.c: Spurious ACK in isa0060/serio0. Some program might be trying access 

Yes, one of my machine does that when it crashes too.  It makes the crash
information scroll off the screen in about half a second, which isn't very
kernel-developer-friendly.


-- 
VGER BF report: H 2.94209e-15

Re: 2.6.18-rc5-mm1

[Grant Coady]

On Fri, 1 Sep 2006 21:12:18 -0400, Dmitry Torokhov <dtor@insightbb.com> wrote:

>On Friday 01 September 2006 21:06, Grant Coady wrote:
>> On Fri, 1 Sep 2006 01:58:18 -0700, Andrew Morton <akpm@osdl.org> wrote:
>> 
>> >
>> >ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc5/2.6.18-rc5-mm1/
>> ...
>> >- See the `hot-fixes' directory for any important updates to this patchset.
>> >
>> Okay, I applied hotfixes and it crashed on boot, keyboard LEDs flashing:
>> 
>> Repeating message, hand copied:
>> atkbd.c: Spurious ACK in isa0060/serio0. Some program might be trying access 
>> hardware directly.
>> 
>
>Please try booting with i8042.panicblink=0 to see the real oops (important
>data). We should probably disable blinking if X is not active...

Please, yes ;)  I always boot to CLI console, run linux boxen 
mostly headless...

Now it say:
VFS: Cannot open root device "803" or unknown-block(8,3)
Please append a correct "root=" boot option
Kernel panic - not syncing: VFS Unable to mount root fs on unknown-block(8,3)
 _

What next?  (CC akpm removed 'cos bounced)

Grant.

-- 
VGER BF report: H 0

Re: 2.6.18-rc5-mm1

[Grant Coady]

On Fri, 1 Sep 2006 18:39:27 -0700, Andrew Morton <akpm@osdl.org> wrote:

>On Sat, 02 Sep 2006 11:06:15 +1000
>Grant Coady <gcoady.lk@gmail.com> wrote:
>
>> On Fri, 1 Sep 2006 01:58:18 -0700, Andrew Morton <akpm@osdl.org> wrote:
>> 
>> >
>> >ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc5/2.6.18-rc5-mm1/
>> ...
>> >- See the `hot-fixes' directory for any important updates to this patchset.
>> >
>> Okay, I applied hotfixes and it crashed on boot,
>
>There's another hotfix there now:  
>
>ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc5/2.6.18-rc5-mm1/hot-fixes/revert-acpi-mwait-c-state-fixes.patch
>
>If that doesn't prevent the crash, please try to get a trace out of it
>somehow?
>
>> keyboard LEDs flashing: Repeating message, hand copied:
>> atkbd.c: Spurious ACK in isa0060/serio0. Some program might be trying access 
>
>Yes, one of my machine does that when it crashes too.  It makes the crash
>information scroll off the screen in about half a second, which isn't very
>kernel-developer-friendly.

Dmitry's patch stopped the LEDs but gave VFS no root device error, make no 
sense to me so I start over...

Apply 2.6.18-rc5-mm1, then:
File: drivers-md-kconfig-fix-block-dependency.patch
File: provide-kernel_execve-on-all-architectures-fix-2.patch
File: provide-kernel_execve-on-all-architectures-fix-3.patch
File: revert-acpi-mwait-c-state-fixes.patch
File: revert-ide-hpa-resume-fix.patch

Falls over, looping, after a VFS no root message :(

Apply Dmitry's patch...

Okay, we're not doing the silly looping:

Error is same as previously reported.

A couple blank menu screens in other areas, make oldconfig doesn't :(

WTF happened to SATA support?  Where's it hiding now?  Found it...

Okay, boots --> Needs Dmitry's non-looping patch so errors don't scroll off 
screen.  Problem was SATA moved to new window and `make oldconfig` didn't ;)

Grant.

-- 
VGER BF report: H 6.04481e-06

Re: 2.6.18-rc5-mm1

[Jeremy Fitzhardinge]

Jeremy Fitzhardinge wrote:
> The NULL EIP is desc->handle_irq in do_IRQ():
>
>         asm volatile(
>             "       xchgl  %%ebx,%%esp      \n"
>             "       call   *%%edi           \n"
>             "       movl   %%ebx,%%esp      \n"
>             : "=a" (arg1), "=d" (arg2), "=c" (arg3), "=b" (ebx)
>             :  "0" (irq),   "1" (desc),  "2" (regs),  "3" (isp),
>                "D" (desc->handle_irq)
>             : "memory", "cc"
>         );
>
> In my case, the IRQ is 0xdb = 219, which is an MSI interrupt for 
> libata (the AHCI SATA controller, presumably).  The exception happens 
> just after the SATA driver has probed all the hard disks.
>
> So it seems to me that the suspects are 1) sata, or 2) MSI.  I'll try 
> turning off MSI to see if it helps.

Yes, that fixed it; with MSI disabled I can boot successfully.

: ezr:pts/0; cd hg/linux-2.6/patches/broken-out/
: ezr:pts/0; ls *msi* | wc -l
23

Hm, where to start...

    J

-- 
VGER BF report: H 0

Re: 2.6.18-rc5-mm1

[Greg KH]

On Sat, Sep 02, 2006 at 01:37:13AM -0700, Jeremy Fitzhardinge wrote:
> Jeremy Fitzhardinge wrote:
> >The NULL EIP is desc->handle_irq in do_IRQ():
> >
> >        asm volatile(
> >            "       xchgl  %%ebx,%%esp      \n"
> >            "       call   *%%edi           \n"
> >            "       movl   %%ebx,%%esp      \n"
> >            : "=a" (arg1), "=d" (arg2), "=c" (arg3), "=b" (ebx)
> >            :  "0" (irq),   "1" (desc),  "2" (regs),  "3" (isp),
> >               "D" (desc->handle_irq)
> >            : "memory", "cc"
> >        );
> >
> >In my case, the IRQ is 0xdb = 219, which is an MSI interrupt for 
> >libata (the AHCI SATA controller, presumably).  The exception happens 
> >just after the SATA driver has probed all the hard disks.
> >
> >So it seems to me that the suspects are 1) sata, or 2) MSI.  I'll try 
> >turning off MSI to see if it helps.
> 
> Yes, that fixed it; with MSI disabled I can boot successfully.
> 
> : ezr:pts/0; cd hg/linux-2.6/patches/broken-out/
> : ezr:pts/0; ls *msi* | wc -l
> 23
> 
> Hm, where to start...

There are 9 MSI patches in my tree that you can just remove.  They were
just recently (a few hours ago) replaced with a total rewrite due to a
number of different problems that were found.  So I'd suggest just
waiting till the next -mm release to see if it works properly or not.

thanks,

greg k-h

-- 
VGER BF report: H 0

Re: 2.6.18-rc5-mm1

[Jeremy Fitzhardinge]

Greg KH wrote:
> There are 9 MSI patches in my tree that you can just remove.  They were
> just recently (a few hours ago) replaced with a total rewrite due to a
> number of different problems that were found.  So I'd suggest just
> waiting till the next -mm release to see if it works properly or not.
>   

This lot?

gregkh-pci-msi-01-merge_msi_disabling_quirks.patch
gregkh-pci-msi-02-factorize_pci_msi_supported.patch
gregkh-pci-msi-03-add_pci_device_exp_type.patch
gregkh-pci-msi-04-use_root_chipset_dev_no_msi_instead_of_pci_bus_flags.patch
gregkh-pci-msi-05-add_no_msi_to_sysfs.patch
gregkh-pci-msi-06-rename_pci_cap_id_ht_irqconf.patch
gregkh-pci-msi-07-check_hypertransport_msi_capabilities.patch
gregkh-pci-msi-08-drop_pci_msi_quirk.patch
gregkh-pci-msi-09-drop_pci_bus_flags.patch

    J

-- 
VGER BF report: H 0

Re: 2.6.18-rc5-mm1

[Greg KH]

On Sat, Sep 02, 2006 at 01:47:43AM -0700, Jeremy Fitzhardinge wrote:
> Greg KH wrote:
> >There are 9 MSI patches in my tree that you can just remove.  They were
> >just recently (a few hours ago) replaced with a total rewrite due to a
> >number of different problems that were found.  So I'd suggest just
> >waiting till the next -mm release to see if it works properly or not.
> >  
> 
> This lot?
> 
> gregkh-pci-msi-01-merge_msi_disabling_quirks.patch
> gregkh-pci-msi-02-factorize_pci_msi_supported.patch
> gregkh-pci-msi-03-add_pci_device_exp_type.patch
> gregkh-pci-msi-04-use_root_chipset_dev_no_msi_instead_of_pci_bus_flags.patch
> gregkh-pci-msi-05-add_no_msi_to_sysfs.patch
> gregkh-pci-msi-06-rename_pci_cap_id_ht_irqconf.patch
> gregkh-pci-msi-07-check_hypertransport_msi_capabilities.patch
> gregkh-pci-msi-08-drop_pci_msi_quirk.patch
> gregkh-pci-msi-09-drop_pci_bus_flags.patch

Yes, try reverting them and see if your machine works again.

thanks,

greg k-h

-- 
VGER BF report: H 0

Re: 2.6.18-rc5-mm1

[Philippe Gramoullé]

Hello Andrew,

On Fri, 1 Sep 2006 01:58:18 -0700
Andrew Morton <akpm@osdl.org> wrote:

  | ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc5/2.6.18-rc5-mm1/

2.6.18-rc5-mm1 doesn't build whereas 2.6.18-rc5 does.

p4:/usr/src/linux-2.6.17# make bzImage
  CHK     include/linux/version.h
  CHK     include/linux/utsrelease.h
  CHK     include/linux/compile.h
  CC      arch/i386/kernel/sys_i386.o
arch/i386/kernel/sys_i386.c: In function 'kernel_execve':
arch/i386/kernel/sys_i386.c:262: error: '__NR_execve' undeclared (first use in this function)
arch/i386/kernel/sys_i386.c:262: error: (Each undeclared identifier is reported only once
arch/i386/kernel/sys_i386.c:262: error: for each function it appears in.)
make[1]: *** [arch/i386/kernel/sys_i386.o] Error 1
make: *** [arch/i386/kernel] Error 2


P4 x86

Thanks,

Philippe

-- 
VGER BF report: H 1.56412e-06

Re: 2.6.18-rc5-mm1

[Jeremy Fitzhardinge]

Greg KH wrote:
> Yes, try reverting them and see if your machine works again.
>   

Reverting them makes the machine work, with basically the same effect as 
disabling CONFIG_PCI_MSI: no MSI interrupts appear in /proc/interrupts, 
and e1000 & libata are using IO-APIC-fasteoi.  So, a reasonable result 
for now.

Thanks,
    J

-- 
VGER BF report: H 0

Re: 2.6.18-rc5-mm1

[Jeff Garzik]

Jeremy Fitzhardinge wrote:
> Greg KH wrote:
>> Yes, try reverting them and see if your machine works again.
>>   
> 
> Reverting them makes the machine work, with basically the same effect as 
> disabling CONFIG_PCI_MSI: no MSI interrupts appear in /proc/interrupts, 
> and e1000 & libata are using IO-APIC-fasteoi.  So, a reasonable result 
> for now.

Did you re-enable CONFIG_PCI_MSI, after reverting the patches?

	Jeff




-- 
VGER BF report: H 0

Re: 2.6.18-rc5-mm1

[Jeremy Fitzhardinge]

Jeff Garzik wrote:
>>
>> Reverting them makes the machine work, with basically the same effect 
>> as disabling CONFIG_PCI_MSI: no MSI interrupts appear in 
>> /proc/interrupts, and e1000 & libata are using IO-APIC-fasteoi.  So, 
>> a reasonable result for now.
>
> Did you re-enable CONFIG_PCI_MSI, after reverting the patches?

Yes.  Er.  Hm, perhaps not, it didn't build:

  CC      drivers/pci/htirq.o
drivers/pci/htirq.c: In function 'ht_create_irq':
drivers/pci/htirq.c:126: error: 'PCI_CAP_ID_HT' undeclared (first use in this function)
drivers/pci/htirq.c:126: error: (Each undeclared identifier is reported only once
drivers/pci/htirq.c:126: error: for each function it appears in.)

I'll try again with CONFIG_HT_IRQ disabled...

    J


-- 
VGER BF report: H 0

Re: 2.6.18-rc5-mm1

[Jeremy Fitzhardinge]

Jeff Garzik wrote:
> Did you re-enable CONFIG_PCI_MSI, after reverting the patches?

Hm, still doesn't link with The GregKH Nine removed but CONFIG_MSI:

drivers/built-in.o: In function `pci_enable_msix':
drivers/pci/msi.c:956: undefined reference to `pci_msi_supported'

I'll just do without for now.

    J

-- 
VGER BF report: H 0

Re: 2.6.18-rc5-mm1

[Stefan Richter]

Philippe Gramoullé wrote:
...
>   | ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc5/2.6.18-rc5-mm1/
> 
> 2.6.18-rc5-mm1 doesn't build whereas 2.6.18-rc5 does.
...
> arch/i386/kernel/sys_i386.c:262: error: '__NR_execve' undeclared (first use in this function)
...

Also apply the hot-fixes from above FTP link.
-- 
Stefan Richter
-=====-=-==- =--= ---=-
http://arcgraph.de/sr/

-- 
VGER BF report: H 0

Re: 2.6.18-rc5-mm1

[Philippe Gramoullé]

Hello Stefan,

Thanks for the hint, it's building fine now.

Philippe

On Sat, 02 Sep 2006 13:40:55 +0200
Stefan Richter <stefanr@s5r6.in-berlin.de> wrote:

  | Philippe Gramoullé wrote:
  | ...
  | >   | ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc5/2.6.18-rc5-mm1/
  | > 
  | > 2.6.18-rc5-mm1 doesn't build whereas 2.6.18-rc5 does.
  | ...
  | > arch/i386/kernel/sys_i386.c:262: error: '__NR_execve' undeclared (first use in this function)
  | ...
  | 
  | Also apply the hot-fixes from above FTP link.
  | -- 
  | Stefan Richter
  | -=====-=-==- =--= ---=-
  | http://arcgraph.de/sr/

-- 
VGER BF report: H 0

Re: 2.6.18-rc5-mm1

[Grant Coady]

On Sat, 02 Sep 2006 13:51:04 +1000, Grant Coady <gcoady.lk@gmail.com> wrote:

>-- 
>VGER BF report: H 6.04481e-06
                 ^^^^^^^^^^^^^--> perhaps whoever is adding this info-gem 
can add a sane sprintf?  The boggle minds ;)

Grant.

-- 
VGER BF report: H 0.00423726

Re: "VGER BF report:.." ?

[Matti Aarnio]

On Sun, Sep 03, 2006 at 06:20:01AM +1000, Grant Coady wrote:
> On Sat, 02 Sep 2006 13:51:04 +1000, Grant Coady <gcoady.lk@gmail.com> wrote:
> >-- 
> >VGER BF report: H 6.04481e-06
>                  ^^^^^^^^^^^^^--> perhaps whoever is adding this info-gem 
> can add a sane sprintf?  The boggle minds ;)
> 
> Grant.
> -- 
> VGER BF report: H 0.00423726

  That is  "bogofilter -T" giving that result.
Presently it is there to debug things and to see what leaked
(unrecognized) spams got..   But my intention is to remove it
quite soon -- say, on monday.

   /Matti Aarnio  -- one of <postmaster@vger.kernel.org>

-- 
VGER BF report: U 0.5

[2.6.18-rc5-mm1 ACPI] Unknown exception code: 0xFFFFFFEA

[Mike Galbraith]

Greetings,

My single P4/HT box tossed the below on boot.

	-Mike

ACPI Error (utglobal-0125): Unknown exception code: 0xFFFFFFEA [20060707]
 [<c1004089>] dump_trace+0x1d7/0x206
 [<c10040d2>] show_trace_log_lvl+0x1a/0x30
 [<c100484c>] show_trace+0x12/0x14
 [<c100496d>] dump_stack+0x19/0x1b
 [<c1229702>] acpi_format_exception+0xa2/0xaf
 [<c1226824>] acpi_ut_status_exit+0x2b/0x58
 [<c1222cbc>] acpi_walk_resources+0xfd/0x109
 [<c12393ca>] acpi_motherboard_add+0x22/0x32
 [<c123848e>] acpi_bus_driver_init+0x2a/0x7a
 [<c123892c>] acpi_bus_register_driver+0x8b/0xfb
 [<c15ebd20>] acpi_motherboard_init+0xd/0xf9
 [<c10003b1>] init+0x108/0x300
 [<c1003c93>] kernel_thread_helper+0x7/0x14
 =======================
ACPI Error (utglobal-0125): Unknown exception code: 0xFFFFFFEA [20060707]
 [<c1004089>] dump_trace+0x1d7/0x206
 [<c10040d2>] show_trace_log_lvl+0x1a/0x30
 [<c100484c>] show_trace+0x12/0x14
 [<c100496d>] dump_stack+0x19/0x1b
 [<c1229702>] acpi_format_exception+0xa2/0xaf
 [<c1226824>] acpi_ut_status_exit+0x2b/0x58
 [<c1222cbc>] acpi_walk_resources+0xfd/0x109
 [<c12393ca>] acpi_motherboard_add+0x22/0x32
 [<c123848e>] acpi_bus_driver_init+0x2a/0x7a
 [<c123892c>] acpi_bus_register_driver+0x8b/0xfb
 [<c15ebd2a>] acpi_motherboard_init+0x17/0xf9
 [<c10003b1>] init+0x108/0x300
 [<c1003c93>] kernel_thread_helper+0x7/0x14
 =======================
ACPI Error (utglobal-0125): Unknown exception code: 0xFFFFFFEA [20060707]
 [<c1004089>] dump_trace+0x1d7/0x206
 [<c10040d2>] show_trace_log_lvl+0x1a/0x30
 [<c100484c>] show_trace+0x12/0x14
 [<c100496d>] dump_stack+0x19/0x1b
 [<c1229702>] acpi_format_exception+0xa2/0xaf
 [<c1226824>] acpi_ut_status_exit+0x2b/0x58
 [<c1222cbc>] acpi_walk_resources+0xfd/0x109
 [<c12393ca>] acpi_motherboard_add+0x22/0x32
 [<c123848e>] acpi_bus_driver_init+0x2a/0x7a
 [<c123892c>] acpi_bus_register_driver+0x8b/0xfb
 [<c15ebd2a>] acpi_motherboard_init+0x17/0xf9
 [<c10003b1>] init+0x108/0x300
 [<c1003c93>] kernel_thread_helper+0x7/0x14
 =======================



-- 
VGER BF report: U 0.500346

[2.6.18-rc5-mm1 ACPI] Unknown exception code: 0xFFFFFFEA

[Mike Galbraith]

Greetings,

My single P4/HT box tossed the below on boot.

	-Mike

ACPI Error (utglobal-0125): Unknown exception code: 0xFFFFFFEA [20060707]
 [<c1004089>] dump_trace+0x1d7/0x206
 [<c10040d2>] show_trace_log_lvl+0x1a/0x30
 [<c100484c>] show_trace+0x12/0x14
 [<c100496d>] dump_stack+0x19/0x1b
 [<c1229702>] acpi_format_exception+0xa2/0xaf
 [<c1226824>] acpi_ut_status_exit+0x2b/0x58
 [<c1222cbc>] acpi_walk_resources+0xfd/0x109
 [<c12393ca>] acpi_motherboard_add+0x22/0x32
 [<c123848e>] acpi_bus_driver_init+0x2a/0x7a
 [<c123892c>] acpi_bus_register_driver+0x8b/0xfb
 [<c15ebd20>] acpi_motherboard_init+0xd/0xf9
 [<c10003b1>] init+0x108/0x300
 [<c1003c93>] kernel_thread_helper+0x7/0x14
 =======================
ACPI Error (utglobal-0125): Unknown exception code: 0xFFFFFFEA [20060707]
 [<c1004089>] dump_trace+0x1d7/0x206
 [<c10040d2>] show_trace_log_lvl+0x1a/0x30
 [<c100484c>] show_trace+0x12/0x14
 [<c100496d>] dump_stack+0x19/0x1b
 [<c1229702>] acpi_format_exception+0xa2/0xaf
 [<c1226824>] acpi_ut_status_exit+0x2b/0x58
 [<c1222cbc>] acpi_walk_resources+0xfd/0x109
 [<c12393ca>] acpi_motherboard_add+0x22/0x32
 [<c123848e>] acpi_bus_driver_init+0x2a/0x7a
 [<c123892c>] acpi_bus_register_driver+0x8b/0xfb
 [<c15ebd2a>] acpi_motherboard_init+0x17/0xf9
 [<c10003b1>] init+0x108/0x300
 [<c1003c93>] kernel_thread_helper+0x7/0x14
 =======================
ACPI Error (utglobal-0125): Unknown exception code: 0xFFFFFFEA [20060707]
 [<c1004089>] dump_trace+0x1d7/0x206
 [<c10040d2>] show_trace_log_lvl+0x1a/0x30
 [<c100484c>] show_trace+0x12/0x14
 [<c100496d>] dump_stack+0x19/0x1b
 [<c1229702>] acpi_format_exception+0xa2/0xaf
 [<c1226824>] acpi_ut_status_exit+0x2b/0x58
 [<c1222cbc>] acpi_walk_resources+0xfd/0x109
 [<c12393ca>] acpi_motherboard_add+0x22/0x32
 [<c123848e>] acpi_bus_driver_init+0x2a/0x7a
 [<c123892c>] acpi_bus_register_driver+0x8b/0xfb
 [<c15ebd2a>] acpi_motherboard_init+0x17/0xf9
 [<c10003b1>] init+0x108/0x300
 [<c1003c93>] kernel_thread_helper+0x7/0x14
 =======================



-- 
VGER BF report: H 0.00749888

Re: "VGER BF report:.." ?

[Jan Engelhardt]

>> >-- 
>> >VGER BF report: H 6.04481e-06
>>                  ^^^^^^^^^^^^^--> perhaps whoever is adding this info-gem 
>> can add a sane sprintf?  The boggle minds ;)

Sane? That's just sprintf("%e") - simple, is not it?
If you are not scientifically gifted, 6.04481 * 10^-6 may be more readable 
to you ;-)

>VGER BF report: U 0.5

Hm, what's "H" (ham?) and "U" standing for?



Jan Engelhardt
-- 

-- 
VGER BF report: U 0.499957

2.6.18-rc5-mm1: sysfs_init() related compile error

[Adrian Bunk]

I'm getting the following compile error on h8300:

<--  snip  -->

...
  CC      arch/h8300/kernel/asm-offsets.s
In file included from /home/bunk/linux/kernel-2.6/linux-2.6.18-rc5-mm1/include/linux/kobject.h:22,
                 from /home/bunk/linux/kernel-2.6/linux-2.6.18-rc5-mm1/include/linux/sysdev.h:24,
                 from /home/bunk/linux/kernel-2.6/linux-2.6.18-rc5-mm1/include/linux/sched.h:1605,
                 from /home/bunk/linux/kernel-2.6/linux-2.6.18-rc5-mm1/arch/h8300/kernel/asm-offsets.c:12:
/home/bunk/linux/kernel-2.6/linux-2.6.18-rc5-mm1/include/linux/sysfs.h:210: error: redefinition of 'sysfs_init'
/home/bunk/linux/kernel-2.6/linux-2.6.18-rc5-mm1/include/linux/sysfs.h:136: error: previous definition of 'sysfs_init' was here
make[2]: *** [arch/h8300/kernel/asm-offsets.s] Error 1

<--  snip  -->

The problem is a merge conflict since both git-block.patch and 
gregkh-driver-sysfs-add-proper-sysfs_init-prototype.patch added
sysfs_init() prototypes and CONFIG_SYSFS=n dummmies to sysfs.h .

The git-block.patch version lacks the __must_check annotation.

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


-- 
VGER BF report: H 0.332312

Re: "VGER BF report:.." ?

[Grant Coady]

On Sun, 3 Sep 2006 17:06:27 +0200 (MEST), Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:

>
>>> >-- 
>>> >VGER BF report: H 6.04481e-06
>>>                  ^^^^^^^^^^^^^--> perhaps whoever is adding this info-gem 
>>> can add a sane sprintf?  The boggle minds ;)
>
>Sane? That's just sprintf("%e") - simple, is not it?

Not my point.  The value could be rounded to 2 or three digit value for 
display, perhaps a 2 digit percentage?  The example may as well be zero.

Grant.

-- 
VGER BF report: H 0.126501

2.6.18-rc5-mm1: MMU=n compile error

[Adrian Bunk]

mm-tracking-shared-dirty-pages.patch breaks CONFIG_MMU=n architectures:

<--  snip  -->

...
  CC      mm/page-writeback.o
/home/bunk/linux/kernel-2.6/linux-2.6.18-rc5-mm1/mm/page-writeback.c: In function 'test_clear_page_dirty':
/home/bunk/linux/kernel-2.6/linux-2.6.18-rc5-mm1/mm/page-writeback.c:867: error: implicit declaration of function 'page_mkclean'
make[2]: *** [mm/page-writeback.o] Error 1

<--  snip  -->

cu
Adrian

BTW: @Andrew:
     The Cc: line in mm-tracking-shared-dirty-pages.patch is busted.

-- 

       "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


-- 
VGER BF report: H 0.00135769

Lost DVD-RW [Was Re: 2.6.18-rc5-mm1]

[J.A. Magallón]

On Fri, 1 Sep 2006 01:58:18 -0700, Andrew Morton <akpm@osdl.org> wrote:

> 
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc5/2.6.18-rc5-mm1/
> 

Err, my burner got lost this summer ;).
This is really not a bug of _this_ kernel, because I noticed it dissapeared
with the previous release also, just before going on vacation... But as it
did not come back with this relase, I report it here.

Last kernel that I have tried that worked was 2.6.18-rc2-mm1. With this
relase, it is gone still. dmesg for both kernels is below.
The only thing I hace noticed is the different IRQ assignment between
them.

Any ideas ? TIA.

dmesg for rc2-mm1:

libata version 2.00 loaded.
ata_piix 0000:00:1f.1: version 2.00ac6
ACPI: PCI Interrupt 0000:00:1f.1[A] -> GSI 18 (level, low) -> IRQ 16
PCI: Setting latency timer of device 0000:00:1f.1 to 64
ata1: PATA max UDMA/100 cmd 0x1F0 ctl 0x3F6 bmdma 0xF000 irq 14
ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xF008 irq 14
scsi0 : ata_piix
ata1.00: ATAPI, max UDMA/33
ata1.01: ATAPI, max MWDMA0, CDB intr
ata1.00: configured for UDMA/33
ata1.01: configured for PIO3
scsi1 : ata_piix
ata2.00: ATA-6, max UDMA/100, 234441648 sectors: LBA48
ata2.00: ata2: dev 0 multi count 16
ata2.01: ATAPI, max UDMA/33
ata2.00: configured for UDMA/100
ata2.01: configured for UDMA/33
  Vendor: HL-DT-ST  Model: DVDRAM GSA-4120B  Rev: A111
  Type:   CD-ROM                             ANSI SCSI revision: 05
  Vendor: IOMEGA    Model: ZIP 250           Rev: 51.G
  Type:   Direct-Access                      ANSI SCSI revision: 05
  Vendor: ATA       Model: ST3120022A        Rev: 3.06
  Type:   Direct-Access                      ANSI SCSI revision: 05
  Vendor: TOSHIBA   Model: DVD-ROM SD-M1712  Rev: 1004
  Type:   CD-ROM                             ANSI SCSI revision: 05
ata_piix 0000:00:1f.2: MAP [ P0 -- P1 -- ]
ACPI: PCI Interrupt 0000:00:1f.2[A] -> GSI 18 (level, low) -> IRQ 16
PCI: Setting latency timer of device 0000:00:1f.2 to 64
ata3: SATA max UDMA/133 cmd 0xC000 ctl 0xC402 bmdma 0xD000 irq 16
ata4: SATA max UDMA/133 cmd 0xC800 ctl 0xCC02 bmdma 0xD008 irq 16
...

dmesg for rc5-mm1:

libata version 2.00 loaded.
ata_piix 0000:00:1f.1: version 2.00ac7
ACPI: PCI Interrupt 0000:00:1f.1[A] -> GSI 18 (level, low) -> IRQ 16
PCI: Setting latency timer of device 0000:00:1f.1 to 64
ata1: PATA max UDMA/100 cmd 0x1F0 ctl 0x3F6 bmdma 0xF000 irq 14
ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xF008 irq 15
scsi0 : ata_piix
ata1.00: failed to IDENTIFY (device reports illegal type, err_mask=0x0)
ata1.01: ATAPI, max MWDMA0, CDB intr
ata1.01: configured for PIO3
scsi1 : ata_piix
ata2.00: ATA-6, max UDMA/100, 234441648 sectors: LBA48
ata2.00: ata2: dev 0 multi count 16
ata2.01: ATAPI, max UDMA/33
ata2.00: configured for UDMA/100
ata2.01: configured for UDMA/33
scsi 0:0:1:0: Direct-Access     IOMEGA   ZIP 250          51.G PQ: 0 ANSI: 5
sd 0:0:1:0: Attached scsi removable disk sda
scsi 1:0:0:0: Direct-Access     ATA      ST3120022A       3.06 PQ: 0 ANSI: 5
SCSI device sdb: 234441648 512-byte hdwr sectors (120034 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 3a 00 00
SCSI device sdb: drive cache: write back
SCSI device sdb: 234441648 512-byte hdwr sectors (120034 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 3a 00 00
SCSI device sdb: drive cache: write back
 sdb: sdb1
sd 1:0:0:0: Attached scsi disk sdb
scsi 1:0:1:0: CD-ROM            TOSHIBA  DVD-ROM SD-M1712 1004 PQ: 0 ANSI: 5
sr0: scsi3-mmc drive: 48x/48x cd/rw xa/form2 cdda tray
Uniform CD-ROM driver Revision: 3.20
sr 1:0:1:0: Attached scsi CD-ROM sr0
ata_piix 0000:00:1f.2: MAP [ P0 -- P1 -- ]
ACPI: PCI Interrupt 0000:00:1f.2[A] -> GSI 18 (level, low) -> IRQ 16
PCI: Setting latency timer of device 0000:00:1f.2 to 64
ata3: SATA max UDMA/133 cmd 0xC000 ctl 0xC402 bmdma 0xD000 irq 16
ata4: SATA max UDMA/133 cmd 0xC800 ctl 0xCC02 bmdma 0xD008 irq 16


--
J.A. Magallon <jamagallon()ono!com>     \               Software is like sex:
                                         \         It's better when it's free
Mandriva Linux release 2007.0 (Cooker) for i586
Linux 2.6.17-jam08 (gcc 4.1.1 20060724 (prerelease) (4.1.1-3mdk)) #1 SMP PREEMPT

-- 
VGER BF report: U 0.5

Re: Lost DVD-RW [Was Re: 2.6.18-rc5-mm1]

[Andrew Morton]

On Mon, 4 Sep 2006 01:34:43 +0200
"J.A. Magallón" <jamagallon@ono.com> wrote:

> On Fri, 1 Sep 2006 01:58:18 -0700, Andrew Morton <akpm@osdl.org> wrote:
> 
> > 
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc5/2.6.18-rc5-mm1/
> > 
> 
> Err, my burner got lost this summer ;).
> This is really not a bug of _this_ kernel, because I noticed it dissapeared
> with the previous release also, just before going on vacation... But as it
> did not come back with this relase, I report it here.
> 
> Last kernel that I have tried that worked was 2.6.18-rc2-mm1. With this
> relase, it is gone still. dmesg for both kernels is below.
> The only thing I hace noticed is the different IRQ assignment between
> them.
> 
> Any ideas ? TIA.
> 
> dmesg for rc2-mm1:
> 
> libata version 2.00 loaded.
> ata_piix 0000:00:1f.1: version 2.00ac6
> ACPI: PCI Interrupt 0000:00:1f.1[A] -> GSI 18 (level, low) -> IRQ 16
> PCI: Setting latency timer of device 0000:00:1f.1 to 64
> ata1: PATA max UDMA/100 cmd 0x1F0 ctl 0x3F6 bmdma 0xF000 irq 14
> ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xF008 irq 14
> scsi0 : ata_piix
> ata1.00: ATAPI, max UDMA/33
> ata1.01: ATAPI, max MWDMA0, CDB intr
> ata1.00: configured for UDMA/33
> ata1.01: configured for PIO3
> scsi1 : ata_piix
> ata2.00: ATA-6, max UDMA/100, 234441648 sectors: LBA48
> ata2.00: ata2: dev 0 multi count 16
> ata2.01: ATAPI, max UDMA/33
> ata2.00: configured for UDMA/100
> ata2.01: configured for UDMA/33
>   Vendor: HL-DT-ST  Model: DVDRAM GSA-4120B  Rev: A111
>   Type:   CD-ROM                             ANSI SCSI revision: 05
>   Vendor: IOMEGA    Model: ZIP 250           Rev: 51.G
>   Type:   Direct-Access                      ANSI SCSI revision: 05
>   Vendor: ATA       Model: ST3120022A        Rev: 3.06
>   Type:   Direct-Access                      ANSI SCSI revision: 05
>   Vendor: TOSHIBA   Model: DVD-ROM SD-M1712  Rev: 1004
>   Type:   CD-ROM                             ANSI SCSI revision: 05
> ata_piix 0000:00:1f.2: MAP [ P0 -- P1 -- ]
> ACPI: PCI Interrupt 0000:00:1f.2[A] -> GSI 18 (level, low) -> IRQ 16
> PCI: Setting latency timer of device 0000:00:1f.2 to 64
> ata3: SATA max UDMA/133 cmd 0xC000 ctl 0xC402 bmdma 0xD000 irq 16
> ata4: SATA max UDMA/133 cmd 0xC800 ctl 0xCC02 bmdma 0xD008 irq 16
> ...
> 
> dmesg for rc5-mm1:
> 
> libata version 2.00 loaded.
> ata_piix 0000:00:1f.1: version 2.00ac7
> ACPI: PCI Interrupt 0000:00:1f.1[A] -> GSI 18 (level, low) -> IRQ 16
> PCI: Setting latency timer of device 0000:00:1f.1 to 64
> ata1: PATA max UDMA/100 cmd 0x1F0 ctl 0x3F6 bmdma 0xF000 irq 14
> ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xF008 irq 15
> scsi0 : ata_piix
> ata1.00: failed to IDENTIFY (device reports illegal type, err_mask=0x0)
> ata1.01: ATAPI, max MWDMA0, CDB intr
> ata1.01: configured for PIO3
> scsi1 : ata_piix
> ata2.00: ATA-6, max UDMA/100, 234441648 sectors: LBA48
> ata2.00: ata2: dev 0 multi count 16
> ata2.01: ATAPI, max UDMA/33
> ata2.00: configured for UDMA/100
> ata2.01: configured for UDMA/33
> scsi 0:0:1:0: Direct-Access     IOMEGA   ZIP 250          51.G PQ: 0 ANSI: 5
> sd 0:0:1:0: Attached scsi removable disk sda
> scsi 1:0:0:0: Direct-Access     ATA      ST3120022A       3.06 PQ: 0 ANSI: 5
> SCSI device sdb: 234441648 512-byte hdwr sectors (120034 MB)
> sdb: Write Protect is off
> sdb: Mode Sense: 00 3a 00 00
> SCSI device sdb: drive cache: write back
> SCSI device sdb: 234441648 512-byte hdwr sectors (120034 MB)
> sdb: Write Protect is off
> sdb: Mode Sense: 00 3a 00 00
> SCSI device sdb: drive cache: write back
>  sdb: sdb1
> sd 1:0:0:0: Attached scsi disk sdb
> scsi 1:0:1:0: CD-ROM            TOSHIBA  DVD-ROM SD-M1712 1004 PQ: 0 ANSI: 5
> sr0: scsi3-mmc drive: 48x/48x cd/rw xa/form2 cdda tray
> Uniform CD-ROM driver Revision: 3.20
> sr 1:0:1:0: Attached scsi CD-ROM sr0
> ata_piix 0000:00:1f.2: MAP [ P0 -- P1 -- ]
> ACPI: PCI Interrupt 0000:00:1f.2[A] -> GSI 18 (level, low) -> IRQ 16
> PCI: Setting latency timer of device 0000:00:1f.2 to 64
> ata3: SATA max UDMA/133 cmd 0xC000 ctl 0xC402 bmdma 0xD000 irq 16
> ata4: SATA max UDMA/133 cmd 0xC800 ctl 0xCC02 bmdma 0xD008 irq 16
> 

Please, try to cc the relevant developers on bug reports.

Thanks.

-- 
VGER BF report: H 0

Re: Lost DVD-RW [Was Re: 2.6.18-rc5-mm1]

[Tejun Heo]

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

Andrew Morton wrote:
> On Mon, 4 Sep 2006 01:34:43 +0200
> "J.A. Magallón" <jamagallon@ono.com> wrote:
> 
>> On Fri, 1 Sep 2006 01:58:18 -0700, Andrew Morton <akpm@osdl.org> wrote:
>>
>>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc5/2.6.18-rc5-mm1/
>>>
>> Err, my burner got lost this summer ;).
>> This is really not a bug of _this_ kernel, because I noticed it dissapeared
>> with the previous release also, just before going on vacation... But as it
>> did not come back with this relase, I report it here.
>>
>> Last kernel that I have tried that worked was 2.6.18-rc2-mm1. With this
>> relase, it is gone still. dmesg for both kernels is below.
>> The only thing I hace noticed is the different IRQ assignment between
>> them.
>>
>> Any ideas ? TIA.
>>
>> dmesg for rc2-mm1:
>> scsi0 : ata_piix
>> ata1.00: ATAPI, max UDMA/33
>> ata1.01: ATAPI, max MWDMA0, CDB intr
>> ata1.00: configured for UDMA/33
>> ata1.01: configured for PIO3
>>   Vendor: HL-DT-ST  Model: DVDRAM GSA-4120B  Rev: A111
>>   Type:   CD-ROM                             ANSI SCSI revision: 05
>>   Vendor: IOMEGA    Model: ZIP 250           Rev: 51.G
>>   Type:   Direct-Access                      ANSI SCSI revision: 05
>>
>> dmesg for rc5-mm1:
>> ata1.00: failed to IDENTIFY (device reports illegal type, err_mask=0x0)

Hmmm... Strange.

The related code hasn't changed much between rc2-mm1 and rc5-mm1.  We're 
talking about 2.6.18-rc2-mm1 and 2.6.18-rc5-mm1, right?

Can you try the attached patch and report what the kernel says?


-- 
tejun

[-- Attachment #2: patch --]
[-- Type: text/plain, Size: 544 bytes --]

diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 1c93154..af2fc6f 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -1276,6 +1276,8 @@ int ata_dev_read_id(struct ata_device *d
 	swap_buf_le16(id, ATA_ID_WORDS);
 
 	/* sanity check */
+	ata_dev_printk(dev, KERN_INFO, "XXX class=%d is_ata=%d is_cfa=%d\n",
+		       class, ata_id_is_ata(id), ata_id_is_cfa(id));
 	if ((class == ATA_DEV_ATA) != (ata_id_is_ata(id) | ata_id_is_cfa(id))) {
 		rc = -EINVAL;
 		reason = "device reports illegal type";

Re: 2.6.18-rc5-mm1: MMU=n compile error

[Peter Zijlstra]

On Mon, 2006-09-04 at 00:17 +0200, Adrian Bunk wrote:
> mm-tracking-shared-dirty-pages.patch breaks CONFIG_MMU=n architectures:
> 
> <--  snip  -->
> 
> ....
>   CC      mm/page-writeback.o
> /home/bunk/linux/kernel-2.6/linux-2.6.18-rc5-mm1/mm/page-writeback.c: In function 'test_clear_page_dirty':
> /home/bunk/linux/kernel-2.6/linux-2.6.18-rc5-mm1/mm/page-writeback.c:867: error: implicit declaration of function 'page_mkclean'
> make[2]: *** [mm/page-writeback.o] Error 1

This might fix it, but I don't have a cross compiler for any nommu arch,
nor an emulator so I can't test. - Will try to build me a toolchain but
this could take some time.

Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
---
 include/linux/rmap.h |    2 ++
 1 file changed, 2 insertions(+)

Index: linux-mm/include/linux/rmap.h
===================================================================
--- linux-mm.orig/include/linux/rmap.h	2006-09-04 08:31:57.000000000 +0200
+++ linux-mm/include/linux/rmap.h	2006-09-04 08:33:44.000000000 +0200
@@ -120,6 +120,8 @@ int page_mkclean(struct page *);
 #define page_referenced(page,l) TestClearPageReferenced(page)
 #define try_to_unmap(page, refs) SWAP_FAIL
 
+#define page_mkclean(page)	(0)
+
 #endif	/* CONFIG_MMU */
 
 /*



-- 
VGER BF report: H 0.393012

2.6.18-rc5-mm1: is_init() parisc compile error

[Adrian Bunk]

pidspace-is_init.patch causes the following compile error on parisc:

<--  snip  -->

...
  CC      arch/parisc/kernel/module.o
/home/bunk/linux/kernel-2.6/linux-2.6.18-rc5-mm1/arch/parisc/kernel/module.c:76: error: conflicting types for 'is_init'
/home/bunk/linux/kernel-2.6/linux-2.6.18-rc5-mm1/include/linux/sched.h:1090: error: previous definition of 'is_init' was here
make[2]: *** [arch/parisc/kernel/module.o] Error 1

<--  snip  -->

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


-- 
VGER BF report: H 2.76804e-05

Re: [parisc-linux] 2.6.18-rc5-mm1: is_init() parisc compile error

[Matthew Wilcox]

On Mon, Sep 04, 2006 at 01:41:30PM +0200, Adrian Bunk wrote:
> pidspace-is_init.patch causes the following compile error on parisc:
> 
> <--  snip  -->
> 
> ...
>   CC      arch/parisc/kernel/module.o
> /home/bunk/linux/kernel-2.6/linux-2.6.18-rc5-mm1/arch/parisc/kernel/module.c:76: error: conflicting types for 'is_init'
> /home/bunk/linux/kernel-2.6/linux-2.6.18-rc5-mm1/include/linux/sched.h:1090: error: previous definition of 'is_init' was here
> make[2]: *** [arch/parisc/kernel/module.o] Error 1
> 
> <--  snip  -->

Looks like ia64 calls the same function in_init().  I'm tempted to
change parisc to have the same name.

Re: 2.6.18-rc5-mm1: MMU=n compile error

[Adrian Bunk]

On Mon, Sep 04, 2006 at 09:44:32AM +0200, Peter Zijlstra wrote:
> On Mon, 2006-09-04 at 00:17 +0200, Adrian Bunk wrote:
> > mm-tracking-shared-dirty-pages.patch breaks CONFIG_MMU=n architectures:
> > 
> > <--  snip  -->
> > 
> > ....
> >   CC      mm/page-writeback.o
> > /home/bunk/linux/kernel-2.6/linux-2.6.18-rc5-mm1/mm/page-writeback.c: In function 'test_clear_page_dirty':
> > /home/bunk/linux/kernel-2.6/linux-2.6.18-rc5-mm1/mm/page-writeback.c:867: error: implicit declaration of function 'page_mkclean'
> > make[2]: *** [mm/page-writeback.o] Error 1
> 
> This might fix it, but I don't have a cross compiler for any nommu arch,
> nor an emulator so I can't test. - Will try to build me a toolchain but
> this could take some time.
>...

Thanks, I can confirm this fixes the compilation.

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] drivers/infiniband/hw/amso1100/: possible cleanups

[Adrian Bunk]

On Fri, Sep 01, 2006 at 01:58:18AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.18-rc4-mm3:
>...
>  git-infiniband.patch
>...
>  git trees.
>...

This patch contains the following possible cleanups:
- make the following needlessly global functions static:
  - c2_ae.c: to_qp_state_str()
  - c2_cq.c: c2_cq_get()
  - c2_cq.c: c2_cq_put()
  - c2_qp.c: to_ib_state()
  - c2_qp.c: to_ib_state_str()
  - c2_rnic.c: c2_rnic_query()
- #if 0 the following unused global function:
  - c2_mq.c: c2_mq_count()

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

---

 drivers/infiniband/hw/amso1100/c2.h      |    1 -
 drivers/infiniband/hw/amso1100/c2_ae.c   |    2 +-
 drivers/infiniband/hw/amso1100/c2_cq.c   |    4 ++--
 drivers/infiniband/hw/amso1100/c2_mq.c   |    3 ++-
 drivers/infiniband/hw/amso1100/c2_mq.h   |    1 -
 drivers/infiniband/hw/amso1100/c2_qp.c   |    4 ++--
 drivers/infiniband/hw/amso1100/c2_rnic.c |    3 +--
 7 files changed, 8 insertions(+), 10 deletions(-)

--- linux-2.6.18-rc5-mm1/drivers/infiniband/hw/amso1100/c2_ae.c.old	2006-09-01 21:02:16.000000000 +0200
+++ linux-2.6.18-rc5-mm1/drivers/infiniband/hw/amso1100/c2_ae.c	2006-09-01 21:02:23.000000000 +0200
@@ -125,7 +125,7 @@
 	return event_str[event];
 }
 
-const char *to_qp_state_str(int state)
+static const char *to_qp_state_str(int state)
 {
 	switch (state) {
 	case C2_QP_STATE_IDLE:
--- linux-2.6.18-rc5-mm1/drivers/infiniband/hw/amso1100/c2_cq.c.old	2006-09-01 21:02:45.000000000 +0200
+++ linux-2.6.18-rc5-mm1/drivers/infiniband/hw/amso1100/c2_cq.c	2006-09-01 21:03:06.000000000 +0200
@@ -41,7 +41,7 @@
 
 #define C2_CQ_MSG_SIZE ((sizeof(struct c2wr_ce) + 32-1) & ~(32-1))
 
-struct c2_cq *c2_cq_get(struct c2_dev *c2dev, int cqn)
+static struct c2_cq *c2_cq_get(struct c2_dev *c2dev, int cqn)
 {
 	struct c2_cq *cq;
 	unsigned long flags;
@@ -57,7 +57,7 @@
 	return cq;
 }
 
-void c2_cq_put(struct c2_cq *cq)
+static void c2_cq_put(struct c2_cq *cq)
 {
 	if (atomic_dec_and_test(&cq->refcount))
 		wake_up(&cq->wait);
--- linux-2.6.18-rc5-mm1/drivers/infiniband/hw/amso1100/c2_mq.h.old	2006-09-01 21:03:23.000000000 +0200
+++ linux-2.6.18-rc5-mm1/drivers/infiniband/hw/amso1100/c2_mq.h	2006-09-01 21:03:30.000000000 +0200
@@ -98,7 +98,6 @@
 extern void c2_mq_produce(struct c2_mq *q);
 extern void *c2_mq_consume(struct c2_mq *q);
 extern void c2_mq_free(struct c2_mq *q);
-extern u32 c2_mq_count(struct c2_mq *q);
 extern void c2_mq_req_init(struct c2_mq *q, u32 index, u32 q_size, u32 msg_size,
 		       u8 __iomem *pool_start, u16 __iomem *peer, u32 type);
 extern void c2_mq_rep_init(struct c2_mq *q, u32 index, u32 q_size, u32 msg_size,
--- linux-2.6.18-rc5-mm1/drivers/infiniband/hw/amso1100/c2_mq.c.old	2006-09-01 21:03:37.000000000 +0200
+++ linux-2.6.18-rc5-mm1/drivers/infiniband/hw/amso1100/c2_mq.c	2006-09-01 21:03:49.000000000 +0200
@@ -121,7 +121,7 @@
 	}
 }
 
-
+#if 0
 u32 c2_mq_count(struct c2_mq *q)
 {
 	s32 count;
@@ -138,6 +138,7 @@
 
 	return (u32) count;
 }
+#endif  /*  0  */
 
 void c2_mq_req_init(struct c2_mq *q, u32 index, u32 q_size, u32 msg_size,
 		    u8 __iomem *pool_start, u16 __iomem *peer, u32 type)
--- linux-2.6.18-rc5-mm1/drivers/infiniband/hw/amso1100/c2_qp.c.old	2006-09-01 21:04:06.000000000 +0200
+++ linux-2.6.18-rc5-mm1/drivers/infiniband/hw/amso1100/c2_qp.c	2006-09-01 21:04:22.000000000 +0200
@@ -75,7 +75,7 @@
 	}
 }
 
-int to_ib_state(enum c2_qp_state c2_state)
+static int to_ib_state(enum c2_qp_state c2_state)
 {
 	switch (c2_state) {
 	case C2_QP_STATE_IDLE:
@@ -95,7 +95,7 @@
 	}
 }
 
-const char *to_ib_state_str(int ib_state)
+static const char *to_ib_state_str(int ib_state)
 {
 	static const char *state_str[] = {
 		"IB_QPS_RESET",
--- linux-2.6.18-rc5-mm1/drivers/infiniband/hw/amso1100/c2.h.old	2006-09-01 21:04:49.000000000 +0200
+++ linux-2.6.18-rc5-mm1/drivers/infiniband/hw/amso1100/c2.h	2006-09-01 21:04:54.000000000 +0200
@@ -485,7 +485,6 @@
 extern int c2_rnic_init(struct c2_dev *c2dev);
 extern void c2_rnic_term(struct c2_dev *c2dev);
 extern void c2_rnic_interrupt(struct c2_dev *c2dev);
-extern int c2_rnic_query(struct c2_dev *c2dev, struct ib_device_attr *props);
 extern int c2_del_addr(struct c2_dev *c2dev, u32 inaddr, u32 inmask);
 extern int c2_add_addr(struct c2_dev *c2dev, u32 inaddr, u32 inmask);
 
--- linux-2.6.18-rc5-mm1/drivers/infiniband/hw/amso1100/c2_rnic.c.old	2006-09-01 21:05:03.000000000 +0200
+++ linux-2.6.18-rc5-mm1/drivers/infiniband/hw/amso1100/c2_rnic.c	2006-09-01 21:05:17.000000000 +0200
@@ -118,8 +118,7 @@
 /*
  * Query the adapter
  */
-int c2_rnic_query(struct c2_dev *c2dev,
-		  struct ib_device_attr *props)
+static int c2_rnic_query(struct c2_dev *c2dev, struct ib_device_attr *props)
 {
 	struct c2_vq_req *vq_req;
 	struct c2wr_rnic_query_req wr;

[-mm patch] make fs/lockd/host.c:nlm_lookup_host() static

[Adrian Bunk]

On Fri, Sep 01, 2006 at 01:58:18AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.18-rc4-mm3:
>...
> +knfsd-hide-use-of-lockds-h_monitored-flag.patch
> +knfsd-consolidate-common-code-for-statd-lockd-notification.patch
> +knfsd-when-looking-up-a-lockd-host-pass-hostname-length.patch
> +knfsd-lockd-introduce-nsm_handle.patch
> +knfsd-misc-minor-fixes-indentation-changes.patch
> +knfsd-lockd-make-nlm_host_rebooted-use-the-nsm_handle.patch
> +knfsd-lockd-make-the-nsm-upcalls-use-the-nsm_handle.patch
> +knfsd-lockd-make-the-hash-chains-use-a-hlist_node.patch
> +knfsd-lockd-change-list-of-blocked-list-to-list_node.patch
> +knfsd-change-nlm_file-to-use-a-hlist.patch
> +knfsd-lockd-make-nlm_traverse_-more-flexible.patch
> +knfsd-lockd-add-nlm_destroy_host.patch
> +knfsd-simplify-nlmsvc_invalidate_all.patch
> +knfsd-lockd-optionally-use-hostnames-for-identifying-peers.patch
> +knfsd-make-nlmclnt_next_cookie-smp-safe.patch
> +knfsd-match-granted_res-replies-using-cookies.patch
> +knfsd-export-nsm_local_state-to-user-space-via-sysctl.patch
> +knfsd-lockd-fix-use-of-h_nextrebind.patch
> +knfsd-register-all-rpc-programs-with-portmapper-by-default.patch
> 
>  nfsd updates.
>...

nlm_lookup_host() can now become static.

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

---

 fs/lockd/host.c             |   48 ++++++++++++++++++------------------
 include/linux/lockd/lockd.h |    1 
 2 files changed, 24 insertions(+), 25 deletions(-)

--- linux-2.6.18-rc5-mm1/include/linux/lockd/lockd.h.old	2006-09-01 20:57:28.000000000 +0200
+++ linux-2.6.18-rc5-mm1/include/linux/lockd/lockd.h	2006-09-01 20:57:34.000000000 +0200
@@ -164,7 +164,6 @@
  */
 struct nlm_host * nlmclnt_lookup_host(const struct sockaddr_in *, int, int, const char *, int);
 struct nlm_host * nlmsvc_lookup_host(struct svc_rqst *, const char *, int);
-struct nlm_host * nlm_lookup_host(int server, const struct sockaddr_in *, int, int, const char *, int);
 struct rpc_clnt * nlm_bind_host(struct nlm_host *);
 void		  nlm_rebind_host(struct nlm_host *);
 struct nlm_host * nlm_get_host(struct nlm_host *);
--- linux-2.6.18-rc5-mm1/fs/lockd/host.c.old	2006-09-01 20:57:42.000000000 +0200
+++ linux-2.6.18-rc5-mm1/fs/lockd/host.c	2006-09-01 20:58:25.000000000 +0200
@@ -38,32 +38,9 @@
 					const char *, int, int);
 
 /*
- * Find an NLM server handle in the cache. If there is none, create it.
- */
-struct nlm_host *
-nlmclnt_lookup_host(const struct sockaddr_in *sin, int proto, int version,
-			const char *hostname, int hostname_len)
-{
-	return nlm_lookup_host(0, sin, proto, version,
-			       hostname, hostname_len);
-}
-
-/*
- * Find an NLM client handle in the cache. If there is none, create it.
- */
-struct nlm_host *
-nlmsvc_lookup_host(struct svc_rqst *rqstp,
-			const char *hostname, int hostname_len)
-{
-	return nlm_lookup_host(1, &rqstp->rq_addr,
-			       rqstp->rq_prot, rqstp->rq_vers,
-			       hostname, hostname_len);
-}
-
-/*
  * Common host lookup routine for server & client
  */
-struct nlm_host *
+static struct nlm_host *
 nlm_lookup_host(int server, const struct sockaddr_in *sin,
 					int proto, int version,
 					const char *hostname,
@@ -165,6 +142,29 @@
 }
 
 /*
+ * Find an NLM server handle in the cache. If there is none, create it.
+ */
+struct nlm_host *
+nlmclnt_lookup_host(const struct sockaddr_in *sin, int proto, int version,
+			const char *hostname, int hostname_len)
+{
+	return nlm_lookup_host(0, sin, proto, version,
+			       hostname, hostname_len);
+}
+
+/*
+ * Find an NLM client handle in the cache. If there is none, create it.
+ */
+struct nlm_host *
+nlmsvc_lookup_host(struct svc_rqst *rqstp,
+			const char *hostname, int hostname_len)
+{
+	return nlm_lookup_host(1, &rqstp->rq_addr,
+			       rqstp->rq_prot, rqstp->rq_vers,
+			       hostname, hostname_len);
+}
+
+/*
  * Destroy a host
  */
 static void

2.6.18-rc5-mm1: ARCH_DISCONTIGMEM_ENABLE=y, SMP=n compile error

[Adrian Bunk]

cpumask-add-highest_possible_node_id.patch causes the following compile 
error with CONFIG_ARCH_DISCONTIGMEM_ENABLE=y, CONFIG_SMP=n
(and CONFIG_SUNRPC=y):

<--  snip  -->

...
  LD      vmlinux
net/built-in.o: In function `svc_create_pooled':
(.text+0x675fc): undefined reference to `highest_possible_node_id'
net/built-in.o: In function `svc_create_pooled':
(.text+0x675fc): relocation truncated to fit: R_M32R_26_PCREL_RELA against undefined symbol `highest_possible_node_id'
make[1]: *** [vmlinux] Error 1

<--  snip  -->

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] fix kernel_execve() related compile errors

[Adrian Bunk]

On Fri, Sep 01, 2006 at 01:58:18AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.18-rc4-mm3:
>...
> +rename-the-provided-execve-functions-to-kernel_execve.patch
>...
>  kernel syscalls cleanup
>...

This patch fixes some typos causing compile errors.

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

---

 arch/arm/kernel/sys_arm.c    |    2 +-
 arch/arm26/kernel/sys_arm.c  |    2 +-
 arch/parisc/kernel/process.c |    2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

--- linux-2.6.18-rc5-mm1/arch/arm/kernel/sys_arm.c.old	2006-09-03 23:32:16.000000000 +0200
+++ linux-2.6.18-rc5-mm1/arch/arm/kernel/sys_arm.c	2006-09-03 23:32:24.000000000 +0200
@@ -279,7 +279,7 @@
 	return error;
 }
 
-int kernel_execve(const char *filename, char *const argv[], char *const envp[]);
+int kernel_execve(const char *filename, char *const argv[], char *const envp[])
 {
 	struct pt_regs regs;
 	int ret;
--- linux-2.6.18-rc5-mm1/arch/arm26/kernel/sys_arm.c.old	2006-09-03 23:32:31.000000000 +0200
+++ linux-2.6.18-rc5-mm1/arch/arm26/kernel/sys_arm.c	2006-09-03 23:32:37.000000000 +0200
@@ -283,7 +283,7 @@
 }
 
 /* FIXME - see if this is correct for arm26 */
-int kernel_execve(const char *filename, char *const argv[], char *const envp[]);
+int kernel_execve(const char *filename, char *const argv[], char *const envp[])
 {
 	struct pt_regs regs;
         int ret;
--- linux-2.6.18-rc5-mm1/arch/parisc/kernel/process.c.old	2006-09-03 23:32:45.000000000 +0200
+++ linux-2.6.18-rc5-mm1/arch/parisc/kernel/process.c	2006-09-03 23:32:50.000000000 +0200
@@ -370,7 +370,7 @@
 
 extern int __execve(const char *filename, char *const argv[],
 		char *const envp[], struct task_struct *task);
-int kernel_execve(const char *filename, char *const argv[], char *const envp[]);
+int kernel_execve(const char *filename, char *const argv[], char *const envp[])
 {
 	return __execve(filename, argv, envp, current);
 }

[-mm patch] lib/ioremap.c must #include <linux/mm.h>

[Adrian Bunk]

generic-ioremap_page_range-implementation.patch causes the following 
compile error with -Werror-implicit-function-declaration on ia64:

<--  snip  -->

  CC      lib/ioremap.o
/home/bunk/linux/kernel-2.6/linux-2.6.18-rc5-mm1/lib/ioremap.c: In function 'ioremap_pte_range':
/home/bunk/linux/kernel-2.6/linux-2.6.18-rc5-mm1/lib/ioremap.c:21: error: implicit declaration of function 'pte_alloc_kernel'
/home/bunk/linux/kernel-2.6/linux-2.6.18-rc5-mm1/lib/ioremap.c:21: warning: assignment makes pointer from integer without a cast
/home/bunk/linux/kernel-2.6/linux-2.6.18-rc5-mm1/lib/ioremap.c: In function 'ioremap_pmd_range':
/home/bunk/linux/kernel-2.6/linux-2.6.18-rc5-mm1/lib/ioremap.c:39: error: implicit declaration of function 'pmd_alloc'
/home/bunk/linux/kernel-2.6/linux-2.6.18-rc5-mm1/lib/ioremap.c:39: warning: assignment makes pointer from integer without a cast
/home/bunk/linux/kernel-2.6/linux-2.6.18-rc5-mm1/lib/ioremap.c: In function 'ioremap_pud_range':
/home/bunk/linux/kernel-2.6/linux-2.6.18-rc5-mm1/lib/ioremap.c:57: error: implicit declaration of function 'pud_alloc'
/home/bunk/linux/kernel-2.6/linux-2.6.18-rc5-mm1/lib/ioremap.c:57: warning: assignment makes pointer from integer without a cast
make[2]: *** [lib/ioremap.o] Error 1

<--  snip  -->

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

--- linux-2.6.18-rc5-mm1/lib/ioremap.c.old	2006-09-04 02:01:22.000000000 +0200
+++ linux-2.6.18-rc5-mm1/lib/ioremap.c	2006-09-04 02:01:32.000000000 +0200
@@ -7,6 +7,7 @@
  */
 #include <linux/io.h>
 #include <linux/vmalloc.h>
+#include <linux/mm.h>
 
 #include <asm/cacheflush.h>
 #include <asm/pgtable.h>

[parisc-linux] [PATCH] Fix conflict with the is_init identifier on parisc

[Eric W. Biederman]

Matthew Wilcox <matthew@wil.cx> writes:

> On Mon, Sep 04, 2006 at 01:41:30PM +0200, Adrian Bunk wrote:
>> pidspace-is_init.patch causes the following compile error on parisc:
>> 
>> <--  snip  -->
>> 
>> ...
>>   CC      arch/parisc/kernel/module.o
>>
> /home/bunk/linux/kernel-2.6/linux-2.6.18-rc5-mm1/arch/parisc/kernel/module.c:76:
> error: conflicting types for 'is_init'
>> /home/bunk/linux/kernel-2.6/linux-2.6.18-rc5-mm1/include/linux/sched.h:1090:
> error: previous definition of 'is_init' was here
>> make[2]: *** [arch/parisc/kernel/module.o] Error 1
>> 
>> <--  snip  -->
>
> Looks like ia64 calls the same function in_init().  I'm tempted to
> change parisc to have the same name.

How does the following patch look?
Since I don't have a parisc compiler so I haven't compile tested it.
But it is a simple substitute and replace and I can't see any problems
by inspection so it should work.

----

This appears to be the only usage of is_init in the kernel
besides the usage in sched.h.   On ia64 the same function is
called in_init.    So to remove the conflict and make the kernel
more consistent rename is_init is_core is_local and is_local_section
to in_init in_core in_local and in_local_section respectively.

Thanks to Adrian Bunk who spotted this, and to Matthew Wilcox
who suggested this fix.

Singed-off-by: Eric Biederman <ebiederm@xmission.com>
---
 arch/parisc/kernel/module.c |   32 ++++++++++++++++----------------
 1 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/arch/parisc/kernel/module.c b/arch/parisc/kernel/module.c
index aee3118..f50b982 100644
--- a/arch/parisc/kernel/module.c
+++ b/arch/parisc/kernel/module.c
@@ -27,7 +27,7 @@
  *    - SEGREL32 handling
  *      We are not doing SEGREL32 handling correctly. According to the ABI, we
  *      should do a value offset, like this:
- *			if (is_init(me, (void *)val))
+ *			if (in_init(me, (void *)val))
  *				val -= (uint32_t)me->module_init;
  *			else
  *				val -= (uint32_t)me->module_core;
@@ -72,27 +72,27 @@ #define MAX_GOTS	1023
 
 /* three functions to determine where in the module core
  * or init pieces the location is */
-static inline int is_init(struct module *me, void *loc)
+static inline int in_init(struct module *me, void *loc)
 {
 	return (loc >= me->module_init &&
 		loc <= (me->module_init + me->init_size));
 }
 
-static inline int is_core(struct module *me, void *loc)
+static inline int in_core(struct module *me, void *loc)
 {
 	return (loc >= me->module_core &&
 		loc <= (me->module_core + me->core_size));
 }
 
-static inline int is_local(struct module *me, void *loc)
+static inline int in_local(struct module *me, void *loc)
 {
-	return is_init(me, loc) || is_core(me, loc);
+	return in_init(me, loc) || in_core(me, loc);
 }
 
-static inline int is_local_section(struct module *me, void *loc, void *dot)
+static inline int in_local_section(struct module *me, void *loc, void *dot)
 {
-	return (is_init(me, loc) && is_init(me, dot)) ||
-		(is_core(me, loc) && is_core(me, dot));
+	return (in_init(me, loc) && in_init(me, dot)) ||
+		(in_core(me, loc) && in_core(me, dot));
 }
 
 
@@ -566,14 +566,14 @@ #endif
 			break;
 		case R_PARISC_PCREL17F:
 			/* 17-bit PC relative address */
-			val = get_stub(me, val, addend, ELF_STUB_GOT, is_init(me, loc));
+			val = get_stub(me, val, addend, ELF_STUB_GOT, in_init(me, loc));
 			val = (val - dot - 8)/4;
 			CHECK_RELOC(val, 17)
 			*loc = (*loc & ~0x1f1ffd) | reassemble_17(val);
 			break;
 		case R_PARISC_PCREL22F:
 			/* 22-bit PC relative address; only defined for pa20 */
-			val = get_stub(me, val, addend, ELF_STUB_GOT, is_init(me, loc));
+			val = get_stub(me, val, addend, ELF_STUB_GOT, in_init(me, loc));
 			DEBUGP("STUB FOR %s loc %lx+%lx at %lx\n", 
 			       strtab + sym->st_name, (unsigned long)loc, addend, 
 			       val)
@@ -670,9 +670,9 @@ #endif
 			       strtab + sym->st_name,
 			       loc, val);
 			/* can we reach it locally? */
-			if(!is_local_section(me, (void *)val, (void *)dot)) {
+			if(!in_local_section(me, (void *)val, (void *)dot)) {
 
-				if (is_local(me, (void *)val))
+				if (in_local(me, (void *)val))
 					/* this is the case where the
 					 * symbol is local to the
 					 * module, but in a different
@@ -680,14 +680,14 @@ #endif
 					 * in case it's more than 22
 					 * bits away */
 					val = get_stub(me, val, addend, ELF_STUB_DIRECT,
-						       is_init(me, loc));
+						       in_init(me, loc));
 				else if (strncmp(strtab + sym->st_name, "$$", 2)
 				    == 0)
 					val = get_stub(me, val, addend, ELF_STUB_MILLI,
-						       is_init(me, loc));
+						       in_init(me, loc));
 				else
 					val = get_stub(me, val, addend, ELF_STUB_GOT,
-						       is_init(me, loc));
+						       in_init(me, loc));
 			}
 			DEBUGP("STUB FOR %s loc %lx, val %lx+%lx at %lx\n", 
 			       strtab + sym->st_name, loc, sym->st_value,
@@ -720,7 +720,7 @@ #endif
 			break;
 		case R_PARISC_FPTR64:
 			/* 64-bit function address */
-			if(is_local(me, (void *)(val + addend))) {
+			if(in_local(me, (void *)(val + addend))) {
 				*loc64 = get_fdesc(me, val+addend);
 				DEBUGP("FDESC for %s at %p points to %lx\n",
 				       strtab + sym->st_name, *loc64,
-- 
1.4.2.rc3.g7e18e-dirty

_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

[PATCH] Fix conflict with the is_init identifier on parisc

[Eric W. Biederman]

Matthew Wilcox <matthew@wil.cx> writes:

> On Mon, Sep 04, 2006 at 01:41:30PM +0200, Adrian Bunk wrote:
>> pidspace-is_init.patch causes the following compile error on parisc:
>> 
>> <--  snip  -->
>> 
>> ...
>>   CC      arch/parisc/kernel/module.o
>>
> /home/bunk/linux/kernel-2.6/linux-2.6.18-rc5-mm1/arch/parisc/kernel/module.c:76:
> error: conflicting types for 'is_init'
>> /home/bunk/linux/kernel-2.6/linux-2.6.18-rc5-mm1/include/linux/sched.h:1090:
> error: previous definition of 'is_init' was here
>> make[2]: *** [arch/parisc/kernel/module.o] Error 1
>> 
>> <--  snip  -->
>
> Looks like ia64 calls the same function in_init().  I'm tempted to
> change parisc to have the same name.

How does the following patch look?
Since I don't have a parisc compiler so I haven't compile tested it.
But it is a simple substitute and replace and I can't see any problems
by inspection so it should work.

----

This appears to be the only usage of is_init in the kernel
besides the usage in sched.h.   On ia64 the same function is
called in_init.    So to remove the conflict and make the kernel
more consistent rename is_init is_core is_local and is_local_section
to in_init in_core in_local and in_local_section respectively.

Thanks to Adrian Bunk who spotted this, and to Matthew Wilcox
who suggested this fix.

Singed-off-by: Eric Biederman <ebiederm@xmission.com>
---
 arch/parisc/kernel/module.c |   32 ++++++++++++++++----------------
 1 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/arch/parisc/kernel/module.c b/arch/parisc/kernel/module.c
index aee3118..f50b982 100644
--- a/arch/parisc/kernel/module.c
+++ b/arch/parisc/kernel/module.c
@@ -27,7 +27,7 @@
  *    - SEGREL32 handling
  *      We are not doing SEGREL32 handling correctly. According to the ABI, we
  *      should do a value offset, like this:
- *			if (is_init(me, (void *)val))
+ *			if (in_init(me, (void *)val))
  *				val -= (uint32_t)me->module_init;
  *			else
  *				val -= (uint32_t)me->module_core;
@@ -72,27 +72,27 @@ #define MAX_GOTS	1023
 
 /* three functions to determine where in the module core
  * or init pieces the location is */
-static inline int is_init(struct module *me, void *loc)
+static inline int in_init(struct module *me, void *loc)
 {
 	return (loc >= me->module_init &&
 		loc <= (me->module_init + me->init_size));
 }
 
-static inline int is_core(struct module *me, void *loc)
+static inline int in_core(struct module *me, void *loc)
 {
 	return (loc >= me->module_core &&
 		loc <= (me->module_core + me->core_size));
 }
 
-static inline int is_local(struct module *me, void *loc)
+static inline int in_local(struct module *me, void *loc)
 {
-	return is_init(me, loc) || is_core(me, loc);
+	return in_init(me, loc) || in_core(me, loc);
 }
 
-static inline int is_local_section(struct module *me, void *loc, void *dot)
+static inline int in_local_section(struct module *me, void *loc, void *dot)
 {
-	return (is_init(me, loc) && is_init(me, dot)) ||
-		(is_core(me, loc) && is_core(me, dot));
+	return (in_init(me, loc) && in_init(me, dot)) ||
+		(in_core(me, loc) && in_core(me, dot));
 }
 
 
@@ -566,14 +566,14 @@ #endif
 			break;
 		case R_PARISC_PCREL17F:
 			/* 17-bit PC relative address */
-			val = get_stub(me, val, addend, ELF_STUB_GOT, is_init(me, loc));
+			val = get_stub(me, val, addend, ELF_STUB_GOT, in_init(me, loc));
 			val = (val - dot - 8)/4;
 			CHECK_RELOC(val, 17)
 			*loc = (*loc & ~0x1f1ffd) | reassemble_17(val);
 			break;
 		case R_PARISC_PCREL22F:
 			/* 22-bit PC relative address; only defined for pa20 */
-			val = get_stub(me, val, addend, ELF_STUB_GOT, is_init(me, loc));
+			val = get_stub(me, val, addend, ELF_STUB_GOT, in_init(me, loc));
 			DEBUGP("STUB FOR %s loc %lx+%lx at %lx\n", 
 			       strtab + sym->st_name, (unsigned long)loc, addend, 
 			       val)
@@ -670,9 +670,9 @@ #endif
 			       strtab + sym->st_name,
 			       loc, val);
 			/* can we reach it locally? */
-			if(!is_local_section(me, (void *)val, (void *)dot)) {
+			if(!in_local_section(me, (void *)val, (void *)dot)) {
 
-				if (is_local(me, (void *)val))
+				if (in_local(me, (void *)val))
 					/* this is the case where the
 					 * symbol is local to the
 					 * module, but in a different
@@ -680,14 +680,14 @@ #endif
 					 * in case it's more than 22
 					 * bits away */
 					val = get_stub(me, val, addend, ELF_STUB_DIRECT,
-						       is_init(me, loc));
+						       in_init(me, loc));
 				else if (strncmp(strtab + sym->st_name, "$$", 2)
 				    == 0)
 					val = get_stub(me, val, addend, ELF_STUB_MILLI,
-						       is_init(me, loc));
+						       in_init(me, loc));
 				else
 					val = get_stub(me, val, addend, ELF_STUB_GOT,
-						       is_init(me, loc));
+						       in_init(me, loc));
 			}
 			DEBUGP("STUB FOR %s loc %lx, val %lx+%lx at %lx\n", 
 			       strtab + sym->st_name, loc, sym->st_value,
@@ -720,7 +720,7 @@ #endif
 			break;
 		case R_PARISC_FPTR64:
 			/* 64-bit function address */
-			if(is_local(me, (void *)(val + addend))) {
+			if(in_local(me, (void *)(val + addend))) {
 				*loc64 = get_fdesc(me, val+addend);
 				DEBUGP("FDESC for %s at %p points to %lx\n",
 				       strtab + sym->st_name, *loc64,
-- 
1.4.2.rc3.g7e18e-dirty

[-mm patch] mm/memory_hotplug.c must #include <linux/cpuset.h>

[Adrian Bunk]

This patch fixes the following compile error:

<--  snip  -->

...
  CC      mm/memory_hotplug.o
/home/bunk/linux/kernel-2.6/linux-2.6.18-rc5-mm1/mm/memory_hotplug.c: In function ‘add_memory’:
/home/bunk/linux/kernel-2.6/linux-2.6.18-rc5-mm1/mm/memory_hotplug.c:286: error: implicit declaration of function ‘cpuset_track_online_nodes’
make[2]: *** [mm/memory_hotplug.o] Error 1

<--  snip  -->

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

--- linux-2.6.18-rc5-mm1/mm/memory_hotplug.c.old	2006-09-04 20:23:30.000000000 +0200
+++ linux-2.6.18-rc5-mm1/mm/memory_hotplug.c	2006-09-04 20:23:48.000000000 +0200
@@ -22,6 +22,7 @@
 #include <linux/highmem.h>
 #include <linux/vmalloc.h>
 #include <linux/ioport.h>
+#include <linux/cpuset.h>
 
 #include <asm/tlbflush.h>
 

Re: [PATCH] Fix conflict with the is_init identifier on parisc

[Adrian Bunk]

On Mon, Sep 04, 2006 at 12:24:27PM -0600, Eric W. Biederman wrote:
> Matthew Wilcox <matthew@wil.cx> writes:
> 
> > On Mon, Sep 04, 2006 at 01:41:30PM +0200, Adrian Bunk wrote:
> >> pidspace-is_init.patch causes the following compile error on parisc:
> >> 
> >> <--  snip  -->
> >> 
> >> ...
> >>   CC      arch/parisc/kernel/module.o
> >>
> > /home/bunk/linux/kernel-2.6/linux-2.6.18-rc5-mm1/arch/parisc/kernel/module.c:76:
> > error: conflicting types for 'is_init'
> >> /home/bunk/linux/kernel-2.6/linux-2.6.18-rc5-mm1/include/linux/sched.h:1090:
> > error: previous definition of 'is_init' was here
> >> make[2]: *** [arch/parisc/kernel/module.o] Error 1
> >> 
> >> <--  snip  -->
> >
> > Looks like ia64 calls the same function in_init().  I'm tempted to
> > change parisc to have the same name.
> 
> How does the following patch look?
> Since I don't have a parisc compiler so I haven't compile tested it.
> But it is a simple substitute and replace and I can't see any problems
> by inspection so it should work.
>...

Thanks, I can confirm it fixes the compilation.

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.18-rc5-mm1: ARCH_DISCONTIGMEM_ENABLE=y, SMP=n compile error

[Andrew Morton]

On Mon, 4 Sep 2006 19:04:11 +0200
Adrian Bunk <bunk@stusta.de> wrote:

> cpumask-add-highest_possible_node_id.patch causes the following compile 
> error with CONFIG_ARCH_DISCONTIGMEM_ENABLE=y, CONFIG_SMP=n
> (and CONFIG_SUNRPC=y):
> 
> <--  snip  -->
> 
> ...
>   LD      vmlinux
> net/built-in.o: In function `svc_create_pooled':
> (.text+0x675fc): undefined reference to `highest_possible_node_id'
> net/built-in.o: In function `svc_create_pooled':
> (.text+0x675fc): relocation truncated to fit: R_M32R_26_PCREL_RELA against undefined symbol `highest_possible_node_id'
> make[1]: *** [vmlinux] Error 1

On m32r?

If so, could it be a binutils or m32r bug?

Re: [PATCH] Fix conflict with the is_init identifier on parisc

[Andrew Morton]

On Mon, 04 Sep 2006 12:24:27 -0600
ebiederm@xmission.com (Eric W. Biederman) wrote:

> Singed-off-by: Eric Biederman <ebiederm@xmission.com>

ouch!  One for the hot-fixes directory, I assume.

Re: 2.6.18-rc5-mm1: ARCH_DISCONTIGMEM_ENABLE=y, SMP=n compile error

[Adrian Bunk]

On Mon, Sep 04, 2006 at 12:04:30PM -0700, Andrew Morton wrote:
> On Mon, 4 Sep 2006 19:04:11 +0200
> Adrian Bunk <bunk@stusta.de> wrote:
> 
> > cpumask-add-highest_possible_node_id.patch causes the following compile 
> > error with CONFIG_ARCH_DISCONTIGMEM_ENABLE=y, CONFIG_SMP=n
> > (and CONFIG_SUNRPC=y):
> > 
> > <--  snip  -->
> > 
> > ...
> >   LD      vmlinux
> > net/built-in.o: In function `svc_create_pooled':
> > (.text+0x675fc): undefined reference to `highest_possible_node_id'
> > net/built-in.o: In function `svc_create_pooled':
> > (.text+0x675fc): relocation truncated to fit: R_M32R_26_PCREL_RELA against undefined symbol `highest_possible_node_id'
> > make[1]: *** [vmlinux] Error 1
> 
> On m32r?
> 
> If so, could it be a binutils or m32r bug?

No, it is a kernel bug (don't be confused by the second message, the 
first one describes the bug).

The problem is simple:

- net/sunrpc/svc.c uses highest_possible_node_id()
- include/linux/nodemask.h says highest_possible_node_id() is
  out-of-line #if MAX_NUMNODES > 1
- the out-of-line highest_possible_node_id() is in lib/cpumask.c
- lib/Makefile: lib-$(CONFIG_SMP) += cpumask.o

CONFIG_ARCH_DISCONTIGMEM_ENABLE=y, CONFIG_SMP=n, CONFIG_SUNRPC=y
-> highest_possible_node_id() is used in net/sunrpc/svc.c
   CONFIG_NODES_SHIFT defined and > 0
-> include/linux/numa.h: MAX_NUMNODES > 1
-> compile error

The bug is not present on architectures where ARCH_DISCONTIGMEM_ENABLE 
depends on NUMA (but m32r isn't the only affected architecture).

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] arch/m68knommu/kernel/sys_m68k.c must #include <asm/unistd.h>

[Adrian Bunk]

On Fri, Sep 01, 2006 at 01:58:18AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.18-rc4-mm3:
>...
> +provide-kernel_execve-on-all-architectures.patch
>...
>  kernel syscalls cleanup
>...

This patch fixes the following compile error on m68knommu:

<--  snip  -->

...
  CC      arch/m68knommu/kernel/sys_m68k.o
/home/bunk/linux/kernel-2.6/linux-2.6.18-rc5-mm1/arch/m68knommu/kernel/sys_m68k.c:215: error: '__NR_execve' undeclared (first use in this function)
/home/bunk/linux/kernel-2.6/linux-2.6.18-rc5-mm1/arch/m68knommu/kernel/sys_m68k.c:215: error: (Each undeclared identifier is reported only once
/home/bunk/linux/kernel-2.6/linux-2.6.18-rc5-mm1/arch/m68knommu/kernel/sys_m68k.c:215: error: for each function it appears in.)
make[2]: *** [arch/m68knommu/kernel/sys_m68k.o] Error 1

<--  snip  -->

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

--- linux-2.6.18-rc5-mm1/arch/m68knommu/kernel/sys_m68k.c.old	2006-09-05 00:16:11.000000000 +0200
+++ linux-2.6.18-rc5-mm1/arch/m68knommu/kernel/sys_m68k.c	2006-09-05 00:16:25.000000000 +0200
@@ -26,6 +26,7 @@
 #include <asm/traps.h>
 #include <asm/ipc.h>
 #include <asm/cacheflush.h>
+#include <asm/unistd.h>
 
 /*
  * sys_pipe() is the normal C calling standard for creating

Re: Lost DVD-RW [Was Re: 2.6.18-rc5-mm1]

[J.A. Magallón]

On Mon, 04 Sep 2006 04:42:35 +0200, Tejun Heo <htejun@gmail.com> wrote:

> Andrew Morton wrote:
> > On Mon, 4 Sep 2006 01:34:43 +0200
> > "J.A. Magallón" <jamagallon@ono.com> wrote:
> > 
> >> On Fri, 1 Sep 2006 01:58:18 -0700, Andrew Morton <akpm@osdl.org> wrote:
> >>
> >>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc5/2.6.18-rc5-mm1/
> >>>
> >> Err, my burner got lost this summer ;).
...
> >> dmesg for rc2-mm1:
> >> scsi0 : ata_piix
> >> ata1.00: ATAPI, max UDMA/33
> >> ata1.01: ATAPI, max MWDMA0, CDB intr
> >> ata1.00: configured for UDMA/33
> >> ata1.01: configured for PIO3
> >>   Vendor: HL-DT-ST  Model: DVDRAM GSA-4120B  Rev: A111
> >>   Type:   CD-ROM                             ANSI SCSI revision: 05
> >>   Vendor: IOMEGA    Model: ZIP 250           Rev: 51.G
> >>   Type:   Direct-Access                      ANSI SCSI revision: 05
> >>
> >> dmesg for rc5-mm1:
> >> ata1.00: failed to IDENTIFY (device reports illegal type, err_mask=0x0)
> 
> Hmmm... Strange.
> 
> The related code hasn't changed much between rc2-mm1 and rc5-mm1.  We're 
> talking about 2.6.18-rc2-mm1 and 2.6.18-rc5-mm1, right?
> 
> Can you try the attached patch and report what the kernel says?
> 
> 

Here it is:

libata version 2.00 loaded.
ata_piix 0000:00:1f.1: version 2.00ac7
ACPI: PCI Interrupt 0000:00:1f.1[A] -> GSI 18 (level, low) -> IRQ 16
PCI: Setting latency timer of device 0000:00:1f.1 to 64
ata1: PATA max UDMA/100 cmd 0x1F0 ctl 0x3F6 bmdma 0xF000 irq 14
ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xF008 irq 15
scsi0 : ata_piix
ata1.00: XXX class=3 is_ata=0 is_cfa=1
ata1.00: failed to IDENTIFY (device reports illegal type, err_mask=0x0)
ata1.01: XXX class=3 is_ata=0 is_cfa=0
ata1.01: ATAPI, max MWDMA0, CDB intr
ata1.01: XXX class=3 is_ata=0 is_cfa=0
ata1.01: configured for PIO3
scsi1 : ata_piix
ata2.00: XXX class=1 is_ata=1 is_cfa=0
ata2.00: ATA-6, max UDMA/100, 234441648 sectors: LBA48 
ata2.00: ata2: dev 0 multi count 16
ata2.01: XXX class=3 is_ata=0 is_cfa=0
ata2.01: ATAPI, max UDMA/33
ata2.00: XXX class=1 is_ata=1 is_cfa=0
ata2.00: configured for UDMA/100
ata2.01: XXX class=3 is_ata=0 is_cfa=0
ata2.01: configured for UDMA/33
scsi 0:0:1:0: Direct-Access     IOMEGA   ZIP 250          51.G PQ: 0 ANSI: 5
sd 0:0:1:0: Attached scsi removable disk sda
scsi 1:0:0:0: Direct-Access     ATA      ST3120022A       3.06 PQ: 0 ANSI: 5
SCSI device sdb: 234441648 512-byte hdwr sectors (120034 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 3a 00 00
SCSI device sdb: drive cache: write back
SCSI device sdb: 234441648 512-byte hdwr sectors (120034 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 3a 00 00
SCSI device sdb: drive cache: write back
 sdb: sdb1
sd 1:0:0:0: Attached scsi disk sdb
scsi 1:0:1:0: CD-ROM            TOSHIBA  DVD-ROM SD-M1712 1004 PQ: 0 ANSI: 5
sr0: scsi3-mmc drive: 48x/48x cd/rw xa/form2 cdda tray
Uniform CD-ROM driver Revision: 3.20
sr 1:0:1:0: Attached scsi CD-ROM sr0
ata_piix 0000:00:1f.2: MAP [ P0 -- P1 -- ]
ACPI: PCI Interrupt 0000:00:1f.2[A] -> GSI 18 (level, low) -> IRQ 16
PCI: Setting latency timer of device 0000:00:1f.2 to 64
ata3: SATA max UDMA/133 cmd 0xC000 ctl 0xC402 bmdma 0xD000 irq 16
ata4: SATA max UDMA/133 cmd 0xC800 ctl 0xCC02 bmdma 0xD008 irq 16
scsi2 : ata_piix
ata3.00: XXX class=1 is_ata=1 is_cfa=0
ata3.00: ATA-6, max UDMA/133, 390721968 sectors: LBA48 
ata3.00: ata3: dev 0 multi count 16
ata3.00: XXX class=1 is_ata=1 is_cfa=0
ata3.00: configured for UDMA/133
scsi3 : ata_piix
ATA: abnormal status 0x7F on port 0xC807
scsi 2:0:0:0: Direct-Access     ATA      ST3200822AS      3.01 PQ: 0 ANSI: 5
SCSI device sdc: 390721968 512-byte hdwr sectors (200050 MB)
sdc: Write Protect is off
sdc: Mode Sense: 00 3a 00 00
SCSI device sdc: drive cache: write back
SCSI device sdc: 390721968 512-byte hdwr sectors (200050 MB)
sdc: Write Protect is off
sdc: Mode Sense: 00 3a 00 00
SCSI device sdc: drive cache: write back
 sdc: sdc1 sdc2 sdc3
sd 2:0:0:0: Attached scsi disk sdc
sata_promise 0000:03:04.0: version 1.04
ACPI: PCI Interrupt 0000:03:04.0[A] -> GSI 23 (level, low) -> IRQ 17
sata_promise PATA port found
ata5: SATA max UDMA/133 cmd 0xF8802200 ctl 0xF8802238 bmdma 0x0 irq 17
ata6: SATA max UDMA/133 cmd 0xF8802280 ctl 0xF88022B8 bmdma 0x0 irq 17
ata7: PATA max UDMA/133 cmd 0xF8802300 ctl 0xF8802338 bmdma 0x0 irq 17
scsi4 : sata_promise
ata5: SATA link down (SStatus 0 SControl 0)
scsi5 : sata_promise
ata6: SATA link down (SStatus 0 SControl 300)
scsi6 : sata_promise
ATA: abnormal status 0x7F on port 0xF880231C
ata7: disabling port


--
J.A. Magallon <jamagallon()ono!com>     \               Software is like sex:
                                         \         It's better when it's free
Mandriva Linux release 2007.0 (Cooker) for i586
Linux 2.6.17-jam08 (gcc 4.1.1 20060724 (prerelease) (4.1.1-3mdk)) #2 SMP PREEMPT

lockdep oddity

[Heiko Carstens]

The lock validator gives me this (latest -mm and 2.6.18-rc6):

===================================== 
[ BUG: bad unlock balance detected! ] 
------------------------------------- 
swapper/0 is trying to release lock (resource_lock) at:
[<0000000000042842>] request_resource+0x52/0x88 
but there are no more locks to release! 

The reason is that the BUILD_LOCK_OPS macros in kernel/lockdep.c don't contain
any of the *_acquire calls, while all of the _unlock functions contain a
*_release call. Hence I get immediately unbalanced locks.

CONFIG_PREEMPT,
CONFIG_SMP,
!CONFIG_PROVE_LOCKING,
CONFIG_DEBUG_LOCK_ALLOC,
and
CONFIG_LOCKDEP

will generate this code.

Found this will debugging some random memory corruptions that happen when
CONFIG_PROVE_LOCKING and CONFIG_PROFILE_LIKELY are both on.
Switching both off or having only one of them on seems to work.

2.6.18-rc5-mm1: {dis,en}able_irq_lockdep_irqrestore compile error

[Adrian Bunk]

lockdep-core-add-enable-disable_irq_irqsave-irqrestore-apis.patch causes 
the following compile error on frv:

<--  snip  -->

...
  LD      .tmp_vmlinux1
drivers/built-in.o: In function `ei_start_xmit':
8390.c:(.text+0x241c8): undefined reference to `disable_irq_nosync_lockdep_irqsave'
8390.c:(.text+0x242a0): undefined reference to `enable_irq_lockdep_irqrestore'
8390.c:(.text+0x2440c): undefined reference to `enable_irq_lockdep_irqrestore'
make: *** [.tmp_vmlinux1] Error 1

<--  snip  -->

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

[PATCH] FRV: Fix {dis,en}able_irq_lockdep_irqrestore compile error

[David Howells]

Fix the lack of certain non-LOCKDEP stub functions in linux/interrupt.h and
also provide FRV with LOCKDEP variants.

This is to be applied to -mm kernel since not all of the functions added exist
in the main kernel.

Signed-Off-By: David Howells <dhowells@redhat.com>
---
warthog>diffstat -p1 frv-irq-lockdep-2618rc5mm1.diff 
 include/asm-frv/irq.h     |   43 +++++++++++++++++++++++++++++++++++++++++++
 include/linux/interrupt.h |    2 ++
 2 files changed, 45 insertions(+)

diff -urp ../kernels/linux-2.6.18-rc5-mm1/include/asm-frv/irq.h linux-2.6.18-rc5-mm1-frv/include/asm-frv/irq.h
--- ../kernels/linux-2.6.18-rc5-mm1/include/asm-frv/irq.h	2006-09-04 18:02:48.000000000 +0100
+++ linux-2.6.18-rc5-mm1-frv/include/asm-frv/irq.h	2006-09-05 15:59:08.000000000 +0100
@@ -39,5 +39,48 @@ extern void disable_irq_nosync(unsigned 
 extern void disable_irq(unsigned int irq);
 extern void enable_irq(unsigned int irq);
 
+#ifdef CONFIG_LOCKDEP
+/*
+ * Special lockdep variants of irq disabling/enabling.
+ * These should be used for locking constructs that
+ * know that a particular irq context which is disabled,
+ * and which is the only irq-context user of a lock,
+ * that it's safe to take the lock in the irq-disabled
+ * section without disabling hardirqs.
+ *
+ * On !CONFIG_LOCKDEP they are equivalent to the normal
+ * irq disable/enable methods.
+ */
+static inline void disable_irq_nosync_lockdep(unsigned int irq)
+{
+	disable_irq_nosync(irq);
+	local_irq_disable();
+}
+
+static inline void disable_irq_nosync_lockdep_irqsave(unsigned int irq, unsigned long *flags)
+{
+	disable_irq_nosync(irq);
+	local_irq_save(*flags);
+}
+
+static inline void disable_irq_lockdep(unsigned int irq)
+{
+	disable_irq(irq);
+	local_irq_disable();
+}
+
+static inline void enable_irq_lockdep(unsigned int irq)
+{
+	local_irq_enable();
+	enable_irq(irq);
+}
+
+static inline void enable_irq_lockdep_irqrestore(unsigned int irq, unsigned long *flags)
+{
+	local_irq_restore(*flags);
+	enable_irq(irq);
+}
+#endif /* CONFIG_LOCKDEP */
+
 
 #endif /* _ASM_IRQ_H_ */
diff -urp ../kernels/linux-2.6.18-rc5-mm1/include/linux/interrupt.h linux-2.6.18-rc5-mm1-frv/include/linux/interrupt.h
--- ../kernels/linux-2.6.18-rc5-mm1/include/linux/interrupt.h	2006-09-04 18:03:31.000000000 +0100
+++ linux-2.6.18-rc5-mm1-frv/include/linux/interrupt.h	2006-09-05 15:58:53.000000000 +0100
@@ -178,6 +178,8 @@ static inline int disable_irq_wake(unsig
 #  define disable_irq_nosync_lockdep(irq)	disable_irq_nosync(irq)
 #  define disable_irq_lockdep(irq)		disable_irq(irq)
 #  define enable_irq_lockdep(irq)		enable_irq(irq)
+#  define disable_irq_nosync_lockdep_irqsave(irq, flags) disable_irq_nosync(irq)
+#  define enable_irq_lockdep_irqrestore(irq, flags) enable_irq(irq)
 # endif
 
 #endif /* CONFIG_GENERIC_HARDIRQS */

[PATCH] NOMMU: Move the fallback arch_vma_name() to a sensible place

[David Howells]

Move the fallback arch_vma_name() to a sensible place (kernel/signal.c).

Currently it's in fs/proc/task_mmu.c, a file that is dependent on both
CONFIG_PROC_FS and CONFIG_MMU being enabled, but it's used from kernel/signal.c
from where it is called unconditionally.

Signed-Off-By: David Howells <dhowells@redhat.com>
---
warthog>diffstat -p1 nommu-arch_vma_name-2618rc5mm1.diff 
 fs/proc/task_mmu.c |    5 -----
 kernel/signal.c    |    5 +++++
 2 files changed, 5 insertions(+), 5 deletions(-)

diff -urp ../kernels/linux-2.6.18-rc5-mm1/fs/proc/task_mmu.c linux-2.6.18-rc5-mm1-frv/fs/proc/task_mmu.c
--- ../kernels/linux-2.6.18-rc5-mm1/fs/proc/task_mmu.c	2006-09-04 18:02:43.000000000 +0100
+++ linux-2.6.18-rc5-mm1-frv/fs/proc/task_mmu.c	2006-09-05 15:49:18.000000000 +0100
@@ -122,11 +122,6 @@ struct mem_size_stats
 	unsigned long private_dirty;
 };
 
-__attribute__((weak)) const char *arch_vma_name(struct vm_area_struct *vma)
-{
-	return NULL;
-}
-
 static int show_map_internal(struct seq_file *m, void *v, struct mem_size_stats *mss)
 {
 	struct proc_maps_private *priv = m->private;
diff -urp ../kernels/linux-2.6.18-rc5-mm1/kernel/signal.c linux-2.6.18-rc5-mm1-frv/kernel/signal.c
--- ../kernels/linux-2.6.18-rc5-mm1/kernel/signal.c	2006-09-04 18:03:32.000000000 +0100
+++ linux-2.6.18-rc5-mm1-frv/kernel/signal.c	2006-09-05 15:49:19.000000000 +0100
@@ -773,6 +773,11 @@ static void pad_len_spaces(int len)
 	printk("%*c", len, ' ');
 }
 
+__attribute__((weak)) const char *arch_vma_name(struct vm_area_struct *vma)
+{
+	return NULL;
+}
+
 static int print_vma(struct vm_area_struct *vma)
 {
 	struct mm_struct *mm = vma->vm_mm;

[PATCH] NOMMU: Provide page_mkclean() for NOMMU

[David Howells]

Provide a page_mkclean() implementation for NOMMU.  This doesn't do anything
except return successfully as there are no PTEs for it to play with.

This is only relevant to the -mm kernels.

Signed-Off-By: David Howells <dhowells@redhat.com>
---
warthog>diffstat -p1 nommu-page_mkclean-2618rc5mm1.diff 
 include/linux/rmap.h |    6 ++++++
 1 file changed, 6 insertions(+)

diff -urp ../kernels/linux-2.6.18-rc5-mm1/include/linux/rmap.h linux-2.6.18-rc5-mm1-frv/include/linux/rmap.h
--- ../kernels/linux-2.6.18-rc5-mm1/include/linux/rmap.h	2006-09-04 18:03:32.000000000 +0100
+++ linux-2.6.18-rc5-mm1-frv/include/linux/rmap.h	2006-09-05 15:34:35.000000000 +0100
@@ -120,6 +120,12 @@ int page_mkclean(struct page *);
 #define page_referenced(page,l) TestClearPageReferenced(page)
 #define try_to_unmap(page, refs) SWAP_FAIL
 
+static inline int page_mkclean(struct page *page)
+{
+	return 0;
+}
+
+
 #endif	/* CONFIG_MMU */
 
 /*

[PATCH] NOMMU: Make lib/ioremap.c conditional

[David Howells]

Make lib/ioremap.c conditional on !CONFIG_MMU.  It plays with PTEs which don't
exist under NOMMU conditions.

Signed-Off-By: David Howells <dhowells@redhat.com>
---
warthog>diffstat -p1 nommu-ioremap-2618rc5mm1.diff 
 lib/Makefile |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff -urp ../kernels/linux-2.6.18-rc5-mm1/lib/Makefile linux-2.6.18-rc5-mm1-frv/lib/Makefile
--- ../kernels/linux-2.6.18-rc5-mm1/lib/Makefile	2006-09-04 18:03:32.000000000 +0100
+++ linux-2.6.18-rc5-mm1-frv/lib/Makefile	2006-09-05 16:01:38.000000000 +0100
@@ -5,8 +5,9 @@
 lib-y := ctype.o string.o vsprintf.o cmdline.o \
 	 bust_spinlocks.o rbtree.o radix-tree.o dump_stack.o \
 	 idr.o div64.o int_sqrt.o bitmap.o extable.o prio_tree.o \
-	 sha1.o ioremap.o
+	 sha1.o
 
+lib-$(CONFIG_MMU) += ioremap.o
 lib-$(CONFIG_SMP) += cpumask.o
 
 lib-y	+= kobject.o kref.o kobject_uevent.o klist.o

[PATCH] FRV: do_gettimeofday() should no longer use tickadj

[David Howells]

Stop do_gettimeofday() on FRV from using tickadj, and model it after ARM
instead.

This patch also provides a placeholder macro for getting hardware timer data to
be filled in when such is available.

Signed-Off-By: David Howells <dhowells@redhat.com>
---
warthog>diffstat -p1 frv-tickadj-2618rc5mm1.diff 
 arch/frv/kernel/time.c |   20 +++++---------------
 1 file changed, 5 insertions(+), 15 deletions(-)

diff -urp ../kernels/linux-2.6.18-rc5-mm1/arch/frv/kernel/time.c linux-2.6.18-rc5-mm1-frv/arch/frv/kernel/time.c
--- ../kernels/linux-2.6.18-rc5-mm1/arch/frv/kernel/time.c	2006-09-04 18:03:14.000000000 +0100
+++ linux-2.6.18-rc5-mm1-frv/arch/frv/kernel/time.c	2006-09-05 15:44:42.000000000 +0100
@@ -31,6 +31,9 @@
 
 #define TICK_SIZE (tick_nsec / 1000)
 
+/* H/W clock data if we can get it (in microseconds) */
+#define FRV_HW_CLOCK_DATA (0)
+
 unsigned long __nongprelbss __clkin_clock_speed_HZ;
 unsigned long __nongprelbss __ext_bus_clock_speed_HZ;
 unsigned long __nongprelbss __res_bus_clock_speed_HZ;
@@ -148,23 +151,10 @@ void do_gettimeofday(struct timeval *tv)
 {
 	unsigned long seq;
 	unsigned long usec, sec;
-	unsigned long max_ntp_tick;
 
 	do {
 		seq = read_seqbegin(&xtime_lock);
-
-		usec = 0;
-
-		/*
-		 * If time_adjust is negative then NTP is slowing the clock
-		 * so make sure not to go into next possible interval.
-		 * Better to lose some accuracy than have time go backwards..
-		 */
-		if (unlikely(time_adjust < 0)) {
-			max_ntp_tick = (USEC_PER_SEC / HZ) - tickadj;
-			usec = min(usec, max_ntp_tick);
-		}
-
+		usec = FRV_HW_CLOCK_DATA;
 		sec = xtime.tv_sec;
 		usec += (xtime.tv_nsec / 1000);
 	} while (read_seqretry(&xtime_lock, seq));
@@ -195,7 +185,7 @@ int do_settimeofday(struct timespec *tv)
 	 * wall time.  Discover what correction gettimeofday() would have
 	 * made, and then undo it!
 	 */
-	nsec -= 0 * NSEC_PER_USEC;
+	nsec -= FRV_HW_CLOCK_DATA * NSEC_PER_USEC;
 
 	wtm_sec  = wall_to_monotonic.tv_sec + (xtime.tv_sec - sec);
 	wtm_nsec = wall_to_monotonic.tv_nsec + (xtime.tv_nsec - nsec);

Re: 2.6.18-rc5-mm1 dependency on curses devel still there

[Steve Fox]

On Fri, 01 Sep 2006 01:58:18 -0700, Andrew Morton wrote:

> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc5/2.6.18-rc5-mm1/

The dependency on having curses installed reported by Andy Whitcroft for
2.6.18-rc4-mm1 is still there. I've included the prior discussion below.
Could this patch be reverted or fixed to not build things which use
curses? Thanks.

Andy Whitcroft wrote:
> Andy Whitcroft wrote:
> > Andrew Morton wrote:
> >> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm1/ 
> >>
> > 
> >>  git-lxdialog.patch
> > 
> > This tree seems to change the Makefile dependancies in the kconfig 
> > subdirectory such that a plain compile of the kernel leads to an attempt 
> > to build the menuconfig targets.  This in turn adds a new dependancy on 
> > the curses development libraries.
> > 
> >   08/15/06-05:23:09 building kernel - make -j4 vmlinux
> >     HOSTCC  scripts/kconfig/lxdialog/checklist.o
> >   In file included from scripts/kconfig/lxdialog/checklist.c:24:
> >               scripts/kconfig/lxdialog/dialog.h:31:20: error: curses.h:
> >               No such file or directory
> > 
> > This seems to come from this rather innocent sounding change in that tree:
> > 
> > commit 9238251dddc15b52656e70b74dffe56193d01215
> > Author: Sam Ravnborg <sam@mars.ravnborg.org>
> > Date:   Mon Jul 24 21:40:46 2006 +0200
> > 
> >     kconfig/lxdialog: refactor color support
> > 
> 
> Ok, reading the patch as if its git output isn't a good plan.  The 
> changeset appears to be this one:
> 
> commit 49140e7b29bb1fcc195efef3e1c54c144dd2eff7
> Author: Sam Ravnborg <sam@mars.ravnborg.org>
> Date:   Thu Jul 27 22:10:27 2006 +0200
> 
>      kconfig/menuconfig: lxdialog is now built-in
> 
> 
> > which also seems to change the Makefile about, specifically bringing the 
> > sub Makefile into the top level one.
> > 
> > [...]
> > -       $(Q)$(MAKE) $(build)=scripts/kconfig/lxdialog
> > [...]
> > +# lxdialog stuff
> > +check-lxdialog  := $(srctree)/$(src)/lxdialog/check-lxdialog.sh
> > [...]
> > 
> > Sam?
> > 
> > -apw

Andy Whitcroft wrote:
> Sam Ravnborg wrote:
> > On Wed, Aug 16, 2006 at 10:41:59AM +0100, Andy Whitcroft wrote:
> >> This tree seems to change the Makefile dependancies in the kconfig 
> >> subdirectory such that a plain compile of the kernel leads to an attempt 
> >> to build the menuconfig targets.  This in turn adds a new dependancy on 
> >> the curses development libraries.
> > What I see is that "make defconfig" builds _all_ *config targets -
> > strange...
> 
> Well it could be trying to build them all for me too, but as I don't 
> have curses development libraries it would fail at that point.  I don't 
> think we want it to build the ones its not using.  Thats daft :).
-- 

Steve Fox
IBM Linux Technology Center

Re: 2.6.18-rc5-mm1

[Bjorn Helgaas]

On Friday 01 September 2006 10:40, Maciej Rutecki wrote:
> ACPI error (similar like in 2.6.18-rc4-mm3):
> 
> [   23.790140] ACPI Error (utglobal-0125): Unknown exception code:
> 0xFFFFFFEA [20060707]
> [   23.790318]  [<c0221ba9>] acpi_format_exception+0x9f/0xa9
> [   23.790445]  [<c021edf9>] acpi_ut_status_exit+0x2e/0x56
> [   23.790554]  [<c021b3ac>] acpi_walk_resources+0x103/0x10d
> [   23.790661]  [<c022901c>] acpi_reserve_io_ranges+0x0/0xfc
> [   23.790774]  [<c022900f>] acpi_motherboard_add+0x1f/0x2c
> [   23.790880]  [<c0228154>] acpi_bus_driver_init+0x2c/0x78
> [   23.790987]  [<c02285b0>] acpi_bus_register_driver+0x60/0xb1
> [   23.791094]  [<c038a8da>] acpi_motherboard_init+0xa/0xf5
> [   23.791205]  [<c01002b0>] init+0x70/0x280
> [   23.791309]  [<c0102db2>] ret_from_fork+0x6/0x14
> [   23.791420]  [<c0100240>] init+0x0/0x280
> [   23.791520]  [<c0100240>] init+0x0/0x280
> [   23.791621]  [<c0103997>] kernel_thread_helper+0x7/0x10

This ACPI "unknown exception code" problem is the same one reported here:
  http://www.mail-archive.com/linux-acpi%40vger.kernel.org/msg02873.html

Basically, we just need to revert this:
  http://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm3/broken-out/hot-add-mem-x86_64-acpi-motherboard-fix.patch

The above patch happened to fix a hot-add memory problem, but it was
the wrong fix, and we're working out a better one.

Re: [2.6.18-rc5-mm1 ACPI] Unknown exception code: 0xFFFFFFEA

[Bjorn Helgaas]

On Sunday 03 September 2006 03:09, Mike Galbraith wrote:
> My single P4/HT box tossed the below on boot.
> 
> ACPI Error (utglobal-0125): Unknown exception code: 0xFFFFFFEA [20060707]
>  [<c1004089>] dump_trace+0x1d7/0x206
>  [<c10040d2>] show_trace_log_lvl+0x1a/0x30
>  [<c100484c>] show_trace+0x12/0x14
>  [<c100496d>] dump_stack+0x19/0x1b
>  [<c1229702>] acpi_format_exception+0xa2/0xaf
>  [<c1226824>] acpi_ut_status_exit+0x2b/0x58
>  [<c1222cbc>] acpi_walk_resources+0xfd/0x109
>  [<c12393ca>] acpi_motherboard_add+0x22/0x32
>  [<c123848e>] acpi_bus_driver_init+0x2a/0x7a
>  [<c123892c>] acpi_bus_register_driver+0x8b/0xfb
>  [<c15ebd20>] acpi_motherboard_init+0xd/0xf9
>  [<c10003b1>] init+0x108/0x300
>  [<c1003c93>] kernel_thread_helper+0x7/0x14

This ACPI "unknown exception code" problem is the same one reported here:
  http://www.mail-archive.com/linux-acpi%40vger.kernel.org/msg02873.html

Basically, we just need to revert this:
  http://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm3/broken-out/hot-add-mem-x86_64-acpi-motherboard-fix.patch

The above patch happened to fix a hot-add memory problem, but it was
the wrong fix, and we're working out a better one.

Re: lockdep oddity

[Ingo Molnar]

* Heiko Carstens <heiko.carstens@de.ibm.com> wrote:

> The lock validator gives me this (latest -mm and 2.6.18-rc6):
> 
> ===================================== 
> [ BUG: bad unlock balance detected! ] 
> ------------------------------------- 
> swapper/0 is trying to release lock (resource_lock) at:
> [<0000000000042842>] request_resource+0x52/0x88 
> but there are no more locks to release! 
> 
> The reason is that the BUILD_LOCK_OPS macros in kernel/lockdep.c don't 
> contain any of the *_acquire calls, while all of the _unlock functions 
> contain a *_release call. Hence I get immediately unbalanced locks.

hmmm ... that sounds like a bug. Weird - i recently ran 
PREEMPT+SMP+LOCKDEP kernels and didnt notice this.

> Found this will debugging some random memory corruptions that happen 
> when CONFIG_PROVE_LOCKING and CONFIG_PROFILE_LIKELY are both on. 
> Switching both off or having only one of them on seems to work.

previously i had some weirdnesses with PROFILE_LIKELY too, they were 
caused by it generating cross-calls from within lockdep. Do the 
corruptions go away if you remove all likely() and unlikely() markings 
from kernel/lockdep.c?

	Ingo

Re: lockdep oddity

[Ingo Molnar]

* Hua Zhong <hzhong@gmail.com> wrote:

> Maybe we should define raw __likely/__unlikely which behave the same 
> way as the vanilla and use them in places like spinlocks to avoid 
> these weird problems.

yes - but only once the true reason for the oddity is debugged.

	Ingo

RE: lockdep oddity

[Hua Zhong]

Maybe we should define raw __likely/__unlikely which behave the same way as the vanilla and use them in places like spinlocks to
avoid these weird problems.

> * Heiko Carstens <heiko.carstens@de.ibm.com> wrote:
> 
> > The lock validator gives me this (latest -mm and 2.6.18-rc6):
> > 
> > =====================================
> > [ BUG: bad unlock balance detected! ]
> > -------------------------------------
> > swapper/0 is trying to release lock (resource_lock) at:
> > [<0000000000042842>] request_resource+0x52/0x88 but there 
> are no more 
> > locks to release!
> > 
> > The reason is that the BUILD_LOCK_OPS macros in 
> kernel/lockdep.c don't 
> > contain any of the *_acquire calls, while all of the 
> _unlock functions 
> > contain a *_release call. Hence I get immediately unbalanced locks.
> 
> hmmm ... that sounds like a bug. Weird - i recently ran 
> PREEMPT+SMP+LOCKDEP kernels and didnt notice this.
> 
> > Found this will debugging some random memory corruptions 
> that happen 
> > when CONFIG_PROVE_LOCKING and CONFIG_PROFILE_LIKELY are both on.
> > Switching both off or having only one of them on seems to work.
> 
> previously i had some weirdnesses with PROFILE_LIKELY too, 
> they were caused by it generating cross-calls from within 
> lockdep. Do the corruptions go away if you remove all 
> likely() and unlikely() markings from kernel/lockdep.c?
> 
> 	Ingo

Re: lockdep oddity

[Ingo Molnar]

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

> > The reason is that the BUILD_LOCK_OPS macros in kernel/lockdep.c 
> > don't contain any of the *_acquire calls, while all of the _unlock 
> > functions contain a *_release call. Hence I get immediately 
> > unbalanced locks.
> 
> hmmm ... that sounds like a bug. Weird - i recently ran 
> PREEMPT+SMP+LOCKDEP kernels and didnt notice this.

ok, the reason i didnt find this problem is because this is fixed in my 
tree, but i didnt realize that it's a fix also for upstream ...

The patch below is what is in my tree, but that needs separation from 
other changes. I'll distill a patch for upstream.

	Ingo

NOT-Signed-off-by: Ingo Molnar <mingo@elte.hu>

Index: linux/kernel/spinlock.c
===================================================================
--- linux.orig/kernel/spinlock.c
+++ linux/kernel/spinlock.c
@@ -20,14 +20,14 @@
  * Generic declaration of the raw read_trylock() function,
  * architectures are supposed to optimize this:
  */
-int __lockfunc generic__raw_read_trylock(raw_rwlock_t *lock)
+int __lockfunc generic_raw_read_trylock(raw_rwlock_t *lock)
 {
-	__raw_read_lock(lock);
+	_raw_read_lock(lock);
 	return 1;
 }
-EXPORT_SYMBOL(generic__raw_read_trylock);
+EXPORT_SYMBOL(generic_raw_read_trylock);
 
-int __lockfunc _spin_trylock(spinlock_t *lock)
+int __lockfunc __spin_trylock(raw_spinlock_t *lock)
 {
 	preempt_disable();
 	if (_raw_spin_trylock(lock)) {
@@ -38,9 +38,46 @@ int __lockfunc _spin_trylock(spinlock_t 
 	preempt_enable();
 	return 0;
 }
-EXPORT_SYMBOL(_spin_trylock);
+EXPORT_SYMBOL(__spin_trylock);
+
+int __lockfunc __spin_trylock_irq(raw_spinlock_t *lock)
+{
+	local_irq_disable();
+	preempt_disable();
+
+	if (_raw_spin_trylock(lock)) {
+		spin_acquire(&lock->dep_map, 0, 1, _RET_IP_);
+		return 1;
+	}
+
+	__preempt_enable_no_resched();
+	local_irq_enable();
+	preempt_check_resched();
+
+	return 0;
+}
+EXPORT_SYMBOL(__spin_trylock_irq);
 
-int __lockfunc _read_trylock(rwlock_t *lock)
+int __lockfunc __spin_trylock_irqsave(raw_spinlock_t *lock,
+					 unsigned long *flags)
+{
+	local_irq_save(*flags);
+	preempt_disable();
+
+	if (_raw_spin_trylock(lock)) {
+		spin_acquire(&lock->dep_map, 0, 1, _RET_IP_);
+		return 1;
+	}
+
+	__preempt_enable_no_resched();
+	local_irq_restore(*flags);
+	preempt_check_resched();
+
+	return 0;
+}
+EXPORT_SYMBOL(__spin_trylock_irqsave);
+
+int __lockfunc __read_trylock(raw_rwlock_t *lock)
 {
 	preempt_disable();
 	if (_raw_read_trylock(lock)) {
@@ -51,9 +88,9 @@ int __lockfunc _read_trylock(rwlock_t *l
 	preempt_enable();
 	return 0;
 }
-EXPORT_SYMBOL(_read_trylock);
+EXPORT_SYMBOL(__read_trylock);
 
-int __lockfunc _write_trylock(rwlock_t *lock)
+int __lockfunc __write_trylock(raw_rwlock_t *lock)
 {
 	preempt_disable();
 	if (_raw_write_trylock(lock)) {
@@ -64,7 +101,7 @@ int __lockfunc _write_trylock(rwlock_t *
 	preempt_enable();
 	return 0;
 }
-EXPORT_SYMBOL(_write_trylock);
+EXPORT_SYMBOL(__write_trylock);
 
 /*
  * If lockdep is enabled then we use the non-preemption spin-ops
@@ -72,17 +109,17 @@ EXPORT_SYMBOL(_write_trylock);
  * not re-enabled during lock-acquire (which the preempt-spin-ops do):
  */
 #if !defined(CONFIG_PREEMPT) || !defined(CONFIG_SMP) || \
-	defined(CONFIG_PROVE_LOCKING)
+	defined(CONFIG_DEBUG_LOCK_ALLOC) || defined(CONFIG_PREEMPT_RT)
 
-void __lockfunc _read_lock(rwlock_t *lock)
+void __lockfunc __read_lock(raw_rwlock_t *lock)
 {
 	preempt_disable();
 	rwlock_acquire_read(&lock->dep_map, 0, 0, _RET_IP_);
 	_raw_read_lock(lock);
 }
-EXPORT_SYMBOL(_read_lock);
+EXPORT_SYMBOL(__read_lock);
 
-unsigned long __lockfunc _spin_lock_irqsave(spinlock_t *lock)
+unsigned long __lockfunc __spin_lock_irqsave(raw_spinlock_t *lock)
 {
 	unsigned long flags;
 
@@ -101,27 +138,27 @@ unsigned long __lockfunc _spin_lock_irqs
 #endif
 	return flags;
 }
-EXPORT_SYMBOL(_spin_lock_irqsave);
+EXPORT_SYMBOL(__spin_lock_irqsave);
 
-void __lockfunc _spin_lock_irq(spinlock_t *lock)
+void __lockfunc __spin_lock_irq(raw_spinlock_t *lock)
 {
 	local_irq_disable();
 	preempt_disable();
 	spin_acquire(&lock->dep_map, 0, 0, _RET_IP_);
 	_raw_spin_lock(lock);
 }
-EXPORT_SYMBOL(_spin_lock_irq);
+EXPORT_SYMBOL(__spin_lock_irq);
 
-void __lockfunc _spin_lock_bh(spinlock_t *lock)
+void __lockfunc __spin_lock_bh(raw_spinlock_t *lock)
 {
 	local_bh_disable();
 	preempt_disable();
 	spin_acquire(&lock->dep_map, 0, 0, _RET_IP_);
 	_raw_spin_lock(lock);
 }
-EXPORT_SYMBOL(_spin_lock_bh);
+EXPORT_SYMBOL(__spin_lock_bh);
 
-unsigned long __lockfunc _read_lock_irqsave(rwlock_t *lock)
+unsigned long __lockfunc __read_lock_irqsave(raw_rwlock_t *lock)
 {
 	unsigned long flags;
 
@@ -131,27 +168,27 @@ unsigned long __lockfunc _read_lock_irqs
 	_raw_read_lock(lock);
 	return flags;
 }
-EXPORT_SYMBOL(_read_lock_irqsave);
+EXPORT_SYMBOL(__read_lock_irqsave);
 
-void __lockfunc _read_lock_irq(rwlock_t *lock)
+void __lockfunc __read_lock_irq(raw_rwlock_t *lock)
 {
 	local_irq_disable();
 	preempt_disable();
 	rwlock_acquire_read(&lock->dep_map, 0, 0, _RET_IP_);
 	_raw_read_lock(lock);
 }
-EXPORT_SYMBOL(_read_lock_irq);
+EXPORT_SYMBOL(__read_lock_irq);
 
-void __lockfunc _read_lock_bh(rwlock_t *lock)
+void __lockfunc __read_lock_bh(raw_rwlock_t *lock)
 {
 	local_bh_disable();
 	preempt_disable();
 	rwlock_acquire_read(&lock->dep_map, 0, 0, _RET_IP_);
 	_raw_read_lock(lock);
 }
-EXPORT_SYMBOL(_read_lock_bh);
+EXPORT_SYMBOL(__read_lock_bh);
 
-unsigned long __lockfunc _write_lock_irqsave(rwlock_t *lock)
+unsigned long __lockfunc __write_lock_irqsave(raw_rwlock_t *lock)
 {
 	unsigned long flags;
 
@@ -161,43 +198,43 @@ unsigned long __lockfunc _write_lock_irq
 	_raw_write_lock(lock);
 	return flags;
 }
-EXPORT_SYMBOL(_write_lock_irqsave);
+EXPORT_SYMBOL(__write_lock_irqsave);
 
-void __lockfunc _write_lock_irq(rwlock_t *lock)
+void __lockfunc __write_lock_irq(raw_rwlock_t *lock)
 {
 	local_irq_disable();
 	preempt_disable();
 	rwlock_acquire(&lock->dep_map, 0, 0, _RET_IP_);
 	_raw_write_lock(lock);
 }
-EXPORT_SYMBOL(_write_lock_irq);
+EXPORT_SYMBOL(__write_lock_irq);
 
-void __lockfunc _write_lock_bh(rwlock_t *lock)
+void __lockfunc __write_lock_bh(raw_rwlock_t *lock)
 {
 	local_bh_disable();
 	preempt_disable();
 	rwlock_acquire(&lock->dep_map, 0, 0, _RET_IP_);
 	_raw_write_lock(lock);
 }
-EXPORT_SYMBOL(_write_lock_bh);
+EXPORT_SYMBOL(__write_lock_bh);
 
-void __lockfunc _spin_lock(spinlock_t *lock)
+void __lockfunc __spin_lock(raw_spinlock_t *lock)
 {
 	preempt_disable();
 	spin_acquire(&lock->dep_map, 0, 0, _RET_IP_);
 	_raw_spin_lock(lock);
 }
 
-EXPORT_SYMBOL(_spin_lock);
+EXPORT_SYMBOL(__spin_lock);
 
-void __lockfunc _write_lock(rwlock_t *lock)
+void __lockfunc __write_lock(raw_rwlock_t *lock)
 {
 	preempt_disable();
 	rwlock_acquire(&lock->dep_map, 0, 0, _RET_IP_);
 	_raw_write_lock(lock);
 }
 
-EXPORT_SYMBOL(_write_lock);
+EXPORT_SYMBOL(__write_lock);
 
 #else /* CONFIG_PREEMPT: */
 
@@ -210,7 +247,7 @@ EXPORT_SYMBOL(_write_lock);
  */
 
 #define BUILD_LOCK_OPS(op, locktype)					\
-void __lockfunc _##op##_lock(locktype##_t *lock)			\
+void __lockfunc __##op##_lock(locktype##_t *lock)			\
 {									\
 	for (;;) {							\
 		preempt_disable();					\
@@ -220,15 +257,16 @@ void __lockfunc _##op##_lock(locktype##_
 									\
 		if (!(lock)->break_lock)				\
 			(lock)->break_lock = 1;				\
-		while (!op##_can_lock(lock) && (lock)->break_lock)	\
+		while (!__raw_##op##_can_lock(&(lock)->raw_lock) &&	\
+			       		(lock)->break_lock)		\
 			cpu_relax();					\
 	}								\
 	(lock)->break_lock = 0;						\
 }									\
 									\
-EXPORT_SYMBOL(_##op##_lock);						\
+EXPORT_SYMBOL(__##op##_lock);						\
 									\
-unsigned long __lockfunc _##op##_lock_irqsave(locktype##_t *lock)	\
+unsigned long __lockfunc __##op##_lock_irqsave(locktype##_t *lock)	\
 {									\
 	unsigned long flags;						\
 									\
@@ -242,23 +280,24 @@ unsigned long __lockfunc _##op##_lock_ir
 									\
 		if (!(lock)->break_lock)				\
 			(lock)->break_lock = 1;				\
-		while (!op##_can_lock(lock) && (lock)->break_lock)	\
+		while (!__raw_##op##_can_lock(&(lock)->raw_lock) &&	\
+						 (lock)->break_lock)	\
 			cpu_relax();					\
 	}								\
 	(lock)->break_lock = 0;						\
 	return flags;							\
 }									\
 									\
-EXPORT_SYMBOL(_##op##_lock_irqsave);					\
+EXPORT_SYMBOL(__##op##_lock_irqsave);					\
 									\
-void __lockfunc _##op##_lock_irq(locktype##_t *lock)			\
+void __lockfunc __##op##_lock_irq(locktype##_t *lock)			\
 {									\
-	_##op##_lock_irqsave(lock);					\
+	__##op##_lock_irqsave(lock);					\
 }									\
 									\
-EXPORT_SYMBOL(_##op##_lock_irq);					\
+EXPORT_SYMBOL(__##op##_lock_irq);					\
 									\
-void __lockfunc _##op##_lock_bh(locktype##_t *lock)			\
+void __lockfunc __##op##_lock_bh(locktype##_t *lock)			\
 {									\
 	unsigned long flags;						\
 									\
@@ -267,147 +306,161 @@ void __lockfunc _##op##_lock_bh(locktype
 	/* irq-disabling. We use the generic preemption-aware	*/	\
 	/* function:						*/	\
 	/**/								\
-	flags = _##op##_lock_irqsave(lock);				\
+	flags = __##op##_lock_irqsave(lock);				\
 	local_bh_disable();						\
 	local_irq_restore(flags);					\
 }									\
 									\
-EXPORT_SYMBOL(_##op##_lock_bh)
+EXPORT_SYMBOL(__##op##_lock_bh)
 
 /*
  * Build preemption-friendly versions of the following
  * lock-spinning functions:
  *
- *         _[spin|read|write]_lock()
- *         _[spin|read|write]_lock_irq()
- *         _[spin|read|write]_lock_irqsave()
- *         _[spin|read|write]_lock_bh()
+ *         __[spin|read|write]_lock()
+ *         __[spin|read|write]_lock_irq()
+ *         __[spin|read|write]_lock_irqsave()
+ *         __[spin|read|write]_lock_bh()
  */
-BUILD_LOCK_OPS(spin, spinlock);
-BUILD_LOCK_OPS(read, rwlock);
-BUILD_LOCK_OPS(write, rwlock);
+BUILD_LOCK_OPS(spin, raw_spinlock);
+BUILD_LOCK_OPS(read, raw_rwlock);
+BUILD_LOCK_OPS(write, raw_rwlock);
 
 #endif /* CONFIG_PREEMPT */
 
 #ifdef CONFIG_DEBUG_LOCK_ALLOC
 
-void __lockfunc _spin_lock_nested(spinlock_t *lock, int subclass)
+void __lockfunc __spin_lock_nested(raw_spinlock_t *lock, int subclass)
 {
 	preempt_disable();
 	spin_acquire(&lock->dep_map, subclass, 0, _RET_IP_);
 	_raw_spin_lock(lock);
 }
 
-EXPORT_SYMBOL(_spin_lock_nested);
+EXPORT_SYMBOL(__spin_lock_nested);
 
 #endif
 
-void __lockfunc _spin_unlock(spinlock_t *lock)
+void __lockfunc __spin_unlock(raw_spinlock_t *lock)
 {
 	spin_release(&lock->dep_map, 1, _RET_IP_);
 	_raw_spin_unlock(lock);
 	preempt_enable();
 }
-EXPORT_SYMBOL(_spin_unlock);
+EXPORT_SYMBOL(__spin_unlock);
 
-void __lockfunc _write_unlock(rwlock_t *lock)
+void __lockfunc __spin_unlock_no_resched(raw_spinlock_t *lock)
+{
+	spin_release(&lock->dep_map, 1, _RET_IP_);
+	_raw_spin_unlock(lock);
+	__preempt_enable_no_resched();
+}
+/* not exported */
+
+void __lockfunc __write_unlock(raw_rwlock_t *lock)
 {
 	rwlock_release(&lock->dep_map, 1, _RET_IP_);
 	_raw_write_unlock(lock);
 	preempt_enable();
 }
-EXPORT_SYMBOL(_write_unlock);
+EXPORT_SYMBOL(__write_unlock);
 
-void __lockfunc _read_unlock(rwlock_t *lock)
+void __lockfunc __read_unlock(raw_rwlock_t *lock)
 {
 	rwlock_release(&lock->dep_map, 1, _RET_IP_);
 	_raw_read_unlock(lock);
 	preempt_enable();
 }
-EXPORT_SYMBOL(_read_unlock);
+EXPORT_SYMBOL(__read_unlock);
 
-void __lockfunc _spin_unlock_irqrestore(spinlock_t *lock, unsigned long flags)
+void __lockfunc __spin_unlock_irqrestore(raw_spinlock_t *lock, unsigned long flags)
 {
 	spin_release(&lock->dep_map, 1, _RET_IP_);
 	_raw_spin_unlock(lock);
+	__preempt_enable_no_resched();
 	local_irq_restore(flags);
-	preempt_enable();
+	preempt_check_resched();
 }
-EXPORT_SYMBOL(_spin_unlock_irqrestore);
+EXPORT_SYMBOL(__spin_unlock_irqrestore);
 
-void __lockfunc _spin_unlock_irq(spinlock_t *lock)
+void __lockfunc __spin_unlock_irq(raw_spinlock_t *lock)
 {
 	spin_release(&lock->dep_map, 1, _RET_IP_);
 	_raw_spin_unlock(lock);
+	__preempt_enable_no_resched();
 	local_irq_enable();
-	preempt_enable();
+	preempt_check_resched();
 }
-EXPORT_SYMBOL(_spin_unlock_irq);
+EXPORT_SYMBOL(__spin_unlock_irq);
 
-void __lockfunc _spin_unlock_bh(spinlock_t *lock)
+void __lockfunc __spin_unlock_bh(raw_spinlock_t *lock)
 {
 	spin_release(&lock->dep_map, 1, _RET_IP_);
 	_raw_spin_unlock(lock);
-	preempt_enable_no_resched();
+	__preempt_enable_no_resched();
 	local_bh_enable_ip((unsigned long)__builtin_return_address(0));
 }
-EXPORT_SYMBOL(_spin_unlock_bh);
+EXPORT_SYMBOL(__spin_unlock_bh);
 
-void __lockfunc _read_unlock_irqrestore(rwlock_t *lock, unsigned long flags)
+void __lockfunc __read_unlock_irqrestore(raw_rwlock_t *lock, unsigned long flags)
 {
 	rwlock_release(&lock->dep_map, 1, _RET_IP_);
 	_raw_read_unlock(lock);
+	__preempt_enable_no_resched();
 	local_irq_restore(flags);
-	preempt_enable();
+	preempt_check_resched();
 }
-EXPORT_SYMBOL(_read_unlock_irqrestore);
+EXPORT_SYMBOL(__read_unlock_irqrestore);
 
-void __lockfunc _read_unlock_irq(rwlock_t *lock)
+void __lockfunc __read_unlock_irq(raw_rwlock_t *lock)
 {
 	rwlock_release(&lock->dep_map, 1, _RET_IP_);
 	_raw_read_unlock(lock);
+	__preempt_enable_no_resched();
 	local_irq_enable();
-	preempt_enable();
+	preempt_check_resched();
 }
-EXPORT_SYMBOL(_read_unlock_irq);
+EXPORT_SYMBOL(__read_unlock_irq);
 
-void __lockfunc _read_unlock_bh(rwlock_t *lock)
+void __lockfunc __read_unlock_bh(raw_rwlock_t *lock)
 {
 	rwlock_release(&lock->dep_map, 1, _RET_IP_);
 	_raw_read_unlock(lock);
-	preempt_enable_no_resched();
+	__preempt_enable_no_resched();
 	local_bh_enable_ip((unsigned long)__builtin_return_address(0));
 }
-EXPORT_SYMBOL(_read_unlock_bh);
+EXPORT_SYMBOL(__read_unlock_bh);
 
-void __lockfunc _write_unlock_irqrestore(rwlock_t *lock, unsigned long flags)
+void __lockfunc __write_unlock_irqrestore(raw_rwlock_t *lock, unsigned long flags)
 {
 	rwlock_release(&lock->dep_map, 1, _RET_IP_);
 	_raw_write_unlock(lock);
+	__preempt_enable_no_resched();
 	local_irq_restore(flags);
-	preempt_enable();
+	preempt_check_resched();
 }
-EXPORT_SYMBOL(_write_unlock_irqrestore);
+EXPORT_SYMBOL(__write_unlock_irqrestore);
 
-void __lockfunc _write_unlock_irq(rwlock_t *lock)
+void __lockfunc __write_unlock_irq(raw_rwlock_t *lock)
 {
 	rwlock_release(&lock->dep_map, 1, _RET_IP_);
 	_raw_write_unlock(lock);
+	__preempt_enable_no_resched();
 	local_irq_enable();
-	preempt_enable();
+	preempt_check_resched();
 }
-EXPORT_SYMBOL(_write_unlock_irq);
+EXPORT_SYMBOL(__write_unlock_irq);
 
-void __lockfunc _write_unlock_bh(rwlock_t *lock)
+void __lockfunc __write_unlock_bh(raw_rwlock_t *lock)
 {
 	rwlock_release(&lock->dep_map, 1, _RET_IP_);
 	_raw_write_unlock(lock);
-	preempt_enable_no_resched();
+	__preempt_enable_no_resched();
 	local_bh_enable_ip((unsigned long)__builtin_return_address(0));
 }
-EXPORT_SYMBOL(_write_unlock_bh);
+EXPORT_SYMBOL(__write_unlock_bh);
 
-int __lockfunc _spin_trylock_bh(spinlock_t *lock)
+int __lockfunc __spin_trylock_bh(raw_spinlock_t *lock)
 {
 	local_bh_disable();
 	preempt_disable();
@@ -416,13 +469,13 @@ int __lockfunc _spin_trylock_bh(spinlock
 		return 1;
 	}
 
-	preempt_enable_no_resched();
+	__preempt_enable_no_resched();
 	local_bh_enable_ip((unsigned long)__builtin_return_address(0));
 	return 0;
 }
-EXPORT_SYMBOL(_spin_trylock_bh);
+EXPORT_SYMBOL(__spin_trylock_bh);
 
-int in_lock_functions(unsigned long addr)
+int in_lock_functions(unsigned long addr)
 {
 	/* Linker adds these: start and end of __lockfunc functions */
 	extern char __lock_text_start[], __lock_text_end[];

Re: lockdep oddity

[Ingo Molnar]

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

> * Ingo Molnar <mingo@elte.hu> wrote:
> 
> > > The reason is that the BUILD_LOCK_OPS macros in kernel/lockdep.c 
> > > don't contain any of the *_acquire calls, while all of the _unlock 
> > > functions contain a *_release call. Hence I get immediately 
> > > unbalanced locks.
> > 
> > hmmm ... that sounds like a bug. Weird - i recently ran 
> > PREEMPT+SMP+LOCKDEP kernels and didnt notice this.
> 
> ok, the reason i didnt find this problem is because this is fixed in 
> my tree, but i didnt realize that it's a fix also for upstream ...

actually ... it works fine in the upstream kernel due to this:

  * If lockdep is enabled then we use the non-preemption spin-ops
  * even on CONFIG_PREEMPT, because lockdep assumes that interrupts are
  * not re-enabled during lock-acquire (which the preempt-spin-ops do):
  */
 #if !defined(CONFIG_PREEMPT) || !defined(CONFIG_SMP) || \
         defined(CONFIG_DEBUG_LOCK_ALLOC)

so i'm wondering, how did you you manage to get into the 
BUILD_LOCK_OPS() branch?

	Ingo

Re: lockdep oddity

[Daniel Walker]

On Tue, 2006-09-05 at 15:03 +0200, Heiko Carstens wrote:

> 
> Found this will debugging some random memory corruptions that happen when
> CONFIG_PROVE_LOCKING and CONFIG_PROFILE_LIKELY are both on.
> Switching both off or having only one of them on seems to work.

There's potential for a some issues in current -mm , given the config
above. If you us the generic atomic operations
(asm-generic/bitops/atomic.h) for test_and_set_bit(). It eventually
calls into trace_hardirqs_off() and then back into likely profiling. 

What architecture are you running this on?

Daniel

Re: [PATCH] FRV: do_gettimeofday() should no longer use tickadj

[john stultz]

On Tue, 2006-09-05 at 16:35 +0100, David Howells wrote:
> Stop do_gettimeofday() on FRV from using tickadj, and model it after ARM
> instead.
> 
> This patch also provides a placeholder macro for getting hardware timer data to
> be filled in when such is available.

>From this patch it looks like the FRV arch could be trivially converted
to GENERIC_TIME.

Would you consider the following, totally untested patch?

Signed-off-by: John Stultz <johnstul@us.ibm.com>

 Kconfig       |    4 ++
 kernel/time.c |   81 ----------------------------------------------------------
 2 files changed, 4 insertions(+), 81 deletions(-)

diff --git a/arch/frv/Kconfig b/arch/frv/Kconfig
index 95a3892..a601a17 100644
--- a/arch/frv/Kconfig
+++ b/arch/frv/Kconfig
@@ -29,6 +29,10 @@ config GENERIC_HARDIRQS
 	bool
 	default n
 
+config GENERIC_TIME
+	bool
+	default y
+
 config TIME_LOW_RES
 	bool
 	default y
diff --git a/arch/frv/kernel/time.c b/arch/frv/kernel/time.c
index d5b64e1..68a77fe 100644
--- a/arch/frv/kernel/time.c
+++ b/arch/frv/kernel/time.c
@@ -32,8 +32,6 @@
 
 #define TICK_SIZE (tick_nsec / 1000)
 
-extern unsigned long wall_jiffies;
-
 unsigned long __nongprelbss __clkin_clock_speed_HZ;
 unsigned long __nongprelbss __ext_bus_clock_speed_HZ;
 unsigned long __nongprelbss __res_bus_clock_speed_HZ;
@@ -145,85 +143,6 @@ void time_init(void)
 }
 
 /*
- * This version of gettimeofday has near microsecond resolution.
- */
-void do_gettimeofday(struct timeval *tv)
-{
-	unsigned long seq;
-	unsigned long usec, sec;
-	unsigned long max_ntp_tick;
-
-	do {
-		unsigned long lost;
-
-		seq = read_seqbegin(&xtime_lock);
-
-		usec = 0;
-		lost = jiffies - wall_jiffies;
-
-		/*
-		 * If time_adjust is negative then NTP is slowing the clock
-		 * so make sure not to go into next possible interval.
-		 * Better to lose some accuracy than have time go backwards..
-		 */
-		if (unlikely(time_adjust < 0)) {
-			max_ntp_tick = (USEC_PER_SEC / HZ) - tickadj;
-			usec = min(usec, max_ntp_tick);
-
-			if (lost)
-				usec += lost * max_ntp_tick;
-		}
-		else if (unlikely(lost))
-			usec += lost * (USEC_PER_SEC / HZ);
-
-		sec = xtime.tv_sec;
-		usec += (xtime.tv_nsec / 1000);
-	} while (read_seqretry(&xtime_lock, seq));
-
-	while (usec >= 1000000) {
-		usec -= 1000000;
-		sec++;
-	}
-
-	tv->tv_sec = sec;
-	tv->tv_usec = usec;
-}
-
-EXPORT_SYMBOL(do_gettimeofday);
-
-int do_settimeofday(struct timespec *tv)
-{
-	time_t wtm_sec, sec = tv->tv_sec;
-	long wtm_nsec, nsec = tv->tv_nsec;
-
-	if ((unsigned long)tv->tv_nsec >= NSEC_PER_SEC)
-		return -EINVAL;
-
-	write_seqlock_irq(&xtime_lock);
-	/*
-	 * This is revolting. We need to set "xtime" correctly. However, the
-	 * value in this location is the value at the most recent update of
-	 * wall time.  Discover what correction gettimeofday() would have
-	 * made, and then undo it!
-	 */
-	nsec -= 0 * NSEC_PER_USEC;
-	nsec -= (jiffies - wall_jiffies) * TICK_NSEC;
-
-	wtm_sec  = wall_to_monotonic.tv_sec + (xtime.tv_sec - sec);
-	wtm_nsec = wall_to_monotonic.tv_nsec + (xtime.tv_nsec - nsec);
-
-	set_normalized_timespec(&xtime, sec, nsec);
-	set_normalized_timespec(&wall_to_monotonic, wtm_sec, wtm_nsec);
-
-	ntp_clear();
-	write_sequnlock_irq(&xtime_lock);
-	clock_was_set();
-	return 0;
-}
-
-EXPORT_SYMBOL(do_settimeofday);
-
-/*
  * Scheduler clock - returns current time in nanosec units.
  */
 unsigned long long sched_clock(void)

Re: lockdep oddity

[Heiko Carstens]

> > > > The reason is that the BUILD_LOCK_OPS macros in kernel/lockdep.c 
> > > > don't contain any of the *_acquire calls, while all of the _unlock 
> > > > functions contain a *_release call. Hence I get immediately 
> > > > unbalanced locks.
> > > 
> > > hmmm ... that sounds like a bug. Weird - i recently ran 
> > > PREEMPT+SMP+LOCKDEP kernels and didnt notice this.
> > 
> > ok, the reason i didnt find this problem is because this is fixed in 
> > my tree, but i didnt realize that it's a fix also for upstream ...
> 
> actually ... it works fine in the upstream kernel due to this:
> 
>   * If lockdep is enabled then we use the non-preemption spin-ops
>   * even on CONFIG_PREEMPT, because lockdep assumes that interrupts are
>   * not re-enabled during lock-acquire (which the preempt-spin-ops do):
>   */
>  #if !defined(CONFIG_PREEMPT) || !defined(CONFIG_SMP) || \
>          defined(CONFIG_DEBUG_LOCK_ALLOC)
> 
> so i'm wondering, how did you you manage to get into the 
> BUILD_LOCK_OPS() branch?

That seems to be code that isn't upstream. 2.6.18-rc5-mm1 as well as
Linus' current git tree have this:

/*
 * If lockdep is enabled then we use the non-preemption spin-ops
 * even on CONFIG_PREEMPT, because lockdep assumes that interrupts are
 * not re-enabled during lock-acquire (which the preempt-spin-ops do):
 */
#if !defined(CONFIG_PREEMPT) || !defined(CONFIG_SMP) || \
        defined(CONFIG_PROVE_LOCKING)

And yes, using CONFIG_DEBUG_LOCK_ALLOC instead of CONFIG_PROVE_LOCKING fixes
this for me :)

Re: lockdep oddity

[Heiko Carstens]

On Tue, Sep 05, 2006 at 01:07:47PM -0700, Daniel Walker wrote:
> On Tue, 2006-09-05 at 15:03 +0200, Heiko Carstens wrote:
> > Found this will debugging some random memory corruptions that happen when
> > CONFIG_PROVE_LOCKING and CONFIG_PROFILE_LIKELY are both on.
> > Switching both off or having only one of them on seems to work.
> 
> There's potential for a some issues in current -mm , given the config
> above. If you us the generic atomic operations
> (asm-generic/bitops/atomic.h) for test_and_set_bit(). It eventually
> calls into trace_hardirqs_off() and then back into likely profiling. 
> 
> What architecture are you running this on?

This was s390. We have our own bitops and trace_hardirqs_off() won't
be called for test_and_set_bit(). Must be something different.

Re: lockdep oddity

[Heiko Carstens]

> > Found this will debugging some random memory corruptions that happen 
> > when CONFIG_PROVE_LOCKING and CONFIG_PROFILE_LIKELY are both on. 
> > Switching both off or having only one of them on seems to work.
> 
> previously i had some weirdnesses with PROFILE_LIKELY too, they were 
> caused by it generating cross-calls from within lockdep. Do the 
> corruptions go away if you remove all likely() and unlikely() markings 
> from kernel/lockdep.c?

No, unfortunately that doesn't help. I'm also wondering why the profile
patch contains this:

+       if (ret)
+               likeliness->count[1]++;
+       else
+               likeliness->count[0]++;

This isn't smp safe. Is that on purpose or a bug?

Re: lockdep oddity

[Andrew Morton]

On Wed, 6 Sep 2006 09:20:43 +0200
Heiko Carstens <heiko.carstens@de.ibm.com> wrote:

> I'm also wondering why the profile
> patch contains this:
> 
> +       if (ret)
> +               likeliness->count[1]++;
> +       else
> +               likeliness->count[0]++;
> 
> This isn't smp safe. Is that on purpose or a bug?

Purposeful.   This is called from all contexts, including NMI.

Re: lockdep oddity

[Heiko Carstens]

On Wed, Sep 06, 2006 at 12:47:24AM -0700, Andrew Morton wrote:
> On Wed, 6 Sep 2006 09:20:43 +0200
> Heiko Carstens <heiko.carstens@de.ibm.com> wrote:
> 
> > I'm also wondering why the profile
> > patch contains this:
> > 
> > +       if (ret)
> > +               likeliness->count[1]++;
> > +       else
> > +               likeliness->count[0]++;
> > 
> > This isn't smp safe. Is that on purpose or a bug?
> 
> Purposeful.   This is called from all contexts, including NMI.

Why not use atomic_inc then? Or is there some architecture dependent
limitation that it can't be done in every context?

RE: lockdep oddity

[Hua Zhong]

We are just trading accuracy for speed here.

> On Wed, Sep 06, 2006 at 12:47:24AM -0700, Andrew Morton wrote:
> > On Wed, 6 Sep 2006 09:20:43 +0200
> > Heiko Carstens <heiko.carstens@de.ibm.com> wrote:
> > 
> > > I'm also wondering why the profile
> > > patch contains this:
> > > 
> > > +       if (ret)
> > > +               likeliness->count[1]++;
> > > +       else
> > > +               likeliness->count[0]++;
> > > 
> > > This isn't smp safe. Is that on purpose or a bug?
> > 
> > Purposeful.   This is called from all contexts, including NMI.
> 
> Why not use atomic_inc then? Or is there some architecture 
> dependent limitation that it can't be done in every context?

Re: lockdep oddity

[Ingo Molnar]

* Hua Zhong <hzhong@gmail.com> wrote:

> We are just trading accuracy for speed here.

no, we are trading _both_ accuracy and speed here! a global 'likeliness' 
pointer for commonly executed codepaths is causing global cacheline 
ping-pongs - which is as bad as it gets.

the right approach, which incidentally would also be perfectly accurate, 
is to store an alloc_percpu()-ed pointer at the call site, not the 
counter itself.

the current code needs more work before it can go upstream i think.

	Ingo

Re: [PATCH] FRV: do_gettimeofday() should no longer use tickadj

[David Howells]

john stultz <johnstul@us.ibm.com> wrote:

> From this patch it looks like the FRV arch could be trivially converted
> to GENERIC_TIME.
> 
> Would you consider the following, totally untested patch?

It certainly looks interesting.  I'll have to study the clocksource stuff -
some FRV CPUs have an effective TSC.

David

Re: [PATCH] FRV: do_gettimeofday() should no longer use tickadj

[Ingo Molnar]

* David Howells <dhowells@redhat.com> wrote:

> john stultz <johnstul@us.ibm.com> wrote:
> 
> > From this patch it looks like the FRV arch could be trivially 
> > converted to GENERIC_TIME.
> > 
> > Would you consider the following, totally untested patch?
> 
> It certainly looks interesting.  I'll have to study the clocksource 
> stuff - some FRV CPUs have an effective TSC.

btw., would be nice to convert it to genirq (and irqchips) too =B-) That 
would solve the kind of disable_irq_lockdep() breakage that was reported 
recently.

	Ingo

Re: lockdep oddity

[Ingo Molnar]

* Heiko Carstens <heiko.carstens@de.ibm.com> wrote:

> That seems to be code that isn't upstream. 2.6.18-rc5-mm1 as well as 
> Linus' current git tree have this:
> 
> /*
>  * If lockdep is enabled then we use the non-preemption spin-ops
>  * even on CONFIG_PREEMPT, because lockdep assumes that interrupts are
>  * not re-enabled during lock-acquire (which the preempt-spin-ops do):
>  */
> #if !defined(CONFIG_PREEMPT) || !defined(CONFIG_SMP) || \
>         defined(CONFIG_PROVE_LOCKING)
> 
> And yes, using CONFIG_DEBUG_LOCK_ALLOC instead of CONFIG_PROVE_LOCKING 
> fixes this for me :)

indeed, this is a very recent fix from Jarek Poplawski - not yet in 
Linus' tree but already in Andrew's.

	Ingo

---------->
From: Jarek Poplawski <jarkao2@o2.pl>

With

CONFIG_SMP=y
CONFIG_PREEMPT=y
CONFIG_LOCKDEP=y
CONFIG_DEBUG_LOCK_ALLOC=y
# CONFIG_PROVE_LOCKING is not set

spin_unlock_irqrestore() goes through lockdep but spin_lock_irqsave() doesn't.
Apparently, bad things happen.

Acked-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Andrew Morton <akpm@osdl.org>
---

 kernel/spinlock.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff -puN kernel/spinlock.c~lockdep-ifdef-fix kernel/spinlock.c
--- a/kernel/spinlock.c~lockdep-ifdef-fix
+++ a/kernel/spinlock.c
@@ -72,7 +72,7 @@ EXPORT_SYMBOL(_write_trylock);
  * not re-enabled during lock-acquire (which the preempt-spin-ops do):
  */
 #if !defined(CONFIG_PREEMPT) || !defined(CONFIG_SMP) || \
-	defined(CONFIG_PROVE_LOCKING)
+	defined(CONFIG_DEBUG_LOCK_ALLOC)
 
 void __lockfunc _read_lock(rwlock_t *lock)
 {
_

Re: lockdep oddity

[Heiko Carstens]

> > Found this will debugging some random memory corruptions that happen when
> > CONFIG_PROVE_LOCKING and CONFIG_PROFILE_LIKELY are both on.
> > Switching both off or having only one of them on seems to work.
> There's potential for a some issues in current -mm , given the config
> above. If you us the generic atomic operations
> (asm-generic/bitops/atomic.h) for test_and_set_bit(). It eventually
> calls into trace_hardirqs_off() and then back into likely profiling. 

Your patch has this in it too:

/* 
 * We check for constant values with __builtin_constant_p() since 
 * it's not interesting to profile them, and there is a compiler 
 * bug in gcc 3.x which blows up during constant evalution when 
 * CONFIG_PROFILE_LIKELY is turned on. 
 */ 
#define likely(x)       (__builtin_constant_p(x) ? (!!(x)) : __check_likely((x), 1)) 
#define unlikely(x)     (__builtin_constant_p(x) ? (!!(x)) : __check_likely((x), 0)) 

Could you define "blows up"? My reading of the text above is: "this code
below makes sure it does work with gcc 3.x as well".
Now I used gcc 3.4.1 and get random memory corruptions while with gcc 4.1.1
everything seems to be ok....

Re: [PATCH] FRV: do_gettimeofday() should no longer use tickadj

[David Howells]

Ingo Molnar <mingo@elte.hu> wrote:

> btw., would be nice to convert it to genirq (and irqchips) too =B-) That 
> would solve the kind of disable_irq_lockdep() breakage that was reported 
> recently.

I can think of reasons for not using that stuff also.

 (1) Passing "struct pt_regs *regs" around is a complete waste of resources on
     FRV.  It's in GR28 at all times and can thus be accessed directly.

 (2) All the little operations functions cause unnecessary jumping, jumps that
     icache lookahead can't predict because they're register-indirect.

 (3) ACK'ing and controlling interrupts has to be done by groups.

 (4) No account is taken of interrupt priority.

 (5) The FRV CPU doesn't tell me which IRQ source fired.  Much of the code
     I've got is stuff to try and work it out.  I could just blindly poll all
     the sources attached to a particular interrupt level, but that seems
     somehow less efficient.

David

BTW, have you looked at my patch to fix lockdep yet?

Re: [PATCH] FRV: Fix {dis,en}able_irq_lockdep_irqrestore compile error

[Ingo Molnar]

* David Howells <dhowells@redhat.com> wrote:

> Fix the lack of certain non-LOCKDEP stub functions in 
> linux/interrupt.h and also provide FRV with LOCKDEP variants.
> 
> This is to be applied to -mm kernel since not all of the functions 
> added exist in the main kernel.
> 
> Signed-Off-By: David Howells <dhowells@redhat.com>

Acked-by: Ingo Molnar <mingo@elte.hu>

	Ingo

Re: [PATCH] FRV: do_gettimeofday() should no longer use tickadj

[Ingo Molnar]

* David Howells <dhowells@redhat.com> wrote:

> Ingo Molnar <mingo@elte.hu> wrote:
> 
> > btw., would be nice to convert it to genirq (and irqchips) too =B-) That 
> > would solve the kind of disable_irq_lockdep() breakage that was reported 
> > recently.
> 
> I can think of reasons for not using that stuff also.
> 
>  (1) Passing "struct pt_regs *regs" around is a complete waste of 
>      resources on FRV.  It's in GR28 at all times and can thus be 
>      accessed directly.

we'll get rid of that pt_regs thing centrally, from all drivers at once 
- there's upstream buy-in for that already, and Thomas already generated 
a test-patch for that a few months ago. But it's not a big issue right 
now.

>  (2) All the little operations functions cause unnecessary jumping, 
>      jumps that icache lookahead can't predict because they're 
>      register-indirect.

this shouldnt be a big issue either - we use indirect jumps all around 
the kernel. CPUs are either smart enough to predict it, or they simply 
dont have that high penalties. (and if they have high penalties but dont 
optimize for it then genirq will be the last of their worries. The VFS 
and the MM is full of function pointers.)

>  (3) ACK'ing and controlling interrupts has to be done by groups.

please be more specific, how is this not possible via genirq?

>  (4) No account is taken of interrupt priority.

hm, i'm not sure what you mean - could you be more specific?

>  (5) The FRV CPU doesn't tell me which IRQ source fired.  Much of the 
>      code I've got is stuff to try and work it out.  I could just 
>      blindly poll all the sources attached to a particular interrupt 
>      level, but that seemssomehow less efficient.

but ... somehow the current FRV code does figure out which IRQ source 
fired, right? How is that a hindrance for a genirq/irqchips based 
design?

> BTW, have you looked at my patch to fix lockdep yet?

oops, i missed it - just acked it. (This problem too was a side-effect 
of FRV having its own IRQ layer.)

	Ingo

Re: lockdep oddity

[Daniel Walker]

On Wed, 2006-09-06 at 10:40 +0200, Ingo Molnar wrote:
> * Hua Zhong <hzhong@gmail.com> wrote:
> 
> > We are just trading accuracy for speed here.
> 
> no, we are trading _both_ accuracy and speed here! a global 'likeliness' 
> pointer for commonly executed codepaths is causing global cacheline 
> ping-pongs - which is as bad as it gets.

Up stream or no, would be better for it to again be light weight.

> the right approach, which incidentally would also be perfectly accurate, 
> is to store an alloc_percpu()-ed pointer at the call site, not the 
> counter itself.

I don't think it could be done via the macro. If it were called during
run time it would have to be special alloc_percpu() that didn't call
back into the profiling code (which almost everything does do).

> the current code needs more work before it can go upstream i think.

It was never really planned to go upstream. It's ultimately a debugging
feature that's really only needed in -mm .. 

Daniel

Re: lockdep oddity

[Heiko Carstens]

On Wed, Sep 06, 2006 at 07:19:19AM -0700, Daniel Walker wrote:
> > the current code needs more work before it can go upstream i think.
> 
> It was never really planned to go upstream. It's ultimately a debugging
> feature that's really only needed in -mm .. 

And I thought the -mm tree was supposed to contain only code that will
go upstream sooner or later (unless it gets dropped for some reason).

Re: lockdep oddity

[Daniel Walker]

On Wed, 2006-09-06 at 16:29 +0200, Heiko Carstens wrote:
> On Wed, Sep 06, 2006 at 07:19:19AM -0700, Daniel Walker wrote:
> > > the current code needs more work before it can go upstream i think.
> > 
> > It was never really planned to go upstream. It's ultimately a debugging
> > feature that's really only needed in -mm .. 
> 
> And I thought the -mm tree was supposed to contain only code that will
> go upstream sooner or later (unless it gets dropped for some reason).

Nope .. There are other -mm only patches. 

Daniel

Re: [PATCH] FRV: do_gettimeofday() should no longer use tickadj

[David Howells]

Ingo Molnar <mingo@elte.hu> wrote:

> we'll get rid of that pt_regs thing centrally, from all drivers at once 
> - there's upstream buy-in for that already, and Thomas already generated 
> a test-patch for that a few months ago. But it's not a big issue right 
> now.

Yay!  Can you give me a pointer to the patch?

> this shouldnt be a big issue either - we use indirect jumps all around 
> the kernel.

Yes, I know.  I'm sometimes concerned at just how fast indirect jumps (and even
direct calls) are proliferating.  Look at the read syscall path for something
like ext3 these days: it's like a pile of spaghetti.  That seems particularly
true of direct-IO where it seems to weave in and out of core code and the
filesystem as it goes down.  I'm also concerned about stack usage.

> CPUs are either smart enough to predict it

I was told a while back (2002?) not to use indirect pointers for some stuff
because CPUs _couldn't_ predict it.  Maybe this has changed in modern CPUs.

> >  (3) ACK'ing and controlling interrupts has to be done by groups.
> 
> please be more specific,

Under some circumstances I can work out which sources have triggered which
interrupts (there are various off-CPU FPGAs which implement auxiliary PICs that
do announce their sources), but the aux-PIC channels are grouped together upon
delivery to the CPU PIC, so some of the ACK'ing has to be done at the group
level.

> how is this not possible via genirq?

How is it possible with genirq?

Unless I tie all the grouped sources together into one virtual IRQ line, this
doesn't appear to be possible.  But doing that I might then also have a mixed
set of "flow" types in any particular IRQ.

> >  (4) No account is taken of interrupt priority.
> 
> hm, i'm not sure what you mean - could you be more specific?

The FRV CPU, like many others, supports interrupt prioritisation.  A particular
interrupt level is set in the PSR, and any interrupt of a higher priority can
interrupt.  do_IRQ() can then do the interrupt processing in the interrupt
level of the interrupt that invoked it, thus permitting higher priority
interrupts to still happen.

> but ... somehow the current FRV code does figure out which IRQ source 
> fired, right?

Not always; sometimes it has to fall back to polling the drivers unfortunately.

Btw why are we using IRQ_INPROGRESS, IRQ_DISABLED, IRQ_PENDING and friends?
They would appear unnecessary.

David

Re: 2.6.18-rc5-mm1

[Maciej Rutecki]

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

Bjorn Helgaas napisał(a):
> 
> This ACPI "unknown exception code" problem is the same one reported here:
>   http://www.mail-archive.com/linux-acpi%40vger.kernel.org/msg02873.html
> 
> Basically, we just need to revert this:
>   http://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm3/broken-out/hot-add-mem-x86_64-acpi-motherboard-fix.patch
> 
Thanks it works.

-- 
Maciej Rutecki <maciej.rutecki@gmail.com>
http://www.unixy.pl
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3265 bytes --]

Re: [PATCH] FRV: do_gettimeofday() should no longer use tickadj

[Benjamin Herrenschmidt]

> Under some circumstances I can work out which sources have triggered which
> interrupts (there are various off-CPU FPGAs which implement auxiliary PICs that
> do announce their sources), but the aux-PIC channels are grouped together upon
> delivery to the CPU PIC, so some of the ACK'ing has to be done at the group
> level.
> 
> > how is this not possible via genirq?
> 
> How is it possible with genirq?

Well, genirq gives you more flexibility than the current mecanism so ...

If I understand correctly, you need to do scray stuff to figure out your
toplevel irq, which shound't be a problem with either mecanisms... 

Now, if you have funky cascades, then you can always group them into a
virtual irq cascade line and have a special chained flow handler that
does all the "figuring out" off those... it's up to you. 

In general, I found genirq allowed me to do more fancy stuff, and end up
with actually less hooks and indirect function calls on the path to a
given irq than before as you can use tailored flow handlers that do just
the right thing.

Ben.

[-mm patch] ATA_JMICRON: remove the superfluous ATA dependency

[Adrian Bunk]

The dependency on ATA is no longer required since this option is now 
inside an "if ATA" block.

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

--- linux-2.6.18-rc5-mm1/drivers/ata/Kconfig.old	2006-09-07 00:39:33.000000000 +0200
+++ linux-2.6.18-rc5-mm1/drivers/ata/Kconfig	2006-09-07 00:39:55.000000000 +0200
@@ -309,7 +309,7 @@
 
 config ATA_JMICRON
 	tristate "JMicron non-AHCI support (Experimental)"
-	depends on ATA && PCI && EXPERIMENTAL
+	depends on PCI && EXPERIMENTAL
 	help
 	  This option enables support for Jmicron ATA controllers
 	  ports running in non-AHCI mode. Where possible you should

[-mm patch] ACPI_SONY shouldn't default m

[Adrian Bunk]

Drivers should default to n.

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

--- linux-2.6.18-rc5-mm1/drivers/acpi/Kconfig.old	2006-09-07 00:49:37.000000000 +0200
+++ linux-2.6.18-rc5-mm1/drivers/acpi/Kconfig	2006-09-07 00:50:01.000000000 +0200
@@ -251,7 +251,6 @@
 config ACPI_SONY
 	tristate "Sony Laptop Extras"
 	depends on X86 && ACPI
-	default m
 	  ---help---
 	  This mini-driver drives the ACPI SNC device present in the
 	  ACPI BIOS of the Sony Vaio laptops.

Re: 2.6.18-rc5-mm1

[Andrew Morton]

On Wed, 06 Sep 2006 18:55:11 +0200
Maciej Rutecki <maciej.rutecki@gmail.com> wrote:

> Bjorn Helgaas napisał(a):
> > 
> > This ACPI "unknown exception code" problem is the same one reported here:
> >   http://www.mail-archive.com/linux-acpi%40vger.kernel.org/msg02873.html
> > 
> > Basically, we just need to revert this:
> >   http://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm3/broken-out/hot-add-mem-x86_64-acpi-motherboard-fix.patch
> > 
> Thanks it works.
> 

So...  should I drop that patch?
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: 2.6.18-rc5-mm1

[Andrew Morton]

On Wed, 06 Sep 2006 18:55:11 +0200
Maciej Rutecki <maciej.rutecki@gmail.com> wrote:

> Bjorn Helgaas napisał(a):
> > 
> > This ACPI "unknown exception code" problem is the same one reported here:
> >   http://www.mail-archive.com/linux-acpi%40vger.kernel.org/msg02873.html
> > 
> > Basically, we just need to revert this:
> >   http://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm3/broken-out/hot-add-mem-x86_64-acpi-motherboard-fix.patch
> > 
> Thanks it works.
> 

So...  should I drop that patch?

Re: [-mm patch] ACPI_SONY shouldn't default m

[Andrew Morton]

On Thu, 7 Sep 2006 01:07:00 +0200
Adrian Bunk <bunk@stusta.de> wrote:

> Drivers should default to n.
> 
> Signed-off-by: Adrian Bunk <bunk@stusta.de>
> 
> --- linux-2.6.18-rc5-mm1/drivers/acpi/Kconfig.old	2006-09-07 00:49:37.000000000 +0200
> +++ linux-2.6.18-rc5-mm1/drivers/acpi/Kconfig	2006-09-07 00:50:01.000000000 +0200
> @@ -251,7 +251,6 @@
>  config ACPI_SONY
>  	tristate "Sony Laptop Extras"
>  	depends on X86 && ACPI
> -	default m

Not this one - I need it on my Vaio and I get sick of the option vanishing.
Make it depend on CONFIG_AKPM?

Re: [-mm patch] ACPI_SONY shouldn't default m

[Randy.Dunlap]

On Wed, 6 Sep 2006 20:30:03 -0700 Andrew Morton wrote:

> On Thu, 7 Sep 2006 01:07:00 +0200
> Adrian Bunk <bunk@stusta.de> wrote:
> 
> > Drivers should default to n.
> > 
> > Signed-off-by: Adrian Bunk <bunk@stusta.de>
> > 
> > --- linux-2.6.18-rc5-mm1/drivers/acpi/Kconfig.old	2006-09-07 00:49:37.000000000 +0200
> > +++ linux-2.6.18-rc5-mm1/drivers/acpi/Kconfig	2006-09-07 00:50:01.000000000 +0200
> > @@ -251,7 +251,6 @@
> >  config ACPI_SONY
> >  	tristate "Sony Laptop Extras"
> >  	depends on X86 && ACPI
> > -	default m
> 
> Not this one - I need it on my Vaio and I get sick of the option vanishing.
> Make it depend on CONFIG_AKPM?

I'll ack that one.  :)
otherwise I also agree with Adrian's patch...

---
~Randy

Re: Lost DVD-RW [Was Re: 2.6.18-rc5-mm1]

[Tejun Heo]

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

J.A. Magallón wrote:
> libata version 2.00 loaded.
> ata_piix 0000:00:1f.1: version 2.00ac7
> ACPI: PCI Interrupt 0000:00:1f.1[A] -> GSI 18 (level, low) -> IRQ 16
> PCI: Setting latency timer of device 0000:00:1f.1 to 64
> ata1: PATA max UDMA/100 cmd 0x1F0 ctl 0x3F6 bmdma 0xF000 irq 14
> ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xF008 irq 15
> scsi0 : ata_piix
> ata1.00: XXX class=3 is_ata=0 is_cfa=1
> ata1.00: failed to IDENTIFY (device reports illegal type, err_mask=0x0)

Magallón, does the attached patch fix the problem?

Alan, it seems that 0x848a indicates CFA device iff the ID data is from 
IDENTIFY DEVICE.  When the command is IDENTIFY PACKET DEVICE, 0x848a 
seems to indicate a valid ATAPI device.

 From ATA8-ACS, 7.17 is IDENTIFY DEVICE.

> 7.17.7.1 Word 0: General configuration
> 
> Devices that conform to this standard shall clear bit 15 to zero. If
> bit 7 is set to one, the device is a removable media device. Bit 6 is
> obsolete.
> 
> If bit 2 is set to one it indicates that the content of the IDENTIFY
> DEVICE data is incomplete. This will occur if the device supports the
> Power-up in Standby feature set and required data is contained on the
> device media. In this case the content of at least word 0 and word 2
> shall be valid.
> 
> Devices supporting the CFA feature set shall place the value 848Ah in
                                                                ^^^^^
> word 0. In this case, the above definitions for the bits in  word 0
> are not valid.

And, 7.18 is on IDENTIFY PACKET DEVICE.

> 7.18.6.2 Word 0: General configuration
> 
> Bits (15:14) of word 0 indicate the type of device. Bit 15 shall be
> set to one and bit 14 shall be cleared to zeroto indicate the device
> implements the PACKET Command feature set.
> 
> Bits (12:8) of word 0 indicate the command packet set implemented by
> the device. This value follows the peripheral device type value as
> defined in SCSI Primary Commands, ANSI INCITS 301:1997.
> 
> Bit 7 if set to one indicates that the device has removable media.
> 
> Bits (6:5) of word 0 indicate the DRQ response time when a PACKET
> command is received. A value of 00b indicates a maximum time of 3 ms
> from receipt of PACKET to the setting of DRQ to one. A value of 10b 
> indicates a maximum time of 50 μs from the receipt of PACKET to the
> setting of DRQ to one. The value 11b is reserved.
> 
> If bit 2 is set to one it indicates that the content of the IDENTIFY
> DEVICE data is incomplete. This will occur if the device supports the
> Power-up in Standby feature set and required data is contained on the
> device media. In this case the content of at least word 0 and word 2
> shall be valid.
> 
> Bits (1:0) of word 0 indicate the packet size the device supports. A
> value of 00b indicates that a 12-byte packet is supported; a value of
> 01b indicates a 16 byte packet. The values 10b and 11b are reserved.

So, when the output is from IDENTIFY PACKET DEVICE, 0x848a doesn't have 
any special meaning.  It indicates a valid write-once, removable media, 
ATAPI device with 16bytes CDB.

The attached patch makes sanity checking logic in ata_dev_read_id() 
check for CFA only if IDENTIFY DEVICE is used.

Thanks.

-- 
tejun

[-- Attachment #2: patch --]
[-- Type: text/plain, Size: 702 bytes --]

diff --git a/drivers/scsi/libata-core.c b/drivers/scsi/libata-core.c
index 73dd6c8..427b73a 100644
--- a/drivers/scsi/libata-core.c
+++ b/drivers/scsi/libata-core.c
@@ -1256,10 +1256,15 @@ int ata_dev_read_id(struct ata_device *d
 	swap_buf_le16(id, ATA_ID_WORDS);
 
 	/* sanity check */
-	if ((class == ATA_DEV_ATA) != (ata_id_is_ata(id) | ata_id_is_cfa(id))) {
-		rc = -EINVAL;
-		reason = "device reports illegal type";
-		goto err_out;
+	rc = -EINVAL;
+	reason = "device reports illegal type";
+
+	if (class == ATA_DEV_ATA) {
+		if (!ata_id_is_ata(id) && !ata_id_is_cfa(id))
+			goto err_out;
+	} else {
+		if (ata_id_is_ata(id))
+			goto err_out;
 	}
 
 	if (post_reset && class == ATA_DEV_ATA) {

Re: [PATCH] FRV: do_gettimeofday() should no longer use tickadj

[David Howells]

Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:

> Well, genirq gives you more flexibility than the current mecanism so ...

No, it doesn't because the FRV arch contains its own mechanism and I can do
what ever I like in it.

genirq's flexibility comes at a price.  Count the number of hooks in struct
irq_chip and struct irq_desc together.

> If I understand correctly, you need to do scray stuff to figure out your
> toplevel irq, which shound't be a problem with either mecanisms... 

Yeah.  I can't actually find out what source caused top-level IRQs.  I have to
guess from looking at the IRQ priority and poking around in the hardware.  I
got bitten that way too: at one point, I was peeking at the interrupt flag in
the serial regs, only to realise this was causing the driver to go wrong
because it cleared the interrupt requested flag in UART.

Obviously I'd rather not use IRQ priorisation to help multiplex irqs, but
unless I want a large polling set...

> Now, if you have funky cascades, then you can always group them into a
> virtual irq cascade line and have a special chained flow handler that
> does all the "figuring out" off those... it's up to you. 

You make it sound so easy, but it's not obvious how to do this, apart from
installing interrupt handlers for the auxiliary PIC interrupts on the CPU and
having those call back into __do_IRQ().  Chaining isn't mentioned in
genericirq.tmpl.

> In general, I found genirq allowed me to do more fancy stuff, and end up
> with actually less hooks and indirect function calls on the path to a
> given irq than before as you can use tailored flow handlers that do just
> the right thing.

My code in the FRV arch has fewer indirection calls than the genirq code
simply because it doesn't require tables of operations.  I can trace through
it with gdb and see them.

I built all the stuff that genirq does in indirections directly into the
handlers.  It certainly has fewer hooks.

I attempted to convert it over to use genirq, and I came up with some numbers:

The difference in kernel sizes:

	   text    data     bss     dec     hex filename
	1993023   77912  166964 2237899  2225cb vmlinux  [with genirq]
	1986511   76016  167908 2230435  2208a3 vmlinux  [without genirq]

The genirq subdir all wraps up into this:

	  10908    3272      12   14192    3770 kernel/irq/built-in.o
	   1548      64       4    1616     650 arch/frv/kernel/irq.o
	---------------------------------------------------------------------
	  12456    3336      16   15808    3dc0 total

My FRV-specific IRQ handling wraps up into these:

	    480     488       0     968     3c8 arch/frv/kernel/irq-mb93091.o
	   4688      16     520    5224    1468 arch/frv/kernel/irq.o
	   1576    1152      16    2744     ab8 arch/frv/kernel/irq-routing.o
	---------------------------------------------------------------------
	   6744    1656     536    8936    22e8 total

There's a difference in BSS size in the main kernel that I can't account for,
but basically genirq uses 6.3KB more code and 1.8KB more initialised data, but
0.9KB less BSS.  Overall, about 7.2KB more memory.  I can shrink the BSS usage
in the FRV specific version by reducing the amount of space in the IRQ sources
table.

So, again, why _should_ I use the generic IRQ stuff?  It's bigger and very
probably slower than what I already have.

David

Re: [PATCH] FRV: do_gettimeofday() should no longer use tickadj

[Ingo Molnar]

* David Howells <dhowells@redhat.com> wrote:

> The genirq subdir all wraps up into this:
> 
> 	  10908    3272      12   14192    3770 kernel/irq/built-in.o
> 	   1548      64       4    1616     650 arch/frv/kernel/irq.o
> 	---------------------------------------------------------------------
> 	  12456    3336      16   15808    3dc0 total

hm, could you take a look at why that difference happens? Do you make 
use of __do_IRQ()? Do you make use of all the various flow handlers that 
are offered in handle.c? Could you #ifdef out all the functions that are 
unused? The kernel build process doesnt remove them and i havent (yet) 
put them into a library.

Could you please send us the patch that genirq-ifies FRV?

> So, again, why _should_ I use the generic IRQ stuff? [...]

To have shared code between architectures? To make generic API updates 
easier for all of us? To have less cruft in interrupt.h? To not having 
to add last-minute patches to v2.6.18 because some arch defines its own 
IRQ prototypes and a difficult generic feature like irqtrace breaks? To 
get new IRQ subsystem features for free like preemptible irqs, irqpoll 
or SHIRQ debugging?

the same "why should we share code" argument could be made for the VFS 
too. Sharing code has a (small) price most of the time, but it's also 
very much worth it. I think the size increases you are seeing are 
artificial and most of it is not caused by the indirections. If they 
were caused by the indirections i'd probably agree with you.

if your argument were true every arch should run its whole Linux kernel 
in arch/frv, with zero sharing with anyone else. There's always a lot of 
'unnecessary' stuff all around the kernel that is just a hindrance for 
FRV. In reality what makes us stronger is to work together. I dont for a 
minute say that we should overdo code sharing - if it's not possible 
then it must not be forced, but just the pure fact of "more 
indirections" or "what does this bring me _now_" isnt a good enough 
reason i believe - it simply makes _future_ changes easier.

	Ingo

Re: Lost DVD-RW [Was Re: 2.6.18-rc5-mm1]

[J.A. Magallón]

On Thu, 07 Sep 2006 11:34:39 +0200, Tejun Heo <htejun@gmail.com> wrote:

> J.A. Magallón wrote:
> > libata version 2.00 loaded.
> > ata_piix 0000:00:1f.1: version 2.00ac7
> > ACPI: PCI Interrupt 0000:00:1f.1[A] -> GSI 18 (level, low) -> IRQ 16
> > PCI: Setting latency timer of device 0000:00:1f.1 to 64
> > ata1: PATA max UDMA/100 cmd 0x1F0 ctl 0x3F6 bmdma 0xF000 irq 14
> > ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xF008 irq 15
> > scsi0 : ata_piix
> > ata1.00: XXX class=3 is_ata=0 is_cfa=1
> > ata1.00: failed to IDENTIFY (device reports illegal type, err_mask=0x0)
> 
> Magallón, does the attached patch fix the problem?
> 

Yes, my burner is back :)

libata version 2.00 loaded.
ata_piix 0000:00:1f.1: version 2.00ac7
ACPI: PCI Interrupt 0000:00:1f.1[A] -> GSI 18 (level, low) -> IRQ 16
PCI: Setting latency timer of device 0000:00:1f.1 to 64
ata1: PATA max UDMA/100 cmd 0x1F0 ctl 0x3F6 bmdma 0xF000 irq 14
ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xF008 irq 15
scsi0 : ata_piix
ata1.00: ATAPI, max UDMA/33
ata1.01: ATAPI, max MWDMA0, CDB intr
ata1.00: configured for UDMA/33
ata1.01: configured for PIO3
scsi1 : ata_piix
ata2.00: ATA-6, max UDMA/100, 234441648 sectors: LBA48 
ata2.00: ata2: dev 0 multi count 16
ata2.01: ATAPI, max UDMA/33
ata2.00: configured for UDMA/100
ata2.01: configured for UDMA/33
scsi 0:0:0:0: CD-ROM            HL-DT-ST DVDRAM GSA-4120B A111 PQ: 0 ANSI: 5
sr0: scsi3-mmc drive: 40x/40x writer dvd-ram cd/rw xa/form2 cdda tray
Uniform CD-ROM driver Revision: 3.20
sr 0:0:0:0: Attached scsi CD-ROM sr0
scsi 0:0:1:0: Direct-Access     IOMEGA   ZIP 250          51.G PQ: 0 ANSI: 5
sd 0:0:1:0: Attached scsi removable disk sda
scsi 1:0:0:0: Direct-Access     ATA      ST3120022A       3.06 PQ: 0 ANSI: 5
SCSI device sdb: 234441648 512-byte hdwr sectors (120034 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 3a 00 00
SCSI device sdb: drive cache: write back
SCSI device sdb: 234441648 512-byte hdwr sectors (120034 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 3a 00 00
SCSI device sdb: drive cache: write back
 sdb: sdb1
sd 1:0:0:0: Attached scsi disk sdb
scsi 1:0:1:0: CD-ROM            TOSHIBA  DVD-ROM SD-M1712 1004 PQ: 0 ANSI: 5
sr1: scsi3-mmc drive: 48x/48x cd/rw xa/form2 cdda tray
sr 1:0:1:0: Attached scsi CD-ROM sr1


Thanks !!

--
J.A. Magallon <jamagallon()ono!com>     \               Software is like sex:
                                         \         It's better when it's free
Mandriva Linux release 2007.0 (Cooker) for i586
Linux 2.6.17-jam08 (gcc 4.1.1 20060724 (prerelease) (4.1.1-3mdk)) #4 SMP PREEMPT

[PATCH libata-dev#upstream-fixes] libata: ignore CFA signature while sanity-checking an ATAPI device

[Tejun Heo]

0x848a in ID word 0 indicates CFA device iff the ID data is obtained
from IDENTIFY DEVICE.  For ATAPI devices, 0x848a in ID work 0
indicates valid ATAPI device.  Fix sanity check in ata_dev_read_id()
such that ATAPI devices reporting 0x848a in ID word 0 is not handled
as error.

The problem is identified by J.A. Magallon with HL-DT-ST DVDRAM
GSA-4120B.

Signed-off-by: Tejun Helo <htejun@gmail.com>
Cc: J.A. Magallon <jamagallon@ono.com>
---
Jeff, this is a regression and thus should go into .19.

diff --git a/drivers/scsi/libata-core.c b/drivers/scsi/libata-core.c
index 73dd6c8..427b73a 100644
--- a/drivers/scsi/libata-core.c
+++ b/drivers/scsi/libata-core.c
@@ -1256,10 +1256,15 @@ int ata_dev_read_id(struct ata_device *d
 	swap_buf_le16(id, ATA_ID_WORDS);
 
 	/* sanity check */
-	if ((class == ATA_DEV_ATA) != (ata_id_is_ata(id) | ata_id_is_cfa(id))) {
-		rc = -EINVAL;
-		reason = "device reports illegal type";
-		goto err_out;
+	rc = -EINVAL;
+	reason = "device reports illegal type";
+
+	if (class == ATA_DEV_ATA) {
+		if (!ata_id_is_ata(id) && !ata_id_is_cfa(id))
+			goto err_out;
+	} else {
+		if (ata_id_is_ata(id))
+			goto err_out;
 	}
 
 	if (post_reset && class == ATA_DEV_ATA) {

Re: [PATCH] FRV: do_gettimeofday() should no longer use tickadj

[David Howells]

Ingo Molnar <mingo@elte.hu> wrote:

> > So, again, why _should_ I use the generic IRQ stuff? [...]
> 
> To have shared code between architectures?

That's reasonable as far as it goes, the algorithms are similar per-arch, but
the PICs are quite ofter quite different.  My FRV board here has three very
different ones, none of them compatible with anything else as far as I know.

> To make generic API updates easier for all of us?

That's reasonable.

> To have less cruft in interrupt.h?

That's specious.  The whole point of having arch-specific code is to support
arch-specific stuff.

> To not having to add last-minute patches to v2.6.18 because some arch
> defines its own IRQ prototypes and a difficult generic feature like irqtrace
> breaks?

Specious again.  If whoever it was made the changes got them right in the
first place, then it wouldn't have required a last minute patch for the
LOCKDEP=n case now would it?

If you're going to insist on the genirq stuff being used, than you should take
CONFIG_GENERIC_HARDIRQS away and force everyone else to move to what you've
decided they should use, right?

> To get new IRQ subsystem features for free like preemptible irqs, irqpoll or
> SHIRQ debugging?

That's reasonable, but you don't get necessarily get features for "free" when
you add up the cost of having support there for them.  The features appear for
the subscribed arches automatically, and so do the costs.

> hm, could you take a look at why that difference happens? Do you make 
> use of __do_IRQ()?

I did say I used it.  In fact, as far as I can tell, I have to use it
recursively.  There doesn't seem to be any other way in that's correct.

> Do you make use of all the various flow handlers that are offered in
> handle.c?

Some of them.

> Could you #ifdef out all the functions that are unused? The kernel build
> process doesnt remove them and i havent (yet) put them into a library.

I could get away with commenting out:

	no_action()
	set_irq_wake()
	can_request_irq()
	set_irq_type()
	set_irq_data()
	set_irq_chip_data()
	handle_simple_irq()
	handle_fasteio_irq()
	bits of handle_irq_name() corresponding to the previous two

This results in a small shrinkage of text and a slight increase in the amount
of data used:

	   text    data     bss     dec     hex filename
	1993023   77908  166964 2237895  2225c7 vmlinux [before]
	1991407   77912  166964 2236283  221f7b vmlinux [after]
	---------------------------------------
	   1616      -4       0    1612

The increase in data size is slightly puzzling, but may have something to do
with there being fewer strings in handle_irq_name().  The text decrease is
about 12% of the unmodified total:

	   text    data     bss     dec     hex filename
	  10908    3272      12   14192    3770 kernel/irq/built-in.o
	   1548      64       4    1616     650 arch/frv/kernel/irq.o
	    744     192       0     936     3a8 arch/frv/kernel/irq-mb93091.o
	---------------------------------------
	  13200    3528      16   16744         total

> the same "why should we share code" argument could be made for the VFS too.

That argument doesn't really follow.  We only have one interrupt system in the
kernel, but we have lots of different filesystems.

> Sharing code has a (small) price most of the time, but it's also very much
> worth it. I think the size increases you are seeing are artificial

Artificial in what manner?  I haven't added extra code to genirq to make it
look bad or anything like that.

> and most of it is not caused by the indirections. If they were caused by the
> indirections i'd probably agree with you.

I think most of the size increase is due to the core genirq function set being
large, not the indirections themselves.  There aren't many indirections
implemented in the core set.

The indirected functions exist in the arch code for the most part, and where
they are implemented they are generally very small.  In FRV's case, one lot in
arch/frv/kernel/irq.c for the CPU and one lot in arch/frv/kernel/irq-mb93091.c
or similar for the on-motherboard FPGA.

> if your argument were true every arch should run its whole Linux kernel 
> in arch/frv, with zero sharing with anyone else.

Not really.  eCos manages this more efficiently than Linux, with generally
fewer indirections through the use of macros and inline functions.

At some point you do have to draw a line and do common stuff.  The VFS is
definitely in the common region.  It has little need of arch-specific stuff in
there, and that that it does is quite readily encapsulated in inline functions
where it has little effect on the space.  I'm not entirely convinced that this
applies to interrupt handling though.  That is at the basic level very
arch-dependent.

> There's always a lot of 'unnecessary' stuff all around the kernel that is
> just a hindrance for FRV.

Or any other platform, embedded or otherwise, that doesn't want it.  A lot of
it I can disable - the block layer now, for instance - but some of it I can't
(like interrupt handling).

> In reality what makes us stronger is to work together.  I dont for a minute
> say that we should overdo code sharing

So who defines what is "overdone"?  You seem to have decided that you do.

> - if it's not possible then it must not be forced, but just the pure fact of
> "more indirections" or "what does this bring me _now_" isnt a good enough
> reason i believe - it simply makes _future_ changes easier.

And makes the kernel larger and slower and makes it consume more stack space
and less easy for the compiler to optimise.

David

Re: 2.6.18-rc5-mm1

[keith mannthey]

On Wed, 2006-09-06 at 20:08 -0700, Andrew Morton wrote:
> On Wed, 06 Sep 2006 18:55:11 +0200
> Maciej Rutecki <maciej.rutecki@gmail.com> wrote:
> 
> > Bjorn Helgaas napisał(a):
> > > 
> > > This ACPI "unknown exception code" problem is the same one reported here:
> > >   http://www.mail-archive.com/linux-acpi%40vger.kernel.org/msg02873.html
> > > 
> > > Basically, we just need to revert this:
> > >   http://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm3/broken-out/hot-add-mem-x86_64-acpi-motherboard-fix.patch
> > > 
> > Thanks it works.
> > 
> 
> So...  should I drop that patch?

Yes please drop this patch.  
  I dislike breaking my boxes functionality without a consensus for the
right fix is but it appears to be breaking others.  The discussion about
what the right fix is ongoing with no definitive direction. At a minimum
this patch will need to be updated. 

Thanks,
  Keith 

-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: 2.6.18-rc5-mm1

[keith mannthey]

On Wed, 2006-09-06 at 20:08 -0700, Andrew Morton wrote:
> On Wed, 06 Sep 2006 18:55:11 +0200
> Maciej Rutecki <maciej.rutecki@gmail.com> wrote:
> 
> > Bjorn Helgaas napisał(a):
> > > 
> > > This ACPI "unknown exception code" problem is the same one reported here:
> > >   http://www.mail-archive.com/linux-acpi%40vger.kernel.org/msg02873.html
> > > 
> > > Basically, we just need to revert this:
> > >   http://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm3/broken-out/hot-add-mem-x86_64-acpi-motherboard-fix.patch
> > > 
> > Thanks it works.
> > 
> 
> So...  should I drop that patch?

Yes please drop this patch.  
  I dislike breaking my boxes functionality without a consensus for the
right fix is but it appears to be breaking others.  The discussion about
what the right fix is ongoing with no definitive direction. At a minimum
this patch will need to be updated. 

Thanks,
  Keith 

Re: [PATCH libata-dev#upstream-fixes] libata: ignore CFA signature while sanity-checking an ATAPI device

[Andrew Morton]

On Thu, 7 Sep 2006 20:32:24 +0900
Tejun Heo <htejun@gmail.com> wrote:

> 0x848a in ID word 0 indicates CFA device iff the ID data is obtained
> from IDENTIFY DEVICE.  For ATAPI devices, 0x848a in ID work 0
> indicates valid ATAPI device.  Fix sanity check in ata_dev_read_id()
> such that ATAPI devices reporting 0x848a in ID word 0 is not handled
> as error.
> 
> The problem is identified by J.A. Magallon with HL-DT-ST DVDRAM
> GSA-4120B.
> 
> Signed-off-by: Tejun Helo <htejun@gmail.com>
> Cc: J.A. Magallon <jamagallon@ono.com>
> ---
> Jeff, this is a regression and thus should go into .19.

You mean 2.6.18, yes?

> diff --git a/drivers/scsi/libata-core.c b/drivers/scsi/libata-core.c
> index 73dd6c8..427b73a 100644
> --- a/drivers/scsi/libata-core.c
> +++ b/drivers/scsi/libata-core.c
> @@ -1256,10 +1256,15 @@ int ata_dev_read_id(struct ata_device *d
>  	swap_buf_le16(id, ATA_ID_WORDS);
>  
>  	/* sanity check */
> -	if ((class == ATA_DEV_ATA) != (ata_id_is_ata(id) | ata_id_is_cfa(id))) {
> -		rc = -EINVAL;
> -		reason = "device reports illegal type";
> -		goto err_out;
> +	rc = -EINVAL;
> +	reason = "device reports illegal type";
> +
> +	if (class == ATA_DEV_ATA) {
> +		if (!ata_id_is_ata(id) && !ata_id_is_cfa(id))
> +			goto err_out;
> +	} else {
> +		if (ata_id_is_ata(id))
> +			goto err_out;
>  	}
>  
>  	if (post_reset && class == ATA_DEV_ATA) {

Re: [PATCH libata-dev#upstream-fixes] libata: ignore CFA signature while sanity-checking an ATAPI device

[Jeff Garzik]

Andrew Morton wrote:
> On Thu, 7 Sep 2006 20:32:24 +0900
> Tejun Heo <htejun@gmail.com> wrote:
> 
>> 0x848a in ID word 0 indicates CFA device iff the ID data is obtained
>> from IDENTIFY DEVICE.  For ATAPI devices, 0x848a in ID work 0
>> indicates valid ATAPI device.  Fix sanity check in ata_dev_read_id()
>> such that ATAPI devices reporting 0x848a in ID word 0 is not handled
>> as error.
>>
>> The problem is identified by J.A. Magallon with HL-DT-ST DVDRAM
>> GSA-4120B.
>>
>> Signed-off-by: Tejun Helo <htejun@gmail.com>
>> Cc: J.A. Magallon <jamagallon@ono.com>
>> ---
>> Jeff, this is a regression and thus should go into .19.
> 
> You mean 2.6.18, yes?

Actually, it looks like it should indeed be 2.6.19 (libata #upstream), 
not 2.6.18 (libata #upstream-fixes).  Alan's "add compactflash support" 
patch isn't in 2.6.18-rc.

So, this should -not- be sent for 2.6.18.

	Jeff

Re: [PATCH] FRV: do_gettimeofday() should no longer use tickadj

[Benjamin Herrenschmidt]

On Thu, 2006-09-07 at 10:55 +0100, David Howells wrote:
> Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> 
> > Well, genirq gives you more flexibility than the current mecanism so ...
> 
> No, it doesn't because the FRV arch contains its own mechanism and I can do
> what ever I like in it.

But genirq allows you to have your own flow handlers... Which does mean
do whatever you like as well

> genirq's flexibility comes at a price.  Count the number of hooks in struct
> irq_chip and struct irq_desc together.

You do not have to implement them all. Some of them are specific to a
given flow. For example, on XICS or MPIC, I only call eoi(), that is a
single hook, using the fasteoi handler. That's actually less than with
the previous generic code.
 
> > If I understand correctly, you need to do scray stuff to figure out your
> > toplevel irq, which shound't be a problem with either mecanisms... 
> 
> Yeah.  I can't actually find out what source caused top-level IRQs.  I have to
> guess from looking at the IRQ priority and poking around in the hardware.  I
> got bitten that way too: at one point, I was peeking at the interrupt flag in
> the serial regs, only to realise this was causing the driver to go wrong
> because it cleared the interrupt requested flag in UART.
> 
> Obviously I'd rather not use IRQ priorisation to help multiplex irqs, but
> unless I want a large polling set...

But neither the old mecanism nor genirq changes nor does anything in the
way of discovering what the toplevel irq is ... They only intervene
after you have found it...

> > Now, if you have funky cascades, then you can always group them into a
> > virtual irq cascade line and have a special chained flow handler that
> > does all the "figuring out" off those... it's up to you. 
> 
> You make it sound so easy, but it's not obvious how to do this, apart from
> installing interrupt handlers for the auxiliary PIC interrupts on the CPU and
> having those call back into __do_IRQ().  Chaining isn't mentioned in
> genericirq.tmpl.

No, you do a chain handler. Look at how I do it in
arch/powerpc/platform/pseries/setup.c for example. It's actually
trivial. You install a special flow handler (which means that there is
very little overhead, almost none, from the toplevel irq to the chained
irq). You can _also_ if you want just install an IRQ handler for the
cascaded controller and call generic_handle_irq (rather than __do_IRQ)
from it, but that has more overhead. A chained handler completely
relaces the flow handler for the cascade, and thus, if you don't need
all of the nits and bits of the other flow handlers for your cascade,
you can speed things up by hooking at that level.

> My code in the FRV arch has fewer indirection calls than the genirq code
> simply because it doesn't require tables of operations.  I can trace through
> it with gdb and see them.
> 
> I built all the stuff that genirq does in indirections directly into the
> handlers.  It certainly has fewer hooks.

genirq allows you to do just that by using custom handlers.

> I attempted to convert it over to use genirq, and I came up with some numbers:
> 
> The difference in kernel sizes:
> 
> 	   text    data     bss     dec     hex filename
> 	1993023   77912  166964 2237899  2225cb vmlinux  [with genirq]
> 	1986511   76016  167908 2230435  2208a3 vmlinux  [without genirq]
> 
> The genirq subdir all wraps up into this:
> 
> 	  10908    3272      12   14192    3770 kernel/irq/built-in.o
> 	   1548      64       4    1616     650 arch/frv/kernel/irq.o
> 	---------------------------------------------------------------------
> 	  12456    3336      16   15808    3dc0 total
> 
> My FRV-specific IRQ handling wraps up into these:
> 
> 	    480     488       0     968     3c8 arch/frv/kernel/irq-mb93091.o
> 	   4688      16     520    5224    1468 arch/frv/kernel/irq.o
> 	   1576    1152      16    2744     ab8 arch/frv/kernel/irq-routing.o
> 	---------------------------------------------------------------------
> 	   6744    1656     536    8936    22e8 total
> 
> There's a difference in BSS size in the main kernel that I can't account for,
> but basically genirq uses 6.3KB more code and 1.8KB more initialised data, but
> 0.9KB less BSS.  Overall, about 7.2KB more memory.  I can shrink the BSS usage
> in the FRV specific version by reducing the amount of space in the IRQ sources
> table.
> 
> So, again, why _should_ I use the generic IRQ stuff?  It's bigger and very
> probably slower than what I already have.

Well, I would have to look precisely at how you did the port to
genirq... But in my case, it's definitely not slower, especially when
cascaded controllers are involved.

Ben.

Re: [PATCH libata-dev#upstream-fixes] libata: ignore CFA signature while sanity-checking an ATAPI device

[Tejun Heo]

Jeff Garzik wrote:
> Andrew Morton wrote:
>> You mean 2.6.18, yes?
> 
> Actually, it looks like it should indeed be 2.6.19 (libata #upstream), 
> not 2.6.18 (libata #upstream-fixes).  Alan's "add compactflash support" 
> patch isn't in 2.6.18-rc.
> 
> So, this should -not- be sent for 2.6.18.

Hello,

Yes, I meant .18.  Jeff, this should be fixed before 2.6.18 is released. 
  It's not the question of whether CFA support is implemented or not. 
We're sanity-checking in 2.6.18-rcX anyway and it's the sanity checking 
which is causing problem.  What seems to have happened is...

1. CFA support is implemented
2. CFA check was added (backported) to upstream-fixes, but it was incorrect.

So, we need to do one of two things.

* apply this patch to 2.6.18-rcX
* remove ata_id_is_cfa() check altogether

-- 
tejun

Re: [PATCH] FRV: do_gettimeofday() should no longer use tickadj

[David Howells]

Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:

> No, you do a chain handler. Look at how I do it in
> arch/powerpc/platform/pseries/setup.c for example. It's actually
> trivial. You install a special flow handler (which means that there is
> very little overhead, almost none, from the toplevel irq to the chained
> irq). You can _also_ if you want just install an IRQ handler for the
> cascaded controller and call generic_handle_irq (rather than __do_IRQ)
> from it, but that has more overhead. A chained handler completely
> relaces the flow handler for the cascade, and thus, if you don't need
> all of the nits and bits of the other flow handlers for your cascade,
> you can speed things up by hooking at that level.

Please update Documentation/DocBook/genericirq.tmpl.  That doesn't mention it.

David

Re: [PATCH] FRV: do_gettimeofday() should no longer use tickadj

[Benjamin Herrenschmidt]

On Fri, 2006-09-08 at 11:25 +0100, David Howells wrote:
> Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> 
> > No, you do a chain handler. Look at how I do it in
> > arch/powerpc/platform/pseries/setup.c for example. It's actually
> > trivial. You install a special flow handler (which means that there is
> > very little overhead, almost none, from the toplevel irq to the chained
> > irq). You can _also_ if you want just install an IRQ handler for the
> > cascaded controller and call generic_handle_irq (rather than __do_IRQ)
> > from it, but that has more overhead. A chained handler completely
> > relaces the flow handler for the cascade, and thus, if you don't need
> > all of the nits and bits of the other flow handlers for your cascade,
> > you can speed things up by hooking at that level.
> 
> Please update Documentation/DocBook/genericirq.tmpl.  That doesn't mention it.

I must admit I haven't read the documentation :) I looked at the
code/patches when genirq was posted and did my powerpc implementation
based on my understanding of the code and discussions with Thomas and
Ingo. I'll have a look at the doc next week and see if I can improve it.

Cheers,
Ben.

Re: [PATCH] FRV: do_gettimeofday() should no longer use tickadj

[David Howells]

Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:

> > Please update Documentation/DocBook/genericirq.tmpl.  That doesn't mention it.
> 
> I must admit I haven't read the documentation :) I looked at the
> code/patches when genirq was posted and did my powerpc implementation
> based on my understanding of the code and discussions with Thomas and
> Ingo. I'll have a look at the doc next week and see if I can improve it.

While you're at it, you should also encomment pseries_8259_cascade() which is
what I suspect you're referring to in the powerpc sources.

David

Re: [PATCH] FRV: do_gettimeofday() should no longer use tickadj

[David Howells]

Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:

> > > Now, if you have funky cascades, then you can always group them into a
> > > virtual irq cascade line and have a special chained flow handler that
> > > does all the "figuring out" off those... it's up to you. 
> > 
> > You make it sound so easy, but it's not obvious how to do this, apart from
> > installing interrupt handlers for the auxiliary PIC interrupts on the CPU and
> > having those call back into __do_IRQ().  Chaining isn't mentioned in
> > genericirq.tmpl.
> 
> No, you do a chain handler. Look at how I do it in
> arch/powerpc/platform/pseries/setup.c for example. It's actually
> trivial. You install a special flow handler (which means that there is
> very little overhead, almost none, from the toplevel irq to the chained
> irq). You can _also_ if you want just install an IRQ handler for the
> cascaded controller and call generic_handle_irq (rather than __do_IRQ)
> from it, but that has more overhead. A chained handler completely
> relaces the flow handler for the cascade, and thus, if you don't need
> all of the nits and bits of the other flow handlers for your cascade,
> you can speed things up by hooking at that level.

But funky cascading using chained flow handlers doesn't work if the cascade
must share an IRQ with some other device, right?

David

Re: [PATCH] FRV: do_gettimeofday() should no longer use tickadj

[Ingo Molnar]

* David Howells <dhowells@redhat.com> wrote:

> Ingo Molnar <mingo@elte.hu> wrote:
> 
> > we'll get rid of that pt_regs thing centrally, from all drivers at once 
> > - there's upstream buy-in for that already, and Thomas already generated 
> > a test-patch for that a few months ago. But it's not a big issue right 
> > now.
> 
> Yay!  Can you give me a pointer to the patch?

i cannot find Thomas' recent 2.6 one (Thomas, do you have a link to 
it?), but i did one 5 years ago:

 http://people.redhat.com/mingo/irq-rewrite-patches/irq-cleanup-2.4.15-B1.bz2

in general it's a large but otherwise pretty dumb patch.

> > this shouldnt be a big issue either - we use indirect jumps all around 
> > the kernel.
> 
> Yes, I know.  I'm sometimes concerned at just how fast indirect jumps 
> (and even direct calls) are proliferating.  Look at the read syscall 
> path for something like ext3 these days: it's like a pile of 
> spaghetti.  That seems particularly true of direct-IO where it seems 
> to weave in and out of core code and the filesystem as it goes down.  
> I'm also concerned about stack usage.

yeah - but unless you can suggest some low-maintainance-overhead 
solution, not much can be done i suspect: being a few cycles slower is a 
lot less of a problem than being less flexible in the design. In general 
CPUs do optimize this quite well, but it is true that not every CPU 
does.

> > CPUs are either smart enough to predict it
> 
> I was told a while back (2002?) not to use indirect pointers for some 
> stuff because CPUs _couldn't_ predict it.  Maybe this has changed in 
> modern CPUs.

indirect pointers are very common both in OSs and in applications, 
especially in C++ based ones, where lots of execution goes off dynamic 
objects which have function pointers associated to them. So _lots_ of 
effort goes into branch prediction on the hardware side - and yes, 
modern CPUs do quite well with indirect pointers too.

The worst-case scenario is when the indirect branch flip-flops between 
multiple destination addresses - but that shouldnt be an issue for 
genirq because most systems have _one_ preferred way of handling 
interrupts that the majority of interrupt traffic uses. (for example on 
i686 it's level-triggered PCI irqs)

But even if there's multiple destinations from the indirect jump, newest 
CPUs (such as Core 2) can actually store _multiple_ branch history 
targets and can prefetch all of them at once (if there's idle capacity 
left).

(And i wouldnt be surprised if some modern CPUs already stored the 
indirection register's index in the BHT, and used that for the 
prediction. Most indirect calls happen off registers, and if the 
compiler loads the register early enough (which it typically does) then 
the branch target value is available to the CPU. Other context 
information can be included in a BHT too.)

Also, in general, if something is arguably a smart thing to do in an OS 
(and more design flexibility via function pointers is a smart thing for 
which there is no viable alternative), we can expect CPUs to get 
gradually better at handling them.

> > >  (4) No account is taken of interrupt priority.
> > 
> > hm, i'm not sure what you mean - could you be more specific?
> 
> The FRV CPU, like many others, supports interrupt prioritisation.  A 
> particular interrupt level is set in the PSR, and any interrupt of a 
> higher priority can interrupt.  do_IRQ() can then do the interrupt 
> processing in the interrupt level of the interrupt that invoked it, 
> thus permitting higher priority interrupts to still happen.

ah, ok. For PREEMPT_HARDIRQS we thought about possibly utilizing 
hw-level IRQ prioritization too - but it's quite inflexible in most IRQ 
controller designs: the prioritization is rarely integrated with the CPU 
and is often attached to the ACK/EOI-ing of the IRQ line (and an 
unACK-ed IRQ can have side-effects).

So the thing we chose for PREEMPT_HARDIRQS was to do the prioritization 
at the OS/scheduler level. And OS level handling of this is what we need 
anyway: IRQ handlers are just the first, often tiny portion in a 
critical workload that a system must perform. (we have softirqs, 
signals, tasks, etc.) Nevertheless the door is open to utilize hw 
capabilities of IRQ prioritization - we 'only' need standard driver and 
/sys APIs to make use of them.

	Ingo

Re: Lost DVD-RW [Was Re: 2.6.18-rc5-mm1]

[Alan Cox]

Ar Iau, 2006-09-07 am 11:34 +0200, ysgrifennodd Tejun Heo:
> Alan, it seems that 0x848a indicates CFA device iff the ID data is from 
> IDENTIFY DEVICE.  When the command is IDENTIFY PACKET DEVICE, 0x848a 
> seems to indicate a valid ATAPI device.

Apparently so - thats a detail I didn't know about.

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

Alan

Re: 2.6.18-rc5-mm1

[Jeremy Fitzhardinge]

Greg KH wrote:
> There are 9 MSI patches in my tree that you can just remove.  They were
> just recently (a few hours ago) replaced with a total rewrite due to a
> number of different problems that were found.  So I'd suggest just
> waiting till the next -mm release to see if it works properly or not.
>   

I'm seeing exactly the same oops with CONFIG_MSI on 2.6.18-rc6-mm1.

    J

Re: 2.6.18-rc5-mm1

[Matthias Hentges]

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

Am Samstag, den 09.09.2006, 16:47 -0700 schrieb Jeremy Fitzhardinge:
> Greg KH wrote:
> > There are 9 MSI patches in my tree that you can just remove.  They were
> > just recently (a few hours ago) replaced with a total rewrite due to a
> > number of different problems that were found.  So I'd suggest just
> > waiting till the next -mm release to see if it works properly or not.
> >   
> 
> I'm seeing exactly the same oops with CONFIG_MSI on 2.6.18-rc6-mm1.

Same here.
-- 
Matthias 'CoreDump' Hentges 

My OS: Debian SID. Geek by Nature, Linux by Choice

[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] FRV: do_gettimeofday() should no longer use tickadj

[Benjamin Herrenschmidt]

> But funky cascading using chained flow handlers doesn't work if the cascade
> must share an IRQ with some other device, right?

Indeed. Best way there is then to have a normal action handler like you
do and have it call generic_handle_irq() on the cascaded interrupts.

Ben.

Re: [PATCH] FRV: do_gettimeofday() should no longer use tickadj

[David Howells]

Ingo Molnar <mingo@elte.hu> wrote:

> i cannot find Thomas' recent 2.6 one (Thomas, do you have a link to 
> it?), but i did one 5 years ago:
> 
>  http://people.redhat.com/mingo/irq-rewrite-patches/irq-cleanup-2.4.15-B1.bz2
> 
> in general it's a large but otherwise pretty dumb patch.

I wrote my own patch to test this last Friday.  I found that removing all the
regs pointer passing from the interrupt code reduced interrupt entry with a
warm cache by 1 cpu cycle out of 87, and interrupt exit by 19 cycles out of 99.

I can't tell from that exactly how many instructions/memory accesses have been
removed since the FRV permits two instructions to be executed in one cycle
under some circumstances, and two registers to be stored/loaded in one
instruction.

But the main gain in the exit path has to be due to recovery of the clobbered
regs parameter due to a call inside a loop, possibly in handle_IRQ_event().

I'd expect i386 to do better in cycle reduction because it has fewer registers
and so getting one back should gain more.

David

Re: 2.6.18-rc5-mm1

[Matthias Hentges]

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

Am Montag, den 04.09.2006, 13:52 +0200 schrieb Matthias Hentges:
> Am Sonntag, den 03.09.2006, 17:50 -0700 schrieb Andrew Morton:
> 
> > Spose so.
> > 
> > But what _did_ cause it?  Looks like we took an IRQ and then leapt into
> > outer space, when do_IRQ() called desc->handle_irq().
> > 
> > Matthias, could you please test with CONFIG_4KSTACKS=n?
> > 
> > Also, one cause of this might be a module which fails to clean up when it's
> > removed.  And the trace indicates that some module has previously
> > been unloaded.  Can you work out which module(s) that might be?
> > 
> 
> I'll try CONFIG_4KSTACKS=n when I get back from work (~10hrs...) and
> report back.

Just tried CONFIG_4KSTACKS=n but as Jeremy Fitzhardinge suggested, it
didn't change anything ;)
-- 
Matthias 'CoreDump' Hentges 

Webmaster of hentges.net and OpenZaurus developer.
You can reach me in #openzaurus on Freenode.

My OS: Debian SID. Geek by Nature, Linux by Choice

[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: 2.6.18-rc5-mm1

[Matthias Hentges]

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

Am Sonntag, den 03.09.2006, 17:50 -0700 schrieb Andrew Morton:

> Spose so.
> 
> But what _did_ cause it?  Looks like we took an IRQ and then leapt into
> outer space, when do_IRQ() called desc->handle_irq().
> 
> Matthias, could you please test with CONFIG_4KSTACKS=n?
> 
> Also, one cause of this might be a module which fails to clean up when it's
> removed.  And the trace indicates that some module has previously
> been unloaded.  Can you work out which module(s) that might be?
> 

I'll try CONFIG_4KSTACKS=n when I get back from work (~10hrs...) and
report back.
-- 
Matthias 'CoreDump' Hentges 

Webmaster of hentges.net and OpenZaurus developer.
You can reach me in #openzaurus on Freenode.

My OS: Debian SID. Geek by Nature, Linux by Choice

[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: 2.6.18-rc5-mm1

[Jeremy Fitzhardinge]

Andrew Morton wrote:
> Spose so.
>
> But what _did_ cause it?  Looks like we took an IRQ and then leapt into
> outer space, when do_IRQ() called desc->handle_irq().
>   

It was specifically an MSI interrupt problem; disabling CONFIG_MSI fixed 
the problem for me.  GregKH said that the MSI patch series in rc5-mm1 is 
broken, and had been replaced.

    J

-- 
VGER BF report: H 0

Re: 2.6.18-rc5-mm1

[Andrew Morton]

On Sun, 3 Sep 2006 17:22:17 -0700
"Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com> wrote:

>  
> 
> >-----Original Message-----
> >From: Andrew Morton [mailto:akpm@osdl.org] 
> >Sent: Friday, September 01, 2006 6:30 PM
> >To: Matthias Hentges
> >Cc: linux-kernel@vger.kernel.org; linux-acpi@vger.kernel.org; 
> >Pallipadi, Venkatesh
> >Subject: Re: 2.6.18-rc5-mm1
> >
> >On Sat, 02 Sep 2006 03:00:47 +0200
> >Matthias Hentges <oe@hentges.net> wrote:
> >
> >> 2.6.18-rc5-mm1 oopses on an Asus P5W DH Deluxe board, full dmesg
> >> attached.
> >> This did not happen in 2.6.18-rc4-mm3.
> >> 
> >> 
> >> BUG: unable to handle kernel NULL pointer dereference at 
> >virtual address
> >> 00000000
> >>  printing eip:
> >> 00000000
> >> *pde = 00000000
> >> Oops: 0000 [#1]
> >> 4K_STACKS SMP 
> >> last sysfs file: 
> >> Modules linked in:
> >> CPU:    0
> >> EIP:    0060:[<00000000>]    Not tainted VLI
> >> EFLAGS: 00010087   (2.6.18-rc5-mm1 #1) 
> >> EIP is at rest_init+0x3feffd78/0x20
> >> eax: 000000da   ebx: c04d5f78   ecx: c04d5f94   edx: c04d2f00
> >> esi: 000000da   edi: 00000000   ebp: c04d2f00   esp: c0516ffc
> >> ds: 007b   es: 007b   ss: 0068
> >> Process swapper (pid: 0, ti=c0516000 task=c045c200 task.ti=c04d5000)
> >> Stack: c0105027 
> >> Call Trace:
> >>  [<c0105027>] do_IRQ+0x8a/0xac
> >>  [<c01035a6>] common_interrupt+0x1a/0x20
> >>  [<c0101a72>] mwait_idle_with_hints+0x36/0x3b
> >>  [<c0101a83>] mwait_idle+0xc/0x1b
> >>  [<c0101a26>] cpu_idle+0x5e/0x74
> >>  [<c04db6fa>] start_kernel+0x363/0x36a
> >>  =======================
> >> Code:  Bad EIP value.
> >> EIP: [<00000000>] rest_init+0x3feffd78/0x20 SS:ESP 0068:c0516ffc
> >>  <0>Kernel panic - not syncing: Fatal exception in interrupt
> >>  BUG: warning at arch/i386/kernel/smp.c:547/smp_call_function()
> >>  [<c010ca45>] smp_call_function+0x54/0xff
> >>  [<c011a270>] printk+0x12/0x16
> >>  [<c010cb03>] smp_send_stop+0x13/0x1c
> >>  [<c0119480>] panic+0x49/0xd3
> >>  [<c010410c>] die+0x273/0x28a
> >>  [<c01126d4>] do_page_fault+0x40d/0x4db
> >>  [<c01122c7>] do_page_fault+0x0/0x4db
> >>  [<c03d1231>] error_code+0x39/0x40
> >>  [<c013007b>] free_module+0x89/0xc3
> >>  [<c0105027>] do_IRQ+0x8a/0xac
> >>  [<c01035a6>] common_interrupt+0x1a/0x20
> >>  [<c0101a72>] mwait_idle_with_hints+0x36/0x3b
> >>  [<c0101a83>] mwait_idle+0xc/0x1b
> >>  [<c0101a26>] cpu_idle+0x5e/0x74
> >>  [<c04db6fa>] start_kernel+0x363/0x36a
> >>  =======================
> >
> >OK, thanks.  That'll be acpi-mwait-c-state-fixes.patch.  I've 
> >uploaded the
> >below revert patch to
> >ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2
> >.6.18-rc5/2.6.18-rc5-mm1/hot-fixes/
> >
> 
> Andrew,
> 
> As this patch doesn't seem to be the issue here, can you un-revert the
> patch in mm...
> 

Spose so.

But what _did_ cause it?  Looks like we took an IRQ and then leapt into
outer space, when do_IRQ() called desc->handle_irq().

Matthias, could you please test with CONFIG_4KSTACKS=n?

Also, one cause of this might be a module which fails to clean up when it's
removed.  And the trace indicates that some module has previously
been unloaded.  Can you work out which module(s) that might be?


-- 
VGER BF report: H 0

Re: 2.6.18-rc5-mm1

[Andrew Morton]

On Sun, 3 Sep 2006 17:22:17 -0700
"Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com> wrote:

>  
> 
> >-----Original Message-----
> >From: Andrew Morton [mailto:akpm@osdl.org] 
> >Sent: Friday, September 01, 2006 6:30 PM
> >To: Matthias Hentges
> >Cc: linux-kernel@vger.kernel.org; linux-acpi@vger.kernel.org; 
> >Pallipadi, Venkatesh
> >Subject: Re: 2.6.18-rc5-mm1
> >
> >On Sat, 02 Sep 2006 03:00:47 +0200
> >Matthias Hentges <oe@hentges.net> wrote:
> >
> >> 2.6.18-rc5-mm1 oopses on an Asus P5W DH Deluxe board, full dmesg
> >> attached.
> >> This did not happen in 2.6.18-rc4-mm3.
> >> 
> >> 
> >> BUG: unable to handle kernel NULL pointer dereference at 
> >virtual address
> >> 00000000
> >>  printing eip:
> >> 00000000
> >> *pde = 00000000
> >> Oops: 0000 [#1]
> >> 4K_STACKS SMP 
> >> last sysfs file: 
> >> Modules linked in:
> >> CPU:    0
> >> EIP:    0060:[<00000000>]    Not tainted VLI
> >> EFLAGS: 00010087   (2.6.18-rc5-mm1 #1) 
> >> EIP is at rest_init+0x3feffd78/0x20
> >> eax: 000000da   ebx: c04d5f78   ecx: c04d5f94   edx: c04d2f00
> >> esi: 000000da   edi: 00000000   ebp: c04d2f00   esp: c0516ffc
> >> ds: 007b   es: 007b   ss: 0068
> >> Process swapper (pid: 0, ti=c0516000 task=c045c200 task.ti=c04d5000)
> >> Stack: c0105027 
> >> Call Trace:
> >>  [<c0105027>] do_IRQ+0x8a/0xac
> >>  [<c01035a6>] common_interrupt+0x1a/0x20
> >>  [<c0101a72>] mwait_idle_with_hints+0x36/0x3b
> >>  [<c0101a83>] mwait_idle+0xc/0x1b
> >>  [<c0101a26>] cpu_idle+0x5e/0x74
> >>  [<c04db6fa>] start_kernel+0x363/0x36a
> >>  =======================
> >> Code:  Bad EIP value.
> >> EIP: [<00000000>] rest_init+0x3feffd78/0x20 SS:ESP 0068:c0516ffc
> >>  <0>Kernel panic - not syncing: Fatal exception in interrupt
> >>  BUG: warning at arch/i386/kernel/smp.c:547/smp_call_function()
> >>  [<c010ca45>] smp_call_function+0x54/0xff
> >>  [<c011a270>] printk+0x12/0x16
> >>  [<c010cb03>] smp_send_stop+0x13/0x1c
> >>  [<c0119480>] panic+0x49/0xd3
> >>  [<c010410c>] die+0x273/0x28a
> >>  [<c01126d4>] do_page_fault+0x40d/0x4db
> >>  [<c01122c7>] do_page_fault+0x0/0x4db
> >>  [<c03d1231>] error_code+0x39/0x40
> >>  [<c013007b>] free_module+0x89/0xc3
> >>  [<c0105027>] do_IRQ+0x8a/0xac
> >>  [<c01035a6>] common_interrupt+0x1a/0x20
> >>  [<c0101a72>] mwait_idle_with_hints+0x36/0x3b
> >>  [<c0101a83>] mwait_idle+0xc/0x1b
> >>  [<c0101a26>] cpu_idle+0x5e/0x74
> >>  [<c04db6fa>] start_kernel+0x363/0x36a
> >>  =======================
> >
> >OK, thanks.  That'll be acpi-mwait-c-state-fixes.patch.  I've 
> >uploaded the
> >below revert patch to
> >ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2
> >.6.18-rc5/2.6.18-rc5-mm1/hot-fixes/
> >
> 
> Andrew,
> 
> As this patch doesn't seem to be the issue here, can you un-revert the
> patch in mm...
> 

Spose so.

But what _did_ cause it?  Looks like we took an IRQ and then leapt into
outer space, when do_IRQ() called desc->handle_irq().

Matthias, could you please test with CONFIG_4KSTACKS=n?

Also, one cause of this might be a module which fails to clean up when it's
removed.  And the trace indicates that some module has previously
been unloaded.  Can you work out which module(s) that might be?


-- 
VGER BF report: H 0

RE: 2.6.18-rc5-mm1

[Pallipadi, Venkatesh]

 

>-----Original Message-----
>From: Andrew Morton [mailto:akpm@osdl.org] 
>Sent: Friday, September 01, 2006 6:30 PM
>To: Matthias Hentges
>Cc: linux-kernel@vger.kernel.org; linux-acpi@vger.kernel.org; 
>Pallipadi, Venkatesh
>Subject: Re: 2.6.18-rc5-mm1
>
>On Sat, 02 Sep 2006 03:00:47 +0200
>Matthias Hentges <oe@hentges.net> wrote:
>
>> 2.6.18-rc5-mm1 oopses on an Asus P5W DH Deluxe board, full dmesg
>> attached.
>> This did not happen in 2.6.18-rc4-mm3.
>> 
>> 
>> BUG: unable to handle kernel NULL pointer dereference at 
>virtual address
>> 00000000
>>  printing eip:
>> 00000000
>> *pde = 00000000
>> Oops: 0000 [#1]
>> 4K_STACKS SMP 
>> last sysfs file: 
>> Modules linked in:
>> CPU:    0
>> EIP:    0060:[<00000000>]    Not tainted VLI
>> EFLAGS: 00010087   (2.6.18-rc5-mm1 #1) 
>> EIP is at rest_init+0x3feffd78/0x20
>> eax: 000000da   ebx: c04d5f78   ecx: c04d5f94   edx: c04d2f00
>> esi: 000000da   edi: 00000000   ebp: c04d2f00   esp: c0516ffc
>> ds: 007b   es: 007b   ss: 0068
>> Process swapper (pid: 0, ti=c0516000 task=c045c200 task.ti=c04d5000)
>> Stack: c0105027 
>> Call Trace:
>>  [<c0105027>] do_IRQ+0x8a/0xac
>>  [<c01035a6>] common_interrupt+0x1a/0x20
>>  [<c0101a72>] mwait_idle_with_hints+0x36/0x3b
>>  [<c0101a83>] mwait_idle+0xc/0x1b
>>  [<c0101a26>] cpu_idle+0x5e/0x74
>>  [<c04db6fa>] start_kernel+0x363/0x36a
>>  =======================
>> Code:  Bad EIP value.
>> EIP: [<00000000>] rest_init+0x3feffd78/0x20 SS:ESP 0068:c0516ffc
>>  <0>Kernel panic - not syncing: Fatal exception in interrupt
>>  BUG: warning at arch/i386/kernel/smp.c:547/smp_call_function()
>>  [<c010ca45>] smp_call_function+0x54/0xff
>>  [<c011a270>] printk+0x12/0x16
>>  [<c010cb03>] smp_send_stop+0x13/0x1c
>>  [<c0119480>] panic+0x49/0xd3
>>  [<c010410c>] die+0x273/0x28a
>>  [<c01126d4>] do_page_fault+0x40d/0x4db
>>  [<c01122c7>] do_page_fault+0x0/0x4db
>>  [<c03d1231>] error_code+0x39/0x40
>>  [<c013007b>] free_module+0x89/0xc3
>>  [<c0105027>] do_IRQ+0x8a/0xac
>>  [<c01035a6>] common_interrupt+0x1a/0x20
>>  [<c0101a72>] mwait_idle_with_hints+0x36/0x3b
>>  [<c0101a83>] mwait_idle+0xc/0x1b
>>  [<c0101a26>] cpu_idle+0x5e/0x74
>>  [<c04db6fa>] start_kernel+0x363/0x36a
>>  =======================
>
>OK, thanks.  That'll be acpi-mwait-c-state-fixes.patch.  I've 
>uploaded the
>below revert patch to
>ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2
>.6.18-rc5/2.6.18-rc5-mm1/hot-fixes/
>

Andrew,

As this patch doesn't seem to be the issue here, can you un-revert the
patch in mm...

Thanks,
Venki

-- 
VGER BF report: H 2.25892e-12

RE: 2.6.18-rc5-mm1

[Pallipadi, Venkatesh]

 

>-----Original Message-----
>From: Andrew Morton [mailto:akpm@osdl.org] 
>Sent: Friday, September 01, 2006 6:30 PM
>To: Matthias Hentges
>Cc: linux-kernel@vger.kernel.org; linux-acpi@vger.kernel.org; 
>Pallipadi, Venkatesh
>Subject: Re: 2.6.18-rc5-mm1
>
>On Sat, 02 Sep 2006 03:00:47 +0200
>Matthias Hentges <oe@hentges.net> wrote:
>
>> 2.6.18-rc5-mm1 oopses on an Asus P5W DH Deluxe board, full dmesg
>> attached.
>> This did not happen in 2.6.18-rc4-mm3.
>> 
>> 
>> BUG: unable to handle kernel NULL pointer dereference at 
>virtual address
>> 00000000
>>  printing eip:
>> 00000000
>> *pde = 00000000
>> Oops: 0000 [#1]
>> 4K_STACKS SMP 
>> last sysfs file: 
>> Modules linked in:
>> CPU:    0
>> EIP:    0060:[<00000000>]    Not tainted VLI
>> EFLAGS: 00010087   (2.6.18-rc5-mm1 #1) 
>> EIP is at rest_init+0x3feffd78/0x20
>> eax: 000000da   ebx: c04d5f78   ecx: c04d5f94   edx: c04d2f00
>> esi: 000000da   edi: 00000000   ebp: c04d2f00   esp: c0516ffc
>> ds: 007b   es: 007b   ss: 0068
>> Process swapper (pid: 0, ti=c0516000 task=c045c200 task.ti=c04d5000)
>> Stack: c0105027 
>> Call Trace:
>>  [<c0105027>] do_IRQ+0x8a/0xac
>>  [<c01035a6>] common_interrupt+0x1a/0x20
>>  [<c0101a72>] mwait_idle_with_hints+0x36/0x3b
>>  [<c0101a83>] mwait_idle+0xc/0x1b
>>  [<c0101a26>] cpu_idle+0x5e/0x74
>>  [<c04db6fa>] start_kernel+0x363/0x36a
>>  =======================
>> Code:  Bad EIP value.
>> EIP: [<00000000>] rest_init+0x3feffd78/0x20 SS:ESP 0068:c0516ffc
>>  <0>Kernel panic - not syncing: Fatal exception in interrupt
>>  BUG: warning at arch/i386/kernel/smp.c:547/smp_call_function()
>>  [<c010ca45>] smp_call_function+0x54/0xff
>>  [<c011a270>] printk+0x12/0x16
>>  [<c010cb03>] smp_send_stop+0x13/0x1c
>>  [<c0119480>] panic+0x49/0xd3
>>  [<c010410c>] die+0x273/0x28a
>>  [<c01126d4>] do_page_fault+0x40d/0x4db
>>  [<c01122c7>] do_page_fault+0x0/0x4db
>>  [<c03d1231>] error_code+0x39/0x40
>>  [<c013007b>] free_module+0x89/0xc3
>>  [<c0105027>] do_IRQ+0x8a/0xac
>>  [<c01035a6>] common_interrupt+0x1a/0x20
>>  [<c0101a72>] mwait_idle_with_hints+0x36/0x3b
>>  [<c0101a83>] mwait_idle+0xc/0x1b
>>  [<c0101a26>] cpu_idle+0x5e/0x74
>>  [<c04db6fa>] start_kernel+0x363/0x36a
>>  =======================
>
>OK, thanks.  That'll be acpi-mwait-c-state-fixes.patch.  I've 
>uploaded the
>below revert patch to
>ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2
>.6.18-rc5/2.6.18-rc5-mm1/hot-fixes/
>

Andrew,

As this patch doesn't seem to be the issue here, can you un-revert the
patch in mm...

Thanks,
Venki

-- 
VGER BF report: H 2.25892e-12