* 2.6.18-rc4-mm1
@ 2006-08-13 8:24 Andrew Morton
2006-08-13 11:45 ` 2.6.18-rc4-mm1 Maciej Rutecki
` (6 more replies)
0 siblings, 7 replies; 80+ messages in thread
From: Andrew Morton @ 2006-08-13 8:24 UTC (permalink / raw)
To: linux-kernel
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm1/
- Warning: all the Serial ATA Kconfig options have been renamed. If you
blindly run `make oldconfig' you won't have any disks.
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-rc3-mm2:
git-alsa.patch
git-agpgart.patch
git-arm.patch
git-block.patch
git-cifs.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-jfs.patch
git-kbuild.patch
git-libata-all.patch
git-lxdialog.patch
git-mmc.patch
git-mtd.patch
git-netdev-all.patch
git-net.patch
git-nfs.patch
git-ocfs2.patch
git-parisc.patch
git-pcmcia.patch
git-powerpc.patch
git-r8169.patch
git-sas.patch
git-s390.patch
git-scsi-misc.patch
git-scsi-rc-fixes.patch
git-scsi-target.patch
git-supertrak.patch
git-watchdog.patch
git-xfs.patch
git-cryptodev.patch
git trees
-make-suspend-possible-with-a-traced-process-at-a-breakpoint.patch
-drivers-edac-edac_mch-must-include-linux-platform_deviceh.patch
-disable-debugging-version-of-write_lock.patch
-bug-in-futex-unqueue_me.patch
-ufs-ufs_get_locked_patch-race-fix.patch
-ufs-handle-truncated-pages.patch
-crash-in-aty128_set_lcd_enable-on-powerbook.patch
-i_mutex-does-not-need-to-be-locked-in-reiserfs_delete_inode.patch
-omap-rng-build-fix.patch
-md-fix-a-bug-that-recently-crept-into-md-linear.patch
-ptrace-make-pid-of-child-process-available-for.patch
-fix-vmstat-per-cpu-usage.patch
-vt-printk-fix-framebuffer-console-triggering-might_sleep.patch
-au1100fb-info-varrotate-fix.patch
-au1100fb-fix-startup-sequence.patch
-fadvise-make-posix_fadv_noreuse-a-no-op.patch
-debug_locksh-add-struct-task_struct.patch
-knfsd-fix-race-related-problem-when-adding-items-to-and-svcrpc-auth-cache.patch
-doc-update-panic_on_oops-documentation.patch
-x86_64-fix-more-per-cpu-typos.patch
-pseries-hvsi-char-driver-null-pointer-deref.patch
-pseries-hvsi-char-driver-janitorial-cleanup.patch
-eicon-fix-define-conflict-with-ptrace.patch
-sh-fix-proc-file-removal-for-superh-store-queue-module.patch
-ieee1394-sbp2-enable-auto-spin-up-for.patch
-fix-befs-slab-corruption.patch
-memory-hotadd-fixes-not-aligned-memory-hotadd.patch
-memory-hotadd-fixes-change-find_next_system_rams.patch
-memory-hotadd-fixes-find_next_system_ram-catch-range.patch
-memory-hotadd-fixes-avoid-check-in-acpi.patch
-memory-hotadd-fixes-avoid-registering-res-twice.patch
-memory-hotadd-fixes-enhance-collistion-check.patch
-fix-reiserfs-lock-inversion-of-bkl-vs-inode-semaphore.patch
-reiserfs_write_full_page-should-not-get_block-past-eof.patch
-pnpacpi-reject-acpi_producer-resources.patch
-futex-apply-recent-futex-fixes-to-futex_compat.patch
-udf-initialize-parts-of-inode-earlier-in-create.patch
-scx200_acbeliminate-spurious-timeout-errors.patch
-ia64-kprobe-invalidate-icache-of-jump-buffer-s390-fix.patch
-git-block-dasd-fix.patch
-git-block-dasd-fix-2.patch
-sysfs_remove_bin_file-no-return-value-dump_stack-on.patch
-kobject-must_check-fixes.patch
-drivers-base-check-errors-fix-2.patch
-remove-null-chars-from-dvb-names.patch
-logips2pp-fix-mx300-button-layout.patch
-remove-polling-timer-from-i8042-v2.patch
-remove-rpm_build_root-from-asm-offsetsh.patch
-rework-legacy-handling-to-remove-much-of-the-cruft.patch
-rework-legacy-handling-to-remove-much-of-the-cruft-fix.patch
-rework-legacy-handling-to-remove-much-of-the-cruft-powerpc-fix.patch
-rework-legacy-handling-to-remove-much-of-the-cruft-fix-2.patch
-add-full-compact-flash-support-to-libata.patch
-forcedeth-move-mac-address-setup-teardown.patch
-forcedeth-mac-address-corrected.patch
-forcdeth-revised-napi-support.patch
-git-net-fib_rules-linkage-fix.patch
-fix-memory-leak-in-net-ipv4-tcp_probectcpprobe_read.patch
-pktgen-oops-when-used-with-balance-tlb-bonding.patch
-gregkh-pci-msi-03-use_root_chipset_dev_no_msi_instead_of_pci_bus_flags.patch
-gregkh-pci-msi-04-rename_pci_cap_id_ht_irqconf.patch
-gregkh-pci-msi-05-check_hypertransport_msi_capabilities.patch
-gregkh-pci-msi-06-drop_pci_msi_quirk.patch
-gregkh-pci-msi-07-drop_pci_bus_flags.patch
-fix-gregkh-pci-pci-express-aer-implemetation-pcie_portdrv-error-handler.patch
-pcie-check-and-return-bus_register-errors.patch
-areca-sysfs-fix.patch
-add-all-wacom-device-to-hid-corec-blacklist.patch
-net1080-inherent-pad-length.patch
-properly-unregister-reboot-notifier-in-case-of-failure-in-ehci-hcd.patch
-quickcam_messenger-compilation-fix.patch
-x86_64-mm-early-param-fix.patch
-fix-x86_64-mm-via-force-dma-mask-config_pcin-fix.patch
-fix-x86_64-mm-allow-users-to-force-a-panic-on-nmi.patch
-x86_64-fix-bus-numbering-format-in-mmconfig-warning.patch
-support-physical-cpu-hotplug-for-x86_64.patch
-sleazy-fpu-feature-x86_64-support.patch
-add-force-of-use-mmconfig.patch
-add-force-of-use-mmconfig-fix.patch
-add-force-of-use-mmconfig-fix-2.patch
-add-efi-e820-memory-mapping-on-x86.patch
-add-efi-e820-memory-mapping-on-x86-tidy.patch
-add-efi-e820-memory-mapping-on-x86-fix.patch
-add-efi-e820-memory-mapping-on-x86-fix-2.patch
-kernel-doc-fixes-for-debugfs.patch
-usb-build-fixes-ohci-omap.patch
-add-imacfb-documentation-and-detection.patch
Merged into mainline or a subsystem tree
+add-force-of-use-mmconfig.patch
+add-efi-e820-memory-mapping-on-x86.patch
+add-imacfb-documentation-and-detection.patch
+adfs-error-message-fix.patch
+initialize-parts-of-udf-inode-earlier-in-create.patch
+fix-hrtimer-percpu-usage-typo.patch
+fix-x86_64-mm-allow-users-to-force-a-panic-on-nmi.patch
+dm-bug-oops-fix.patch
+change-panic_on_oops-message-to-fatal-exception.patch
+fcntlf_setsig-fix.patch
+sys_getppid-oopses-on-debug-kernel-v2.patch
+sys_getppid-oopses-on-debug-kernel-v2-simplify.patch
+futex_handle_fault-always-fails.patch
+fbdev-include-backlighth-only-when-__kernel__-is-defined.patch
+workqueue-remove-lock_cpu_hotplug.patch
+fuse-fix-error-case-in-fuse_readpages.patch
+fuse-fix-error-case-in-fuse_readpages-kernel-doc-fix.patch
+dm-fix-deadlock-under-high-i-o-load-in-raid1-setup.patch
2.6.18 queue.
+trigger-a-syntax-error-if-percpu-macros-are-incorrectly-used.patch
Build-time check.
+acpi-change-gfp_atomic-to-gfp_kernel-for-non-atomic.patch
+acpi-clear-gpe-before-disabling-it.patch
+acpi-correctly-recover-from-a-failed-s3-attempt.patch
+acpi-memory-hotplug-remove-useless-message-at-boot-time.patch
ACPi updates
+sound-pci-fm801-use-array_size-macro.patch
ALSA driver cleanup
+kthread-switch-arch-arm-kernel-apmc.patch
ARM kthread conversion
+gregkh-driver-class_device_create-make-fmt-argument-const-char.patch
+gregkh-driver-device_create-make-fmt-argument-const-char.patch
+gregkh-driver-sysfs-make-poll-behaviour-consistent.patch
+gregkh-driver-debugfs-kernel-doc-fixes-for-debugfs.patch
+gregkh-driver-make-suspend-quieter.patch
+gregkh-driver-device-virtual.patch
+gregkh-driver-kobject-must_check-fixes.patch
+gregkh-driver-sysfs_remove_bin_file-no-return-value-dump_stack-on-error.patch
+gregkh-driver-driver-core-fix-comments-in-drivers-base-power-resume.c.patch
+gregkh-driver-driver-core-fixed-add_bind_files-definition.patch
+gregkh-driver-sound-device.patch
driver tree updates
+drm-build-fix.patch
+drm-build-fixes-2.patch
+git-drm-build-fix.patch
Fix git-drm.patch
+config_pm=n-slim-drivers-media-video.patch
Fix git-dvb.patch
+video1394-add-poll-file-operation-support.patch
+ieee1394-safer-definition-of-empty-macros.patch
+ieee1394-sbp2-workaround-for-write-protect-bit-of.patch
+ieee1394-sbp2-enable-auto-spin-up-for-all-sbp-2-devices.patch
+config_pm=n-slim-drivers-ieee1394-ohci1394c.patch
1394 updates
+stowaway-keyboard-support.patch
+stowaway-keyboard-support-update.patch
+i8042-get-rid-of-polling-timer-v4.patch
Input updates
+asus-mv-device-ids.patch
SATA device IDs
+1-of-2-jmicron-driver-hard_port_no-fix.patch
Fix 1-of-2-jmicron-driver.patch for libata changes
+piix_host_stop-leak-fix.patch
Fix git-libata-all leak
-sata-is-bust-on-s390.patch
Dropped
+config_pm=n-slim-drivers-scsi-sata_sil.patch
SATA cleanup
+kthread-update-arch-mips-kernel-apmc.patch
MIPS kthread conversion
+mtd-printk-format-warning.patch
+mtd-nand-fix-ams-delta-after-core-conversion.patch
MTD fixes
+add-ethtool-g-support-to-spidernet-network-driver.patch
+ehea-interface-to-network-stack.patch
+ehea-phyp-interface.patch
+ehea-queue-management.patch
+ehea-header-files.patch
+ehea-makefile.patch
+ehea-kernel-build-kconfig--makefile.patch
+skge-remember-to-run-netif_poll_disable.patch
+pal-support-of-the-fixed-phy.patch
+pal-support-of-the-fixed-phy-fix.patch
+pal-support-of-the-fixed-phy-export.patch
+fs_enet-use-pal-for-mii-management.patch
+ppc32-board-specific-part-of-fs_enet-update.patch
netdev updates
+netfilter-make-unused-signal-code-go-away-so-nobody-copies-its-broken-ness.patch
+net-add-the-udpsndbuferrors-and-udprcvbuferrors-mibs.patch
+fix-potential-stack-overflow-in-net-core-utilsc.patch
+constify-tigon3-ether-firmware-structs.patch
net updates
+config_pm=n-slim-drivers-pcmcia.patch
pcmcia tweak
+libsas-externs-not-needed.patch
Cleanup for git-sas.patch
+config_pm=n-slim-drivers-serial-8250_pcic.patch
+omap1510-serial-fix-for-115200-baud.patch
Serial updates
+gregkh-pci-pciehp-make-pciehp-build-for-powerpc.patch
+gregkh-pci-pci-remove-dead-hotplug_pci_shpc_phprm_legacy-option.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
+gregkh-pci-pcie-check-and-return-bus_register-errors.patch
PCI tree updates
+revert-gregkh-pci-pci-use-pci_bios-as-last-fallback.patch
+fix-gregkh-pci-pci-express-aer-implemetation-aer-core-and-aerdriver-on-powerpc.patch
Fix it.
+megaraid-use-the-proper-type-to-hold-the-irq-number.patch
+scsi-limit-recursion-when-flushing-shost-starved_list.patch
+scsi-target-printk-format-warnings.patch
+git-scsi-target-ibmvscsi-build-fix.patch
scsi updates
+gregkh-usb-usb-unusual_devs-entry-for-a-vox-wsx-300er-mp3-player.patch
+gregkh-usb-usb-removed-a-unbalanced-endif-from-ohci-au1xxx.c.patch
+gregkh-usb-usb-appletouch-fix-atp_disconnect.patch
+gregkh-usb-usb-additional-pid-for-sharp-w-zero3.patch
+gregkh-usb-usb-ftdi_sio-driver-new-pids.patch
+gregkh-usb-usb-usbtest.c-unsigned-retval-makes-ctrl_out-return-0-in-case-of-error.patch
+gregkh-usb-usbnet-printk-format-warning.patch
+gregkh-usb-usb-ipaq-minor-ipaq_open-cleanup.patch
+gregkh-usb-usb-usbcore-get-rid-of-the-timer-in-usb_start_wait_urb.patch
+gregkh-usb-usb-wacom-tablet-driver-reorganization.patch
+gregkh-usb-usb-add-all-wacom-device-to-hid-core.c-blacklist.patch
+gregkh-usb-usb-garmin_gps-support-for-new-generation-of-gps-receivers.patch
+gregkh-usb-usb-build-fixes-ohci-omap.patch
+gregkh-usb-usb-onetouch-handle-errors-from-input_register_device.patch
+gregkh-usb-usb-correct-locking-in-gadgetfs_disconnect.patch
+gregkh-usb-usb-fix-ep_config-to-return-correct-value.patch
+gregkh-usb-usb-gadgetfs-protect-ep_release-with-lock.patch
+gregkh-usb-usb-gmidi-new-usb-midi-gadget-class-driver.patch
+gregkh-usb-usb-make-file-operations-structs-in-drivers-usb-const.patch
+gregkh-usb-usb-making-the-kernel-wshadow-clean-usb-completion.patch
+gregkh-usb-usb-new-functions-to-check-endpoints-info.patch
+gregkh-usb-usb-usblp-use-usb_endpoint_-functions.patch
+gregkh-usb-usb-hub-use-usb_endpoint_-functions.patch
+gregkh-usb-usb-appletouch-use-usb_endpoint_-functions.patch
+gregkh-usb-usb-acecad-use-usb_endpoint_-functions.patch
+gregkh-usb-usb-ati_remote-use-usb_endpoint_-functions.patch
+gregkh-usb-usb-keyspan_remote-use-usb_endpoint_-functions.patch
+gregkh-usb-usb-powermate-use-usb_endpoint_-functions.patch
+gregkh-usb-usb-usb-serial-use-usb_endpoint_-functions.patch
+gregkh-usb-usb-usblcd-use-usb_endpoint_-functions.patch
+gregkh-usb-usb-ldusb-use-usb_endpoint_-functions.patch
+gregkh-usb-usb-net1080-inherent-pad-length.patch
+gregkh-usb-usb-add-poll-to-gadgetfs-s-endpoint-zero.patch
+gregkh-usb-usb-gadget-gadgetfs-dont-try-to-lock-before-free.patch
+gregkh-usb-usb-properly-unregister-reboot-notifier-in-case-of-failure-in-ehci-hcd.patch
+gregkh-usb-add-aircable-usb-bluetooth-dongle-driver.patch
+gregkh-usb-usb-adutux-driver.patch
+gregkh-usb-usb-multithread.patch
+gregkh-usb-usb-serial-serqt_usb.patch
USB tree updates
+stex-adjust-command-timeout-in-slave_config-routine.patch
+stex-use-more-efficient-method-for-unload-shutdown-flush.patch
Update git-supertrak.patch
+x86_64-mm-remove-early-lockdep.patch
+x86_64-mm-stacktrace-cleanup.patch
+x86_64-mm-module-locks-raw-spinlock.patch
+x86_64-mm-early-safe-smp-processor-id.patch
+x86_64-mm-early-unwind-init.patch
+x86_64-mm-stacktrace-unwinder.patch
+x86_64-mm-i386-stacktrace-unwinder.patch
+x86_64-mm-lockdep-dont-force-framepointer.patch
+x86_64-mm-improve-crash-dump-description.patch
+x86_64-mm-boot-param-bss.patch
+x86_64-mm-i386-fix-mpparse-warning.patch
+x86_64-mm-fault-notifier-export.patch
+x86_64-mm-i386-fault-notifier-export.patch
+x86_64-mm-i386-acpi_force-static.patch
+x86_64-mm-i386-enable_local_apic-static.patch
+x86_64-mm-i386-kernel-thread.patch
+x86_64-mm-i386-desc-cleanup.patch
+x86_64-mm-per-cpu-area-size.patch
+x86_64-mm-i386-topology-cleanup.patch
+x86_64-mm-i386-more-init.patch
+x86_64-mm-fix-bus-numbering-format-in-mmconfig-warning.patch
+x86_64-mm-support-physical-cpu-hotplug-for-x86_64.patch
+x86_64-mm-less-lazy-fpu.patch
+x86_64-mm-wire-up-oops_enter-oops_exit.patch
+x86_64-mm-add-mem-fix.patch
+x86_64-mm-kprobe_entry-ends-up-putting-code-into-.fixup.patch
+x86_64-mm-remove-redundant-generic_identify-calls-when-identifying-cpus.patch
+x86_64-mm-mark-init_amd-as-__cpuinit.patch
+x86_64-mm-mark-cpu_dev-structures-as-__cpuinitdata.patch
+x86_64-mm-mark-cpu-init-functions-as-__cpuinit,-data-as-__cpuinitdata.patch
+x86_64-mm-mark-cpu-identify-functions-as-__cpuinit.patch
+x86_64-mm-mark-cpu-cache-functions-as-__cpuinit.patch
+x86_64-mm-i386-kprobes-mca.patch
+x86_64-mm-i386-kprobes-nmi.patch
+x86_64-mm-remove-config.h-includes-from-asm-i386-asm-x86_64.patch
x86_64 tree updates
+revert-x86_64-mm-i386-semaphore-to-asm.patch
+revert-x86_64-mm-detect-cfi.patch
+x86_64-mm-module-locks-raw-spinlock-hack-hack-hack.patch
+fix-x86_64-mm-stacktrace-cleanup-for-s390.patch
Fix it.
+x86_64-make-numa_emulation-__init.patch
section tweaks
-hot-add-mem-x86_64-x86_64-kernel-mapping-fix.patch
+hot-add-mem-x86_64-memory_add_physaddr_to_nid-node-fixup-fix-2.patch
-hot-add-mem-x86_64-valid-add-range-check.patch
+hot-add-mem-x86_64-use-config_memory_hotplug_reserve-fix.patch
Update memory hotadd patches
+git-cryptodev-s390-fixes.patch
Fix git-cryptodev.patch
+page-migration-replace-radix_tree_lookup_slot-with-radix_tree_lockup.patch
mm hack for an unknown bug.
+apply-type-enum-zone_type-fix.patch
Fix apply-type-enum-zone_type.patch
+mm-remove_mapping-safeness-fix.patch
Fix mm-remove_mapping-safeness.patch
+slab-extract-__kmem_cache_destroy-from-kmem_cache_destroy.patch
+slab-do-not-panic-when-alloc_kmemlist-fails-and-slab-is-up.patch
+slab-fix-lockdep-warnings.patch
+slab-fix-lockdep-warnings-fix.patch
+slab-fix-lockdep-warnings-fix-2.patch
+add-__gfp_thisnode-to-avoid-fallback-to-other-nodes-and-ignore.patch
+add-__gfp_thisnode-to-avoid-fallback-to-other-nodes-and-ignore-fix.patch
+sys_move_pages-do-not-fall-back-to-other-nodes.patch
+guarantee-that-the-uncached-allocator-gets-pages-on-the-correct.patch
+cleanup-add-zone-pointer-to-get_page_from_freelist.patch
+profiling-require-buffer-allocation-on-the-correct-node.patch
+define-easier-to-handle-gfp_thisnode.patch
+fix-potential-stack-overflow-in-mm-slabc.patch
+standardize-pxx_page-macros.patch
Memory management updates
+tiacx-sparse-cleanups.patch
wireless driver cleanups
+selinux-enable-configuration-of-max-policy-version.patch
+selinux-add-support-for-range-transitions-on-object.patch
SELinux updates
+avr32-switch-to-generic-timekeeping-framework.patch
avr32 update
+sh-fix-fpn_start-typo.patch
SUperH fix
+split-i386-and-x86_64-ptraceh.patch
+uml-use-ptrace-abih-instead-of-ptraceh.patch
+x86-allow-a-kernel-to-not-be-in-ring-0-tidy.patch
+voyager-tty-locking.patch
+i386-kill-references-to-xtime.patch
x86 updates
+clean-up-suspend-header.patch
+change-the-name-of-pagedir_nosave.patch
+swsusp-introduce-some-helpful-constants.patch
+swsusp-introduce-memory-bitmaps.patch
+swsusp-use-memory-bitmaps-during-resume.patch
swsusp updates
+uml-move-signal-handlers-to-arch-code-fix.patch
Fix uml-move-signal-handlers-to-arch-code.patch
+uml-clean-our-set_ether_mac.patch
+uml-stack-usage-reduction.patch
+uml-use-mcmodel=kernel-for-x86_64.patch
+uml-fix-proc-vs-interrupt-context-spinlock-deadlock.patch
UML updates
+fix-kerneldoc-comments-in-kernel-timerc-fix.patch
Fix fix-kerneldoc-comments-in-kernel-timerc.patch
+apple-motion-sensor-driver-kconfig-fix.patch
Fix apple-motion-sensor-driver-2.patch some more
-fix-bounds-check-bug-in-__register_chrdev_region.patch
Dropped
+unwind-fix-unused-variable-warning-when.patch
+reiserfs-ifdef-xattr_sem.patch
+reiserfs-ifdef-acl-stuff-from-inode.patch
+fsh-ifdef-security-fields.patch
+oprofile-ppro-need-to-enable-disable-all-the-counters.patch
+add-o-flush-for-fat.patch
+tty-locking-on-resize.patch
+kthread-convert-arch-i386-kernel-apmc.patch
+fix-unserialized-task-files-changing.patch
+fix-unserialized-task-files-changing-fix.patch
+pidspace-is_init.patch
+simplify-update_times-avoid-jiffies-jiffies_64-aliasing-problem.patch
+chardev-checking-of-overlapping-ranges.patch
+ahci-ati-sb600-sata-support-for-various-modes.patch
+atiixp-ati-sb600-ide-support-for-various-modes.patch
+lockdep-print-kernel-version.patch
+memory-ordering-in-__kfifo-primitives.patch
+small-update-to-credits.patch
+fix-wrong-error-code-on-interrupted-close-syscalls.patch
+remove-another-configh.patch
+fix-up-lockdep-trace-in-fs-execc.patch
+make-ledsh-include-relevant-headers.patch
+config_pm=n-slim-drivers-parport-parport_serialc.patch
+config_pm=n-slim-sound-oss-tridentc.patch
+config_pm=n-slim-sound-oss-cs46xxc.patch
+ext3-and-jbd-cleanup-remove-whitespace.patch
+posix-timers-fix-clock_nanosleep-doesnt-return-the-remaining-time-in-compatibility-mode.patch
+posix-timers-fix-the-flags-handling-in-posix_cpu_nsleep.patch
Misc patches
+ntp-move-all-the-ntp-related-code-to-ntpc.patch
+ntp-move-all-the-ntp-related-code-to-ntpc-fix.patch
+ntp-add-ntp_update_frequency.patch
+ntp-add-time_adj-to-tick-length.patch
+ntp-add-time_freq-to-tick-length.patch
+ntp-prescale-time_offset.patch
+ntp-add-time_adjust-to-tick-length.patch
+ntp-remove-time_tolerance.patch
+ntp-convert-time_freq-to-nsec-value.patch
+ntp-convert-to-the-ntp4-reference-model.patch
+ntp-cleanup-defines-and-comments.patch
NTP updates
+csa-basic-accounting-over-taskstats-fix.patch
Fix csa-basic-accounting-over-taskstats.patch
+csa-accounting-taskstats-update.patch
Update CSA patches
+reiserfs-make-sure-all-dentries-refs-are-released-before-calling-kill_block_super-try-2.patch
Fix reiserfs for the fs-cache patches
+fs-cache-make-kafs-use-fs-cache-fix.patch
Fix fs-cache-make-kafs-use-fs-cache.patch
+fs-cache-cachefiles-a-cache-that-backs-onto-a-mounted-filesystem-cachefiles-printk-format-warning.patch
Fix fs-cache-cachefiles-a-cache-that-backs-onto-a-mounted-filesystem.patch
+r-o-bind-mount-prepare-for-write-access-checks-collapse-if.patch
+r-o-bind-mount-prepwork-move-open_nameis-vfs_create.patch
+r-o-bind-mount-unlink-monitor-i_nlink.patch
+r-o-bind-mount-prepwork-inc_nlink-helper.patch
+r-o-bind-mount-clean-up-ocfs2-nlink-handling.patch
+r-o-bind-mount-monitor-zeroing-of-i_nlink.patch
read-only bind mounts
+thinkpad_ec-new-driver-for-thinkpad-embedded-controller-access.patch
+hdaps-use-thinkpad_ec-instead-of-direct-port-access.patch
+hdaps-unify-and-cache-hdaps-readouts.patch
+hdaps-correct-readout-and-remove-nonsensical-attributes.patch
+hdaps-remember-keyboard-and-mouse-activity.patch
+hdaps-limit-hardware-query-rate.patch
+hdaps-delay-calibration-to-first-hardware-query.patch
+hdaps-add-explicit-hardware-configuration-functions.patch
+hdaps-add-new-sysfs-attributes.patch
+hdaps-power-off-accelerometer-on-suspend-and-unload.patch
+hdaps-stop-polling-timer-when-suspended.patch
+hdaps-simplify-whitelist.patch
HDAPS driver updates
+generic-ioremap_page_range-implementation.patch
+generic-ioremap_page_range-flush_cache_vmap.patch
+generic-ioremap_page_range-alpha-conversion.patch
+generic-ioremap_page_range-arm-conversion.patch
+generic-ioremap_page_range-avr32-conversion.patch
+generic-ioremap_page_range-cris-conversion.patch
+generic-ioremap_page_range-i386-conversion.patch
+generic-ioremap_page_range-m32r-conversion.patch
+generic-ioremap_page_range-mips-conversion.patch
+generic-ioremap_page_range-parisc-conversion.patch
+generic-ioremap_page_range-s390-conversion.patch
+generic-ioremap_page_range-sh-conversion.patch
+generic-ioremap_page_range-sh64-conversion.patch
+generic-ioremap_page_range-x86_64-conversion.patch
Code consolidation
+paravirt-remove-read-hazard-from-cow.patch
+paravirt-pte-clear-not-present.patch
+paravirt-lazy-mmu-mode-hooks.patch
+paravirt-combine-flush-accessed-dirty.patch
+paravirt-kpte-flush.patch
+paravirt-optimize-ptep-establish-for-pae.patch
+paravirt-remove-set-pte-atomic.patch
+paravirt-pae-compile-fix.patch
+paravirt-update-pte-hook.patch
Virtualisation preparatory stuff
+isdn-work-around-excessive-udelay.patch
ISDN is doing gross things.
+knfsd-make-rpc-threads-pools-numa-aware-fix.patch
Fix knfsd-make-rpc-threads-pools-numa-aware.patch
-revert-knfsd-make-rpc-threads-pools-numa-aware.patch
Unneeded
+lower-migration-thread-stop-machine-prio.patch
sched tweak
+ecryptfs-fs-makefile-and-fs-kconfig-kconfig-help-update.patch
+ecryptfs-graceful-handling-of-mount-error.patch
+ecryptfs-associate-vfsmount-with-dentry-rather-than-superblock.patch
ecryptfs updates
+namespaces-utsname-use-init_utsname-when-appropriate-gmidi.patch
+namespaces-utsname-use-init_utsname-when-appropriate-print_kernel_version.patch
People keep on using system_utsname.
+readahead-call-scheme-fix.patch
Fix readahead-call-scheme.patch
+reiser4-rename-generic_sounding_globalspatch.patch
+reiser4-rename-generic_sounding_globalspatch-fix.patch
reiser4 update
+add-full-compact-flash-support-to-libata.patch
+config_pm=n-slim-drivers-ide-pci-sc1200c.patch
IDE things
fbcon-use-persistent-allocation-for-cursor-blinking.patch
+fbcon-remove-cursor-timer-if-unused.patch
+vt-honor-the-return-value-of-device_create_file.patch
+fbdev-honor-the-return-value-of-device_create_file.patch
+fbcon-honor-the-return-value-of-device_create_file.patch
+atyfb-honor-the-return-value-of-pci_register_driver.patch
+matroxfb-honor-the-return-value-of-pci_register_driver.patch
+nvidiafb-honor-the-return-value-of-pci_enable_device.patch
+i810fb-honor-the-return-value-of-pci_enable_device.patch
+drivers-video-sis-init301h-removal-of-old.patch
+drivers-video-sis-initextlfbc-removal-of.patch
+drivers-video-sis-inith-removal-of-old-code.patch
+drivers-video-sis-osdefh-removal-of-old-code.patch
+drivers-video-sis-sis_accelc-removal-of-old.patch
+drivers-video-sis-sis_accelh-removal-of-old.patch
+drivers-video-sis-sis_mainc-removal-of-old.patch
+drivers-video-sis-sis_mainh-removal-of-old.patch
+drivers-video-sis-vgatypesh-removal-of-old.patch
fbdev updates
+fs-jffs2-jffs2_fs_ih-removal-of-old-code.patch
jffs2 cleanup
+add-srcu-based-notifier-chains-cleanup.patch
Tidy add-srcu-based-notifier-chains.patch
+kill-include-linux-configh.patch
Remove config.h inclusions
+input_register_device-debug.patch
+put_bh-debug.patch
debugging patches.
All 1382 patches:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm1/patch-list
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-13 8:24 2.6.18-rc4-mm1 Andrew Morton
@ 2006-08-13 11:45 ` Maciej Rutecki
2006-08-13 19:11 ` 2.6.18-rc4-mm1 Andrew Morton
2006-08-13 23:58 ` 2.6.18-rc4-mm1 Dmitry Torokhov
2006-08-13 12:24 ` 2.6.18-rc4-mm1 Michal Piotrowski
` (5 subsequent siblings)
6 siblings, 2 replies; 80+ messages in thread
From: Maciej Rutecki @ 2006-08-13 11:45 UTC (permalink / raw)
To: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 466 bytes --]
Andrew Morton napisał(a):
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm1/
I have problem with my keyboard. I have no error in dmesg and syslog,
but it doesn't work. I read google and try "i8042.nomux", but it didn't
help.
I enclose dmesg with "i8042.debug=1" option and my config.
Maybe I forgot something in config?
Greetings
--
Maciej Rutecki <maciej.rutecki@gmail.com>
http://www.unixy.pl
JID: bc547@jabber.gda.pl
[-- Attachment #2: config-2.6.18-rc4-mm1.gz --]
[-- Type: application/x-gzip, Size: 14622 bytes --]
[-- Attachment #3: dmesg.gz --]
[-- Type: application/x-gzip, Size: 9598 bytes --]
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-13 8:24 2.6.18-rc4-mm1 Andrew Morton
2006-08-13 11:45 ` 2.6.18-rc4-mm1 Maciej Rutecki
@ 2006-08-13 12:24 ` Michal Piotrowski
2006-08-14 6:36 ` 2.6.18-rc4-mm1 Reuben Farrelly
2006-08-13 12:43 ` 2.6.18-rc4-mm1 Rafael J. Wysocki
` (4 subsequent siblings)
6 siblings, 1 reply; 80+ messages in thread
From: Michal Piotrowski @ 2006-08-13 12:24 UTC (permalink / raw)
To: Andrew Morton; +Cc: Ingo Molnar, Arjan van de Ven, linux-kernel
On 13/08/06, Andrew Morton <akpm@osdl.org> wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm1/
>
> - Warning: all the Serial ATA Kconfig options have been renamed. If you
> blindly run `make oldconfig' you won't have any disks.
>
MAX_STACK_TRACE_ENTRIES too low!
What does it mean?
BUG: MAX_STACK_TRACE_ENTRIES too low!
turning off the locking correctness validator.
[<c0103e41>] dump_trace+0x70/0x176
[<c0103fc1>] show_trace_log_lvl+0x12/0x22
[<c0103fde>] show_trace+0xd/0xf
[<c01040b0>] dump_stack+0x17/0x19
[<c0138f30>] save_trace+0xce/0xd7
[<c0139370>] add_lock_to_list+0x22/0x39
[<c0139b3c>] check_prev_add+0x139/0x1b4
[<c0139c04>] check_prevs_add+0x4d/0xaf
[<c013b646>] __lock_acquire+0x8a1/0x93c
[<c013bd4c>] lock_acquire+0x6f/0x8f
[<c03033e8>] _spin_lock_irq+0x29/0x35
[<c01ed022>] __make_request+0x68/0x413
[<c01ed6a7>] generic_make_request+0x273/0x2a4
[<c01ed802>] submit_bio+0x12a/0x132
[<c017b6f6>] submit_bh+0x10e/0x12e
[<c0179fd3>] __block_write_full_page+0x231/0x326
[<c017b567>] block_write_full_page+0xd7/0xdf
[<c017e17a>] blkdev_writepage+0xf/0x11
[<c0199d92>] mpage_writepages+0x1b6/0x324
[<c017f3ee>] generic_writepages+0xa/0xc
[<c015b6b5>] do_writepages+0x23/0x36
[<c019871c>] __sync_single_inode+0x7b/0x199
[<c01989ac>] __writeback_single_inode+0x172/0x17a
[<c0198b50>] generic_sync_sb_inodes+0x19c/0x242
[<c0198c13>] sync_sb_inodes+0x1d/0x20
[<c0198c8e>] writeback_inodes+0x78/0xae
[<c015b52b>] wb_kupdate+0x7c/0xdd
[<c015bf14>] __pdflush+0xcc/0x163
[<c015bfdd>] pdflush+0x32/0x34
[<c01347a9>] kthread+0x82/0xaa
[<c0303dfd>] kernel_thread_helper+0x5/0xb
[<c0103fc1>] show_trace_log_lvl+0x12/0x22
[<c0103fde>] show_trace+0xd/0xf
[<c01040b0>] dump_stack+0x17/0x19
[<c0138f30>] save_trace+0xce/0xd7
[<c0139370>] add_lock_to_list+0x22/0x39
[<c0139b3c>] check_prev_add+0x139/0x1b4
[<c0139c04>] check_prevs_add+0x4d/0xaf
[<c013b646>] __lock_acquire+0x8a1/0x93c
[<c013bd4c>] lock_acquire+0x6f/0x8f
[<c03033e8>] _spin_lock_irq+0x29/0x35
[<c01ed022>] __make_request+0x68/0x413
[<c01ed6a7>] generic_make_request+0x273/0x2a4
[<c01ed802>] submit_bio+0x12a/0x132
[<c017b6f6>] submit_bh+0x10e/0x12e
[<c0179fd3>] __block_write_full_page+0x231/0x326
[<c017b567>] block_write_full_page+0xd7/0xdf
[<c017e17a>] blkdev_writepage+0xf/0x11
[<c0199d92>] mpage_writepages+0x1b6/0x324
[<c017f3ee>] generic_writepages+0xa/0xc
[<c015b6b5>] do_writepages+0x23/0x36
[<c019871c>] __sync_single_inode+0x7b/0x199
[<c01989ac>] __writeback_single_inode+0x172/0x17a
[<c0198b50>] generic_sync_sb_inodes+0x19c/0x242
[<c0198c13>] sync_sb_inodes+0x1d/0x20
[<c0198c8e>] writeback_inodes+0x78/0xae
[<c015b52b>] wb_kupdate+0x7c/0xdd
[<c015bf14>] __pdflush+0xcc/0x163
[<c015bfdd>] pdflush+0x32/0x34
[<c01347a9>] kthread+0x82/0xaa
[<c0303dfd>] kernel_thread_helper+0x5/0xb
=======================
config & dmesg http://www.stardust.webpages.pl/files/mm/2.6.18-rc4-mm1/frontline/
Regards,
Michal
--
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-13 8:24 2.6.18-rc4-mm1 Andrew Morton
2006-08-13 11:45 ` 2.6.18-rc4-mm1 Maciej Rutecki
2006-08-13 12:24 ` 2.6.18-rc4-mm1 Michal Piotrowski
@ 2006-08-13 12:43 ` Rafael J. Wysocki
2006-08-13 17:38 ` 2.6.18-rc4-mm1 Laurent Riffard
` (3 subsequent siblings)
6 siblings, 0 replies; 80+ messages in thread
From: Rafael J. Wysocki @ 2006-08-13 12:43 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
On Sunday 13 August 2006 10:24, Andrew Morton wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm1/
>
> - Warning: all the Serial ATA Kconfig options have been renamed. If you
> blindly run `make oldconfig' you won't have any disks.
Something like the appended patch is needed for the SATA/PATA options to show
up in the menu.
Greetings,
Rafael
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
---
drivers/ata/Kconfig | 8 ++++++++
1 files changed, 8 insertions(+)
Index: linux-2.6.18-rc4-mm1/drivers/ata/Kconfig
===================================================================
--- linux-2.6.18-rc4-mm1.orig/drivers/ata/Kconfig
+++ linux-2.6.18-rc4-mm1/drivers/ata/Kconfig
@@ -1,3 +1,9 @@
+#
+# SATA/PATA driver configuration
+#
+
+menu "Serial and Parallel ATA (SATA/PATA) drivers"
+ depends on SCSI
config ATA
tristate "ATA device support"
@@ -481,3 +487,5 @@ config PATA_WINBOND
If unsure, say N.
+endmenu
+
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-13 8:24 2.6.18-rc4-mm1 Andrew Morton
` (2 preceding siblings ...)
2006-08-13 12:43 ` 2.6.18-rc4-mm1 Rafael J. Wysocki
@ 2006-08-13 17:38 ` Laurent Riffard
2006-08-13 20:39 ` 2.6.18-rc4-mm1 Andrew Morton
` (2 subsequent siblings)
6 siblings, 0 replies; 80+ messages in thread
From: Laurent Riffard @ 2006-08-13 17:38 UTC (permalink / raw)
To: Andrew Morton, Kernel development list
[-- Attachment #1: Type: text/plain, Size: 2638 bytes --]
Le 13.08.2006 10:24, Andrew Morton a écrit :
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm1/
>
> - Warning: all the Serial ATA Kconfig options have been renamed. If you
> blindly run `make oldconfig' you won't have any disks.
>
Tried pata_via : it could not identify my DVD drive (LG HL-DT-ST DVDRAM GSA-4165B):
Here is an excerpt from dmesg:
libata version 2.00 loaded.
pata_via 0000:00:04.1: version 0.1.13
ata1: PATA max UDMA/100 cmd 0x1F0 ctl 0x3F6 bmdma 0xD800 irq 14
ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xD808 irq 15
scsi0 : pata_via
input: AT Translated Set 2 keyboard as /class/input/input0
ata1.00: ATA-5, max UDMA/100, 78165360 sectors: LBA
ata1.00: ata1: dev 0 multi count 16
ata1.01: ATA-7, max UDMA/133, 160086528 sectors: LBA
ata1.01: ata1: dev 1 multi count 16
ata1.00: configured for UDMA/100
ata1.01: configured for UDMA/100
scsi1 : pata_via
input: ImExPS/2 Generic Explorer Mouse as /class/input/input1
ata2.00: failed to IDENTIFY (device reports illegal type, err_mask=0x0) <======= here
ata2.01: ATAPI, max MWDMA2, CDB intr
ata2.01: configured for MWDMA2
scsi 0:0:0:0: Direct access ATA ST340016A 3.75 PQ: 0 ANSI: 5
scsi 0:0:1:0: Direct access ATA Maxtor 6Y080L0 YAR4 PQ: 0 ANSI: 5
scsi 1:0:1:0: CD/DVD E-IDE CD-950E/AKU A4Q PQ: 0 ANSI: 5
And here is an except from dmesg-2.6.18-rc3-mm2 with via via82cxxx driver:
VP_IDE: chipset revision 6
VP_IDE: not 100% native mode: will probe irqs later
VP_IDE: VIA vt82c686b (rev 40) IDE UDMA100 controller on pci0000:00:04.1
ide0: BM-DMA at 0xd800-0xd807, BIOS settings: hda:DMA, hdb:DMA
ide1: BM-DMA at 0xd808-0xd80f, BIOS settings: hdc:DMA, hdd:DMA
Probing IDE interface ide0...
input: AT Translated Set 2 keyboard as /class/input/input0
input: ImExPS/2 Generic Explorer Mouse as /class/input/input1
hda: ST340016A, ATA DISK drive
hdb: Maxtor 6Y080L0, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hda: max request size: 128KiB
hda: 78165360 sectors (40020 MB) w/2048KiB Cache, CHS=65535/16/63, UDMA(100)
hda: cache flushes not supported
hda: hda1 hda2 hda3 < hda5 hda6 hda7 > hda4
hdb: max request size: 128KiB
hdb: 160086528 sectors (81964 MB) w/2048KiB Cache, CHS=65535/16/63, UDMA(100)
hdb: cache flushes supported
hdb: hdb1 hdb2 < hdb5 hdb6 hdb7 hdb8 hdb9 >
Probing IDE interface ide1...
hdc: HL-DT-ST DVDRAM GSA-4165B, ATAPI CD/DVD-ROM drive
hdd: CD-950E/AKU, ATAPI CD/DVD-ROM drive
ide1 at 0x170-0x177,0x376 on irq 15
Full dmesg attached.
~~
laurent
[-- Attachment #2: dmesg-2.6.18-rc4-mm1 --]
[-- Type: text/plain, Size: 25252 bytes --]
Linux version 2.6.18-rc4-mm1 (laurent@antares.localdomain) (gcc version 4.1.1 20060724 (prerelease) (4.1.1-3mdk)) #91 Sun Aug 13 12:14:47 CEST 2006
BIOS-provided physical RAM map:
sanitize start
sanitize end
copy_e820_map() start: 0000000000000000 size: 000000000009fc00 end: 000000000009fc00 type: 1
copy_e820_map() type is E820_RAM
copy_e820_map() start: 000000000009fc00 size: 0000000000000400 end: 00000000000a0000 type: 2
copy_e820_map() start: 00000000000f0000 size: 0000000000010000 end: 0000000000100000 type: 2
copy_e820_map() start: 0000000000100000 size: 000000001feec000 end: 000000001ffec000 type: 1
copy_e820_map() type is E820_RAM
copy_e820_map() start: 000000001ffec000 size: 0000000000003000 end: 000000001ffef000 type: 3
copy_e820_map() start: 000000001ffef000 size: 0000000000010000 end: 000000001ffff000 type: 2
copy_e820_map() start: 000000001ffff000 size: 0000000000001000 end: 0000000020000000 type: 4
copy_e820_map() start: 00000000ffff0000 size: 0000000000010000 end: 0000000100000000 type: 2
BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000001ffec000 (usable)
BIOS-e820: 000000001ffec000 - 000000001ffef000 (ACPI data)
BIOS-e820: 000000001ffef000 - 000000001ffff000 (reserved)
BIOS-e820: 000000001ffff000 - 0000000020000000 (ACPI NVS)
BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
511MB LOWMEM available.
On node 0 totalpages: 131052
DMA zone: 4096 pages, LIFO batch:0
Normal zone: 126956 pages, LIFO batch:31
DMI 2.3 present.
ACPI: RSDP (v000 ASUS ) @ 0x000f6a80
ACPI: RSDT (v001 ASUS A7V133-C 0x30303031 MSFT 0x31313031) @ 0x1ffec000
ACPI: FADT (v001 ASUS A7V133-C 0x30303031 MSFT 0x31313031) @ 0x1ffec080
ACPI: BOOT (v001 ASUS A7V133-C 0x30303031 MSFT 0x31313031) @ 0x1ffec040
ACPI: DSDT (v001 ASUS A7V133-C 0x00001000 MSFT 0x0100000b) @ 0x00000000
ACPI: PM-Timer IO Port: 0xe408
Allocating PCI resources starting at 30000000 (gap: 20000000:dfff0000)
Detected 1410.372 MHz processor.
Built 1 zonelists. Total pages: 131052
Kernel command line: root=/dev/vglinux1/lvroot video=vesafb:ywrap,mtrr splash=silent resume=/dev/hdb6 netconsole=@192.163.0.3/,@192.168.0.1/00:0E:9B:91:ED:72
netconsole: local port 6665
netconsole: local IP 192.163.0.3
netconsole: interface eth0
netconsole: remote port 6666
netconsole: remote IP 192.168.0.1
netconsole: remote ethernet address 00:0e:9b:91:ed:72
Local APIC disabled by BIOS -- you can enable it with "lapic"
mapped APIC to ffffd000 (01407000)
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Initializing CPU#0
PID hash table entries: 2048 (order: 11, 8192 bytes)
Console: colour VGA+ 80x25
Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
... MAX_LOCKDEP_SUBCLASSES: 8
... MAX_LOCK_DEPTH: 30
... MAX_LOCKDEP_KEYS: 2048
... CLASSHASH_SIZE: 1024
... MAX_LOCKDEP_ENTRIES: 8192
... MAX_LOCKDEP_CHAINS: 8192
... CHAINHASH_SIZE: 4096
memory used by lock dependency info: 904 kB
per task-struct memory footprint: 1200 bytes
------------------------
| Locking API testsuite:
----------------------------------------------------------------------------
| spin |wlock |rlock |mutex | wsem | rsem |
--------------------------------------------------------------------------
A-A deadlock: ok | ok | ok | ok | ok | ok |
A-B-B-A deadlock: ok | ok | ok | ok | ok | ok |
A-B-B-C-C-A deadlock: ok | ok | ok | ok | ok | ok |
A-B-C-A-B-C deadlock: ok | ok | ok | ok | ok | ok |
A-B-B-C-C-D-D-A deadlock: ok | ok | ok | ok | ok | ok |
A-B-C-D-B-D-D-A deadlock: ok | ok | ok | ok | ok | ok |
A-B-C-D-B-C-D-A deadlock: ok | ok | ok | ok | ok | ok |
double unlock: ok | ok | ok | ok | ok | ok |
initialize held: ok | ok | ok | ok | ok | ok |
bad unlock order: ok | ok | ok | ok | ok | ok |
--------------------------------------------------------------------------
recursive read-lock: | ok | | ok |
recursive read-lock #2: | ok | | ok |
mixed read-write-lock: | ok | | ok |
mixed write-read-lock: | ok | | ok |
--------------------------------------------------------------------------
hard-irqs-on + irq-safe-A/12: ok | ok | ok |
soft-irqs-on + irq-safe-A/12: ok | ok | ok |
hard-irqs-on + irq-safe-A/21: ok | ok | ok |
soft-irqs-on + irq-safe-A/21: ok | ok | ok |
sirq-safe-A => hirqs-on/12: ok | ok | ok |
sirq-safe-A => hirqs-on/21: ok | ok | ok |
hard-safe-A + irqs-on/12: ok | ok | ok |
soft-safe-A + irqs-on/12: ok | ok | ok |
hard-safe-A + irqs-on/21: ok | ok | ok |
soft-safe-A + irqs-on/21: ok | ok | ok |
hard-safe-A + unsafe-B #1/123: ok | ok | ok |
soft-safe-A + unsafe-B #1/123: ok | ok | ok |
hard-safe-A + unsafe-B #1/132: ok | ok | ok |
soft-safe-A + unsafe-B #1/132: ok | ok | ok |
hard-safe-A + unsafe-B #1/213: ok | ok | ok |
soft-safe-A + unsafe-B #1/213: ok | ok | ok |
hard-safe-A + unsafe-B #1/231: ok | ok | ok |
soft-safe-A + unsafe-B #1/231: ok | ok | ok |
hard-safe-A + unsafe-B #1/312: ok | ok | ok |
soft-safe-A + unsafe-B #1/312: ok | ok | ok |
hard-safe-A + unsafe-B #1/321: ok | ok | ok |
soft-safe-A + unsafe-B #1/321: ok | ok | ok |
hard-safe-A + unsafe-B #2/123: ok | ok | ok |
soft-safe-A + unsafe-B #2/123: ok | ok | ok |
hard-safe-A + unsafe-B #2/132: ok | ok | ok |
soft-safe-A + unsafe-B #2/132: ok | ok | ok |
hard-safe-A + unsafe-B #2/213: ok | ok | ok |
soft-safe-A + unsafe-B #2/213: ok | ok | ok |
hard-safe-A + unsafe-B #2/231: ok | ok | ok |
soft-safe-A + unsafe-B #2/231: ok | ok | ok |
hard-safe-A + unsafe-B #2/312: ok | ok | ok |
soft-safe-A + unsafe-B #2/312: ok | ok | ok |
hard-safe-A + unsafe-B #2/321: ok | ok | ok |
soft-safe-A + unsafe-B #2/321: ok | ok | ok |
hard-irq lock-inversion/123: ok | ok | ok |
soft-irq lock-inversion/123: ok | ok | ok |
hard-irq lock-inversion/132: ok | ok | ok |
soft-irq lock-inversion/132: ok | ok | ok |
hard-irq lock-inversion/213: ok | ok | ok |
soft-irq lock-inversion/213: ok | ok | ok |
hard-irq lock-inversion/231: ok | ok | ok |
soft-irq lock-inversion/231: ok | ok | ok |
hard-irq lock-inversion/312: ok | ok | ok |
soft-irq lock-inversion/312: ok | ok | ok |
hard-irq lock-inversion/321: ok | ok | ok |
soft-irq lock-inversion/321: ok | ok | ok |
hard-irq read-recursion/123: ok |
soft-irq read-recursion/123: ok |
hard-irq read-recursion/132: ok |
soft-irq read-recursion/132: ok |
hard-irq read-recursion/213: ok |
soft-irq read-recursion/213: ok |
hard-irq read-recursion/231: ok |
soft-irq read-recursion/231: ok |
hard-irq read-recursion/312: ok |
soft-irq read-recursion/312: ok |
hard-irq read-recursion/321: ok |
soft-irq read-recursion/321: ok |
-------------------------------------------------------
Good, all 218 testcases passed! |
---------------------------------
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 514020k/524208k available (1613k kernel code, 9564k reserved, 1194k data, 160k init, 0k highmem)
virtual kernel memory layout:
fixmap : 0xfffb7000 - 0xfffff000 ( 288 kB)
vmalloc : 0xe0800000 - 0xfffb5000 ( 503 MB)
lowmem : 0xc0000000 - 0xdffec000 ( 511 MB)
.init : 0xc03c2000 - 0xc03ea000 ( 160 kB)
.data : 0xc029374e - 0xc03be1f8 (1194 kB)
.text : 0xc0100000 - 0xc029374e (1613 kB)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay using timer specific routine.. 2824.46 BogoMIPS (lpj=5648933)
Mount-cache hash table entries: 512
CPU: After generic identify, caps: 0383f9ff c1cbf9ff 00000000 00000000 00000000 00000000 00000000
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 256K (64 bytes/line)
CPU: After all inits, caps: 0383f9ff c1cbf9ff 00000000 00000420 00000000 00000000 00000000
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: AMD Athlon(TM) XP 1600+ stepping 02
Checking 'hlt' instruction... OK.
ACPI: Core revision 20060707
tbxface-0107 [01] load_tables : ACPI Tables successfully acquired
Parsing all Control Methods:
Table [DSDT](id 0005) - 356 Objects with 38 Devices 115 Methods 24 Regions
ACPI Namespace successfully loaded at root c0572630
ACPI: setting ELCR to 0200 (from 0c20)
evxfevnt-0089 [02] enable : Transition to ACPI mode successful
checking if image is initramfs... it is
Freeing initrd memory: 398k freed
NET: Registered protocol family 16
ACPI: bus type pci registered
PCI: PCI BIOS revision 2.10 entry at 0xf1180, last bus=1
Setting up standard PCI resources
evgpeblk-0951 [04] ev_create_gpe_block : GPE 00 to 0F [_GPE] 2 regs on int 0x9
evgpeblk-1048 [03] ev_initialize_gpe_bloc: Found 4 Wake, Enabled 0 Runtime GPEs in this block
Completing Region/Field/Buffer/Package initialization:.......................................................
Initialized 23/24 Regions 2/2 Fields 19/19 Buffers 11/14 Packages (365 nodes)
Initializing Device/Processor/Thermal objects by executing _INI methods:
Executed 0 _INI methods requiring 0 _STA executions (examined 41 objects)
ACPI: Interpreter enabled
ACPI: Using PIC for interrupt routing
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 *10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 *5 6 7 9 10 11 12 14 15)
ACPI: PCI Root Bridge [PCI0] (0000:00)
PCI: Probing PCI hardware (bus 00)
ACPI: Assume root bridge [\_SB_.PCI0] bus is 0
PCI quirk: region e200-e27f claimed by vt82c686 HW-mon
PCI quirk: region e800-e80f claimed by vt82c686 SMB
Boot video device is 0000:01:00.0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report
ACPI Error (utglobal-0125): Unknown exception code: 0xFFFFFFEA [20060707]
ACPI Error (utglobal-0125): Unknown exception code: 0xFFFFFFEA [20060707]
ACPI Error (utglobal-0125): Unknown exception code: 0xFFFFFFEA [20060707]
PCI: Bridge: 0000:00:01.0
IO window: disabled.
MEM window: c6000000-c7efffff
PREFETCH window: c7f00000-cfffffff
PCI: Setting latency timer of device 0000:00:01.0 to 64
NET: Registered protocol family 2
IP route cache hash table entries: 4096 (order: 2, 16384 bytes)
TCP established hash table entries: 16384 (order: 7, 655360 bytes)
TCP bind hash table entries: 8192 (order: 6, 360448 bytes)
TCP: Hash tables configured (established 16384 bind 8192)
TCP reno registered
Simple Boot Flag at 0x3a set to 0x1
Initializing Cryptographic API
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
Applying VIA southbridge workaround.
PCI: Disabling Via external APIC routing
ACPI: Power Button (FF) [PWRF]
ACPI: Power Button (CM) [PWRB]
ACPI: CPU0 (power states: C1[C1] C2[C2])
ACPI: Processor [CPU0] (supports 16 throttling states)
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
ne2k-pci.c:v1.03 9/22/2003 D. Becker/P. Gortmaker
http://www.scyld.com/network/ne2k-pci.html
ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 10
PCI: setting IRQ 10 as level-triggered
ACPI: PCI Interrupt 0000:00:0b.0[A] -> Link [LNKB] -> GSI 10 (level, low) -> IRQ 10
eth0: RealTek RTL-8029 found at 0xa400, IRQ 10, 00:40:95:46:6E:2D.
netconsole: device eth0 not up yet, forcing it
netconsole: carrier detect appears untrustworthy, waiting 4 seconds
=================================
[ INFO: inconsistent lock state ]
2.6.18-rc4-mm1 #91
---------------------------------
inconsistent {in-softirq-W} -> {softirq-on-W} usage.
swapper/1 [HC0[0]:SC0[0]:HE1:SE1] takes:
(&dev->_xmit_lock){-+..}, at: [<c025353f>] netpoll_send_skb+0x6b/0xdb
{in-softirq-W} state was registered at:
[<c012c793>] __lock_acquire+0x3e1/0x9aa
[<c012d021>] lock_acquire+0x60/0x80
[<c0292638>] _spin_lock+0x19/0x28
[<c02550f6>] dev_watchdog+0x11/0xaf
[<c011da6d>] run_timer_softirq+0xed/0x145
[<c011a8e4>] __do_softirq+0x46/0x9c
[<c011a964>] do_softirq+0x2a/0x42
[<c011acda>] irq_exit+0x31/0x33
[<c0104f39>] do_IRQ+0x97/0xa6
[<c0103699>] common_interrupt+0x25/0x2c
[<c0101aa5>] cpu_idle+0x3c/0x51
[<c0100553>] rest_init+0x1e/0x23
[<c03c26cd>] start_kernel+0x2e2/0x2e4
[<c0100199>] 0xc0100199
[<ffffffff>] 0xffffffff
irq event stamp: 623920
hardirqs last enabled at (623919): [<c0292900>] _spin_unlock_irqrestore+0x36/0x3c
hardirqs last disabled at (623920): [<c0292951>] _spin_lock_irqsave+0xf/0x32
softirqs last enabled at (623880): [<c024bb29>] dev_mc_upload+0x36/0x3a
softirqs last disabled at (623876): [<c0292652>] _spin_lock_bh+0xb/0x2d
other info that might help us debug this:
1 lock held by swapper/1:
#0: (&dev->_xmit_lock){-+..}, at: [<c025353f>] netpoll_send_skb+0x6b/0xdb
stack backtrace:
[<c0103894>] show_trace_log_lvl+0x12/0x25
[<c0103975>] show_trace+0xd/0x10
[<c01040aa>] dump_stack+0x19/0x1b
[<c012b6b9>] print_usage_bug+0x1d1/0x1de
[<c012bbc9>] mark_lock+0x22d/0x349
[<c012bd2c>] mark_held_locks+0x47/0x65
[<c012be39>] trace_hardirqs_on+0xef/0x119
[<c0223eaa>] ei_start_xmit+0x258/0x27e
[<c025355d>] netpoll_send_skb+0x89/0xdb
[<c0254201>] netpoll_send_udp+0x1fd/0x208
[<c0224070>] write_msg+0x42/0x6a
[<c0116823>] __call_console_drivers+0x3b/0x48
[<c0116884>] _call_console_drivers+0x54/0x58
[<c0116a46>] release_console_sem+0x122/0x1ed
[<c0116da7>] register_console+0x190/0x197
[<c022401a>] init_netconsole+0x4e/0x62
[<c01003b4>] init+0x88/0x209
[<c0292be1>] kernel_thread_helper+0x5/0xb
=======================
netconsole: network logging started
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
serio: i8042 KBD port at 0x60,0x64 irq 1
serio: i8042 AUX port at 0x60,0x64 irq 12
mice: PS/2 mouse device common for all mice
TCP bic registered
NET: Registered protocol family 1
Using IPI Shortcut mode
ACPI: (supports S0 S1 S3 S4 S5)
BIOS EDD facility v0.16 2004-Jun-25, 2 devices found
Freeing unused kernel memory: 160k freed
Write protecting the kernel read-only data: 712k
Time: tsc clocksource has been installed.
Time: acpi_pm clocksource has been installed.
SCSI subsystem initialized
libata version 2.00 loaded.
pata_via 0000:00:04.1: version 0.1.13
ata1: PATA max UDMA/100 cmd 0x1F0 ctl 0x3F6 bmdma 0xD800 irq 14
ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xD808 irq 15
scsi0 : pata_via
input: AT Translated Set 2 keyboard as /class/input/input0
ata1.00: ATA-5, max UDMA/100, 78165360 sectors: LBA
ata1.00: ata1: dev 0 multi count 16
ata1.01: ATA-7, max UDMA/133, 160086528 sectors: LBA
ata1.01: ata1: dev 1 multi count 16
ata1.00: configured for UDMA/100
ata1.01: configured for UDMA/100
scsi1 : pata_via
input: ImExPS/2 Generic Explorer Mouse as /class/input/input1
ata2.00: failed to IDENTIFY (device reports illegal type, err_mask=0x0)
ata2.01: ATAPI, max MWDMA2, CDB intr
ata2.01: configured for MWDMA2
scsi 0:0:0:0: Direct access ATA ST340016A 3.75 PQ: 0 ANSI: 5
scsi 0:0:1:0: Direct access ATA Maxtor 6Y080L0 YAR4 PQ: 0 ANSI: 5
scsi 1:0:1:0: CD/DVD E-IDE CD-950E/AKU A4Q PQ: 0 ANSI: 5
SCSI device sda: 78165360 512-byte hdwr sectors (40021 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: drive cache: write back
SCSI device sda: 78165360 512-byte hdwr sectors (40021 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: drive cache: write back
sda: sda1 sda2 sda3 < sda5 sda6 sda7 > sda4
sd 0:0:0:0: Attached scsi disk sda
SCSI device sdb: 160086528 512-byte hdwr sectors (81964 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 3a 00 00
SCSI device sdb: drive cache: write back
SCSI device sdb: 160086528 512-byte hdwr sectors (81964 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 3a 00 00
SCSI device sdb: drive cache: write back
sdb: sdb1 sdb2 < sdb5 sdb6 sdb7 sdb8 sdb9 >
sd 0:0:1:0: Attached scsi disk sdb
sr0: scsi3-mmc drive: 0x/48x cd/rw xa/form2 cdda tray
Uniform CD-ROM driver Revision: 3.20
sr 1:0:1:0: Attached scsi CD-ROM sr0
device-mapper: ioctl: 4.8.0-ioctl (2006-06-24) initialised: dm-devel@redhat.com
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
USB Universal Host Controller Interface driver v3.0
ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 5
PCI: setting IRQ 5 as level-triggered
ACPI: PCI Interrupt 0000:00:04.2[D] -> Link [LNKD] -> GSI 5 (level, low) -> IRQ 5
uhci_hcd 0000:00:04.2: UHCI Host Controller
uhci_hcd 0000:00:04.2: new USB bus registered, assigned bus number 1
uhci_hcd 0000:00:04.2: irq 5, io base 0x0000d400
usb usb1: new device found, idVendor=0000, idProduct=0000
usb usb1: new device strings: Mfr=3, Product=2, SerialNumber=1
usb usb1: Product: UHCI Host Controller
usb usb1: Manufacturer: Linux 2.6.18-rc4-mm1 uhci_hcd
usb usb1: SerialNumber: 0000:00:04.2
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
warning: process `sleep' used the obsolete sysctl system call
ACPI: PCI Interrupt 0000:00:04.3[D] -> Link [LNKD] -> GSI 5 (level, low) -> IRQ 5
uhci_hcd 0000:00:04.3: UHCI Host Controller
uhci_hcd 0000:00:04.3: new USB bus registered, assigned bus number 2
uhci_hcd 0000:00:04.3: irq 5, io base 0x0000d000
usb usb2: new device found, idVendor=0000, idProduct=0000
usb usb2: new device strings: Mfr=3, Product=2, SerialNumber=1
usb usb2: Product: UHCI Host Controller
usb usb2: Manufacturer: Linux 2.6.18-rc4-mm1 uhci_hcd
usb usb2: SerialNumber: 0000:00:04.3
usb usb2: configuration #1 chosen from 1 choice
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
ACPI: PCI Interrupt 0000:00:09.0[A] -> Link [LNKD] -> GSI 5 (level, low) -> IRQ 5
usb 1-2: new low speed USB device using uhci_hcd and address 2
ohci1394: fw-host0: OHCI-1394 1.0 (PCI): IRQ=[5] MMIO=[c5800000-c58007ff] Max Packet=[2048] IR/IT contexts=[8/8]
usb 1-2: new device found, idVendor=044f, idProduct=b303
usb 1-2: new device strings: Mfr=4, Product=30, SerialNumber=0
usb 1-2: Product: FireStorm Dual Analog 2
usb 1-2: Manufacturer: THRUSTMASTER
usb 1-2: configuration #1 chosen from 1 choice
ohci1394: fw-host0: Running dma failed because Node ID is not valid
input: THRUSTMASTER FireStorm Dual Analog 2 as /class/input/input2
input: USB HID v1.10 Gamepad [THRUSTMASTER FireStorm Dual Analog 2] on usb-0000:00:04.2-2
usbcore: registered new interface driver usbhid
drivers/usb/input/hid-core.c: v2.6:USB HID core driver
warning: process `date' used the obsolete sysctl system call
ohci1394: fw-host0: AT dma reset ctx=0, aborting transmission
ieee1394: Current remote IRM is not 1394a-2000 compliant, resetting...
input: PC Speaker as /class/input/input3
parport_pc: VIA 686A/8231 detected
parport_pc: probing current configuration
parport_pc: Current parallel port base: 0x378
parport0: PC-style at 0x378 (0x778), irq 7 [PCSPP,TRISTATE]
parport0: Printer, HEWLETT-PACKARD DESKJET 710C
parport_pc: VIA parallel port: io=0x378, irq=7
ieee1394: Host added: ID:BUS[0-00:1023] GUID[00308d0120e085ca]
lp0: using parport0 (interrupt-driven).
Real Time Clock Driver v1.12ac
Linux agpgart interface v0.101 (c) Dave Jones
agpgart: Detected VIA Twister-K/KT133x/KM133 chipset
agpgart: AGP aperture is 256M @ 0xd0000000
Using specific hotkey driver
EXT3 FS on dm-4, internal journal
Adding 64220k swap on /dev/sda5. Priority:2 extents:1 across:64220k
ReiserFS: dm-1: found reiserfs format "3.6" with standard journal
ReiserFS: dm-1: using ordered data mode
reiserfs: using flush barriers
ReiserFS: dm-1: journal params: device dm-1, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: dm-1: checking transaction log (dm-1)
ReiserFS: dm-1: Using r5 hash to sort names
ReiserFS: dm-6: found reiserfs format "3.6" with standard journal
ReiserFS: dm-6: using ordered data mode
reiserfs: using flush barriers
ReiserFS: dm-6: journal params: device dm-6, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: dm-6: checking transaction log (dm-6)
ReiserFS: dm-6: Using r5 hash to sort names
Loading Reiser4. See www.namesys.com for a description of Reiser4.
ps_hash_table: 32 buckets
d_cursor_hash_table: 256 buckets
z_hash_table: 8192 buckets
z_hash_table: 8192 buckets
j_hash_table: 16384 buckets
loading reiser4 bitmap......done (34 jiffies)
d_cursor_hash_table: 256 buckets
z_hash_table: 8192 buckets
z_hash_table: 8192 buckets
j_hash_table: 16384 buckets
loading reiser4 bitmap......done (33 jiffies)
ReiserFS: sda7: found reiserfs format "3.6" with standard journal
ReiserFS: sda7: using ordered data mode
reiserfs: using flush barriers
ReiserFS: sda7: journal params: device sda7, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: sda7: checking transaction log (sda7)
ReiserFS: sda7: Using r5 hash to sort names
ReiserFS: dm-0: found reiserfs format "3.6" with standard journal
ReiserFS: dm-0: using ordered data mode
reiserfs: using flush barriers
ReiserFS: dm-0: journal params: device dm-0, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: dm-0: checking transaction log (dm-0)
ReiserFS: dm-0: Using r5 hash to sort names
kjournald starting. Commit interval 5 seconds
EXT3-fs warning: maximal mount count reached, running e2fsck is recommended
EXT3 FS on dm-2, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
loop: loaded (max 8 devices)
warning: process `ls' used the obsolete sysctl system call
warning: process `prcsys' used the obsolete sysctl system call
warning: process `prcsys' used the obsolete sysctl system call
Using specific hotkey driver
ACPI: PCI Interrupt 0000:00:0d.0[A] -> Link [LNKD] -> GSI 5 (level, low) -> IRQ 5
NET: Registered protocol family 17
ReiserFS: dm-5: found reiserfs format "3.6" with standard journal
ReiserFS: dm-5: using ordered data mode
reiserfs: using flush barriers
ReiserFS: dm-5: journal params: device dm-5, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: dm-5: checking transaction log (dm-5)
ReiserFS: dm-5: Using r5 hash to sort names
UDF-fs: No VRS found
attempt to access beyond end of device
sda3: rw=0, want=68, limit=2
attempt to access beyond end of device
sda3: rw=0, want=1252, limit=2
attempt to access beyond end of device
sda3: rw=0, want=1028, limit=2
UDF-fs: No partition found (1)
FAT: bogus number of reserved sectors
VFS: Can't find a valid FAT filesystem on dev sda3.
UDF-fs: No partition found (1)
FAT: bogus number of reserved sectors
VFS: Can't find a valid FAT filesystem on dev sda6.
UDF-fs: No VRS found
attempt to access beyond end of device
sdb2: rw=0, want=68, limit=2
attempt to access beyond end of device
sdb2: rw=0, want=1252, limit=2
attempt to access beyond end of device
sdb2: rw=0, want=1028, limit=2
UDF-fs: No partition found (1)
FAT: bogus number of reserved sectors
VFS: Can't find a valid FAT filesystem on dev sdb2.
UDF-fs: No VRS found
attempt to access beyond end of device
sdb2: rw=0, want=68, limit=2
attempt to access beyond end of device
sdb2: rw=0, want=1252, limit=2
attempt to access beyond end of device
sdb2: rw=0, want=1028, limit=2
UDF-fs: No partition found (1)
FAT: bogus number of reserved sectors
VFS: Can't find a valid FAT filesystem on dev sdb2.
UDF-fs: No VRS found
UDF-fs: No VRS found
FAT: bogus number of reserved sectors
VFS: Can't find a valid FAT filesystem on dev sdb6.
UDF-fs: No VRS found
FAT: bogus number of reserved sectors
VFS: Can't find a valid FAT filesystem on dev sdb7.
UDF-fs: No partition found (1)
FAT: bogus number of reserved sectors
VFS: Can't find a valid FAT filesystem on dev sdb8.
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-13 11:45 ` 2.6.18-rc4-mm1 Maciej Rutecki
@ 2006-08-13 19:11 ` Andrew Morton
2006-08-13 22:44 ` 2.6.18-rc4-mm1 Ben Buxton
2022-08-14 8:42 ` 2.6.18-rc4-mm1 Maciej Rutecki
2006-08-13 23:58 ` 2.6.18-rc4-mm1 Dmitry Torokhov
1 sibling, 2 replies; 80+ messages in thread
From: Andrew Morton @ 2006-08-13 19:11 UTC (permalink / raw)
To: Maciej Rutecki; +Cc: linux-kernel, Dmitry Torokhov
Please always do reply-to-all.
On Sun, 13 Aug 2006 13:45:35 +0200
Maciej Rutecki <maciej.rutecki@gmail.com> wrote:
> Andrew Morton napisał(a):
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm1/
>
> I have problem with my keyboard. I have no error in dmesg and syslog,
> but it doesn't work. I read google and try "i8042.nomux", but it didn't
> help.
>
> I enclose dmesg with "i8042.debug=1" option and my config.
>
> Maybe I forgot something in config?
>
Could be i8042-get-rid-of-polling-timer-v4.patch. Please try the below
reversion patch, on top of rc4-mm1, thanks.
diff -puN drivers/input/serio/i8042.c~revert-i8042-get-rid-of-polling-timer-v4 drivers/input/serio/i8042.c
--- a/drivers/input/serio/i8042.c~revert-i8042-get-rid-of-polling-timer-v4
+++ a/drivers/input/serio/i8042.c
@@ -90,24 +90,46 @@ static DEFINE_SPINLOCK(i8042_lock);
struct i8042_port {
struct serio *serio;
int irq;
+ unsigned char disable;
+ unsigned char irqen;
unsigned char exists;
signed char mux;
+ char name[8];
};
#define I8042_KBD_PORT_NO 0
#define I8042_AUX_PORT_NO 1
#define I8042_MUX_PORT_NO 2
#define I8042_NUM_PORTS (I8042_NUM_MUX_PORTS + 2)
-
-static struct i8042_port i8042_ports[I8042_NUM_PORTS];
+static struct i8042_port i8042_ports[I8042_NUM_PORTS] = {
+ {
+ .disable = I8042_CTR_KBDDIS,
+ .irqen = I8042_CTR_KBDINT,
+ .mux = -1,
+ .name = "KBD",
+ },
+ {
+ .disable = I8042_CTR_AUXDIS,
+ .irqen = I8042_CTR_AUXINT,
+ .mux = -1,
+ .name = "AUX",
+ }
+};
static unsigned char i8042_initial_ctr;
static unsigned char i8042_ctr;
+static unsigned char i8042_mux_open;
static unsigned char i8042_mux_present;
-static unsigned char i8042_kbd_irq_registered;
-static unsigned char i8042_aux_irq_registered;
+static struct timer_list i8042_timer;
static struct platform_device *i8042_platform_device;
+
+/*
+ * Shared IRQ's require a device pointer, but this driver doesn't support
+ * multiple devices
+ */
+#define i8042_request_irq_cookie (&i8042_timer)
+
static irqreturn_t i8042_interrupt(int irq, void *dev_id, struct pt_regs *regs);
/*
@@ -119,7 +141,6 @@ static irqreturn_t i8042_interrupt(int i
static int i8042_wait_read(void)
{
int i = 0;
-
while ((~i8042_read_status() & I8042_STR_OBF) && (i < I8042_CTL_TIMEOUT)) {
udelay(50);
i++;
@@ -130,7 +151,6 @@ static int i8042_wait_read(void)
static int i8042_wait_write(void)
{
int i = 0;
-
while ((i8042_read_status() & I8042_STR_IBF) && (i < I8042_CTL_TIMEOUT)) {
udelay(50);
i++;
@@ -172,57 +192,48 @@ static int i8042_flush(void)
* encoded in bits 8-11 of the command number.
*/
-static int __i8042_command(unsigned char *param, int command)
+static int i8042_command(unsigned char *param, int command)
{
- int i, error;
+ unsigned long flags;
+ int i, retval, auxerr = 0;
if (i8042_noloop && command == I8042_CMD_AUX_LOOP)
return -1;
- error = i8042_wait_write();
- if (error)
- return error;
+ spin_lock_irqsave(&i8042_lock, flags);
+
+ if ((retval = i8042_wait_write()))
+ goto out;
dbg("%02x -> i8042 (command)", command & 0xff);
i8042_write_command(command & 0xff);
for (i = 0; i < ((command >> 12) & 0xf); i++) {
- error = i8042_wait_write();
- if (error)
- return error;
+ if ((retval = i8042_wait_write()))
+ goto out;
dbg("%02x -> i8042 (parameter)", param[i]);
i8042_write_data(param[i]);
}
for (i = 0; i < ((command >> 8) & 0xf); i++) {
- error = i8042_wait_read();
- if (error) {
- dbg(" -- i8042 (timeout)");
- return error;
- }
+ if ((retval = i8042_wait_read()))
+ goto out;
if (command == I8042_CMD_AUX_LOOP &&
!(i8042_read_status() & I8042_STR_AUXDATA)) {
- dbg(" -- i8042 (auxerr)");
- return -1;
+ retval = auxerr = -1;
+ goto out;
}
param[i] = i8042_read_data();
dbg("%02x <- i8042 (return)", param[i]);
}
- return 0;
-}
-
-static int i8042_command(unsigned char *param, int command)
-{
- unsigned long flags;
- int retval;
+ if (retval)
+ dbg(" -- i8042 (%s)", auxerr ? "auxerr" : "timeout");
- spin_lock_irqsave(&i8042_lock, flags);
- retval = __i8042_command(param, command);
+ out:
spin_unlock_irqrestore(&i8042_lock, flags);
-
return retval;
}
@@ -237,7 +248,7 @@ static int i8042_kbd_write(struct serio
spin_lock_irqsave(&i8042_lock, flags);
- if (!(retval = i8042_wait_write())) {
+ if(!(retval = i8042_wait_write())) {
dbg("%02x -> i8042 (kbd-data)", c);
i8042_write_data(c);
}
@@ -276,6 +287,100 @@ static int i8042_aux_write(struct serio
}
/*
+ * i8042_activate_port() enables port on a chip.
+ */
+
+static int i8042_activate_port(struct i8042_port *port)
+{
+ if (!port->serio)
+ return -1;
+
+ i8042_flush();
+
+ /*
+ * Enable port again here because it is disabled if we are
+ * resuming (normally it is enabled already).
+ */
+ i8042_ctr &= ~port->disable;
+
+ i8042_ctr |= port->irqen;
+
+ if (i8042_command(&i8042_ctr, I8042_CMD_CTL_WCTR)) {
+ i8042_ctr &= ~port->irqen;
+ return -1;
+ }
+
+ return 0;
+}
+
+
+/*
+ * i8042_open() is called when a port is open by the higher layer.
+ * It allocates the interrupt and calls i8042_enable_port.
+ */
+
+static int i8042_open(struct serio *serio)
+{
+ struct i8042_port *port = serio->port_data;
+
+ if (port->mux != -1)
+ if (i8042_mux_open++)
+ return 0;
+
+ if (request_irq(port->irq, i8042_interrupt,
+ IRQF_SHARED, "i8042", i8042_request_irq_cookie)) {
+ printk(KERN_ERR "i8042.c: Can't get irq %d for %s, unregistering the port.\n", port->irq, port->name);
+ goto irq_fail;
+ }
+
+ if (i8042_activate_port(port)) {
+ printk(KERN_ERR "i8042.c: Can't activate %s, unregistering the port\n", port->name);
+ goto activate_fail;
+ }
+
+ i8042_interrupt(0, NULL, NULL);
+
+ return 0;
+
+ activate_fail:
+ free_irq(port->irq, i8042_request_irq_cookie);
+
+ irq_fail:
+ serio_unregister_port_delayed(serio);
+
+ return -1;
+}
+
+/*
+ * i8042_close() frees the interrupt, so that it can possibly be used
+ * by another driver. We never know - if the user doesn't have a mouse,
+ * the BIOS could have used the AUX interrupt for PCI.
+ */
+
+static void i8042_close(struct serio *serio)
+{
+ struct i8042_port *port = serio->port_data;
+
+ if (port->mux != -1)
+ if (--i8042_mux_open)
+ return;
+
+ i8042_ctr &= ~port->irqen;
+
+ if (i8042_command(&i8042_ctr, I8042_CMD_CTL_WCTR)) {
+ printk(KERN_WARNING "i8042.c: Can't write CTR while closing %s.\n", port->name);
+/*
+ * We still want to continue and free IRQ so if more data keeps coming in
+ * kernel will just ignore the irq.
+ */
+ }
+
+ free_irq(port->irq, i8042_request_irq_cookie);
+
+ i8042_flush();
+}
+
+/*
* i8042_start() is called by serio core when port is about to finish
* registering. It will mark port as existing so i8042_interrupt can
* start sending data through it.
@@ -318,6 +423,8 @@ static irqreturn_t i8042_interrupt(int i
unsigned int port_no;
int ret;
+ mod_timer(&i8042_timer, jiffies + I8042_POLL_PERIOD);
+
spin_lock_irqsave(&i8042_lock, flags);
str = i8042_read_status();
if (unlikely(~str & I8042_STR_OBF)) {
@@ -373,8 +480,8 @@ static irqreturn_t i8042_interrupt(int i
port = &i8042_ports[port_no];
- dbg("%02x <- i8042 (interrupt, %d, %d%s%s)",
- data, port_no, irq,
+ dbg("%02x <- i8042 (interrupt, %s, %d%s%s)",
+ data, port->name, irq,
dfl & SERIO_PARITY ? ", bad parity" : "",
dfl & SERIO_TIMEOUT ? ", timeout" : "");
@@ -387,58 +494,6 @@ static irqreturn_t i8042_interrupt(int i
}
/*
- * i8042_enable_kbd_port enables keybaord port on chip
- */
-
-static int i8042_enable_kbd_port(void)
-{
- i8042_ctr &= ~I8042_CTR_KBDDIS;
- i8042_ctr |= I8042_CTR_KBDINT;
-
- if (i8042_command(&i8042_ctr, I8042_CMD_CTL_WCTR)) {
- printk(KERN_ERR "i8042.c: Failed to enable KBD port.\n");
- return -EIO;
- }
-
- return 0;
-}
-
-/*
- * i8042_enable_aux_port enables AUX (mouse) port on chip
- */
-
-static int i8042_enable_aux_port(void)
-{
- i8042_ctr &= ~I8042_CTR_AUXDIS;
- i8042_ctr |= I8042_CTR_AUXINT;
-
- if (i8042_command(&i8042_ctr, I8042_CMD_CTL_WCTR)) {
- printk(KERN_ERR "i8042.c: Failed to enable AUX port.\n");
- return -EIO;
- }
-
- return 0;
-}
-
-/*
- * i8042_enable_mux_ports enables 4 individual AUX ports after
- * the controller has been switched into Multiplexed mode
- */
-
-static int i8042_enable_mux_ports(void)
-{
- unsigned char param;
- int i;
-
- for (i = 0; i < I8042_NUM_MUX_PORTS; i++) {
- i8042_command(¶m, I8042_CMD_MUX_PFX + i);
- i8042_command(¶m, I8042_CMD_AUX_ENABLE);
- }
-
- return i8042_enable_aux_port();
-}
-
-/*
* i8042_set_mux_mode checks whether the controller has an active
* multiplexor and puts the chip into Multiplexed (1) or Legacy (0) mode.
*/
@@ -455,7 +510,8 @@ static int i8042_set_mux_mode(unsigned i
/*
* Internal loopback test - send three bytes, they should come back from the
- * mouse interface, the last should be version.
+ * mouse interface, the last should be version. Note that we negate mouseport
+ * command responses for the i8042_check_aux() routine.
*/
param = 0xf0;
@@ -474,67 +530,67 @@ static int i8042_set_mux_mode(unsigned i
return 0;
}
-/*
- * i8042_check_mux() checks whether the controller supports the PS/2 Active
- * Multiplexing specification by Synaptics, Phoenix, Insyde and
- * LCS/Telegraphics.
- */
-
-static int __devinit i8042_check_mux(void)
-{
- unsigned char mux_version;
-
- if (i8042_set_mux_mode(1, &mux_version))
- return -1;
/*
- * Workaround for interference with USB Legacy emulation
- * that causes a v10.12 MUX to be found.
+ * i8042_enable_mux_ports enables 4 individual AUX ports after
+ * the controller has been switched into Multiplexed mode
*/
- if (mux_version == 0xAC)
- return -1;
-
- printk(KERN_INFO "i8042.c: Detected active multiplexing controller, rev %d.%d.\n",
- (mux_version >> 4) & 0xf, mux_version & 0xf);
+static int i8042_enable_mux_ports(void)
+{
+ unsigned char param;
+ int i;
/*
* Disable all muxed ports by disabling AUX.
*/
+
i8042_ctr |= I8042_CTR_AUXDIS;
i8042_ctr &= ~I8042_CTR_AUXINT;
if (i8042_command(&i8042_ctr, I8042_CMD_CTL_WCTR)) {
printk(KERN_ERR "i8042.c: Failed to disable AUX port, can't use MUX.\n");
- return -EIO;
+ return -1;
}
- i8042_mux_present = 1;
+/*
+ * Enable all muxed ports.
+ */
+
+ for (i = 0; i < I8042_NUM_MUX_PORTS; i++) {
+ i8042_command(¶m, I8042_CMD_MUX_PFX + i);
+ i8042_command(¶m, I8042_CMD_AUX_ENABLE);
+ }
return 0;
}
+
/*
- * The following is used to test AUX IRQ delivery.
+ * i8042_check_mux() checks whether the controller supports the PS/2 Active
+ * Multiplexing specification by Synaptics, Phoenix, Insyde and
+ * LCS/Telegraphics.
*/
-static struct completion i8042_aux_irq_delivered __devinitdata;
-static int i8042_irq_being_tested __devinitdata;
-static irqreturn_t __devinit i8042_aux_test_irq(int irq, void *dev_id, struct pt_regs *regs)
+static int __devinit i8042_check_mux(void)
{
- unsigned long flags;
- unsigned char str, data;
+ unsigned char mux_version;
- spin_lock_irqsave(&i8042_lock, flags);
- str = i8042_read_status();
- if (str & I8042_STR_OBF) {
- data = i8042_read_data();
- if (i8042_irq_being_tested &&
- data == 0xa5 && (str & I8042_STR_AUXDATA))
- complete(&i8042_aux_irq_delivered);
- }
- spin_unlock_irqrestore(&i8042_lock, flags);
+ if (i8042_set_mux_mode(1, &mux_version))
+ return -1;
- return IRQ_HANDLED;
+ /* Workaround for interference with USB Legacy emulation */
+ /* that causes a v10.12 MUX to be found. */
+ if (mux_version == 0xAC)
+ return -1;
+
+ printk(KERN_INFO "i8042.c: Detected active multiplexing controller, rev %d.%d.\n",
+ (mux_version >> 4) & 0xf, mux_version & 0xf);
+
+ if (i8042_enable_mux_ports())
+ return -1;
+
+ i8042_mux_present = 1;
+ return 0;
}
@@ -545,10 +601,18 @@ static irqreturn_t __devinit i8042_aux_t
static int __devinit i8042_check_aux(void)
{
- int retval = -1;
- int irq_registered = 0;
- unsigned long flags;
unsigned char param;
+ static int i8042_check_aux_cookie;
+
+/*
+ * Check if AUX irq is available. If it isn't, then there is no point
+ * in trying to detect AUX presence.
+ */
+
+ if (request_irq(i8042_ports[I8042_AUX_PORT_NO].irq, i8042_interrupt,
+ IRQF_SHARED, "i8042", &i8042_check_aux_cookie))
+ return -1;
+ free_irq(i8042_ports[I8042_AUX_PORT_NO].irq, &i8042_check_aux_cookie);
/*
* Get rid of bytes in the queue.
@@ -573,9 +637,9 @@ static int __devinit i8042_check_aux(voi
* AUX ports, we test for this only when the LOOP command failed.
*/
- if (i8042_command(¶m, I8042_CMD_AUX_TEST) ||
- (param && param != 0xfa && param != 0xff))
- return -1;
+ if (i8042_command(¶m, I8042_CMD_AUX_TEST)
+ || (param && param != 0xfa && param != 0xff))
+ return -1;
}
/*
@@ -595,74 +659,54 @@ static int __devinit i8042_check_aux(voi
return -1;
/*
- * Test AUX IRQ delivery to make sure BIOS did not grab the IRQ and
- * used it for a PCI card or somethig else.
- */
-
- if (i8042_noloop) {
-/*
- * Without LOOP command we can't test AUX IRQ delivery. Assume the port
- * is working and hope we are right.
+ * Disable the interface.
*/
- retval = 0;
- goto out;
- }
-
- if (request_irq(I8042_AUX_IRQ, i8042_aux_test_irq, IRQF_SHARED,
- "i8042", i8042_platform_device))
- goto out;
-
- irq_registered = 1;
- if (i8042_enable_aux_port())
- goto out;
-
- spin_lock_irqsave(&i8042_lock, flags);
-
- init_completion(&i8042_aux_irq_delivered);
- i8042_irq_being_tested = 1;
-
- param = 0xa5;
- retval = __i8042_command(¶m, I8042_CMD_AUX_LOOP & 0xf0ff);
-
- spin_unlock_irqrestore(&i8042_lock, flags);
+ i8042_ctr |= I8042_CTR_AUXDIS;
+ i8042_ctr &= ~I8042_CTR_AUXINT;
- if (retval)
- goto out;
+ if (i8042_command(&i8042_ctr, I8042_CMD_CTL_WCTR))
+ return -1;
- if (wait_for_completion_timeout(&i8042_aux_irq_delivered,
- msecs_to_jiffies(250)) == 0)
- retval = -1;
+ return 0;
+}
- out:
/*
- * Disable the interface.
+ * i8042_port_register() marks the device as existing,
+ * registers it, and reports to the user.
*/
- i8042_ctr |= I8042_CTR_AUXDIS;
- i8042_ctr &= ~I8042_CTR_AUXINT;
+static int __devinit i8042_port_register(struct i8042_port *port)
+{
+ i8042_ctr &= ~port->disable;
- if (i8042_command(&i8042_ctr, I8042_CMD_CTL_WCTR))
- retval = -1;
+ if (i8042_command(&i8042_ctr, I8042_CMD_CTL_WCTR)) {
+ printk(KERN_WARNING "i8042.c: Can't write CTR while registering.\n");
+ kfree(port->serio);
+ port->serio = NULL;
+ i8042_ctr |= port->disable;
+ return -EIO;
+ }
- if (irq_registered)
- free_irq(I8042_AUX_IRQ, i8042_platform_device);
+ printk(KERN_INFO "serio: i8042 %s port at %#lx,%#lx irq %d\n",
+ port->name,
+ (unsigned long) I8042_DATA_REG,
+ (unsigned long) I8042_COMMAND_REG,
+ port->irq);
- return retval;
+ serio_register_port(port->serio);
+
+ return 0;
}
-static int i8042_controller_check(void)
-{
- if (i8042_flush() == I8042_BUFFER_SIZE) {
- printk(KERN_ERR "i8042.c: No controller found.\n");
- return -ENODEV;
- }
- return 0;
+static void i8042_timer_func(unsigned long data)
+{
+ i8042_interrupt(0, NULL, NULL);
}
-static int i8042_controller_selftest(void)
+static int i8042_ctl_test(void)
{
unsigned char param;
@@ -671,13 +715,13 @@ static int i8042_controller_selftest(voi
if (i8042_command(¶m, I8042_CMD_CTL_TEST)) {
printk(KERN_ERR "i8042.c: i8042 controller self test timeout.\n");
- return -ENODEV;
+ return -1;
}
if (param != I8042_RET_CTL_TEST) {
printk(KERN_ERR "i8042.c: i8042 controller selftest failed. (%#x != %#x)\n",
param, I8042_RET_CTL_TEST);
- return -EIO;
+ return -1;
}
return 0;
@@ -694,12 +738,25 @@ static int i8042_controller_init(void)
unsigned long flags;
/*
+ * Test the i8042. We need to know if it thinks it's working correctly
+ * before doing anything else.
+ */
+
+ if (i8042_flush() == I8042_BUFFER_SIZE) {
+ printk(KERN_ERR "i8042.c: No controller found.\n");
+ return -1;
+ }
+
+ if (i8042_ctl_test())
+ return -1;
+
+/*
* Save the CTR for restoral on unload / reboot.
*/
if (i8042_command(&i8042_ctr, I8042_CMD_CTL_RCTR)) {
printk(KERN_ERR "i8042.c: Can't read CTR while initializing i8042.\n");
- return -EIO;
+ return -1;
}
i8042_initial_ctr = i8042_ctr;
@@ -725,10 +782,8 @@ static int i8042_controller_init(void)
spin_unlock_irqrestore(&i8042_lock, flags);
/*
- ** If the chip is configured into nontranslated mode by the BIOS, don't
- ** bother enabling translating and be happy.
- * If we were in xlate mode before (that means we are resuming)
- * restore it.
+ * If the chip is configured into nontranslated mode by the BIOS, don't
+ * bother enabling translating and be happy.
*/
if (~i8042_ctr & I8042_CTR_XLATE)
@@ -750,7 +805,7 @@ static int i8042_controller_init(void)
if (i8042_command(&i8042_ctr, I8042_CMD_CTL_WCTR)) {
printk(KERN_ERR "i8042.c: Can't write CTR while initializing i8042.\n");
- return -EIO;
+ return -1;
}
return 0;
@@ -758,31 +813,30 @@ static int i8042_controller_init(void)
/*
- * Reset the controller and reset CRT to the original value set by BIOS.
+ * Reset the controller.
*/
-
static void i8042_controller_reset(void)
{
- i8042_flush();
-
/*
- * Disable MUX mode if present.
+ * Reset the controller if requested.
*/
- if (i8042_mux_present)
- i8042_set_mux_mode(0, NULL);
+ i8042_ctl_test();
/*
- * Reset the controller if requested.
+ * Disable MUX mode if present.
*/
- i8042_controller_selftest();
+ if (i8042_mux_present)
+ i8042_set_mux_mode(0, NULL);
/*
* Restore the original control register setting.
*/
- if (i8042_command(&i8042_initial_ctr, I8042_CMD_CTL_WCTR))
+ i8042_ctr = i8042_initial_ctr;
+
+ if (i8042_command(&i8042_ctr, I8042_CMD_CTL_WCTR))
printk(KERN_WARNING "i8042.c: Can't restore CTR.\n");
}
@@ -796,12 +850,14 @@ static void i8042_controller_cleanup(voi
{
int i;
+ i8042_flush();
+
/*
* Reset anything that is connected to the ports.
*/
for (i = 0; i < I8042_NUM_PORTS; i++)
- if (i8042_ports[i].serio)
+ if (i8042_ports[i].exists)
serio_cleanup(i8042_ports[i].serio);
i8042_controller_reset();
@@ -857,7 +913,8 @@ static long i8042_panic_blink(long count
static int i8042_suspend(struct platform_device *dev, pm_message_t state)
{
- i8042_controller_cleanup();
+ del_timer_sync(&i8042_timer);
+ i8042_controller_reset();
return 0;
}
@@ -869,39 +926,33 @@ static int i8042_suspend(struct platform
static int i8042_resume(struct platform_device *dev)
{
- int error;
-
- error = i8042_controller_check();
- if (error)
- return error;
-
- error = i8042_controller_selftest();
- if (error)
- return error;
+ int i;
-/*
- * Restore pre-resume CTR value and disable all ports
- */
+ if (i8042_ctl_test())
+ return -1;
- i8042_ctr |= I8042_CTR_AUXDIS | I8042_CTR_KBDDIS;
- i8042_ctr &= ~(I8042_CTR_AUXINT | I8042_CTR_KBDINT);
if (i8042_command(&i8042_ctr, I8042_CMD_CTL_WCTR)) {
- printk(KERN_ERR "i8042: Can't write CTR to resume\n");
- return -EIO;
+ printk(KERN_ERR "i8042: Can't write CTR\n");
+ return -1;
}
- if (i8042_mux_present) {
+ if (i8042_mux_present)
if (i8042_set_mux_mode(1, NULL) || i8042_enable_mux_ports())
- printk(KERN_WARNING
- "i8042: failed to resume active multiplexor, "
- "mouse won't work.\n");
- } else if (i8042_ports[I8042_AUX_PORT_NO].serio)
- i8042_enable_aux_port();
+ printk(KERN_WARNING "i8042: failed to resume active multiplexor, mouse won't work.\n");
- if (i8042_ports[I8042_KBD_PORT_NO].serio)
- i8042_enable_kbd_port();
+/*
+ * Activate all ports.
+ */
- i8042_interrupt(0, NULL, NULL);
+ for (i = 0; i < I8042_NUM_PORTS; i++)
+ i8042_activate_port(&i8042_ports[i]);
+
+/*
+ * Restart timer (for polling "stuck" data)
+ */
+ mod_timer(&i8042_timer, jiffies + I8042_POLL_PERIOD);
+
+ panic_blink = i8042_panic_blink;
return 0;
}
@@ -927,24 +978,24 @@ static int __devinit i8042_create_kbd_po
serio->id.type = i8042_direct ? SERIO_8042 : SERIO_8042_XL;
serio->write = i8042_dumbkbd ? NULL : i8042_kbd_write;
+ serio->open = i8042_open;
+ serio->close = i8042_close;
serio->start = i8042_start;
serio->stop = i8042_stop;
serio->port_data = port;
serio->dev.parent = &i8042_platform_device->dev;
- strlcpy(serio->name, "i8042 KBD port", sizeof(serio->name));
+ strlcpy(serio->name, "i8042 Kbd Port", sizeof(serio->name));
strlcpy(serio->phys, I8042_KBD_PHYS_DESC, sizeof(serio->phys));
port->serio = serio;
- port->irq = I8042_KBD_IRQ;
- return 0;
+ return i8042_port_register(port);
}
-static int __devinit i8042_create_aux_port(int idx)
+static int __devinit i8042_create_aux_port(void)
{
struct serio *serio;
- int port_no = idx < 0 ? I8042_AUX_PORT_NO : I8042_MUX_PORT_NO + idx;
- struct i8042_port *port = &i8042_ports[port_no];
+ struct i8042_port *port = &i8042_ports[I8042_AUX_PORT_NO];
serio = kzalloc(sizeof(struct serio), GFP_KERNEL);
if (!serio)
@@ -952,191 +1003,111 @@ static int __devinit i8042_create_aux_po
serio->id.type = SERIO_8042;
serio->write = i8042_aux_write;
+ serio->open = i8042_open;
+ serio->close = i8042_close;
serio->start = i8042_start;
serio->stop = i8042_stop;
serio->port_data = port;
serio->dev.parent = &i8042_platform_device->dev;
- if (idx < 0) {
- strlcpy(serio->name, "i8042 AUX port", sizeof(serio->name));
- strlcpy(serio->phys, I8042_AUX_PHYS_DESC, sizeof(serio->phys));
- } else {
- snprintf(serio->name, sizeof(serio->name), "i8042 AUX%d port", idx);
- snprintf(serio->phys, sizeof(serio->phys), I8042_MUX_PHYS_DESC, idx + 1);
- }
+ strlcpy(serio->name, "i8042 Aux Port", sizeof(serio->name));
+ strlcpy(serio->phys, I8042_AUX_PHYS_DESC, sizeof(serio->phys));
port->serio = serio;
- port->mux = idx;
- port->irq = I8042_AUX_IRQ;
- return 0;
-}
-
-static void __devinit i8042_free_kbd_port(void)
-{
- kfree(i8042_ports[I8042_KBD_PORT_NO].serio);
- i8042_ports[I8042_KBD_PORT_NO].serio = NULL;
+ return i8042_port_register(port);
}
-static void __devinit i8042_free_aux_ports(void)
+static int __devinit i8042_create_mux_port(int index)
{
- int i;
-
- for (i = I8042_AUX_PORT_NO; i < I8042_NUM_PORTS; i++) {
- kfree(i8042_ports[i].serio);
- i8042_ports[i].serio = NULL;
- }
-}
+ struct serio *serio;
+ struct i8042_port *port = &i8042_ports[I8042_MUX_PORT_NO + index];
-static void __devinit i8042_register_ports(void)
-{
- int i;
+ serio = kzalloc(sizeof(struct serio), GFP_KERNEL);
+ if (!serio)
+ return -ENOMEM;
- for (i = 0; i < I8042_NUM_PORTS; i++) {
- if (i8042_ports[i].serio) {
- printk(KERN_INFO "serio: %s at %#lx,%#lx irq %d\n",
- i8042_ports[i].serio->name,
- (unsigned long) I8042_DATA_REG,
- (unsigned long) I8042_COMMAND_REG,
- i8042_ports[i].irq);
- serio_register_port(i8042_ports[i].serio);
- }
- }
-}
+ serio->id.type = SERIO_8042;
+ serio->write = i8042_aux_write;
+ serio->open = i8042_open;
+ serio->close = i8042_close;
+ serio->start = i8042_start;
+ serio->stop = i8042_stop;
+ serio->port_data = port;
+ serio->dev.parent = &i8042_platform_device->dev;
+ snprintf(serio->name, sizeof(serio->name), "i8042 Aux-%d Port", index);
+ snprintf(serio->phys, sizeof(serio->phys), I8042_MUX_PHYS_DESC, index + 1);
-static void __devinit i8042_unregister_ports(void)
-{
- int i;
+ *port = i8042_ports[I8042_AUX_PORT_NO];
+ port->exists = 0;
+ snprintf(port->name, sizeof(port->name), "AUX%d", index);
+ port->mux = index;
+ port->serio = serio;
- for (i = 0; i < I8042_NUM_PORTS; i++) {
- if (i8042_ports[i].serio) {
- serio_unregister_port(i8042_ports[i].serio);
- i8042_ports[i].serio = NULL;
- }
- }
+ return i8042_port_register(port);
}
-static void i8042_free_irqs(void)
+static int __devinit i8042_probe(struct platform_device *dev)
{
- if (i8042_aux_irq_registered)
- free_irq(I8042_AUX_IRQ, i8042_platform_device);
- if (i8042_kbd_irq_registered)
- free_irq(I8042_KBD_IRQ, i8042_platform_device);
-
- i8042_aux_irq_registered = i8042_kbd_irq_registered = 0;
-}
+ int i, have_ports = 0;
+ int err;
-static int __devinit i8042_setup_aux(void)
-{
- int (*aux_enable)(void);
- int error;
- int i;
+ init_timer(&i8042_timer);
+ i8042_timer.function = i8042_timer_func;
- if (i8042_check_aux())
+ if (i8042_controller_init())
return -ENODEV;
- if (i8042_nomux || i8042_check_mux()) {
- error = i8042_create_aux_port(-1);
- if (error)
- goto err_free_ports;
- aux_enable = i8042_enable_aux_port;
- } else {
- for (i = 0; i < I8042_NUM_MUX_PORTS; i++) {
- error = i8042_create_aux_port(i);
- if (error)
- goto err_free_ports;
+ if (!i8042_noaux && !i8042_check_aux()) {
+ if (!i8042_nomux && !i8042_check_mux()) {
+ for (i = 0; i < I8042_NUM_MUX_PORTS; i++) {
+ err = i8042_create_mux_port(i);
+ if (err)
+ goto err_unregister_ports;
+ }
+ } else {
+ err = i8042_create_aux_port();
+ if (err)
+ goto err_unregister_ports;
}
- aux_enable = i8042_enable_mux_ports;
- }
-
- error = request_irq(I8042_AUX_IRQ, i8042_interrupt, IRQF_SHARED,
- "i8042", i8042_platform_device);
- if (error)
- goto err_free_ports;
-
- if (aux_enable())
- goto err_free_irq;
-
- i8042_aux_irq_registered = 1;
- return 0;
-
- err_free_irq:
- free_irq(I8042_AUX_IRQ, i8042_platform_device);
- err_free_ports:
- i8042_free_aux_ports();
- return error;
-}
-
-static int __devinit i8042_setup_kbd(void)
-{
- int error;
-
- error = i8042_create_kbd_port();
- if (error)
- return error;
-
- error = request_irq(I8042_KBD_IRQ, i8042_interrupt, IRQF_SHARED,
- "i8042", i8042_platform_device);
- if (error)
- goto err_free_port;
-
- error = i8042_enable_kbd_port();
- if (error)
- goto err_free_irq;
-
- i8042_kbd_irq_registered = 1;
- return 0;
-
- err_free_irq:
- free_irq(I8042_KBD_IRQ, i8042_platform_device);
- err_free_port:
- i8042_free_kbd_port();
- return error;
-}
-
-static int __devinit i8042_probe(struct platform_device *dev)
-{
- int error;
-
- error = i8042_controller_selftest();
- if (error)
- return error;
-
- error = i8042_controller_init();
- if (error)
- return error;
-
- if (!i8042_noaux) {
- error = i8042_setup_aux();
- if (error && error != -ENODEV && error != -EBUSY)
- goto out_fail;
+ have_ports = 1;
}
if (!i8042_nokbd) {
- error = i8042_setup_kbd();
- if (error)
- goto out_fail;
+ err = i8042_create_kbd_port();
+ if (err)
+ goto err_unregister_ports;
+ have_ports = 1;
}
-/*
- * Ok, everything is ready, let's register all serio ports
- */
- i8042_register_ports();
+ if (!have_ports) {
+ err = -ENODEV;
+ goto err_controller_cleanup;
+ }
+ mod_timer(&i8042_timer, jiffies + I8042_POLL_PERIOD);
return 0;
- out_fail:
- i8042_free_aux_ports(); /* in case KBD failed but AUX not */
- i8042_free_irqs();
- i8042_controller_reset();
+ err_unregister_ports:
+ for (i = 0; i < I8042_NUM_PORTS; i++)
+ if (i8042_ports[i].serio)
+ serio_unregister_port(i8042_ports[i].serio);
+ err_controller_cleanup:
+ i8042_controller_cleanup();
- return error;
+ return err;
}
static int __devexit i8042_remove(struct platform_device *dev)
{
- i8042_unregister_ports();
- i8042_free_irqs();
- i8042_controller_reset();
+ int i;
+
+ i8042_controller_cleanup();
+
+ for (i = 0; i < I8042_NUM_PORTS; i++)
+ if (i8042_ports[i].exists)
+ serio_unregister_port(i8042_ports[i].serio);
+
+ del_timer_sync(&i8042_timer);
return 0;
}
@@ -1163,9 +1134,8 @@ static int __init i8042_init(void)
if (err)
return err;
- err = i8042_controller_check();
- if (err)
- goto err_platform_exit;
+ i8042_ports[I8042_AUX_PORT_NO].irq = I8042_AUX_IRQ;
+ i8042_ports[I8042_KBD_PORT_NO].irq = I8042_KBD_IRQ;
err = platform_driver_register(&i8042_driver);
if (err)
@@ -1181,8 +1151,6 @@ static int __init i8042_init(void)
if (err)
goto err_free_device;
- panic_blink = i8042_panic_blink;
-
return 0;
err_free_device:
@@ -1199,6 +1167,7 @@ static void __exit i8042_exit(void)
{
platform_device_unregister(i8042_platform_device);
platform_driver_unregister(&i8042_driver);
+
i8042_platform_exit();
panic_blink = NULL;
diff -puN drivers/input/serio/i8042.h~revert-i8042-get-rid-of-polling-timer-v4 drivers/input/serio/i8042.h
--- a/drivers/input/serio/i8042.h~revert-i8042-get-rid-of-polling-timer-v4
+++ a/drivers/input/serio/i8042.h
@@ -37,6 +37,15 @@
#define I8042_CTL_TIMEOUT 10000
/*
+ * When the device isn't opened and it's interrupts aren't used, we poll it at
+ * regular intervals to see if any characters arrived. If yes, we can start
+ * probing for any mouse / keyboard connected. This is the period of the
+ * polling.
+ */
+
+#define I8042_POLL_PERIOD HZ/20
+
+/*
* Status register bits.
*/
_
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-13 8:24 2.6.18-rc4-mm1 Andrew Morton
` (3 preceding siblings ...)
2006-08-13 17:38 ` 2.6.18-rc4-mm1 Laurent Riffard
@ 2006-08-13 20:39 ` Andrew Morton
2006-08-14 7:58 ` 2.6.18-rc4-mm1 David Howells
` (3 more replies)
2006-08-14 14:02 ` 2.6.18-rc4-mm1 Michal Piotrowski
2006-08-14 17:54 ` 2.6.18-rc4-mm1 Rafael J. Wysocki
6 siblings, 4 replies; 80+ messages in thread
From: Andrew Morton @ 2006-08-13 20:39 UTC (permalink / raw)
To: linux-kernel; +Cc: Trond Myklebust, David Howells, Ian Kent
On Sun, 13 Aug 2006 01:24:54 -0700
Andrew Morton <akpm@osdl.org> wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm1/
This kernel breaks autofs /net handling. Bisection shows that the bug is
introduced by git-nfs.patch.
sony:/home/akpm> showmount -e bix
Export list for bix:
/ *
/usr/src *
/mnt/export *
sony:/home/akpm> ls -l /net/bix
total 1025280
drwxr-xr-x 3 root root 4096 Apr 10 03:19 bin
drwxr-xr-x 2 root root 4096 Mar 10 2004 boot
drwxr-xr-x 23 root root 118784 Jun 26 00:48 dev
drwxr-xr-x 98 root root 8192 Aug 13 04:03 etc
drwxr-xr-x 7 root root 4096 Apr 1 2004 home
drwxr-xr-x 2 root root 4096 Oct 7 2003 initrd
drwxr-xr-x 10 root root 4096 Apr 10 03:19 lib
drwx------ 2 root root 16384 Mar 10 2004 lost+found
drwxr-xr-x 2 root root 4096 Sep 8 2003 misc
?--------- ? ? ? ? ? /net/bix/mnt
?--------- ? ? ? ? ? /net/bix/usr
drwxrwxrwx 8 root root 4096 Jul 10 02:50 opt
drwxr-xr-x 2 root root 4096 Mar 10 2004 proc
drwxr-xr-x 20 root root 4096 Aug 7 16:39 root
drwxr-xr-x 2 root root 57344 Apr 24 2004 rpms
drwxr-xr-x 2 root root 8192 Apr 10 03:19 sbin
-rw-r--r-- 1 root root 1048576000 Mar 12 2004 swap
drwxr-xr-x 2 root root 4096 Mar 12 2004 sys
drwxr-xr-x 3 root root 4096 Mar 10 2004 tftpboot
drwxrwxrwt 14 root root 16384 Aug 13 13:29 tmp
drwxr-xr-x 27 root root 4096 Mar 10 2004 var
sony:/home/akpm> ls -l /net/bix/usr
ls: /net/bix/usr: No such file or directory
sony:/home/akpm> mount
/dev/sda6 on / type ext3 (rw,noatime)
/dev/proc on /proc type proc (rw)
/dev/sys on /sys type sysfs (rw)
/dev/devpts on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/shm on /dev/shm type tmpfs (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
automount(pid1757) on /net type autofs (rw,fd=5,pgrp=1757,minproto=2,maxproto=4)
bix:/ on /net/bix type nfs (rw,nosuid,nodev,hard,intr,tcp,addr=192.168.2.33)
distro is fairly-up-to-date FC5.
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-13 19:11 ` 2.6.18-rc4-mm1 Andrew Morton
@ 2006-08-13 22:44 ` Ben Buxton
2006-08-13 22:58 ` 2.6.18-rc4-mm1 Michal Piotrowski
` (2 more replies)
2022-08-14 8:42 ` 2.6.18-rc4-mm1 Maciej Rutecki
1 sibling, 3 replies; 80+ messages in thread
From: Ben Buxton @ 2006-08-13 22:44 UTC (permalink / raw)
To: Andrew Morton; +Cc: Maciej Rutecki, linux-kernel, Dmitry Torokhov
Andrew Morton <akpm@osdl.org> uttered the following thing:
> On Sun, 13 Aug 2006 13:45:35 +0200
> Maciej Rutecki <maciej.rutecki@gmail.com> wrote:
>
> > Andrew Morton napisa??(a):
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm1/
> >
> > I have problem with my keyboard. I have no error in dmesg and syslog,
> > but it doesn't work. I read google and try "i8042.nomux", but it didn't
> > help.
> >
> > I enclose dmesg with "i8042.debug=1" option and my config.
> >
> > Maybe I forgot something in config?
> >
>
>
> Could be i8042-get-rid-of-polling-timer-v4.patch. Please try the below
> reversion patch, on top of rc4-mm1, thanks.
Acking the same issue. Applied the revert patch and my keyboard now
works. Also, it turns out that my keyboard is now the only thing that
failed to resume from S3 on my HP Nc6400, but adding "irqpoll" has fixed
that for now.
Also, to two other things I spotted with cpufreq. Running
speedstep-centrino on a Core Duo T2400 (1.83GHz) I see the
"cpuinfo_max_freq" is 1833000, but "scaling_max_freq" is fixed at 1333000,
regardless of the governor, and I cannot change it.
Also, whenever I echo anything to "scaling_governor", I get the
following kernel message:
[ 734.156000] BUG: warning at kernel/cpu.c:38/lock_cpu_hotplug()
[ 734.156000] [<c013c3ec>] lock_cpu_hotplug+0x7c/0x90
[ 734.156000] [<c01327f4>] __create_workqueue+0x44/0x140
[ 734.156000] [<c02dcf7b>] mutex_lock+0xb/0x20
[ 734.156000] [<e01f2665>] cpufreq_governor_dbs+0x2b5/0x310
[cpufreq_ondemand]
[ 734.156000] [<c012f6a5>] notifier_call_chain+0x25/0x40
[ 734.156000] [<c0274b06>] __cpufreq_governor+0x46/0xe0
[ 734.156000] [<c0274c84>] __cpufreq_set_policy+0xe4/0x130
[ 734.156000] [<c0275ae4>] store_scaling_governor+0xd4/0x210
[ 734.160000] [<c02756a0>] handle_update+0x0/0x10
[ 734.160000] [<c01e2000>] kobject_get+0x0/0x20
[ 734.160000] [<c0275a10>] store_scaling_governor+0x0/0x210
[ 734.160000] [<c027521d>] store+0x3d/0x60
[ 734.160000] [<c01a2e0c>] sysfs_write_file+0x9c/0xf0
[ 734.160000] [<c016a8c6>] vfs_write+0xa6/0x160
[ 734.160000] [<c01a2d70>] sysfs_write_file+0x0/0xf0
[ 734.160000] [<c016b001>] sys_write+0x41/0x70
[ 734.160000] [<c0103115>] sysenter_past_esp+0x56/0x79
It seems that scaling still works, but this message is a bit unnerving.
BB
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-13 22:44 ` 2.6.18-rc4-mm1 Ben Buxton
@ 2006-08-13 22:58 ` Michal Piotrowski
2006-08-13 23:25 ` 2.6.18-rc4-mm1 Dave Jones
2006-08-14 0:00 ` 2.6.18-rc4-mm1 Dmitry Torokhov
2 siblings, 0 replies; 80+ messages in thread
From: Michal Piotrowski @ 2006-08-13 22:58 UTC (permalink / raw)
To: Ben Buxton; +Cc: Andrew Morton, Maciej Rutecki, linux-kernel, Dmitry Torokhov
On 14/08/06, Ben Buxton <kernel@bb.cactii.net> wrote:
> Andrew Morton <akpm@osdl.org> uttered the following thing:
> > On Sun, 13 Aug 2006 13:45:35 +0200
> > Maciej Rutecki <maciej.rutecki@gmail.com> wrote:
> >
> > > Andrew Morton napisa??(a):
> > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm1/
> > >
> > > I have problem with my keyboard. I have no error in dmesg and syslog,
> > > but it doesn't work. I read google and try "i8042.nomux", but it didn't
> > > help.
> > >
> > > I enclose dmesg with "i8042.debug=1" option and my config.
> > >
> > > Maybe I forgot something in config?
> > >
> >
> >
> > Could be i8042-get-rid-of-polling-timer-v4.patch. Please try the below
> > reversion patch, on top of rc4-mm1, thanks.
>
> Acking the same issue. Applied the revert patch and my keyboard now
> works. Also, it turns out that my keyboard is now the only thing that
> failed to resume from S3 on my HP Nc6400, but adding "irqpoll" has fixed
> that for now.
>
> Also, to two other things I spotted with cpufreq. Running
> speedstep-centrino on a Core Duo T2400 (1.83GHz) I see the
> "cpuinfo_max_freq" is 1833000, but "scaling_max_freq" is fixed at 1333000,
> regardless of the governor, and I cannot change it.
>
> Also, whenever I echo anything to "scaling_governor", I get the
> following kernel message:
>
> [ 734.156000] BUG: warning at kernel/cpu.c:38/lock_cpu_hotplug()
> [ 734.156000] [<c013c3ec>] lock_cpu_hotplug+0x7c/0x90
> [ 734.156000] [<c01327f4>] __create_workqueue+0x44/0x140
> [ 734.156000] [<c02dcf7b>] mutex_lock+0xb/0x20
> [ 734.156000] [<e01f2665>] cpufreq_governor_dbs+0x2b5/0x310
> [cpufreq_ondemand]
> [ 734.156000] [<c012f6a5>] notifier_call_chain+0x25/0x40
> [ 734.156000] [<c0274b06>] __cpufreq_governor+0x46/0xe0
> [ 734.156000] [<c0274c84>] __cpufreq_set_policy+0xe4/0x130
> [ 734.156000] [<c0275ae4>] store_scaling_governor+0xd4/0x210
> [ 734.160000] [<c02756a0>] handle_update+0x0/0x10
> [ 734.160000] [<c01e2000>] kobject_get+0x0/0x20
> [ 734.160000] [<c0275a10>] store_scaling_governor+0x0/0x210
> [ 734.160000] [<c027521d>] store+0x3d/0x60
> [ 734.160000] [<c01a2e0c>] sysfs_write_file+0x9c/0xf0
> [ 734.160000] [<c016a8c6>] vfs_write+0xa6/0x160
> [ 734.160000] [<c01a2d70>] sysfs_write_file+0x0/0xf0
> [ 734.160000] [<c016b001>] sys_write+0x41/0x70
> [ 734.160000] [<c0103115>] sysenter_past_esp+0x56/0x79
>
> It seems that scaling still works, but this message is a bit unnerving.
It's known bug.
>
> BB
>
Regards,
Michal
--
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-13 22:44 ` 2.6.18-rc4-mm1 Ben Buxton
2006-08-13 22:58 ` 2.6.18-rc4-mm1 Michal Piotrowski
@ 2006-08-13 23:25 ` Dave Jones
2006-08-14 11:55 ` 2.6.18-rc4-mm1 Ben Buxton
2006-08-14 0:00 ` 2.6.18-rc4-mm1 Dmitry Torokhov
2 siblings, 1 reply; 80+ messages in thread
From: Dave Jones @ 2006-08-13 23:25 UTC (permalink / raw)
To: Ben Buxton; +Cc: Andrew Morton, Maciej Rutecki, linux-kernel, Dmitry Torokhov
On Mon, Aug 14, 2006 at 12:44:13AM +0200, Ben Buxton wrote:
> Also, whenever I echo anything to "scaling_governor", I get the
> following kernel message:
>
> [ 734.156000] BUG: warning at kernel/cpu.c:38/lock_cpu_hotplug()
> [ 734.156000] [<c013c3ec>] lock_cpu_hotplug+0x7c/0x90
> [ 734.156000] [<c01327f4>] __create_workqueue+0x44/0x140
> [ 734.156000] [<c02dcf7b>] mutex_lock+0xb/0x20
> [ 734.156000] [<e01f2665>] cpufreq_governor_dbs+0x2b5/0x310 [cpufreq_ondemand]
This makes no sense at all, because in -mm __create_workqueue doesn't
call lock_cpu_hotplug().
Are you sure this was from a tree with -mm1 applied ?
Dave
--
http://www.codemonkey.org.uk
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-13 11:45 ` 2.6.18-rc4-mm1 Maciej Rutecki
2006-08-13 19:11 ` 2.6.18-rc4-mm1 Andrew Morton
@ 2006-08-13 23:58 ` Dmitry Torokhov
[not found] ` <d120d5000608140643tddd9ce4o986560740ef5dbd7@mail.gmail.com>
1 sibling, 1 reply; 80+ messages in thread
From: Dmitry Torokhov @ 2006-08-13 23:58 UTC (permalink / raw)
To: Maciej Rutecki; +Cc: linux-kernel
On Sunday 13 August 2006 07:45, Maciej Rutecki wrote:
> Andrew Morton napisał(a):
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm1/
>
> I have problem with my keyboard. I have no error in dmesg and syslog,
> but it doesn't work. I read google and try "i8042.nomux", but it didn't
> help.
>
> I enclose dmesg with "i8042.debug=1" option and my config.
>
> Maybe I forgot something in config?
>
You have keyboard configured as a module in your .config but I do not
see it trying to attach to the keyboard serio port. Make sure the module
is loaded.
--
Dmitry
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-13 22:44 ` 2.6.18-rc4-mm1 Ben Buxton
2006-08-13 22:58 ` 2.6.18-rc4-mm1 Michal Piotrowski
2006-08-13 23:25 ` 2.6.18-rc4-mm1 Dave Jones
@ 2006-08-14 0:00 ` Dmitry Torokhov
2006-08-14 12:03 ` 2.6.18-rc4-mm1 Ben B
2 siblings, 1 reply; 80+ messages in thread
From: Dmitry Torokhov @ 2006-08-14 0:00 UTC (permalink / raw)
To: Ben Buxton; +Cc: Andrew Morton, Maciej Rutecki, linux-kernel
On Sunday 13 August 2006 18:44, Ben Buxton wrote:
> > Could be i8042-get-rid-of-polling-timer-v4.patch. Please try the below
> > reversion patch, on top of rc4-mm1, thanks.
>
> Acking the same issue. Applied the revert patch and my keyboard now
> works. Also, it turns out that my keyboard is now the only thing that
> failed to resume from S3 on my HP Nc6400, but adding "irqpoll" has fixed
> that for now.
>
Can I please have dmesg of booting unpatched -rc4-mm1 with i8042.debug=1?
--
Dmitry
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-13 12:24 ` 2.6.18-rc4-mm1 Michal Piotrowski
@ 2006-08-14 6:36 ` Reuben Farrelly
2006-08-14 9:06 ` 2.6.18-rc4-mm1 Rafael J. Wysocki
0 siblings, 1 reply; 80+ messages in thread
From: Reuben Farrelly @ 2006-08-14 6:36 UTC (permalink / raw)
To: Michal Piotrowski
Cc: Ingo Molnar, Arjan van de Ven, linux-kernel, Andrew Morton
On 14/08/2006 12:24 a.m., Michal Piotrowski wrote:
> On 13/08/06, Andrew Morton <akpm@osdl.org> wrote:
>>
>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm1/
>>
>>
>> - Warning: all the Serial ATA Kconfig options have been renamed. If you
>> blindly run `make oldconfig' you won't have any disks.
>>
>
> MAX_STACK_TRACE_ENTRIES too low!
>
> What does it mean?
>
> BUG: MAX_STACK_TRACE_ENTRIES too low!
> turning off the locking correctness validator.
> [<c0103e41>] dump_trace+0x70/0x176
> [<c0103fc1>] show_trace_log_lvl+0x12/0x22
> [<c0103fde>] show_trace+0xd/0xf
> [<c01040b0>] dump_stack+0x17/0x19
> [<c0138f30>] save_trace+0xce/0xd7
> [<c0139370>] add_lock_to_list+0x22/0x39
> [<c0139b3c>] check_prev_add+0x139/0x1b4
> [<c0139c04>] check_prevs_add+0x4d/0xaf
> [<c013b646>] __lock_acquire+0x8a1/0x93c
> [<c013bd4c>] lock_acquire+0x6f/0x8f
> [<c03033e8>] _spin_lock_irq+0x29/0x35
> [<c01ed022>] __make_request+0x68/0x413
> [<c01ed6a7>] generic_make_request+0x273/0x2a4
> [<c01ed802>] submit_bio+0x12a/0x132
> [<c017b6f6>] submit_bh+0x10e/0x12e
> [<c0179fd3>] __block_write_full_page+0x231/0x326
> [<c017b567>] block_write_full_page+0xd7/0xdf
> [<c017e17a>] blkdev_writepage+0xf/0x11
> [<c0199d92>] mpage_writepages+0x1b6/0x324
> [<c017f3ee>] generic_writepages+0xa/0xc
> [<c015b6b5>] do_writepages+0x23/0x36
> [<c019871c>] __sync_single_inode+0x7b/0x199
> [<c01989ac>] __writeback_single_inode+0x172/0x17a
> [<c0198b50>] generic_sync_sb_inodes+0x19c/0x242
> [<c0198c13>] sync_sb_inodes+0x1d/0x20
> [<c0198c8e>] writeback_inodes+0x78/0xae
> [<c015b52b>] wb_kupdate+0x7c/0xdd
> [<c015bf14>] __pdflush+0xcc/0x163
> [<c015bfdd>] pdflush+0x32/0x34
> [<c01347a9>] kthread+0x82/0xaa
> [<c0303dfd>] kernel_thread_helper+0x5/0xb
> [<c0103fc1>] show_trace_log_lvl+0x12/0x22
> [<c0103fde>] show_trace+0xd/0xf
> [<c01040b0>] dump_stack+0x17/0x19
> [<c0138f30>] save_trace+0xce/0xd7
> [<c0139370>] add_lock_to_list+0x22/0x39
> [<c0139b3c>] check_prev_add+0x139/0x1b4
> [<c0139c04>] check_prevs_add+0x4d/0xaf
> [<c013b646>] __lock_acquire+0x8a1/0x93c
> [<c013bd4c>] lock_acquire+0x6f/0x8f
> [<c03033e8>] _spin_lock_irq+0x29/0x35
> [<c01ed022>] __make_request+0x68/0x413
> [<c01ed6a7>] generic_make_request+0x273/0x2a4
> [<c01ed802>] submit_bio+0x12a/0x132
> [<c017b6f6>] submit_bh+0x10e/0x12e
> [<c0179fd3>] __block_write_full_page+0x231/0x326
> [<c017b567>] block_write_full_page+0xd7/0xdf
> [<c017e17a>] blkdev_writepage+0xf/0x11
> [<c0199d92>] mpage_writepages+0x1b6/0x324
> [<c017f3ee>] generic_writepages+0xa/0xc
> [<c015b6b5>] do_writepages+0x23/0x36
> [<c019871c>] __sync_single_inode+0x7b/0x199
> [<c01989ac>] __writeback_single_inode+0x172/0x17a
> [<c0198b50>] generic_sync_sb_inodes+0x19c/0x242
> [<c0198c13>] sync_sb_inodes+0x1d/0x20
> [<c0198c8e>] writeback_inodes+0x78/0xae
> [<c015b52b>] wb_kupdate+0x7c/0xdd
> [<c015bf14>] __pdflush+0xcc/0x163
> [<c015bfdd>] pdflush+0x32/0x34
> [<c01347a9>] kthread+0x82/0xaa
> [<c0303dfd>] kernel_thread_helper+0x5/0xb
> =======================
>
> config & dmesg
> http://www.stardust.webpages.pl/files/mm/2.6.18-rc4-mm1/frontline/
>
> Regards,
> Michal
Seeing this message here as well, which I guess is the same thing even though
the trace is a bit different.
IPv6 over IPv4 tunneling driver
eth0: no IPv6 routers present
BUG: MAX_STACK_TRACE_ENTRIES too low!
turning off the locking correctness validator.
Call Trace:
[<ffffffff8026cdfe>] dump_trace+0xbe/0x3a0
[<ffffffff8026d11c>] show_trace+0x3c/0x55
[<ffffffff8026d14a>] dump_stack+0x15/0x1b
[<ffffffff8029bec6>] save_trace+0xd6/0xe3
[<ffffffff8029bf55>] add_lock_to_list+0x82/0xab
[<ffffffff8029e720>] __lock_acquire+0xad0/0xc78
[<ffffffff8029e917>] lock_acquire+0x4f/0x78
[<ffffffff80268698>] _spin_lock+0x25/0x34
[<ffffffff803ff699>] ata_scsi_queuecmd+0x39/0x16a
[<ffffffff803e7fb7>] scsi_dispatch_cmd+0x1f7/0x250
[<ffffffff803ecbd6>] scsi_request_fn+0x296/0x380
[<ffffffff8035f7b2>] __generic_unplug_device+0x28/0x2f
[<ffffffff8025ea4b>] generic_unplug_device+0x25/0x38
[<ffffffff80261a4b>] blk_backing_dev_unplug+0x16/0x1b
[<ffffffff80215aa9>] sync_buffer+0x39/0x42
[<ffffffff80266951>] __wait_on_bit+0x45/0x79
[<ffffffff802669f4>] out_of_line_wait_on_bit+0x6f/0x8b
[<ffffffff8024c49a>] __wait_on_buffer+0x20/0x22
[<ffffffff8023c790>] sync_dirty_buffer+0x90/0xd0
[<ffffffff803329e9>] journal_update_superblock+0x89/0xd6
[<ffffffff80330e01>] cleanup_journal_tail+0x121/0x132
[<ffffffff80330eec>] log_do_checkpoint+0x1c/0x47b
[<ffffffff803314ae>] __log_wait_for_space+0x9a/0xc0
[<ffffffff8032d84b>] start_this_handle+0x1fb/0x46a
[<ffffffff8032db95>] journal_start+0xdb/0x116
[<ffffffff80325a4a>] ext3_journal_start_sb+0x4a/0x4c
[<ffffffff8032067e>] ext3_dirty_inode+0x31/0x93
[<ffffffff802140fe>] __mark_inode_dirty+0x2e/0x19f
[<ffffffff8020bd2c>] touch_atime+0x9c/0xa3
[<ffffffff80222464>] generic_file_mmap+0x39/0x4f
[<ffffffff8020e5e5>] do_mmap_pgoff+0x4b5/0x7b5
[<ffffffff802241a1>] sys_mmap+0x94/0xcf
[<ffffffff802625fe>] system_call+0x7e/0x83
[<00002b03387e4e0a>]
[<ffffffff8029bec6>] save_trace+0xd6/0xe3
[<ffffffff8029bf55>] add_lock_to_list+0x82/0xab
[<ffffffff8029e720>] __lock_acquire+0xad0/0xc78
[<ffffffff803e7841>] scsi_done+0x0/0x24
[<ffffffff8029e917>] lock_acquire+0x4f/0x78
[<ffffffff803ff699>] ata_scsi_queuecmd+0x39/0x16a
[<ffffffff80268698>] _spin_lock+0x25/0x34
[<ffffffff803ff699>] ata_scsi_queuecmd+0x39/0x16a
[<ffffffff803e7fb7>] scsi_dispatch_cmd+0x1f7/0x250
[<ffffffff803ecbd6>] scsi_request_fn+0x296/0x380
[<ffffffff8035f7b2>] __generic_unplug_device+0x28/0x2f
[<ffffffff8025ea4b>] generic_unplug_device+0x25/0x38
[<ffffffff80261a4b>] blk_backing_dev_unplug+0x16/0x1b
[<ffffffff80215aa9>] sync_buffer+0x39/0x42
[<ffffffff80266951>] __wait_on_bit+0x45/0x79
[<ffffffff80215a70>] sync_buffer+0x0/0x42
[<ffffffff80215a70>] sync_buffer+0x0/0x42
[<ffffffff802669f4>] out_of_line_wait_on_bit+0x6f/0x8b
[<ffffffff80298270>] wake_bit_function+0x0/0x31
[<ffffffff8024c49a>] __wait_on_buffer+0x20/0x22
[<ffffffff8023c790>] sync_dirty_buffer+0x90/0xd0
[<ffffffff803329e9>] journal_update_superblock+0x89/0xd6
[<ffffffff80330e01>] cleanup_journal_tail+0x121/0x132
[<ffffffff80330eec>] log_do_checkpoint+0x1c/0x47b
[<ffffffff8029dc25>] check_noncircular+0x95/0xc0
[<ffffffff8029dc25>] check_noncircular+0x95/0xc0
[<ffffffff8029dc25>] check_noncircular+0x95/0xc0
[<ffffffff8029cf5d>] find_usage_backwards+0x7a/0xa1
[<ffffffff8029d91c>] check_usage+0x35/0x2a9
[<ffffffff8029e67d>] __lock_acquire+0xa2d/0xc78
[<ffffffff803314ae>] __log_wait_for_space+0x9a/0xc0
[<ffffffff8032d84b>] start_this_handle+0x1fb/0x46a
[<ffffffff8020a649>] kmem_cache_alloc+0xb9/0xd0
[<ffffffff8032db95>] journal_start+0xdb/0x116
[<ffffffff80325a4a>] ext3_journal_start_sb+0x4a/0x4c
[<ffffffff8032067e>] ext3_dirty_inode+0x31/0x93
[<ffffffff802140fe>] __mark_inode_dirty+0x2e/0x19f
[<ffffffff80222421>] dbg_redzone1+0x1d/0x27
[<ffffffff8020bd2c>] touch_atime+0x9c/0xa3
[<ffffffff80222464>] generic_file_mmap+0x39/0x4f
[<ffffffff8020e5e5>] do_mmap_pgoff+0x4b5/0x7b5
[<ffffffff8026899f>] _spin_unlock_irq+0x2b/0x33
[<ffffffff802241a1>] sys_mmap+0x94/0xcf
[<ffffffff802625fe>] system_call+0x7e/0x83
Can someone take a look at this too, please?
Reuben
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-13 20:39 ` 2.6.18-rc4-mm1 Andrew Morton
@ 2006-08-14 7:58 ` David Howells
2006-08-14 8:06 ` 2.6.18-rc4-mm1 Ian Kent
` (2 subsequent siblings)
3 siblings, 0 replies; 80+ messages in thread
From: David Howells @ 2006-08-14 7:58 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, Trond Myklebust, David Howells, Ian Kent
Andrew Morton <akpm@osdl.org> wrote:
> This kernel breaks autofs /net handling. Bisection shows that the bug is
> introduced by git-nfs.patch.
What's your autofs setup? What gets mounted on /net/bix? Is it "bix:/"?
David
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-13 20:39 ` 2.6.18-rc4-mm1 Andrew Morton
2006-08-14 7:58 ` 2.6.18-rc4-mm1 David Howells
@ 2006-08-14 8:06 ` Ian Kent
2006-08-14 9:32 ` 2.6.18-rc4-mm1 David Howells
2006-08-14 18:32 ` 2.6.18-rc4-mm1 David Howells
2006-08-14 22:49 ` 2.6.18-rc4-mm1 Trond Myklebust
3 siblings, 1 reply; 80+ messages in thread
From: Ian Kent @ 2006-08-14 8:06 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, Trond Myklebust, David Howells
Hi Andrew,
I'm having trouble duplicating this.
Is there any more info. about this I'm missing?
[raven@raven ~]$ /usr/sbin/showmount -e budgie
Export list for budgie:
/ *
/usr/src *
[raven@raven ~]$
[raven@raven ~]$ cd /net/budgie
[raven@raven budgie]$ ls -l
total 116
drwxrwxrwx 10 root root 4096 Jul 15 13:23 autofs
drwxr-xr-x 2 root root 4096 Oct 31 2004 bin
drwxr-xr-x 2 root root 4096 Jan 5 2005 boot
drwxr-xr-x 2 root root 4096 Oct 19 2003 cdrom
drwxr-xr-x 11 root root 24576 Aug 14 08:48 dev
drwxr-xr-x 65 root root 8192 Aug 14 08:49 etc
drwxr-xr-x 2 root root 4096 Oct 19 2003 floppy
drwxrwsr-x 5 root ftp 4096 Apr 3 19:42 home
drwxr-xr-x 2 root root 4096 Oct 19 2003 initrd
lrwxrwxrwx 1 root root 28 Oct 31 2004 initrd.img ->
boot/initrd.img-2.4.27-1-386
lrwxrwxrwx 1 root root 29 Oct 19 2003 initrd.img.old
-> /boot/initrd.img-2.4.18-1-386
drwxr-xr-x 7 root root 4096 Oct 30 2005 lib
drwx------ 2 root root 16384 Oct 19 2003 lost+found
drwxr-xr-x 5 root root 4096 Dec 19 2004 mnt
drwxr-xr-x 2 root root 4096 Oct 19 2003 opt
drwxr-xr-x 2 root root 4096 Feb 8 2002 proc
drwxr-xr-x 7 root root 4096 Oct 30 2005 root
drwxr-xr-x 2 root root 4096 Oct 30 2005 sbin
drwxr-xr-x 2 root root 4096 Oct 14 2004 sys
drwxrwxrwt 4 root root 4096 Aug 14 12:49 tmp
drwxr-xr-x 12 root root 4096 Oct 31 2004 usr
drwxr-xr-x 15 root root 4096 Oct 31 2004 var
lrwxrwxrwx 1 root root 25 Oct 31 2004 vmlinuz ->
boot/vmlinuz-2.4.27-1-386
lrwxrwxrwx 1 root root 25 Oct 19 2003 vmlinuz.old ->
boot/vmlinuz-2.4.18-1-386
[raven@raven budgie]$
[raven@raven budgie]$ cd usr/src
[raven@raven src]$ ls -l
total 49660
drwxr-xr-x 5 root root 4096 Dec 25 2004 kernel-headers-2.4.27-1
drwxr-xr-x 3 root root 4096 Dec 26 2004
kernel-headers-2.4.27-1-386
-rw-r--r-- 1 root root 4685364 Dec 25 2004
kernel-headers-2.4.27-1-386_1_i386.deb
-rw-r--r-- 1 root root 11270432 Dec 26 2004
kernel-image-2.4.27-1-386_1_i386.deb
drwxr-xr-x 3 root root 4096 Dec 19 2004 kernel-patches
drwxr-xr-x 16 root root 4096 Dec 26 2004 kernel-source-2.4.27
-rw-r--r-- 1 root root 30980829 Dec 1 2004
kernel-source-2.4.27.tar.bz2
drwx------ 2 root root 16384 Dec 19 2004 lost+found
-rw-r--r-- 1 root root 145984 Dec 26 2004
madwifi-module-2.4.27-1-386_20041216-1-onoe+1_i386.deb
-rw-r--r-- 1 root root 1692484 Dec 26 2004
madwifi-source_20041216_all.deb
-rw-r--r-- 1 root root 1680344 Dec 16 2004 madwifi.tar.gz
-rw-r--r-- 1 root root 14828 Dec 26 2004
madwifi-tools_20041216_i386.deb
drwxr-xr-x 4 root root 4096 Dec 16 2004 modules
-rw-r--r-- 1 root root 55752 Dec 26 2004
ndiswrapper-modules-2.4.27-1-386_0.11-1+1_i386.deb
-rw-r--r-- 1 root root 84130 Dec 26 2004
ndiswrapper-source_0.11-1_i386.deb
-rw-r--r-- 1 root root 76469 Nov 8 2004 ndiswrapper-source.tar.bz2
-rw-r--r-- 1 root root 20086 Dec 26 2004
ndiswrapper-utils_0.11-1_i386.deb
On Sun, 2006-08-13 at 13:39 -0700, Andrew Morton wrote:
> On Sun, 13 Aug 2006 01:24:54 -0700
> Andrew Morton <akpm@osdl.org> wrote:
>
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm1/
>
> This kernel breaks autofs /net handling. Bisection shows that the bug is
> introduced by git-nfs.patch.
>
>
> sony:/home/akpm> showmount -e bix
> Export list for bix:
> / *
> /usr/src *
> /mnt/export *
> sony:/home/akpm> ls -l /net/bix
> total 1025280
> drwxr-xr-x 3 root root 4096 Apr 10 03:19 bin
> drwxr-xr-x 2 root root 4096 Mar 10 2004 boot
> drwxr-xr-x 23 root root 118784 Jun 26 00:48 dev
> drwxr-xr-x 98 root root 8192 Aug 13 04:03 etc
> drwxr-xr-x 7 root root 4096 Apr 1 2004 home
> drwxr-xr-x 2 root root 4096 Oct 7 2003 initrd
> drwxr-xr-x 10 root root 4096 Apr 10 03:19 lib
> drwx------ 2 root root 16384 Mar 10 2004 lost+found
> drwxr-xr-x 2 root root 4096 Sep 8 2003 misc
> ?--------- ? ? ? ? ? /net/bix/mnt
> ?--------- ? ? ? ? ? /net/bix/usr
> drwxrwxrwx 8 root root 4096 Jul 10 02:50 opt
> drwxr-xr-x 2 root root 4096 Mar 10 2004 proc
> drwxr-xr-x 20 root root 4096 Aug 7 16:39 root
> drwxr-xr-x 2 root root 57344 Apr 24 2004 rpms
> drwxr-xr-x 2 root root 8192 Apr 10 03:19 sbin
> -rw-r--r-- 1 root root 1048576000 Mar 12 2004 swap
> drwxr-xr-x 2 root root 4096 Mar 12 2004 sys
> drwxr-xr-x 3 root root 4096 Mar 10 2004 tftpboot
> drwxrwxrwt 14 root root 16384 Aug 13 13:29 tmp
> drwxr-xr-x 27 root root 4096 Mar 10 2004 var
> sony:/home/akpm> ls -l /net/bix/usr
> ls: /net/bix/usr: No such file or directory
> sony:/home/akpm> mount
> /dev/sda6 on / type ext3 (rw,noatime)
> /dev/proc on /proc type proc (rw)
> /dev/sys on /sys type sysfs (rw)
> /dev/devpts on /dev/pts type devpts (rw,gid=5,mode=620)
> /dev/shm on /dev/shm type tmpfs (rw)
> none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
> sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
> automount(pid1757) on /net type autofs (rw,fd=5,pgrp=1757,minproto=2,maxproto=4)
> bix:/ on /net/bix type nfs (rw,nosuid,nodev,hard,intr,tcp,addr=192.168.2.33)
>
>
> distro is fairly-up-to-date FC5.
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-14 6:36 ` 2.6.18-rc4-mm1 Reuben Farrelly
@ 2006-08-14 9:06 ` Rafael J. Wysocki
0 siblings, 0 replies; 80+ messages in thread
From: Rafael J. Wysocki @ 2006-08-14 9:06 UTC (permalink / raw)
To: Reuben Farrelly
Cc: Michal Piotrowski, Ingo Molnar, Arjan van de Ven, linux-kernel,
Andrew Morton
On Monday 14 August 2006 08:36, Reuben Farrelly wrote:
> On 14/08/2006 12:24 a.m., Michal Piotrowski wrote:
> > On 13/08/06, Andrew Morton <akpm@osdl.org> wrote:
> >>
> >> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm1/
> >>
> >>
> >> - Warning: all the Serial ATA Kconfig options have been renamed. If you
> >> blindly run `make oldconfig' you won't have any disks.
> >>
> >
> > MAX_STACK_TRACE_ENTRIES too low!
> >
> > What does it mean?
> >
> > BUG: MAX_STACK_TRACE_ENTRIES too low!
> > turning off the locking correctness validator.
> > [<c0103e41>] dump_trace+0x70/0x176
> > [<c0103fc1>] show_trace_log_lvl+0x12/0x22
> > [<c0103fde>] show_trace+0xd/0xf
> > [<c01040b0>] dump_stack+0x17/0x19
> > [<c0138f30>] save_trace+0xce/0xd7
> > [<c0139370>] add_lock_to_list+0x22/0x39
> > [<c0139b3c>] check_prev_add+0x139/0x1b4
> > [<c0139c04>] check_prevs_add+0x4d/0xaf
> > [<c013b646>] __lock_acquire+0x8a1/0x93c
> > [<c013bd4c>] lock_acquire+0x6f/0x8f
> > [<c03033e8>] _spin_lock_irq+0x29/0x35
> > [<c01ed022>] __make_request+0x68/0x413
> > [<c01ed6a7>] generic_make_request+0x273/0x2a4
> > [<c01ed802>] submit_bio+0x12a/0x132
> > [<c017b6f6>] submit_bh+0x10e/0x12e
> > [<c0179fd3>] __block_write_full_page+0x231/0x326
> > [<c017b567>] block_write_full_page+0xd7/0xdf
> > [<c017e17a>] blkdev_writepage+0xf/0x11
> > [<c0199d92>] mpage_writepages+0x1b6/0x324
> > [<c017f3ee>] generic_writepages+0xa/0xc
> > [<c015b6b5>] do_writepages+0x23/0x36
> > [<c019871c>] __sync_single_inode+0x7b/0x199
> > [<c01989ac>] __writeback_single_inode+0x172/0x17a
> > [<c0198b50>] generic_sync_sb_inodes+0x19c/0x242
> > [<c0198c13>] sync_sb_inodes+0x1d/0x20
> > [<c0198c8e>] writeback_inodes+0x78/0xae
> > [<c015b52b>] wb_kupdate+0x7c/0xdd
> > [<c015bf14>] __pdflush+0xcc/0x163
> > [<c015bfdd>] pdflush+0x32/0x34
> > [<c01347a9>] kthread+0x82/0xaa
> > [<c0303dfd>] kernel_thread_helper+0x5/0xb
> > [<c0103fc1>] show_trace_log_lvl+0x12/0x22
> > [<c0103fde>] show_trace+0xd/0xf
> > [<c01040b0>] dump_stack+0x17/0x19
> > [<c0138f30>] save_trace+0xce/0xd7
> > [<c0139370>] add_lock_to_list+0x22/0x39
> > [<c0139b3c>] check_prev_add+0x139/0x1b4
> > [<c0139c04>] check_prevs_add+0x4d/0xaf
> > [<c013b646>] __lock_acquire+0x8a1/0x93c
> > [<c013bd4c>] lock_acquire+0x6f/0x8f
> > [<c03033e8>] _spin_lock_irq+0x29/0x35
> > [<c01ed022>] __make_request+0x68/0x413
> > [<c01ed6a7>] generic_make_request+0x273/0x2a4
> > [<c01ed802>] submit_bio+0x12a/0x132
> > [<c017b6f6>] submit_bh+0x10e/0x12e
> > [<c0179fd3>] __block_write_full_page+0x231/0x326
> > [<c017b567>] block_write_full_page+0xd7/0xdf
> > [<c017e17a>] blkdev_writepage+0xf/0x11
> > [<c0199d92>] mpage_writepages+0x1b6/0x324
> > [<c017f3ee>] generic_writepages+0xa/0xc
> > [<c015b6b5>] do_writepages+0x23/0x36
> > [<c019871c>] __sync_single_inode+0x7b/0x199
> > [<c01989ac>] __writeback_single_inode+0x172/0x17a
> > [<c0198b50>] generic_sync_sb_inodes+0x19c/0x242
> > [<c0198c13>] sync_sb_inodes+0x1d/0x20
> > [<c0198c8e>] writeback_inodes+0x78/0xae
> > [<c015b52b>] wb_kupdate+0x7c/0xdd
> > [<c015bf14>] __pdflush+0xcc/0x163
> > [<c015bfdd>] pdflush+0x32/0x34
> > [<c01347a9>] kthread+0x82/0xaa
> > [<c0303dfd>] kernel_thread_helper+0x5/0xb
> > =======================
> >
> > config & dmesg
> > http://www.stardust.webpages.pl/files/mm/2.6.18-rc4-mm1/frontline/
> >
> > Regards,
> > Michal
>
> Seeing this message here as well, which I guess is the same thing even though
> the trace is a bit different.
I'm seeing these too, on x86_64:
PM: Adding info for No Bus:vcs7
PM: Adding info for No Bus:vcsa7
hdb: ATAPI 24X DVD-ROM CD-R/RW drive, 2048kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.20
BUG: MAX_STACK_TRACE_ENTRIES too low!
turning off the locking correctness validator.
Call Trace:
[<ffffffff8020b0d9>] dump_trace+0x99/0x3b0
[<ffffffff8020b433>] show_trace+0x43/0x60
[<ffffffff8020b735>] dump_stack+0x15/0x20
[<ffffffff802484d6>] save_trace+0xd6/0xf0
[<ffffffff80248601>] add_lock_to_list+0x91/0xc0
[<ffffffff8024a861>] __lock_acquire+0xb01/0xd30
[<ffffffff8024ae2b>] lock_acquire+0x8b/0xc0
[<ffffffff8047259f>] _spin_lock+0x2f/0x40
[<ffffffff802889a2>] cache_alloc_refill+0xa2/0x7f0
[<ffffffff802888a7>] kmem_cache_alloc+0x77/0xd0
[<ffffffff804349ce>] inet_twsk_alloc+0x2e/0x140
[<ffffffff8044a404>] tcp_time_wait+0x64/0x350
[<ffffffff8043ba5e>] tcp_fin+0xde/0x1f0
[<ffffffff8043efa5>] tcp_data_queue+0x2c5/0xbf0
[<ffffffff804405b8>] tcp_rcv_state_process+0xce8/0xd80
[<ffffffff804486f4>] tcp_v4_do_rcv+0x334/0x390
[<ffffffff804496e7>] tcp_v4_rcv+0x8f7/0x960
[<ffffffff8042c44a>] ip_local_deliver+0x19a/0x250
[<ffffffff8042c9a4>] ip_rcv+0x4a4/0x4f0
[<ffffffff8040ded4>] netif_receive_skb+0x314/0x370
[<ffffffff8813b1cf>] :skge:skge_poll+0x43f/0x570
[<ffffffff8040c25a>] net_rx_action+0xba/0x1f0
[<ffffffff80232e40>] __do_softirq+0x70/0xf0
[<ffffffff8020aa7c>] call_softirq+0x1c/0x30
[<ffffffff8020cbcd>] do_softirq+0x3d/0xb0
[<ffffffff80232c9e>] irq_exit+0x4e/0x60
[<ffffffff8020cd75>] do_IRQ+0x135/0x140
[<ffffffff8020a266>] ret_from_intr+0x0/0xf
[<ffffffff802083b2>] default_idle+0x42/0x80
[<ffffffff80208445>] cpu_idle+0x55/0xa0
[<ffffffff8020703a>] rest_init+0x3a/0x40
[<ffffffff8090d81f>] start_kernel+0x24f/0x260
[<ffffffff8090d15f>] _sinittext+0x15f/0x170
<IRQ> [<ffffffff802484d6>] save_trace+0xd6/0xf0
[<ffffffff80248601>] add_lock_to_list+0x91/0xc0
[<ffffffff8024a861>] __lock_acquire+0xb01/0xd30
[<ffffffff8024aed9>] mark_held_locks+0x79/0xa0
[<ffffffff802889a2>] cache_alloc_refill+0xa2/0x7f0
[<ffffffff8024ae2b>] lock_acquire+0x8b/0xc0
[<ffffffff802889a2>] cache_alloc_refill+0xa2/0x7f0
[<ffffffff804349ce>] inet_twsk_alloc+0x2e/0x140
[<ffffffff8047259f>] _spin_lock+0x2f/0x40
[<ffffffff802889a2>] cache_alloc_refill+0xa2/0x7f0
[<ffffffff80287fbf>] check_poison_obj+0x2f/0x1e0
[<ffffffff8028715d>] dbg_redzone1+0x1d/0x30
[<ffffffff804349ce>] inet_twsk_alloc+0x2e/0x140
[<ffffffff802888a7>] kmem_cache_alloc+0x77/0xd0
[<ffffffff804349ce>] inet_twsk_alloc+0x2e/0x140
[<ffffffff8044a404>] tcp_time_wait+0x64/0x350
[<ffffffff8043ba5e>] tcp_fin+0xde/0x1f0
[<ffffffff8043efa5>] tcp_data_queue+0x2c5/0xbf0
[<ffffffff8023723b>] mod_timer+0x2b/0x30
[<ffffffff804405b8>] tcp_rcv_state_process+0xce8/0xd80
[<ffffffff804486f4>] tcp_v4_do_rcv+0x334/0x390
[<ffffffff80449280>] tcp_v4_rcv+0x490/0x960
[<ffffffff804496e7>] tcp_v4_rcv+0x8f7/0x960
[<ffffffff8042c44a>] ip_local_deliver+0x19a/0x250
[<ffffffff8042c9a4>] ip_rcv+0x4a4/0x4f0
[<ffffffff80407797>] kfree_skb+0x27/0x30
[<ffffffff88297634>] :af_packet:packet_rcv_spkt+0x184/0x1a0
[<ffffffff8040ded4>] netif_receive_skb+0x314/0x370
[<ffffffff8813b1cf>] :skge:skge_poll+0x43f/0x570
[<ffffffff8040c25a>] net_rx_action+0xba/0x1f0
[<ffffffff80232e40>] __do_softirq+0x70/0xf0
[<ffffffff8020aa7c>] call_softirq+0x1c/0x30
[<ffffffff8020cbcd>] do_softirq+0x3d/0xb0
[<ffffffff80232c9e>] irq_exit+0x4e/0x60
[<ffffffff8020cd75>] do_IRQ+0x135/0x140
[<ffffffff80208370>] default_idle+0x0/0x80
[<ffffffff8020a266>] ret_from_intr+0x0/0xf
<EOI> [<ffffffff802083b0>] default_idle+0x40/0x80
[<ffffffff802083b2>] default_idle+0x42/0x80
[<ffffffff80208445>] cpu_idle+0x55/0xa0
[<ffffffff8020703a>] rest_init+0x3a/0x40
[<ffffffff8090d81f>] start_kernel+0x24f/0x260
[<ffffffff8090d15f>] _sinittext+0x15f/0x170
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 2.6.18-rc4-mm1
2022-08-14 8:42 ` 2.6.18-rc4-mm1 Maciej Rutecki
@ 2006-08-14 9:12 ` Rafael J. Wysocki
2006-08-14 11:35 ` 2.6.18-rc4-mm1 Maciej Rutecki
2006-08-17 12:22 ` 2.6.18-rc4-mm1 Andreas Mohr
1 sibling, 1 reply; 80+ messages in thread
From: Rafael J. Wysocki @ 2006-08-14 9:12 UTC (permalink / raw)
To: Maciej Rutecki; +Cc: Andrew Morton, linux-kernel, Dmitry Torokhov
On Sunday 14 August 2022 10:42, Maciej Rutecki wrote:
> Andrew Morton napisał(a):
> > Please always do reply-to-all.
> >
>
> Sorry.
>
> >
> >
> > Could be i8042-get-rid-of-polling-timer-v4.patch. Please try the below
> > reversion patch, on top of rc4-mm1, thanks.
> >
> >
>
> Thanks for help.
>
> I try this patch, keyboard works, but I have other problem. When I try:
>
> echo "standby" > /sys/power/state
>
> system goes to standby, but keyboard stop working and CMOS clock was
> corrupted (randomize date and time e.g. Fri Feb 18 2028 13:57:43). So I
> must reset computer.
To fix the CMOS clock problem please try to unset CONFIG_PM_TRACE .
Greetings,
Rafael
--
You never change things by fighting the existing reality.
R. Buckminster Fuller
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-14 8:06 ` 2.6.18-rc4-mm1 Ian Kent
@ 2006-08-14 9:32 ` David Howells
2006-08-14 17:16 ` 2.6.18-rc4-mm1 Andrew Morton
0 siblings, 1 reply; 80+ messages in thread
From: David Howells @ 2006-08-14 9:32 UTC (permalink / raw)
To: Ian Kent; +Cc: Andrew Morton, linux-kernel, Trond Myklebust, David Howells
Ian Kent <raven@themaw.net> wrote:
> I'm having trouble duplicating this.
> Is there any more info. about this I'm missing?
Works fine for me also.
Andrew, can you do the following:
cat /proc/fs/nfsfs/*
And can you try mounting "bix:/" manually to see if that exhibits the same
problem? It'd be useful to know if autofs is actually having an effect.
Also, can you do a module list and check that it's autofs4 that's being used,
and not autofs. It would be handy if we could rule out an adverse interaction
between nfs and autofs4.
> Bisection shows that the bug is introduced by git-nfs.patch.
But what does it actually show? Do you know where the bug is then? (I don't
know exactly how bisection works).
David
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-14 9:12 ` 2.6.18-rc4-mm1 Rafael J. Wysocki
@ 2006-08-14 11:35 ` Maciej Rutecki
0 siblings, 0 replies; 80+ messages in thread
From: Maciej Rutecki @ 2006-08-14 11:35 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: Andrew Morton, linux-kernel, Dmitry Torokhov
Rafael J. Wysocki napisał(a):
> On Sunday 14 August 2022 10:42, Maciej Rutecki wrote:
>>
>> I try this patch, keyboard works, but I have other problem. When I try:
>>
>> echo "standby" > /sys/power/state
>>
>> system goes to standby, but keyboard stop working and CMOS clock was
>> corrupted (randomize date and time e.g. Fri Feb 18 2028 13:57:43). So I
>> must reset computer.
>
> To fix the CMOS clock problem please try to unset CONFIG_PM_TRACE .
Thanks for help, CMOS clock works correct now. But still is problem with
keyboard after standby.
Greetings
--
Maciej Rutecki <maciej.rutecki@gmail.com>
http://www.unixy.pl
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-13 23:25 ` 2.6.18-rc4-mm1 Dave Jones
@ 2006-08-14 11:55 ` Ben Buxton
2006-08-14 20:20 ` 2.6.18-rc4-mm1 Dave Jones
0 siblings, 1 reply; 80+ messages in thread
From: Ben Buxton @ 2006-08-14 11:55 UTC (permalink / raw)
To: Dave Jones, Andrew Morton, Maciej Rutecki, linux-kernel
Dave Jones <davej@redhat.com> uttered the following thing:
> On Mon, Aug 14, 2006 at 12:44:13AM +0200, Ben Buxton wrote:
>
> > Also, whenever I echo anything to "scaling_governor", I get the
> > following kernel message:
> >
> > [ 734.156000] BUG: warning at kernel/cpu.c:38/lock_cpu_hotplug()
> > [ 734.156000] [<c013c3ec>] lock_cpu_hotplug+0x7c/0x90
> > [ 734.156000] [<c01327f4>] __create_workqueue+0x44/0x140
> > [ 734.156000] [<c02dcf7b>] mutex_lock+0xb/0x20
> > [ 734.156000] [<e01f2665>] cpufreq_governor_dbs+0x2b5/0x310 [cpufreq_ondemand]
>
> This makes no sense at all, because in -mm __create_workqueue doesn't
> call lock_cpu_hotplug().
>
> Are you sure this was from a tree with -mm1 applied ?
Definitely 2.6.18-rc4-mm1, and I've done a clean rebuild + removal of
all modules under /lib/modules beforehand.
BB
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-14 0:00 ` 2.6.18-rc4-mm1 Dmitry Torokhov
@ 2006-08-14 12:03 ` Ben B
2006-08-14 13:45 ` 2.6.18-rc4-mm1 Dmitry Torokhov
0 siblings, 1 reply; 80+ messages in thread
From: Ben B @ 2006-08-14 12:03 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Andrew Morton, Maciej Rutecki, linux-kernel
Dmitry Torokhov <dtor@insightbb.com> uttered the following thing:
> On Sunday 13 August 2006 18:44, Ben Buxton wrote:
> > > Could be i8042-get-rid-of-polling-timer-v4.patch. Please try the below
> > > reversion patch, on top of rc4-mm1, thanks.
> >
> > Acking the same issue. Applied the revert patch and my keyboard now
> > works. Also, it turns out that my keyboard is now the only thing that
> > failed to resume from S3 on my HP Nc6400, but adding "irqpoll" has fixed
> > that for now.
> >
>
> Can I please have dmesg of booting unpatched -rc4-mm1 with i8042.debug=1?
I've got masses of these messages - about 100-200 per second filling my
logs. It seems that they came through as such a rate that the dmesg
buffer emptied of everything else before syslogd started.
Aug 14 12:53:23 gromit kernel: [ 23.070229] drivers/input/serio/i8042.c: Interrupt 1, without any data [4669]
Aug 14 12:53:23 gromit kernel: [ 23.070249] drivers/input/serio/i8042.c: Interrupt 12, without any data [4669]
Aug 14 12:53:23 gromit kernel: [ 23.074223] drivers/input/serio/i8042.c: Interrupt 1, without any data [4670]
Aug 14 12:53:23 gromit kernel: [ 23.074243] drivers/input/serio/i8042.c: Interrupt 12, without any data [4670]
Aug 14 12:53:23 gromit kernel: [ 23.078216] drivers/input/serio/i8042.c: Interrupt 1, without any data [4671]
Aug 14 12:53:23 gromit kernel: [ 23.078237] drivers/input/serio/i8042.c: Interrupt 12, without any data [4671]
Aug 14 12:53:23 gromit kernel: [ 23.082210] drivers/input/serio/i8042.c: Interrupt 1, without any data [4672]
I can try to get a full boot log later when I get home.
The interrupt counts don't actually seem to increase, I checked
/proc/interrupts several times in a row and there's no change to the
8042 interrupt counts:
root@gromit:~# cat /proc/interrupts
CPU0 CPU1
0: 66050 0 IO-APIC-edge timer
1: 10 0 IO-APIC-edge i8042
8: 3 0 IO-APIC-edge rtc
9: 10 0 IO-APIC-level acpi
12: 1796 0 IO-APIC-edge i8042
14: 92 0 IO-APIC-edge libata
15: 0 0 IO-APIC-edge libata
58: 1527 5427 PCI-MSI libata
66: 20 0 IO-APIC-level sdhci:slot0, uhci_hcd:usb2
74: 22513 0 IO-APIC-level uhci_hcd:usb1, ehci_hcd:usb5
82: 1366 0 PCI-MSI eth0
177: 13870 0 IO-APIC-level HDA Intel, i915@pci:0000:00:02.0
193: 0 0 IO-APIC-level uhci_hcd:usb4
201: 30 0 IO-APIC-level yenta, uhci_hcd:usb3
NMI: 0 0
LOC: 65373 65374
ERR: 0
MIS: 6
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-14 12:03 ` 2.6.18-rc4-mm1 Ben B
@ 2006-08-14 13:45 ` Dmitry Torokhov
2006-08-14 21:44 ` 2.6.18-rc4-mm1 Ben B
0 siblings, 1 reply; 80+ messages in thread
From: Dmitry Torokhov @ 2006-08-14 13:45 UTC (permalink / raw)
To: Ben B; +Cc: Andrew Morton, Maciej Rutecki, linux-kernel
On 8/14/06, Ben B <kernel@bb.cactii.net> wrote:
> Dmitry Torokhov <dtor@insightbb.com> uttered the following thing:
> > On Sunday 13 August 2006 18:44, Ben Buxton wrote:
> > > > Could be i8042-get-rid-of-polling-timer-v4.patch. Please try the below
> > > > reversion patch, on top of rc4-mm1, thanks.
> > >
> > > Acking the same issue. Applied the revert patch and my keyboard now
> > > works. Also, it turns out that my keyboard is now the only thing that
> > > failed to resume from S3 on my HP Nc6400, but adding "irqpoll" has fixed
> > > that for now.
> > >
> >
> > Can I please have dmesg of booting unpatched -rc4-mm1 with i8042.debug=1?
>
> I've got masses of these messages - about 100-200 per second filling my
> logs. It seems that they came through as such a rate that the dmesg
> buffer emptied of everything else before syslogd started.
>
> Aug 14 12:53:23 gromit kernel: [ 23.070229] drivers/input/serio/i8042.c: Interrupt 1, without any data [4669]
> Aug 14 12:53:23 gromit kernel: [ 23.070249] drivers/input/serio/i8042.c: Interrupt 12, without any data [4669]
> Aug 14 12:53:23 gromit kernel: [ 23.074223] drivers/input/serio/i8042.c: Interrupt 1, without any data [4670]
> Aug 14 12:53:23 gromit kernel: [ 23.074243] drivers/input/serio/i8042.c: Interrupt 12, without any data [4670]
> Aug 14 12:53:23 gromit kernel: [ 23.078216] drivers/input/serio/i8042.c: Interrupt 1, without any data [4671]
> Aug 14 12:53:23 gromit kernel: [ 23.078237] drivers/input/serio/i8042.c: Interrupt 12, without any data [4671]
> Aug 14 12:53:23 gromit kernel: [ 23.082210] drivers/input/serio/i8042.c: Interrupt 1, without any data [4672]
>
> I can try to get a full boot log later when I get home.
>
Please.
> The interrupt counts don't actually seem to increase, I checked
> /proc/interrupts several times in a row and there's no change to the
> 8042 interrupt counts:
>
> root@gromit:~# cat /proc/interrupts
> CPU0 CPU1
> 0: 66050 0 IO-APIC-edge timer
> 1: 10 0 IO-APIC-edge i8042
> 8: 3 0 IO-APIC-edge rtc
> 9: 10 0 IO-APIC-level acpi
> 12: 1796 0 IO-APIC-edge i8042
^^^^^^^
It loos like it does (on AUX port)
--
Dmitry
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-13 8:24 2.6.18-rc4-mm1 Andrew Morton
` (4 preceding siblings ...)
2006-08-13 20:39 ` 2.6.18-rc4-mm1 Andrew Morton
@ 2006-08-14 14:02 ` Michal Piotrowski
2006-08-14 18:19 ` 2.6.18-rc4-mm1 Andrew Morton
2006-08-14 17:54 ` 2.6.18-rc4-mm1 Rafael J. Wysocki
6 siblings, 1 reply; 80+ messages in thread
From: Michal Piotrowski @ 2006-08-14 14:02 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
On 13/08/06, Andrew Morton <akpm@osdl.org> wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm1/
>
Aug 14 15:35:10 ltg01-fedora kernel: BUG: unable to handle kernel
paging request at virtual address fffeffbf
Aug 14 15:35:10 ltg01-fedora kernel: printing eip:
Aug 14 15:35:10 ltg01-fedora kernel: c013d539
Aug 14 15:35:10 ltg01-fedora kernel: *pde = 00004067
Aug 14 15:35:10 ltg01-fedora kernel: *pte = 00000000
Aug 14 15:35:10 ltg01-fedora kernel: Oops: 0000 [#1]
Aug 14 15:35:10 ltg01-fedora kernel: 4K_STACKS PREEMPT SMP
Aug 14 15:35:10 ltg01-fedora kernel: last sysfs file:
/devices/platform/i2c-9191/9191-0290/temp2_input
Aug 14 15:35:10 ltg01-fedora kernel: Modules linked in: ipv6 w83627hf
hwmon_vid hwmon i2c_isa af_packet ip_conntrack_netbios
_ns ipt_REJECT xt_state ip_conntrack nfnetlink xt_tcpudp
iptable_filter ip_tables x_tables cpufreq_userspace p4_clockmod spe
edstep_lib binfmt_misc thermal processor fan container evdev
snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_seq_dummy snd_seq_
oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss
snd_mixer_oss snd_pcm sk98lin snd_timer skge snd soundcore snd_pag
e_alloc ide_cd intel_agp agpgart cdrom i2c_i801 rtc unix
Aug 14 15:35:10 ltg01-fedora kernel: CPU: 1
Aug 14 15:35:10 ltg01-fedora kernel: EIP: 0060:[<c013d539>] Not
tainted VLI
Aug 14 15:35:10 ltg01-fedora kernel: EFLAGS: 00210286 (2.6.18-rc4-mm1 #97)
Aug 14 15:35:10 ltg01-fedora kernel: EIP is at futex_wake+0x9c/0xcb
Aug 14 15:35:10 ltg01-fedora kernel: eax: 0808c000 ebx: c0670a60
ecx: d3a1dfa2 edx: fffeffbf
Aug 14 15:35:10 ltg01-fedora kernel: esi: 00000000 edi: fffeffbf
ebp: f4896f64 esp: f4896f40
Aug 14 15:35:10 ltg01-fedora kernel: ds: 007b es: 007b ss: 0068
Aug 14 15:35:10 ltg01-fedora kernel: Process firefox-bin (pid: 2210,
ti=f4896000 task=f3d180f0 task.ti=f4896000)
Aug 14 15:35:10 ltg01-fedora kernel: Stack: c0670a80 00000001 0808c000
f4302e74 00000044 ffffffe7 0808c044 bf8f35b0
Aug 14 15:35:10 ltg01-fedora kernel: 00000000 f4896f7c c013ed39
00000001 0808c044 7fffffff bf8f35b0 f4896fb4
Aug 14 15:35:10 ltg01-fedora kernel: c013ee84 7fffffff bf8f35b0
00000000 bf8f3528 00000000 f4896fa8 00000000
Aug 14 15:35:10 ltg01-fedora kernel: Call Trace:
Aug 14 15:35:10 ltg01-fedora kernel: [<c013ed39>] do_futex+0x3c/0x92
Aug 14 15:35:10 ltg01-fedora kernel: [<c013ee84>] sys_futex+0xf5/0x101
Aug 14 15:35:11 ltg01-fedora kernel: [<c010312d>] sysenter_past_esp+0x56/0x8d
Aug 14 15:35:11 ltg01-fedora kernel: [<b7f1d410>] 0xb7f1d410
Aug 14 15:35:11 ltg01-fedora kernel: [<c0103fc1>] show_trace_log_lvl+0x12/0x22
Aug 14 15:35:11 ltg01-fedora kernel: [<c0104067>] show_stack_log_lvl+0x87/0x8f
Aug 14 15:35:11 ltg01-fedora kernel: [<c0104203>] show_registers+0x151/0x1d8
Aug 14 15:35:11 ltg01-fedora kernel: [<c010444d>] die+0x120/0x1f0
Aug 14 15:35:11 ltg01-fedora kernel: [<c01185cf>] do_page_fault+0x49d/0x580
Aug 14 15:35:11 ltg01-fedora kernel: [<c0303ba9>] error_code+0x39/0x40
Aug 14 15:35:11 ltg01-fedora kernel: [<c013ed39>] do_futex+0x3c/0x92
Aug 14 15:35:11 ltg01-fedora kernel: [<c013ee84>] sys_futex+0xf5/0x101
Aug 14 15:35:11 ltg01-fedora kernel: [<c010312d>] sysenter_past_esp+0x56/0x8d
Aug 14 15:35:11 ltg01-fedora kernel: =======================
Aug 14 15:35:11 ltg01-fedora kernel: Code: 45 e8 39 41 04 75 22 8b 45
ec 39 41 08 75 1a 83 7a 48 00 74 07 be ea ff ff ff eb
16 89 d0 46 e8 00 fd ff ff 3b 75 e0 7d 09 89 fa <8b> 3f 3b 55 dc eb c0
89 d8 e8 bd 60 1c 00 89 e0 25 00 f0 ff ff
Aug 14 15:35:11 ltg01-fedora kernel: EIP: [<c013d539>]
futex_wake+0x9c/0xcb SS:ESP 0068:f4896f40
Aug 14 15:35:11 ltg01-fedora kernel: <6>note: firefox-bin[2210]
exited with preempt_count 1
Aug 14 15:35:11 ltg01-fedora kernel: BUG: sleeping function called
from invalid context at /usr/src/linux-mm/mm/slab.c:2989
Aug 14 15:35:11 ltg01-fedora kernel: in_atomic():1, irqs_disabled():1
Aug 14 15:35:11 ltg01-fedora kernel: [<c0103e41>] dump_trace+0x70/0x176
Aug 14 15:35:11 ltg01-fedora kernel: [<c0103fc1>] show_trace_log_lvl+0x12/0x22
Aug 14 15:35:11 ltg01-fedora kernel: [<c0103fde>] show_trace+0xd/0xf
Aug 14 15:35:11 ltg01-fedora kernel: [<c01040b0>] dump_stack+0x17/0x19
Aug 14 15:35:11 ltg01-fedora kernel: [<c011ec0c>] __might_sleep+0x92/0x9a
Aug 14 15:35:11 ltg01-fedora kernel: [<c01731ba>] kmem_cache_zalloc+0x27/0xe7
Aug 14 15:35:11 ltg01-fedora kernel: [<c0154b73>]
taskstats_exit_alloc+0x30/0x6e
Aug 14 15:35:11 ltg01-fedora kernel: [<c012455e>] do_exit+0x1a3/0x5cd
Aug 14 15:35:11 ltg01-fedora kernel: [<c0104515>] die+0x1e8/0x1f0
Aug 14 15:35:11 ltg01-fedora kernel: [<c01185cf>] do_page_fault+0x49d/0x580
Aug 14 15:35:11 ltg01-fedora kernel: [<c0303ba9>] error_code+0x39/0x40
Aug 14 15:35:11 ltg01-fedora kernel: [<c013d539>] futex_wake+0x9c/0xcb
Aug 14 15:35:11 ltg01-fedora kernel: [<c013ed39>] do_futex+0x3c/0x92
Aug 14 15:35:12 ltg01-fedora kernel: [<c013ee84>] sys_futex+0xf5/0x101
Aug 14 15:35:12 ltg01-fedora kernel: [<c010312d>] sysenter_past_esp+0x56/0x8d
Aug 14 15:35:12 ltg01-fedora kernel: [<b7f1d410>] 0xb7f1d410
Aug 14 15:35:12 ltg01-fedora kernel: [<c0103fc1>] show_trace_log_lvl+0x12/0x22
Aug 14 15:35:12 ltg01-fedora kernel: [<c0103fde>] show_trace+0xd/0xf
Aug 14 15:35:12 ltg01-fedora kernel: [<c01040b0>] dump_stack+0x17/0x19
Aug 14 15:35:12 ltg01-fedora kernel: [<c011ec0c>] __might_sleep+0x92/0x9a
Aug 14 15:35:12 ltg01-fedora kernel: [<c01731ba>] kmem_cache_zalloc+0x27/0xe7
Aug 14 15:35:12 ltg01-fedora kernel: [<c0154b73>]
taskstats_exit_alloc+0x30/0x6e
Aug 14 15:35:12 ltg01-fedora kernel: [<c012455e>] do_exit+0x1a3/0x5cd
Aug 14 15:35:12 ltg01-fedora kernel: [<c0104515>] die+0x1e8/0x1f0
Aug 14 15:35:12 ltg01-fedora kernel: [<c01185cf>] do_page_fault+0x49d/0x580
Aug 14 15:35:12 ltg01-fedora kernel: [<c0303ba9>] error_code+0x39/0x40
Aug 14 15:35:12 ltg01-fedora kernel: [<c013ed39>] do_futex+0x3c/0x92
Aug 14 15:35:12 ltg01-fedora kernel: [<c013ee84>] sys_futex+0xf5/0x101
Aug 14 15:35:12 ltg01-fedora kernel: [<c010312d>] sysenter_past_esp+0x56/0x8d
Aug 14 15:35:12 ltg01-fedora kernel: =======================
Aug 14 15:35:20 ltg01-fedora kernel: BUG: soft lockup detected on CPU#0!
Aug 14 15:35:20 ltg01-fedora kernel: [<c0103e41>] dump_trace+0x70/0x176
Aug 14 15:35:20 ltg01-fedora kernel: [<c0103fc1>] show_trace_log_lvl+0x12/0x22
Aug 14 15:35:20 ltg01-fedora kernel: [<c0103fde>] show_trace+0xd/0xf
Aug 14 15:35:20 ltg01-fedora kernel: [<c01040b0>] dump_stack+0x17/0x19
Aug 14 15:35:20 ltg01-fedora kernel: [<c0150ff3>] softlockup_tick+0xca/0xde
Aug 14 15:35:20 ltg01-fedora kernel: [<c012ad52>] run_local_timers+0x12/0x14
Aug 14 15:35:20 ltg01-fedora kernel: [<c012abaa>]
update_process_times+0x40/0x65
Aug 14 15:35:20 ltg01-fedora kernel: [<c0113989>]
smp_apic_timer_interrupt+0x6d/0x75
Aug 14 15:35:20 ltg01-fedora kernel: [<c0103c5a>]
apic_timer_interrupt+0x2a/0x30
Aug 14 15:35:20 ltg01-fedora kernel: [<c01f81c3>] delay_tsc+0xe/0x17
Aug 14 15:35:20 ltg01-fedora kernel: [<c01f8200>] __delay+0x9/0xb
Aug 14 15:35:20 ltg01-fedora kernel: [<c0204aed>] __spin_lock_debug+0x46/0x94
Aug 14 15:35:20 ltg01-fedora kernel: [<c0204be3>] _raw_spin_lock+0xa8/0xbe
Aug 14 15:35:20 ltg01-fedora kernel: [<c030359c>] _spin_lock+0x2a/0x2f
Aug 14 15:35:20 ltg01-fedora kernel: [<c013d4f3>] futex_wake+0x56/0xcb
Aug 14 15:35:20 ltg01-fedora kernel: [<c013ed39>] do_futex+0x3c/0x92
Aug 14 15:35:20 ltg01-fedora kernel: [<c013ee84>] sys_futex+0xf5/0x101
Aug 14 15:35:20 ltg01-fedora kernel: [<c010312d>] sysenter_past_esp+0x56/0x8d
Aug 14 15:35:20 ltg01-fedora kernel: [<b7f1d410>] 0xb7f1d410
Aug 14 15:35:20 ltg01-fedora kernel: [<c0103fc1>] show_trace_log_lvl+0x12/0x22
Aug 14 15:35:20 ltg01-fedora kernel: [<c0103fde>] show_trace+0xd/0xf
Aug 14 15:35:21 ltg01-fedora kernel: [<c01040b0>] dump_stack+0x17/0x19
Aug 14 15:35:21 ltg01-fedora kernel: [<c0150ff3>] softlockup_tick+0xca/0xde
Aug 14 15:35:21 ltg01-fedora kernel: [<c012ad52>] run_local_timers+0x12/0x14
Aug 14 15:35:21 ltg01-fedora kernel: [<c012abaa>]
update_process_times+0x40/0x65
Aug 14 15:35:21 ltg01-fedora kernel: [<c0113989>]
smp_apic_timer_interrupt+0x6d/0x75
Aug 14 15:35:21 ltg01-fedora kernel: [<c0103c5a>]
apic_timer_interrupt+0x2a/0x30
Aug 14 15:35:21 ltg01-fedora kernel: [<c01f8200>] __delay+0x9/0xb
Aug 14 15:35:21 ltg01-fedora kernel: [<c0204aed>] __spin_lock_debug+0x46/0x94
Aug 14 15:35:21 ltg01-fedora kernel: [<c0204be3>] _raw_spin_lock+0xa8/0xbe
Aug 14 15:35:21 ltg01-fedora kernel: [<c030359c>] _spin_lock+0x2a/0x2f
Aug 14 15:35:21 ltg01-fedora kernel: [<c013d4f3>] futex_wake+0x56/0xcb
Aug 14 15:35:21 ltg01-fedora kernel: [<c013ed39>] do_futex+0x3c/0x92
Aug 14 15:35:21 ltg01-fedora kernel: [<c013ee84>] sys_futex+0xf5/0x101
Aug 14 15:35:21 ltg01-fedora kernel: [<c010312d>] sysenter_past_esp+0x56/0x8d
Aug 14 15:35:21 ltg01-fedora kernel: =======================
0xc013d539 is in futex_wake (/usr/src/linux-mm/kernel/futex.c:671).
666
667 hb = hash_futex(&key);
668 spin_lock(&hb->lock);
669 head = &hb->chain;
670
671 list_for_each_entry_safe(this, next, head, list) {
672 if (match_futex (&this->key, &key)) {
673 if (this->pi_state) {
674 ret = -EINVAL;
675 break;
Here is a config file
http://www.stardust.webpages.pl/files/mm/2.6.18-rc4-mm1/frontline/mm-config
Regards,
Michal
--
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-14 9:32 ` 2.6.18-rc4-mm1 David Howells
@ 2006-08-14 17:16 ` Andrew Morton
2006-08-14 18:12 ` 2.6.18-rc4-mm1 David Howells
0 siblings, 1 reply; 80+ messages in thread
From: Andrew Morton @ 2006-08-14 17:16 UTC (permalink / raw)
To: David Howells; +Cc: Ian Kent, linux-kernel, Trond Myklebust
On Mon, 14 Aug 2006 10:32:10 +0100
David Howells <dhowells@redhat.com> wrote:
> Ian Kent <raven@themaw.net> wrote:
>
> > I'm having trouble duplicating this.
> > Is there any more info. about this I'm missing?
>
> Works fine for me also.
>
> Andrew, can you do the following:
>
> cat /proc/fs/nfsfs/*
sony:/home/akpm> cat /proc/fs/nfsfs/*
NV SERVER PORT USE HOSTNAME
NV SERVER PORT DEV FSID FSC
sony:/home/akpm> ls -l /net/bix
total 1025280
drwxr-xr-x 3 root root 4096 Apr 10 03:19 bin
drwxr-xr-x 2 root root 4096 Mar 10 2004 boot
drwxr-xr-x 23 root root 118784 Jun 26 00:48 dev
drwxr-xr-x 98 root root 8192 Aug 14 04:03 etc
drwxr-xr-x 7 root root 4096 Apr 1 2004 home
drwxr-xr-x 2 root root 4096 Oct 7 2003 initrd
drwxr-xr-x 10 root root 4096 Apr 10 03:19 lib
drwx------ 2 root root 16384 Mar 10 2004 lost+found
drwxr-xr-x 2 root root 4096 Sep 8 2003 misc
?--------- ? ? ? ? ? /net/bix/mnt
?--------- ? ? ? ? ? /net/bix/usr
drwxrwxrwx 8 root root 4096 Jul 10 02:50 opt
drwxr-xr-x 2 root root 4096 Mar 10 2004 proc
drwxr-xr-x 20 root root 4096 Aug 7 16:39 root
drwxr-xr-x 2 root root 57344 Apr 24 2004 rpms
drwxr-xr-x 2 root root 8192 Apr 10 03:19 sbin
-rw-r--r-- 1 root root 1048576000 Mar 12 2004 swap
drwxr-xr-x 2 root root 4096 Mar 12 2004 sys
drwxr-xr-x 3 root root 4096 Mar 10 2004 tftpboot
drwxrwxrwt 14 root root 16384 Aug 14 09:57 tmp
drwxr-xr-x 27 root root 4096 Mar 10 2004 var
sony:/home/akpm> cat /proc/fs/nfsfs/*
NV SERVER PORT USE HOSTNAME
v3 c0a80221 801 1 bix
NV SERVER PORT DEV FSID FSC
v3 c0a80221 801 0:21 802:0 no
> And can you try mounting "bix:/" manually to see if that exhibits the same
> problem?
sony:/home/akpm# mount bix:/ /mnt/bix
sony:/home/akpm# ls -l /mnt/bix
total 1025288
drwxr-xr-x 3 root root 4096 Apr 10 03:19 bin
drwxr-xr-x 2 root root 4096 Mar 10 2004 boot
drwxr-xr-x 23 root root 118784 Jun 26 00:48 dev
drwxr-xr-x 98 root root 8192 Aug 14 04:03 etc
drwxr-xr-x 7 root root 4096 Apr 1 2004 home
drwxr-xr-x 2 root root 4096 Oct 7 2003 initrd
drwxr-xr-x 10 root root 4096 Apr 10 03:19 lib
drwx------ 2 root root 16384 Mar 10 2004 lost+found
drwxr-xr-x 2 root root 4096 Sep 8 2003 misc
drwxr-xr-x 19 root root 4096 Jul 3 15:29 mnt
drwxrwxrwx 8 root root 4096 Jul 10 02:50 opt
drwxr-xr-x 2 root root 4096 Mar 10 2004 proc
drwxr-xr-x 20 root root 4096 Aug 7 16:39 root
drwxr-xr-x 2 root root 57344 Apr 24 2004 rpms
drwxr-xr-x 2 root root 8192 Apr 10 03:19 sbin
-rw-r--r-- 1 root root 1048576000 Mar 12 2004 swap
drwxr-xr-x 2 root root 4096 Mar 12 2004 sys
drwxr-xr-x 3 root root 4096 Mar 10 2004 tftpboot
drwxrwxrwt 14 root root 16384 Aug 14 09:57 tmp
drwxr-xr-x 17 root root 4096 Mar 22 2005 usr
drwxr-xr-x 27 root root 4096 Mar 10 2004 var
sony:/home/akpm# mount bix:/usr/src /mnt/bix/usr/src
sony:/home/akpm# ls -l /mnt/bix
total 1025288
drwxr-xr-x 3 root root 4096 Apr 10 03:19 bin
drwxr-xr-x 2 root root 4096 Mar 10 2004 boot
drwxr-xr-x 23 root root 118784 Jun 26 00:48 dev
drwxr-xr-x 98 root root 8192 Aug 14 04:03 etc
drwxr-xr-x 7 root root 4096 Apr 1 2004 home
drwxr-xr-x 2 root root 4096 Oct 7 2003 initrd
drwxr-xr-x 10 root root 4096 Apr 10 03:19 lib
drwx------ 2 root root 16384 Mar 10 2004 lost+found
drwxr-xr-x 2 root root 4096 Sep 8 2003 misc
drwxr-xr-x 19 root root 4096 Jul 3 15:29 mnt
drwxrwxrwx 8 root root 4096 Jul 10 02:50 opt
drwxr-xr-x 2 root root 4096 Mar 10 2004 proc
drwxr-xr-x 20 root root 4096 Aug 7 16:39 root
drwxr-xr-x 2 root root 57344 Apr 24 2004 rpms
drwxr-xr-x 2 root root 8192 Apr 10 03:19 sbin
-rw-r--r-- 1 root root 1048576000 Mar 12 2004 swap
drwxr-xr-x 2 root root 4096 Mar 12 2004 sys
drwxr-xr-x 3 root root 4096 Mar 10 2004 tftpboot
drwxrwxrwt 14 root root 16384 Aug 14 09:57 tmp
drwxr-xr-x 17 root root 4096 Mar 22 2005 usr
drwxr-xr-x 27 root root 4096 Mar 10 2004 var
sony:/home/akpm# ls -l /mnt/bix/usr/src
total 1049780
drwxr-xr-x 21 akpm akpm 4096 Jun 17 16:02 24
lrwxrwxrwx 1 akpm akpm 5 Jan 23 2006 25 -> devel
drwxr-xr-x 27 akpm akpm 4096 May 20 01:44 25-alpha
...
> It'd be useful to know if autofs is actually having an effect.
Everything seems OK doing it by hand.
> Also, can you do a module list and check that it's autofs4 that's being used,
> and not autofs.
sony:/home/akpm# lsmod|grep auto
autofs4 20228 1
> It would be handy if we could rule out an adverse interaction
> between nfs and autofs4.
I'd say that's exactly what it is.
> > Bisection shows that the bug is introduced by git-nfs.patch.
>
> But what does it actually show? Do you know where the bug is then? (I don't
> know exactly how bisection works).
>
I mean: bisection searching through the rc4-mm1 patch pile indicates that:
everything up to but not including git-nfs.patch: OK
add git-nfs.patch to the above: fails.
The server is running 2.6.17-rc1-mm3, if that matters. (It shouldn't:
git-nfs.patch has changed the client's behaviour).
And, as I said, this machine is running stock mostly-up-to-date FC5.
sony:/home/akpm> rpm -q autofs
autofs-4.1.4-29
sony:/home/akpm> rpm -V autofs
sony:/home/akpm>
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-13 8:24 2.6.18-rc4-mm1 Andrew Morton
` (5 preceding siblings ...)
2006-08-14 14:02 ` 2.6.18-rc4-mm1 Michal Piotrowski
@ 2006-08-14 17:54 ` Rafael J. Wysocki
2006-08-14 18:15 ` 2.6.18-rc4-mm1 Andrew Morton
2006-08-15 14:07 ` 2.6.18-rc4-mm1 Atsushi Nemoto
6 siblings, 2 replies; 80+ messages in thread
From: Rafael J. Wysocki @ 2006-08-14 17:54 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
On Sunday 13 August 2006 10:24, Andrew Morton wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm1/
>
This patch:
simplify-update_times-avoid-jiffies-jiffies_64-aliasing-problem.patch
makes my x86_64 SMP box (dual-core Athlon 64 on an ULi-based AsRock mobo) run
_very_ slow (it would take tens of minutes to boot the box if I were as
patient as to wait for that).
Strangely enough, on a non-SMP box I have tested it on it works just fine.
Greetings,
Rafael
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-14 17:16 ` 2.6.18-rc4-mm1 Andrew Morton
@ 2006-08-14 18:12 ` David Howells
2006-08-14 18:17 ` 2.6.18-rc4-mm1 David Howells
2006-08-14 18:24 ` 2.6.18-rc4-mm1 Andrew Morton
0 siblings, 2 replies; 80+ messages in thread
From: David Howells @ 2006-08-14 18:12 UTC (permalink / raw)
To: Andrew Morton; +Cc: David Howells, Ian Kent, linux-kernel, Trond Myklebust
Andrew Morton <akpm@osdl.org> wrote:
> ?--------- ? ? ? ? ? /net/bix/mnt
> ?--------- ? ? ? ? ? /net/bix/usr
Do /mnt and /usr have other things mounted on them on bix? Can you dump fstab
on bix?
If so, it's possible that the server-mountpoint-crossing automounter internal
to NFS doesn't like working with autofs.
David
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-14 17:54 ` 2.6.18-rc4-mm1 Rafael J. Wysocki
@ 2006-08-14 18:15 ` Andrew Morton
2006-08-15 14:07 ` 2.6.18-rc4-mm1 Atsushi Nemoto
1 sibling, 0 replies; 80+ messages in thread
From: Andrew Morton @ 2006-08-14 18:15 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: linux-kernel, Atsushi Nemoto
On Mon, 14 Aug 2006 19:54:29 +0200
"Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> On Sunday 13 August 2006 10:24, Andrew Morton wrote:
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm1/
> >
>
> This patch:
>
> simplify-update_times-avoid-jiffies-jiffies_64-aliasing-problem.patch
>
> makes my x86_64 SMP box (dual-core Athlon 64 on an ULi-based AsRock mobo) run
> _very_ slow (it would take tens of minutes to boot the box if I were as
> patient as to wait for that).
>
> Strangely enough, on a non-SMP box I have tested it on it works just fine.
>
Thanks. I dropped a reversion patch into
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm1/hot-fixes/
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-14 18:12 ` 2.6.18-rc4-mm1 David Howells
@ 2006-08-14 18:17 ` David Howells
2006-08-14 18:24 ` 2.6.18-rc4-mm1 Andrew Morton
1 sibling, 0 replies; 80+ messages in thread
From: David Howells @ 2006-08-14 18:17 UTC (permalink / raw)
To: David Howells; +Cc: Andrew Morton, Ian Kent, linux-kernel, Trond Myklebust
David Howells <dhowells@redhat.com> wrote:
> Do /mnt and /usr have other things mounted on them on bix? Can you dump fstab
> on bix?
I don't mean fstab, I mean /proc/mounts.
David
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-14 14:02 ` 2.6.18-rc4-mm1 Michal Piotrowski
@ 2006-08-14 18:19 ` Andrew Morton
2006-08-14 19:01 ` 2.6.18-rc4-mm1 Michal Piotrowski
0 siblings, 1 reply; 80+ messages in thread
From: Andrew Morton @ 2006-08-14 18:19 UTC (permalink / raw)
To: Michal Piotrowski; +Cc: linux-kernel, john stultz, Thomas Gleixner, Ingo Molnar
On Mon, 14 Aug 2006 16:02:52 +0200
"Michal Piotrowski" <michal.k.k.piotrowski@gmail.com> wrote:
> On 13/08/06, Andrew Morton <akpm@osdl.org> wrote:
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm1/
> >
>
> Aug 14 15:35:10 ltg01-fedora kernel: BUG: unable to handle kernel
> paging request at virtual address fffeffbf
> Aug 14 15:35:10 ltg01-fedora kernel: printing eip:
> Aug 14 15:35:10 ltg01-fedora kernel: c013d539
> Aug 14 15:35:10 ltg01-fedora kernel: *pde = 00004067
> Aug 14 15:35:10 ltg01-fedora kernel: *pte = 00000000
> Aug 14 15:35:10 ltg01-fedora kernel: Oops: 0000 [#1]
> Aug 14 15:35:10 ltg01-fedora kernel: 4K_STACKS PREEMPT SMP
> Aug 14 15:35:10 ltg01-fedora kernel: last sysfs file:
> /devices/platform/i2c-9191/9191-0290/temp2_input
> Aug 14 15:35:10 ltg01-fedora kernel: Modules linked in: ipv6 w83627hf
> hwmon_vid hwmon i2c_isa af_packet ip_conntrack_netbios
> _ns ipt_REJECT xt_state ip_conntrack nfnetlink xt_tcpudp
> iptable_filter ip_tables x_tables cpufreq_userspace p4_clockmod spe
> edstep_lib binfmt_misc thermal processor fan container evdev
> snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_seq_dummy snd_seq_
> oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss
> snd_mixer_oss snd_pcm sk98lin snd_timer skge snd soundcore snd_pag
> e_alloc ide_cd intel_agp agpgart cdrom i2c_i801 rtc unix
> Aug 14 15:35:10 ltg01-fedora kernel: CPU: 1
> Aug 14 15:35:10 ltg01-fedora kernel: EIP: 0060:[<c013d539>] Not
> tainted VLI
> Aug 14 15:35:10 ltg01-fedora kernel: EFLAGS: 00210286 (2.6.18-rc4-mm1 #97)
> Aug 14 15:35:10 ltg01-fedora kernel: EIP is at futex_wake+0x9c/0xcb
> Aug 14 15:35:10 ltg01-fedora kernel: eax: 0808c000 ebx: c0670a60
> ecx: d3a1dfa2 edx: fffeffbf
> Aug 14 15:35:10 ltg01-fedora kernel: esi: 00000000 edi: fffeffbf
> ebp: f4896f64 esp: f4896f40
> Aug 14 15:35:10 ltg01-fedora kernel: ds: 007b es: 007b ss: 0068
> Aug 14 15:35:10 ltg01-fedora kernel: Process firefox-bin (pid: 2210,
> ti=f4896000 task=f3d180f0 task.ti=f4896000)
> Aug 14 15:35:10 ltg01-fedora kernel: Stack: c0670a80 00000001 0808c000
> f4302e74 00000044 ffffffe7 0808c044 bf8f35b0
> Aug 14 15:35:10 ltg01-fedora kernel: 00000000 f4896f7c c013ed39
> 00000001 0808c044 7fffffff bf8f35b0 f4896fb4
> Aug 14 15:35:10 ltg01-fedora kernel: c013ee84 7fffffff bf8f35b0
> 00000000 bf8f3528 00000000 f4896fa8 00000000
> Aug 14 15:35:10 ltg01-fedora kernel: Call Trace:
> Aug 14 15:35:10 ltg01-fedora kernel: [<c013ed39>] do_futex+0x3c/0x92
> Aug 14 15:35:10 ltg01-fedora kernel: [<c013ee84>] sys_futex+0xf5/0x101
> Aug 14 15:35:11 ltg01-fedora kernel: [<c010312d>] sysenter_past_esp+0x56/0x8d
> Aug 14 15:35:11 ltg01-fedora kernel: [<b7f1d410>] 0xb7f1d410
> Aug 14 15:35:11 ltg01-fedora kernel: [<c0103fc1>] show_trace_log_lvl+0x12/0x22
> Aug 14 15:35:11 ltg01-fedora kernel: [<c0104067>] show_stack_log_lvl+0x87/0x8f
> Aug 14 15:35:11 ltg01-fedora kernel: [<c0104203>] show_registers+0x151/0x1d8
> Aug 14 15:35:11 ltg01-fedora kernel: [<c010444d>] die+0x120/0x1f0
> Aug 14 15:35:11 ltg01-fedora kernel: [<c01185cf>] do_page_fault+0x49d/0x580
> Aug 14 15:35:11 ltg01-fedora kernel: [<c0303ba9>] error_code+0x39/0x40
> Aug 14 15:35:11 ltg01-fedora kernel: [<c013ed39>] do_futex+0x3c/0x92
> Aug 14 15:35:11 ltg01-fedora kernel: [<c013ee84>] sys_futex+0xf5/0x101
> Aug 14 15:35:11 ltg01-fedora kernel: [<c010312d>] sysenter_past_esp+0x56/0x8d
> Aug 14 15:35:11 ltg01-fedora kernel: =======================
> Aug 14 15:35:11 ltg01-fedora kernel: Code: 45 e8 39 41 04 75 22 8b 45
> ec 39 41 08 75 1a 83 7a 48 00 74 07 be ea ff ff ff eb
> 16 89 d0 46 e8 00 fd ff ff 3b 75 e0 7d 09 89 fa <8b> 3f 3b 55 dc eb c0
> 89 d8 e8 bd 60 1c 00 89 e0 25 00 f0 ff ff
> Aug 14 15:35:11 ltg01-fedora kernel: EIP: [<c013d539>]
> futex_wake+0x9c/0xcb SS:ESP 0068:f4896f40
This is worrisome. Is it reproducible? If so, reverting
futex_handle_fault-always-fails.patch and retesting would be useful.
(please kill the wordwrapping in your email client, btw).
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 2.6.18-rc4-mm1
[not found] ` <d120d5000608140643tddd9ce4o986560740ef5dbd7@mail.gmail.com>
@ 2006-08-14 18:24 ` Maciej Rutecki
0 siblings, 0 replies; 80+ messages in thread
From: Maciej Rutecki @ 2006-08-14 18:24 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 771 bytes --]
Dmitry Torokhov napisał(a):
>
> I was wrong, it is trying to detect keyboard but failing and I think I
> know why. Coud you please try sticking i8042_flush() in
> i8042_check_aux() like this for me:
>
> if (wait_for_completion_timeout(&i8042_aux_irq_delivered,
> msecs_to_jiffies(250)) == 0) {
> /*
> * AUX IRQ was never delivered so we need to flush the controller to
> * get rid of the byte we put there; otherwise keyboard may not work.
> */
> i8042_flush();
> retval = -1;
> }
>
> Thanks!
>
I changed this, and my keyboard works fine. Thanks
--
Maciej Rutecki <maciej.rutecki@gmail.com>
http://www.unixy.pl
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)
[-- Attachment #2: dmesg.gz --]
[-- Type: application/x-gzip, Size: 9678 bytes --]
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-14 18:12 ` 2.6.18-rc4-mm1 David Howells
2006-08-14 18:17 ` 2.6.18-rc4-mm1 David Howells
@ 2006-08-14 18:24 ` Andrew Morton
1 sibling, 0 replies; 80+ messages in thread
From: Andrew Morton @ 2006-08-14 18:24 UTC (permalink / raw)
To: David Howells; +Cc: Ian Kent, linux-kernel, Trond Myklebust
On Mon, 14 Aug 2006 19:12:23 +0100
David Howells <dhowells@redhat.com> wrote:
> Andrew Morton <akpm@osdl.org> wrote:
>
> > ?--------- ? ? ? ? ? /net/bix/mnt
> > ?--------- ? ? ? ? ? /net/bix/usr
>
> Do /mnt and /usr have other things mounted on them on bix?
nope.
> Can you dump fstab
> on bix?
bix:/home/akpm> cat /proc/mounts
rootfs / rootfs rw 0 0
/dev/root / ext3 rw,noatime,data=ordered 0 0
/proc /proc proc rw 0 0
none /dev/pts devpts rw 0 0
/dev/sda1 /boot ext3 rw,data=ordered 0 0
none /dev/shm tmpfs rw 0 0
/dev/sdb1 /usr/src ext3 rw,noatime,data=ordered 0 0
none /sys sysfs rw 0 0
/dev/sdb2 /mnt/export ext3 rw,noatime,data=ordered 0 0
nodev /dev/oprofile oprofilefs rw 0 0
> If so, it's possible that the server-mountpoint-crossing automounter internal
> to NFS doesn't like working with autofs.
I'd say it's something like that. Odd thing is, /mnt and /usr don't have
anything mounted on them. But they do have a local partition mounted on
subdirectories within them: /mnt/export and /usr/src.
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-13 20:39 ` 2.6.18-rc4-mm1 Andrew Morton
2006-08-14 7:58 ` 2.6.18-rc4-mm1 David Howells
2006-08-14 8:06 ` 2.6.18-rc4-mm1 Ian Kent
@ 2006-08-14 18:32 ` David Howells
2006-08-14 21:31 ` 2.6.18-rc4-mm1 Andrew Morton
2006-08-14 22:49 ` 2.6.18-rc4-mm1 Trond Myklebust
3 siblings, 1 reply; 80+ messages in thread
From: David Howells @ 2006-08-14 18:32 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, Trond Myklebust, David Howells, Ian Kent
Andrew Morton <akpm@osdl.org> wrote:
> sony:/home/akpm> showmount -e bix
> Export list for bix:
> / *
> /usr/src *
> /mnt/export *
What's in your /etc/exports file?
David
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-14 18:19 ` 2.6.18-rc4-mm1 Andrew Morton
@ 2006-08-14 19:01 ` Michal Piotrowski
2006-08-14 19:20 ` 2.6.18-rc4-mm1 john stultz
0 siblings, 1 reply; 80+ messages in thread
From: Michal Piotrowski @ 2006-08-14 19:01 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, john stultz, Thomas Gleixner, Ingo Molnar
Andrew Morton wrote:
> On Mon, 14 Aug 2006 16:02:52 +0200
> "Michal Piotrowski" <michal.k.k.piotrowski@gmail.com> wrote:
>
>> On 13/08/06, Andrew Morton <akpm@osdl.org> wrote:
>>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm1/
>>>
>> Aug 14 15:35:10 ltg01-fedora kernel: BUG: unable to handle kernel
>> paging request at virtual address fffeffbf
>> Aug 14 15:35:10 ltg01-fedora kernel: printing eip:
>> Aug 14 15:35:10 ltg01-fedora kernel: c013d539
>> Aug 14 15:35:10 ltg01-fedora kernel: *pde = 00004067
>> Aug 14 15:35:10 ltg01-fedora kernel: *pte = 00000000
>> Aug 14 15:35:10 ltg01-fedora kernel: Oops: 0000 [#1]
>> Aug 14 15:35:10 ltg01-fedora kernel: 4K_STACKS PREEMPT SMP
>> Aug 14 15:35:10 ltg01-fedora kernel: last sysfs file:
>> /devices/platform/i2c-9191/9191-0290/temp2_input
>> Aug 14 15:35:10 ltg01-fedora kernel: Modules linked in: ipv6 w83627hf
>> hwmon_vid hwmon i2c_isa af_packet ip_conntrack_netbios
>> _ns ipt_REJECT xt_state ip_conntrack nfnetlink xt_tcpudp
>> iptable_filter ip_tables x_tables cpufreq_userspace p4_clockmod spe
>> edstep_lib binfmt_misc thermal processor fan container evdev
>> snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_seq_dummy snd_seq_
>> oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss
>> snd_mixer_oss snd_pcm sk98lin snd_timer skge snd soundcore snd_pag
>> e_alloc ide_cd intel_agp agpgart cdrom i2c_i801 rtc unix
>> Aug 14 15:35:10 ltg01-fedora kernel: CPU: 1
>> Aug 14 15:35:10 ltg01-fedora kernel: EIP: 0060:[<c013d539>] Not
>> tainted VLI
>> Aug 14 15:35:10 ltg01-fedora kernel: EFLAGS: 00210286 (2.6.18-rc4-mm1 #97)
>> Aug 14 15:35:10 ltg01-fedora kernel: EIP is at futex_wake+0x9c/0xcb
>> Aug 14 15:35:10 ltg01-fedora kernel: eax: 0808c000 ebx: c0670a60
>> ecx: d3a1dfa2 edx: fffeffbf
>> Aug 14 15:35:10 ltg01-fedora kernel: esi: 00000000 edi: fffeffbf
>> ebp: f4896f64 esp: f4896f40
>> Aug 14 15:35:10 ltg01-fedora kernel: ds: 007b es: 007b ss: 0068
>> Aug 14 15:35:10 ltg01-fedora kernel: Process firefox-bin (pid: 2210,
>> ti=f4896000 task=f3d180f0 task.ti=f4896000)
>> Aug 14 15:35:10 ltg01-fedora kernel: Stack: c0670a80 00000001 0808c000
>> f4302e74 00000044 ffffffe7 0808c044 bf8f35b0
>> Aug 14 15:35:10 ltg01-fedora kernel: 00000000 f4896f7c c013ed39
>> 00000001 0808c044 7fffffff bf8f35b0 f4896fb4
>> Aug 14 15:35:10 ltg01-fedora kernel: c013ee84 7fffffff bf8f35b0
>> 00000000 bf8f3528 00000000 f4896fa8 00000000
>> Aug 14 15:35:10 ltg01-fedora kernel: Call Trace:
>> Aug 14 15:35:10 ltg01-fedora kernel: [<c013ed39>] do_futex+0x3c/0x92
>> Aug 14 15:35:10 ltg01-fedora kernel: [<c013ee84>] sys_futex+0xf5/0x101
>> Aug 14 15:35:11 ltg01-fedora kernel: [<c010312d>] sysenter_past_esp+0x56/0x8d
>> Aug 14 15:35:11 ltg01-fedora kernel: [<b7f1d410>] 0xb7f1d410
>> Aug 14 15:35:11 ltg01-fedora kernel: [<c0103fc1>] show_trace_log_lvl+0x12/0x22
>> Aug 14 15:35:11 ltg01-fedora kernel: [<c0104067>] show_stack_log_lvl+0x87/0x8f
>> Aug 14 15:35:11 ltg01-fedora kernel: [<c0104203>] show_registers+0x151/0x1d8
>> Aug 14 15:35:11 ltg01-fedora kernel: [<c010444d>] die+0x120/0x1f0
>> Aug 14 15:35:11 ltg01-fedora kernel: [<c01185cf>] do_page_fault+0x49d/0x580
>> Aug 14 15:35:11 ltg01-fedora kernel: [<c0303ba9>] error_code+0x39/0x40
>> Aug 14 15:35:11 ltg01-fedora kernel: [<c013ed39>] do_futex+0x3c/0x92
>> Aug 14 15:35:11 ltg01-fedora kernel: [<c013ee84>] sys_futex+0xf5/0x101
>> Aug 14 15:35:11 ltg01-fedora kernel: [<c010312d>] sysenter_past_esp+0x56/0x8d
>> Aug 14 15:35:11 ltg01-fedora kernel: =======================
>> Aug 14 15:35:11 ltg01-fedora kernel: Code: 45 e8 39 41 04 75 22 8b 45
>> ec 39 41 08 75 1a 83 7a 48 00 74 07 be ea ff ff ff eb
>> 16 89 d0 46 e8 00 fd ff ff 3b 75 e0 7d 09 89 fa <8b> 3f 3b 55 dc eb c0
>> 89 d8 e8 bd 60 1c 00 89 e0 25 00 f0 ff ff
>> Aug 14 15:35:11 ltg01-fedora kernel: EIP: [<c013d539>]
>> futex_wake+0x9c/0xcb SS:ESP 0068:f4896f40
>
> This is worrisome. Is it reproducible?
I don't know how to reproduce it, but it happened second time today.
> If so, reverting
> futex_handle_fault-always-fails.patch and retesting would be useful.
I reverted this patch.
>
> (please kill the wordwrapping in your email client, btw).
>
>
>
Regards,
Michal
--
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-14 19:01 ` 2.6.18-rc4-mm1 Michal Piotrowski
@ 2006-08-14 19:20 ` john stultz
2006-08-14 19:27 ` 2.6.18-rc4-mm1 Michal Piotrowski
0 siblings, 1 reply; 80+ messages in thread
From: john stultz @ 2006-08-14 19:20 UTC (permalink / raw)
To: Michal Piotrowski
Cc: Andrew Morton, linux-kernel, Thomas Gleixner, Ingo Molnar,
Dinakar Guniguntala
On Mon, 2006-08-14 at 21:01 +0200, Michal Piotrowski wrote:
> Andrew Morton wrote:
> > On Mon, 14 Aug 2006 16:02:52 +0200
> > "Michal Piotrowski" <michal.k.k.piotrowski@gmail.com> wrote:
> >> On 13/08/06, Andrew Morton <akpm@osdl.org> wrote:
> >>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm1/
> >>>
> >> Aug 14 15:35:10 ltg01-fedora kernel: BUG: unable to handle kernel
> >> paging request at virtual address fffeffbf
> >> Aug 14 15:35:10 ltg01-fedora kernel: printing eip:
> >> Aug 14 15:35:10 ltg01-fedora kernel: c013d539
> >> Aug 14 15:35:10 ltg01-fedora kernel: *pde = 00004067
> >> Aug 14 15:35:10 ltg01-fedora kernel: *pte = 00000000
> >> Aug 14 15:35:10 ltg01-fedora kernel: Oops: 0000 [#1]
> >> Aug 14 15:35:10 ltg01-fedora kernel: 4K_STACKS PREEMPT SMP
> >> Aug 14 15:35:10 ltg01-fedora kernel: last sysfs file:
> >> /devices/platform/i2c-9191/9191-0290/temp2_input
> >> Aug 14 15:35:10 ltg01-fedora kernel: Modules linked in: ipv6 w83627hf
> >> hwmon_vid hwmon i2c_isa af_packet ip_conntrack_netbios
> >> _ns ipt_REJECT xt_state ip_conntrack nfnetlink xt_tcpudp
> >> iptable_filter ip_tables x_tables cpufreq_userspace p4_clockmod spe
> >> edstep_lib binfmt_misc thermal processor fan container evdev
> >> snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_seq_dummy snd_seq_
> >> oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss
> >> snd_mixer_oss snd_pcm sk98lin snd_timer skge snd soundcore snd_pag
> >> e_alloc ide_cd intel_agp agpgart cdrom i2c_i801 rtc unix
> >> Aug 14 15:35:10 ltg01-fedora kernel: CPU: 1
> >> Aug 14 15:35:10 ltg01-fedora kernel: EIP: 0060:[<c013d539>] Not
> >> tainted VLI
> >> Aug 14 15:35:10 ltg01-fedora kernel: EFLAGS: 00210286 (2.6.18-rc4-mm1 #97)
> >> Aug 14 15:35:10 ltg01-fedora kernel: EIP is at futex_wake+0x9c/0xcb
> >> Aug 14 15:35:10 ltg01-fedora kernel: eax: 0808c000 ebx: c0670a60
> >> ecx: d3a1dfa2 edx: fffeffbf
> >> Aug 14 15:35:10 ltg01-fedora kernel: esi: 00000000 edi: fffeffbf
> >> ebp: f4896f64 esp: f4896f40
> >> Aug 14 15:35:10 ltg01-fedora kernel: ds: 007b es: 007b ss: 0068
> >> Aug 14 15:35:10 ltg01-fedora kernel: Process firefox-bin (pid: 2210,
> >> ti=f4896000 task=f3d180f0 task.ti=f4896000)
> >> Aug 14 15:35:10 ltg01-fedora kernel: Stack: c0670a80 00000001 0808c000
> >> f4302e74 00000044 ffffffe7 0808c044 bf8f35b0
> >> Aug 14 15:35:10 ltg01-fedora kernel: 00000000 f4896f7c c013ed39
> >> 00000001 0808c044 7fffffff bf8f35b0 f4896fb4
> >> Aug 14 15:35:10 ltg01-fedora kernel: c013ee84 7fffffff bf8f35b0
> >> 00000000 bf8f3528 00000000 f4896fa8 00000000
> >> Aug 14 15:35:10 ltg01-fedora kernel: Call Trace:
> >> Aug 14 15:35:10 ltg01-fedora kernel: [<c013ed39>] do_futex+0x3c/0x92
> >> Aug 14 15:35:10 ltg01-fedora kernel: [<c013ee84>] sys_futex+0xf5/0x101
> >> Aug 14 15:35:11 ltg01-fedora kernel: [<c010312d>] sysenter_past_esp+0x56/0x8d
> >> Aug 14 15:35:11 ltg01-fedora kernel: [<b7f1d410>] 0xb7f1d410
> >> Aug 14 15:35:11 ltg01-fedora kernel: [<c0103fc1>] show_trace_log_lvl+0x12/0x22
> >> Aug 14 15:35:11 ltg01-fedora kernel: [<c0104067>] show_stack_log_lvl+0x87/0x8f
> >> Aug 14 15:35:11 ltg01-fedora kernel: [<c0104203>] show_registers+0x151/0x1d8
> >> Aug 14 15:35:11 ltg01-fedora kernel: [<c010444d>] die+0x120/0x1f0
> >> Aug 14 15:35:11 ltg01-fedora kernel: [<c01185cf>] do_page_fault+0x49d/0x580
> >> Aug 14 15:35:11 ltg01-fedora kernel: [<c0303ba9>] error_code+0x39/0x40
> >> Aug 14 15:35:11 ltg01-fedora kernel: [<c013ed39>] do_futex+0x3c/0x92
> >> Aug 14 15:35:11 ltg01-fedora kernel: [<c013ee84>] sys_futex+0xf5/0x101
> >> Aug 14 15:35:11 ltg01-fedora kernel: [<c010312d>] sysenter_past_esp+0x56/0x8d
> >> Aug 14 15:35:11 ltg01-fedora kernel: =======================
> >> Aug 14 15:35:11 ltg01-fedora kernel: Code: 45 e8 39 41 04 75 22 8b 45
> >> ec 39 41 08 75 1a 83 7a 48 00 74 07 be ea ff ff ff eb
> >> 16 89 d0 46 e8 00 fd ff ff 3b 75 e0 7d 09 89 fa <8b> 3f 3b 55 dc eb c0
> >> 89 d8 e8 bd 60 1c 00 89 e0 25 00 f0 ff ff
> >> Aug 14 15:35:11 ltg01-fedora kernel: EIP: [<c013d539>]
> >> futex_wake+0x9c/0xcb SS:ESP 0068:f4896f40
> >
> > This is worrisome. Is it reproducible?
>
> I don't know how to reproduce it, but it happened second time today.
>
> > If so, reverting
> > futex_handle_fault-always-fails.patch and retesting would be useful.
>
> I reverted this patch.
Just to be clear, the issue has shown itself without the patch? Or is
that not the case?
thanks
-john
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-14 19:20 ` 2.6.18-rc4-mm1 john stultz
@ 2006-08-14 19:27 ` Michal Piotrowski
2006-08-14 19:44 ` 2.6.18-rc4-mm1 john stultz
0 siblings, 1 reply; 80+ messages in thread
From: Michal Piotrowski @ 2006-08-14 19:27 UTC (permalink / raw)
To: john stultz
Cc: Andrew Morton, linux-kernel, Thomas Gleixner, Ingo Molnar,
Dinakar Guniguntala
On 14/08/06, john stultz <johnstul@us.ibm.com> wrote:
> On Mon, 2006-08-14 at 21:01 +0200, Michal Piotrowski wrote:
> > Andrew Morton wrote:
> > > On Mon, 14 Aug 2006 16:02:52 +0200
> > > "Michal Piotrowski" <michal.k.k.piotrowski@gmail.com> wrote:
> > >> On 13/08/06, Andrew Morton <akpm@osdl.org> wrote:
> > >>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm1/
> > >>>
> > >> Aug 14 15:35:10 ltg01-fedora kernel: BUG: unable to handle kernel
> > >> paging request at virtual address fffeffbf
> > >> Aug 14 15:35:10 ltg01-fedora kernel: printing eip:
> > >> Aug 14 15:35:10 ltg01-fedora kernel: c013d539
> > >> Aug 14 15:35:10 ltg01-fedora kernel: *pde = 00004067
> > >> Aug 14 15:35:10 ltg01-fedora kernel: *pte = 00000000
> > >> Aug 14 15:35:10 ltg01-fedora kernel: Oops: 0000 [#1]
> > >> Aug 14 15:35:10 ltg01-fedora kernel: 4K_STACKS PREEMPT SMP
> > >> Aug 14 15:35:10 ltg01-fedora kernel: last sysfs file:
> > >> /devices/platform/i2c-9191/9191-0290/temp2_input
> > >> Aug 14 15:35:10 ltg01-fedora kernel: Modules linked in: ipv6 w83627hf
> > >> hwmon_vid hwmon i2c_isa af_packet ip_conntrack_netbios
> > >> _ns ipt_REJECT xt_state ip_conntrack nfnetlink xt_tcpudp
> > >> iptable_filter ip_tables x_tables cpufreq_userspace p4_clockmod spe
> > >> edstep_lib binfmt_misc thermal processor fan container evdev
> > >> snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_seq_dummy snd_seq_
> > >> oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss
> > >> snd_mixer_oss snd_pcm sk98lin snd_timer skge snd soundcore snd_pag
> > >> e_alloc ide_cd intel_agp agpgart cdrom i2c_i801 rtc unix
> > >> Aug 14 15:35:10 ltg01-fedora kernel: CPU: 1
> > >> Aug 14 15:35:10 ltg01-fedora kernel: EIP: 0060:[<c013d539>] Not
> > >> tainted VLI
> > >> Aug 14 15:35:10 ltg01-fedora kernel: EFLAGS: 00210286 (2.6.18-rc4-mm1 #97)
> > >> Aug 14 15:35:10 ltg01-fedora kernel: EIP is at futex_wake+0x9c/0xcb
> > >> Aug 14 15:35:10 ltg01-fedora kernel: eax: 0808c000 ebx: c0670a60
> > >> ecx: d3a1dfa2 edx: fffeffbf
> > >> Aug 14 15:35:10 ltg01-fedora kernel: esi: 00000000 edi: fffeffbf
> > >> ebp: f4896f64 esp: f4896f40
> > >> Aug 14 15:35:10 ltg01-fedora kernel: ds: 007b es: 007b ss: 0068
> > >> Aug 14 15:35:10 ltg01-fedora kernel: Process firefox-bin (pid: 2210,
> > >> ti=f4896000 task=f3d180f0 task.ti=f4896000)
> > >> Aug 14 15:35:10 ltg01-fedora kernel: Stack: c0670a80 00000001 0808c000
> > >> f4302e74 00000044 ffffffe7 0808c044 bf8f35b0
> > >> Aug 14 15:35:10 ltg01-fedora kernel: 00000000 f4896f7c c013ed39
> > >> 00000001 0808c044 7fffffff bf8f35b0 f4896fb4
> > >> Aug 14 15:35:10 ltg01-fedora kernel: c013ee84 7fffffff bf8f35b0
> > >> 00000000 bf8f3528 00000000 f4896fa8 00000000
> > >> Aug 14 15:35:10 ltg01-fedora kernel: Call Trace:
> > >> Aug 14 15:35:10 ltg01-fedora kernel: [<c013ed39>] do_futex+0x3c/0x92
> > >> Aug 14 15:35:10 ltg01-fedora kernel: [<c013ee84>] sys_futex+0xf5/0x101
> > >> Aug 14 15:35:11 ltg01-fedora kernel: [<c010312d>] sysenter_past_esp+0x56/0x8d
> > >> Aug 14 15:35:11 ltg01-fedora kernel: [<b7f1d410>] 0xb7f1d410
> > >> Aug 14 15:35:11 ltg01-fedora kernel: [<c0103fc1>] show_trace_log_lvl+0x12/0x22
> > >> Aug 14 15:35:11 ltg01-fedora kernel: [<c0104067>] show_stack_log_lvl+0x87/0x8f
> > >> Aug 14 15:35:11 ltg01-fedora kernel: [<c0104203>] show_registers+0x151/0x1d8
> > >> Aug 14 15:35:11 ltg01-fedora kernel: [<c010444d>] die+0x120/0x1f0
> > >> Aug 14 15:35:11 ltg01-fedora kernel: [<c01185cf>] do_page_fault+0x49d/0x580
> > >> Aug 14 15:35:11 ltg01-fedora kernel: [<c0303ba9>] error_code+0x39/0x40
> > >> Aug 14 15:35:11 ltg01-fedora kernel: [<c013ed39>] do_futex+0x3c/0x92
> > >> Aug 14 15:35:11 ltg01-fedora kernel: [<c013ee84>] sys_futex+0xf5/0x101
> > >> Aug 14 15:35:11 ltg01-fedora kernel: [<c010312d>] sysenter_past_esp+0x56/0x8d
> > >> Aug 14 15:35:11 ltg01-fedora kernel: =======================
> > >> Aug 14 15:35:11 ltg01-fedora kernel: Code: 45 e8 39 41 04 75 22 8b 45
> > >> ec 39 41 08 75 1a 83 7a 48 00 74 07 be ea ff ff ff eb
> > >> 16 89 d0 46 e8 00 fd ff ff 3b 75 e0 7d 09 89 fa <8b> 3f 3b 55 dc eb c0
> > >> 89 d8 e8 bd 60 1c 00 89 e0 25 00 f0 ff ff
> > >> Aug 14 15:35:11 ltg01-fedora kernel: EIP: [<c013d539>]
> > >> futex_wake+0x9c/0xcb SS:ESP 0068:f4896f40
> > >
> > > This is worrisome. Is it reproducible?
> >
> > I don't know how to reproduce it, but it happened second time today.
> >
> > > If so, reverting
> > > futex_handle_fault-always-fails.patch and retesting would be useful.
> >
> > I reverted this patch.
>
> Just to be clear, the issue has shown itself without the patch?
No, it hasn't.
> Or is
> that not the case?
In current -mm only futex_handle_fault-always-fails.patch changes
kernel/futex.c, so IMHO it's very probable that there is something
wrong with this patch.
>
> thanks
> -john
Regards,
Michal
--
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-14 19:27 ` 2.6.18-rc4-mm1 Michal Piotrowski
@ 2006-08-14 19:44 ` john stultz
2006-08-14 20:48 ` 2.6.18-rc4-mm1 Michal Piotrowski
0 siblings, 1 reply; 80+ messages in thread
From: john stultz @ 2006-08-14 19:44 UTC (permalink / raw)
To: Michal Piotrowski
Cc: Andrew Morton, linux-kernel, Thomas Gleixner, Ingo Molnar,
Dinakar Guniguntala
On Mon, 2006-08-14 at 21:27 +0200, Michal Piotrowski wrote:
> On 14/08/06, john stultz <johnstul@us.ibm.com> wrote:
> > On Mon, 2006-08-14 at 21:01 +0200, Michal Piotrowski wrote:
> > > Andrew Morton wrote:
> > > > On Mon, 14 Aug 2006 16:02:52 +0200
> > > > "Michal Piotrowski" <michal.k.k.piotrowski@gmail.com> wrote:
> > > >> On 13/08/06, Andrew Morton <akpm@osdl.org> wrote:
> > > >>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm1/
> > > >>>
> > > >> Aug 14 15:35:10 ltg01-fedora kernel: BUG: unable to handle kernel
> > > >> paging request at virtual address fffeffbf
> > > >> Aug 14 15:35:10 ltg01-fedora kernel: printing eip:
> > > >> Aug 14 15:35:10 ltg01-fedora kernel: c013d539
> > > >> Aug 14 15:35:10 ltg01-fedora kernel: *pde = 00004067
> > > >> Aug 14 15:35:10 ltg01-fedora kernel: *pte = 00000000
> > > >> Aug 14 15:35:10 ltg01-fedora kernel: Oops: 0000 [#1]
> > > >> Aug 14 15:35:10 ltg01-fedora kernel: 4K_STACKS PREEMPT SMP
> > > >> Aug 14 15:35:10 ltg01-fedora kernel: last sysfs file:
> > > >> /devices/platform/i2c-9191/9191-0290/temp2_input
> > > >> Aug 14 15:35:10 ltg01-fedora kernel: Modules linked in: ipv6 w83627hf
> > > >> hwmon_vid hwmon i2c_isa af_packet ip_conntrack_netbios
> > > >> _ns ipt_REJECT xt_state ip_conntrack nfnetlink xt_tcpudp
> > > >> iptable_filter ip_tables x_tables cpufreq_userspace p4_clockmod spe
> > > >> edstep_lib binfmt_misc thermal processor fan container evdev
> > > >> snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_seq_dummy snd_seq_
> > > >> oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss
> > > >> snd_mixer_oss snd_pcm sk98lin snd_timer skge snd soundcore snd_pag
> > > >> e_alloc ide_cd intel_agp agpgart cdrom i2c_i801 rtc unix
> > > >> Aug 14 15:35:10 ltg01-fedora kernel: CPU: 1
> > > >> Aug 14 15:35:10 ltg01-fedora kernel: EIP: 0060:[<c013d539>] Not
> > > >> tainted VLI
> > > >> Aug 14 15:35:10 ltg01-fedora kernel: EFLAGS: 00210286 (2.6.18-rc4-mm1 #97)
> > > >> Aug 14 15:35:10 ltg01-fedora kernel: EIP is at futex_wake+0x9c/0xcb
> > > >> Aug 14 15:35:10 ltg01-fedora kernel: eax: 0808c000 ebx: c0670a60
> > > >> ecx: d3a1dfa2 edx: fffeffbf
> > > >> Aug 14 15:35:10 ltg01-fedora kernel: esi: 00000000 edi: fffeffbf
> > > >> ebp: f4896f64 esp: f4896f40
> > > >> Aug 14 15:35:10 ltg01-fedora kernel: ds: 007b es: 007b ss: 0068
> > > >> Aug 14 15:35:10 ltg01-fedora kernel: Process firefox-bin (pid: 2210,
> > > >> ti=f4896000 task=f3d180f0 task.ti=f4896000)
> > > >> Aug 14 15:35:10 ltg01-fedora kernel: Stack: c0670a80 00000001 0808c000
> > > >> f4302e74 00000044 ffffffe7 0808c044 bf8f35b0
> > > >> Aug 14 15:35:10 ltg01-fedora kernel: 00000000 f4896f7c c013ed39
> > > >> 00000001 0808c044 7fffffff bf8f35b0 f4896fb4
> > > >> Aug 14 15:35:10 ltg01-fedora kernel: c013ee84 7fffffff bf8f35b0
> > > >> 00000000 bf8f3528 00000000 f4896fa8 00000000
> > > >> Aug 14 15:35:10 ltg01-fedora kernel: Call Trace:
> > > >> Aug 14 15:35:10 ltg01-fedora kernel: [<c013ed39>] do_futex+0x3c/0x92
> > > >> Aug 14 15:35:10 ltg01-fedora kernel: [<c013ee84>] sys_futex+0xf5/0x101
> > > >> Aug 14 15:35:11 ltg01-fedora kernel: [<c010312d>] sysenter_past_esp+0x56/0x8d
> > > >> Aug 14 15:35:11 ltg01-fedora kernel: [<b7f1d410>] 0xb7f1d410
> > > >> Aug 14 15:35:11 ltg01-fedora kernel: [<c0103fc1>] show_trace_log_lvl+0x12/0x22
> > > >> Aug 14 15:35:11 ltg01-fedora kernel: [<c0104067>] show_stack_log_lvl+0x87/0x8f
> > > >> Aug 14 15:35:11 ltg01-fedora kernel: [<c0104203>] show_registers+0x151/0x1d8
> > > >> Aug 14 15:35:11 ltg01-fedora kernel: [<c010444d>] die+0x120/0x1f0
> > > >> Aug 14 15:35:11 ltg01-fedora kernel: [<c01185cf>] do_page_fault+0x49d/0x580
> > > >> Aug 14 15:35:11 ltg01-fedora kernel: [<c0303ba9>] error_code+0x39/0x40
> > > >> Aug 14 15:35:11 ltg01-fedora kernel: [<c013ed39>] do_futex+0x3c/0x92
> > > >> Aug 14 15:35:11 ltg01-fedora kernel: [<c013ee84>] sys_futex+0xf5/0x101
> > > >> Aug 14 15:35:11 ltg01-fedora kernel: [<c010312d>] sysenter_past_esp+0x56/0x8d
> > > >> Aug 14 15:35:11 ltg01-fedora kernel: =======================
> > > >> Aug 14 15:35:11 ltg01-fedora kernel: Code: 45 e8 39 41 04 75 22 8b 45
> > > >> ec 39 41 08 75 1a 83 7a 48 00 74 07 be ea ff ff ff eb
> > > >> 16 89 d0 46 e8 00 fd ff ff 3b 75 e0 7d 09 89 fa <8b> 3f 3b 55 dc eb c0
> > > >> 89 d8 e8 bd 60 1c 00 89 e0 25 00 f0 ff ff
> > > >> Aug 14 15:35:11 ltg01-fedora kernel: EIP: [<c013d539>]
> > > >> futex_wake+0x9c/0xcb SS:ESP 0068:f4896f40
> > > >
> > > > This is worrisome. Is it reproducible?
> > >
> > > I don't know how to reproduce it, but it happened second time today.
> > >
> > > > If so, reverting
> > > > futex_handle_fault-always-fails.patch and retesting would be useful.
> > >
> > > I reverted this patch.
> >
> > Just to be clear, the issue has shown itself without the patch?
>
> No, it hasn't.
Thanks for the clarification.
> > Or is
> > that not the case?
>
> In current -mm only futex_handle_fault-always-fails.patch changes
> kernel/futex.c, so IMHO it's very probable that there is something
> wrong with this patch.
Yea, I'd believe that. I'm newish to the futex code, and as I said w/
the patch I'm not 100% sure its the right fix, but it does resolve an
issue we found.
I'll take another look to see if I futzed something up or if the fix is
just incomplete, although some more familiar eyes with the code would
probably help here.
thanks
-john
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-14 11:55 ` 2.6.18-rc4-mm1 Ben Buxton
@ 2006-08-14 20:20 ` Dave Jones
2006-08-14 21:13 ` 2.6.18-rc4-mm1 Ben B
2006-08-14 21:46 ` 2.6.18-rc4-mm1 Andrew Morton
0 siblings, 2 replies; 80+ messages in thread
From: Dave Jones @ 2006-08-14 20:20 UTC (permalink / raw)
To: Ben Buxton; +Cc: Andrew Morton, Maciej Rutecki, linux-kernel
On Mon, Aug 14, 2006 at 01:55:56PM +0200, Ben Buxton wrote:
> > > Also, whenever I echo anything to "scaling_governor", I get the
> > > following kernel message:
> > >
> > > [ 734.156000] BUG: warning at kernel/cpu.c:38/lock_cpu_hotplug()
> > > [ 734.156000] [<c013c3ec>] lock_cpu_hotplug+0x7c/0x90
> > > [ 734.156000] [<c01327f4>] __create_workqueue+0x44/0x140
> > > [ 734.156000] [<c02dcf7b>] mutex_lock+0xb/0x20
> > > [ 734.156000] [<e01f2665>] cpufreq_governor_dbs+0x2b5/0x310 [cpufreq_ondemand]
> >
> > This makes no sense at all, because in -mm __create_workqueue doesn't
> > call lock_cpu_hotplug().
> >
> > Are you sure this was from a tree with -mm1 applied ?
>
> Definitely 2.6.18-rc4-mm1, and I've done a clean rebuild + removal of
> all modules under /lib/modules beforehand.
It's a real mystery. Andrew ?
Dave
--
http://www.codemonkey.org.uk
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-14 19:44 ` 2.6.18-rc4-mm1 john stultz
@ 2006-08-14 20:48 ` Michal Piotrowski
2006-08-14 20:56 ` 2.6.18-rc4-mm1 Dave Jones
0 siblings, 1 reply; 80+ messages in thread
From: Michal Piotrowski @ 2006-08-14 20:48 UTC (permalink / raw)
To: john stultz
Cc: Andrew Morton, linux-kernel, Thomas Gleixner, Ingo Molnar,
Dinakar Guniguntala, Dave Jones
john stultz wrote:
> On Mon, 2006-08-14 at 21:27 +0200, Michal Piotrowski wrote:
>> On 14/08/06, john stultz <johnstul@us.ibm.com> wrote:
>>> On Mon, 2006-08-14 at 21:01 +0200, Michal Piotrowski wrote:
>>>> Andrew Morton wrote:
>>>>> On Mon, 14 Aug 2006 16:02:52 +0200
>>>>> "Michal Piotrowski" <michal.k.k.piotrowski@gmail.com> wrote:
>>>>>> On 13/08/06, Andrew Morton <akpm@osdl.org> wrote:
>>>>>>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm1/
>>>>>>>
>>>>>> Aug 14 15:35:10 ltg01-fedora kernel: BUG: unable to handle kernel
>>>>>> paging request at virtual address fffeffbf
>>>>>> Aug 14 15:35:10 ltg01-fedora kernel: printing eip:
>>>>>> Aug 14 15:35:10 ltg01-fedora kernel: c013d539
>>>>>> Aug 14 15:35:10 ltg01-fedora kernel: *pde = 00004067
>>>>>> Aug 14 15:35:10 ltg01-fedora kernel: *pte = 00000000
>>>>>> Aug 14 15:35:10 ltg01-fedora kernel: Oops: 0000 [#1]
>>>>>> Aug 14 15:35:10 ltg01-fedora kernel: 4K_STACKS PREEMPT SMP
>>>>>> Aug 14 15:35:10 ltg01-fedora kernel: last sysfs file:
>>>>>> /devices/platform/i2c-9191/9191-0290/temp2_input
>>>>>> Aug 14 15:35:10 ltg01-fedora kernel: Modules linked in: ipv6 w83627hf
>>>>>> hwmon_vid hwmon i2c_isa af_packet ip_conntrack_netbios
>>>>>> _ns ipt_REJECT xt_state ip_conntrack nfnetlink xt_tcpudp
>>>>>> iptable_filter ip_tables x_tables cpufreq_userspace p4_clockmod spe
>>>>>> edstep_lib binfmt_misc thermal processor fan container evdev
>>>>>> snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_seq_dummy snd_seq_
>>>>>> oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss
>>>>>> snd_mixer_oss snd_pcm sk98lin snd_timer skge snd soundcore snd_pag
>>>>>> e_alloc ide_cd intel_agp agpgart cdrom i2c_i801 rtc unix
>>>>>> Aug 14 15:35:10 ltg01-fedora kernel: CPU: 1
>>>>>> Aug 14 15:35:10 ltg01-fedora kernel: EIP: 0060:[<c013d539>] Not
>>>>>> tainted VLI
>>>>>> Aug 14 15:35:10 ltg01-fedora kernel: EFLAGS: 00210286 (2.6.18-rc4-mm1 #97)
>>>>>> Aug 14 15:35:10 ltg01-fedora kernel: EIP is at futex_wake+0x9c/0xcb
>>>>>> Aug 14 15:35:10 ltg01-fedora kernel: eax: 0808c000 ebx: c0670a60
>>>>>> ecx: d3a1dfa2 edx: fffeffbf
>>>>>> Aug 14 15:35:10 ltg01-fedora kernel: esi: 00000000 edi: fffeffbf
>>>>>> ebp: f4896f64 esp: f4896f40
>>>>>> Aug 14 15:35:10 ltg01-fedora kernel: ds: 007b es: 007b ss: 0068
>>>>>> Aug 14 15:35:10 ltg01-fedora kernel: Process firefox-bin (pid: 2210,
>>>>>> ti=f4896000 task=f3d180f0 task.ti=f4896000)
>>>>>> Aug 14 15:35:10 ltg01-fedora kernel: Stack: c0670a80 00000001 0808c000
>>>>>> f4302e74 00000044 ffffffe7 0808c044 bf8f35b0
>>>>>> Aug 14 15:35:10 ltg01-fedora kernel: 00000000 f4896f7c c013ed39
>>>>>> 00000001 0808c044 7fffffff bf8f35b0 f4896fb4
>>>>>> Aug 14 15:35:10 ltg01-fedora kernel: c013ee84 7fffffff bf8f35b0
>>>>>> 00000000 bf8f3528 00000000 f4896fa8 00000000
>>>>>> Aug 14 15:35:10 ltg01-fedora kernel: Call Trace:
>>>>>> Aug 14 15:35:10 ltg01-fedora kernel: [<c013ed39>] do_futex+0x3c/0x92
>>>>>> Aug 14 15:35:10 ltg01-fedora kernel: [<c013ee84>] sys_futex+0xf5/0x101
>>>>>> Aug 14 15:35:11 ltg01-fedora kernel: [<c010312d>] sysenter_past_esp+0x56/0x8d
>>>>>> Aug 14 15:35:11 ltg01-fedora kernel: [<b7f1d410>] 0xb7f1d410
>>>>>> Aug 14 15:35:11 ltg01-fedora kernel: [<c0103fc1>] show_trace_log_lvl+0x12/0x22
>>>>>> Aug 14 15:35:11 ltg01-fedora kernel: [<c0104067>] show_stack_log_lvl+0x87/0x8f
>>>>>> Aug 14 15:35:11 ltg01-fedora kernel: [<c0104203>] show_registers+0x151/0x1d8
>>>>>> Aug 14 15:35:11 ltg01-fedora kernel: [<c010444d>] die+0x120/0x1f0
>>>>>> Aug 14 15:35:11 ltg01-fedora kernel: [<c01185cf>] do_page_fault+0x49d/0x580
>>>>>> Aug 14 15:35:11 ltg01-fedora kernel: [<c0303ba9>] error_code+0x39/0x40
>>>>>> Aug 14 15:35:11 ltg01-fedora kernel: [<c013ed39>] do_futex+0x3c/0x92
>>>>>> Aug 14 15:35:11 ltg01-fedora kernel: [<c013ee84>] sys_futex+0xf5/0x101
>>>>>> Aug 14 15:35:11 ltg01-fedora kernel: [<c010312d>] sysenter_past_esp+0x56/0x8d
>>>>>> Aug 14 15:35:11 ltg01-fedora kernel: =======================
>>>>>> Aug 14 15:35:11 ltg01-fedora kernel: Code: 45 e8 39 41 04 75 22 8b 45
>>>>>> ec 39 41 08 75 1a 83 7a 48 00 74 07 be ea ff ff ff eb
>>>>>> 16 89 d0 46 e8 00 fd ff ff 3b 75 e0 7d 09 89 fa <8b> 3f 3b 55 dc eb c0
>>>>>> 89 d8 e8 bd 60 1c 00 89 e0 25 00 f0 ff ff
>>>>>> Aug 14 15:35:11 ltg01-fedora kernel: EIP: [<c013d539>]
>>>>>> futex_wake+0x9c/0xcb SS:ESP 0068:f4896f40
>>>>> This is worrisome. Is it reproducible?
>>>> I don't know how to reproduce it, but it happened second time today.
>>>>
>>>>> If so, reverting
>>>>> futex_handle_fault-always-fails.patch and retesting would be useful.
>>>> I reverted this patch.
>>> Just to be clear, the issue has shown itself without the patch?
>> No, it hasn't.
>
> Thanks for the clarification.
>
>>> Or is
>>> that not the case?
>> In current -mm only futex_handle_fault-always-fails.patch changes
>> kernel/futex.c, so IMHO it's very probable that there is something
>> wrong with this patch.
>
> Yea, I'd believe that. I'm newish to the futex code, and as I said w/
> the patch I'm not 100% sure its the right fix, but it does resolve an
> issue we found.
>
> I'll take another look to see if I futzed something up or if the fix is
> just incomplete, although some more familiar eyes with the code would
> probably help here.
>
Hmmm... It looks a bit different without futex_handle_fault-always-fails.patch
Aug 14 22:30:09 ltg01-fedora kernel: general protection fault: 0000 [#1]
Aug 14 22:30:09 ltg01-fedora kernel: 4K_STACKS PREEMPT SMP
Aug 14 22:30:09 ltg01-fedora kernel: last sysfs file: /devices/platform/i2c-9191/9191-0290/temp2_input
Aug 14 22:30:09 ltg01-fedora kernel: Modules linked in: ipv6 w83627hf hwmon_vid hwmon i2c_isa af_packet ip_conntrack_netbios
_ns ipt_REJECT xt_state ip_conntrack nfnetlink xt_tcpudp iptable_filter ip_tables x_tables cpufreq_userspace p4_clockmod spe
edstep_lib binfmt_misc thermal processor fan container evdev snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_seq_dummy snd_seq_
oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm sk98lin skge snd_timer snd soundcore snd_pag
e_alloc ide_cd i2c_i801 intel_agp agpgart cdrom rtc unix
Aug 14 22:30:09 ltg01-fedora kernel: CPU: 0
Aug 14 22:30:09 ltg01-fedora kernel: EIP: 0060:[<c0205249>] Not tainted VLI
Aug 14 22:30:09 ltg01-fedora kernel: EFLAGS: 00010246 (2.6.18-rc4-mm1 #101)
Aug 14 22:30:09 ltg01-fedora kernel: EIP is at __list_add+0x3d/0x7a
Aug 14 22:30:09 ltg01-fedora kernel: eax: 00000000 ebx: c0670a80 ecx: c038d4dc edx: 00000000
Aug 14 22:30:09 ltg01-fedora kernel: esi: ffffffff edi: f50ebee8 ebp: f50ebed0 esp: f50ebec4
Aug 14 22:30:09 ltg01-fedora kernel: ds: 007b es: 007b ss: 0068
Aug 14 22:30:09 ltg01-fedora kernel: Process thunderbird-bin (pid: 2288, ti=f50eb000 task=c75b9260 task.ti=f50eb000)
Aug 14 22:30:09 ltg01-fedora kernel: Stack: f50ebee8 080e7dc0 c0670a60 f50ebf64 c013de71 00000001 c75b9260 0000ea6b
Aug 14 22:30:10 ltg01-fedora kernel: 00000001 f50ebf20 c013adf0 00000001 00000000 dead4ead ffffffff ffffffff
Aug 14 22:30:10 ltg01-fedora kernel: c75b9260 00000000 00000000 f50ebf10 f50ebf10 c0670a60 080e7000 f3e65c94
Aug 14 22:30:10 ltg01-fedora kernel: Call Trace:
Aug 14 22:30:10 ltg01-fedora kernel: [<c013de71>] futex_wait+0x15c/0x220
Aug 14 22:30:10 ltg01-fedora kernel: [<c013ed17>] do_futex+0x33/0x92
Aug 14 22:30:10 ltg01-fedora kernel: [<c013ee6b>] sys_futex+0xf5/0x101
Aug 14 22:30:10 ltg01-fedora kernel: [<c010312d>] sysenter_past_esp+0x56/0x8d
Aug 14 22:30:10 ltg01-fedora kernel: [<b7f12410>] 0xb7f12410
Aug 14 22:30:10 ltg01-fedora kernel: [<c0103fc1>] show_trace_log_lvl+0x12/0x22
Aug 14 22:30:10 ltg01-fedora kernel: [<c0104067>] show_stack_log_lvl+0x87/0x8f
Aug 14 22:30:10 ltg01-fedora kernel: [<c0104203>] show_registers+0x151/0x1d8
Aug 14 22:30:10 ltg01-fedora kernel: [<c010444d>] die+0x120/0x1f0
Aug 14 22:30:10 ltg01-fedora kernel: [<c0104c9f>] do_general_protection+0x1d1/0x1d9
Aug 14 22:30:10 ltg01-fedora kernel: [<c0303b89>] error_code+0x39/0x40
Aug 14 22:30:10 ltg01-fedora kernel: [<c013de71>] futex_wait+0x15c/0x220
Aug 14 22:30:10 ltg01-fedora kernel: [<c013ed17>] do_futex+0x33/0x92
Aug 14 22:30:10 ltg01-fedora kernel: [<c013ee6b>] sys_futex+0xf5/0x101
Aug 14 22:30:10 ltg01-fedora kernel: [<c010312d>] sysenter_past_esp+0x56/0x8d
Aug 14 22:30:10 ltg01-fedora kernel: =======================
Aug 14 22:30:10 ltg01-fedora kernel: Code: cb 39 71 04 0f 95 c2 e8 12 0f 00 00 85 c0 74 19 ff 73 04 56 68 a1 89 33 c0 e8 97
ce f1 ff 0f 0b 1a 00 7e 89 33 c0 83 c4 0c 31 d2 <39> 1e b8 f8 d4 38 c0 0f 95 c2 e8 e4 0e 00 00 85 c0 74 18 ff 36
Aug 14 22:30:10 ltg01-fedora kernel: EIP: [<c0205249>] __list_add+0x3d/0x7a SS:ESP 0068:f50ebec4
Aug 14 22:30:10 ltg01-fedora kernel: <6>note: thunderbird-bin[2288] exited with preempt_count 1
Aug 14 22:30:10 ltg01-fedora kernel: BUG: sleeping function called from invalid context at /usr/src/linux-mm/mm/slab.c:2989
Aug 14 22:30:10 ltg01-fedora kernel: in_atomic():1, irqs_disabled():0
Aug 14 22:30:10 ltg01-fedora kernel: [<c0103e41>] dump_trace+0x70/0x176
Aug 14 22:30:10 ltg01-fedora kernel: [<c0103fc1>] show_trace_log_lvl+0x12/0x22
Aug 14 22:30:10 ltg01-fedora kernel: [<c0103fde>] show_trace+0xd/0xf
Aug 14 22:30:10 ltg01-fedora kernel: [<c01040b0>] dump_stack+0x17/0x19
Aug 14 22:30:10 ltg01-fedora kernel: [<c011ec0c>] __might_sleep+0x92/0x9a
Aug 14 22:30:10 ltg01-fedora kernel: [<c017319e>] kmem_cache_zalloc+0x27/0xe7
Aug 14 22:30:11 ltg01-fedora kernel: [<c0154b57>] taskstats_exit_alloc+0x30/0x6e
Aug 14 22:30:11 ltg01-fedora kernel: [<c012455e>] do_exit+0x1a3/0x5cd
Aug 14 22:30:11 ltg01-fedora kernel: [<c0104515>] die+0x1e8/0x1f0
Aug 14 22:30:11 ltg01-fedora kernel: [<c0104c9f>] do_general_protection+0x1d1/0x1d9
Aug 14 22:30:11 ltg01-fedora kernel: [<c0303b89>] error_code+0x39/0x40
Aug 14 22:30:11 ltg01-fedora kernel: [<c0205249>] __list_add+0x3d/0x7a
Aug 14 22:30:11 ltg01-fedora kernel: [<c013de71>] futex_wait+0x15c/0x220
Aug 14 22:30:11 ltg01-fedora kernel: [<c013ed17>] do_futex+0x33/0x92
Aug 14 22:30:11 ltg01-fedora kernel: [<c013ee6b>] sys_futex+0xf5/0x101
Aug 14 22:30:11 ltg01-fedora kernel: [<c010312d>] sysenter_past_esp+0x56/0x8d
Aug 14 22:30:11 ltg01-fedora kernel: [<b7f12410>] 0xb7f12410
Aug 14 22:30:11 ltg01-fedora kernel: [<c0103fc1>] show_trace_log_lvl+0x12/0x22
Aug 14 22:30:11 ltg01-fedora kernel: [<c0103fde>] show_trace+0xd/0xf
Aug 14 22:30:11 ltg01-fedora kernel: [<c01040b0>] dump_stack+0x17/0x19
Aug 14 22:30:11 ltg01-fedora kernel: [<c011ec0c>] __might_sleep+0x92/0x9a
Aug 14 22:30:11 ltg01-fedora kernel: [<c017319e>] kmem_cache_zalloc+0x27/0xe7
Aug 14 22:30:11 ltg01-fedora kernel: [<c0154b57>] taskstats_exit_alloc+0x30/0x6e
Aug 14 22:30:11 ltg01-fedora kernel: [<c012455e>] do_exit+0x1a3/0x5cd
Aug 14 22:30:11 ltg01-fedora kernel: [<c0104515>] die+0x1e8/0x1f0
Aug 14 22:30:11 ltg01-fedora kernel: [<c0104c9f>] do_general_protection+0x1d1/0x1d9
Aug 14 22:30:11 ltg01-fedora kernel: [<c0303b89>] error_code+0x39/0x40
Aug 14 22:30:11 ltg01-fedora kernel: [<c013de71>] futex_wait+0x15c/0x220
Aug 14 22:30:11 ltg01-fedora kernel: [<c013ed17>] do_futex+0x33/0x92
Aug 14 22:30:11 ltg01-fedora kernel: [<c013ee6b>] sys_futex+0xf5/0x101
Aug 14 22:30:11 ltg01-fedora kernel: [<c010312d>] sysenter_past_esp+0x56/0x8d
Aug 14 22:30:11 ltg01-fedora kernel: =======================
0xc0205249 is in __list_add (/usr/src/linux-mm/lib/list_debug.c:28).
23 if (unlikely(next->prev != prev)) {
24 printk("list_add corruption. next->prev should be %p, but was %p\n",
25 prev, next->prev);
26 BUG();
27 }
28 if (unlikely(prev->next != next)) {
29 printk("list_add corruption. prev->next should be %p, but was %p\n",
30 next, prev->next);
31 BUG();
32 }
I'll revert debug-variants-of-linked-list-macros.patch
> thanks
> -john
>
>
Regards,
Michal
--
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-14 20:48 ` 2.6.18-rc4-mm1 Michal Piotrowski
@ 2006-08-14 20:56 ` Dave Jones
2006-08-14 21:13 ` 2.6.18-rc4-mm1 Michal Piotrowski
0 siblings, 1 reply; 80+ messages in thread
From: Dave Jones @ 2006-08-14 20:56 UTC (permalink / raw)
To: Michal Piotrowski
Cc: john stultz, Andrew Morton, linux-kernel, Thomas Gleixner,
Ingo Molnar, Dinakar Guniguntala
On Mon, Aug 14, 2006 at 10:48:58PM +0200, Michal Piotrowski wrote:
>
> Hmmm... It looks a bit different without futex_handle_fault-always-fails.patch
>
> Aug 14 22:30:09 ltg01-fedora kernel: general protection fault: 0000 [#1]
> Aug 14 22:30:09 ltg01-fedora kernel: 4K_STACKS PREEMPT SMP
> Aug 14 22:30:09 ltg01-fedora kernel: last sysfs file: /devices/platform/i2c-9191/9191-0290/temp2_input
> Aug 14 22:30:09 ltg01-fedora kernel: Modules linked in: ipv6 w83627hf hwmon_vid hwmon i2c_isa af_packet ip_conntrack_netbios
> _ns ipt_REJECT xt_state ip_conntrack nfnetlink xt_tcpudp iptable_filter ip_tables x_tables cpufreq_userspace p4_clockmod spe
> edstep_lib binfmt_misc thermal processor fan container evdev snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_seq_dummy snd_seq_
> oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm sk98lin skge snd_timer snd soundcore snd_pag
> e_alloc ide_cd i2c_i801 intel_agp agpgart cdrom rtc unix
> Aug 14 22:30:09 ltg01-fedora kernel: CPU: 0
> Aug 14 22:30:09 ltg01-fedora kernel: EIP: 0060:[<c0205249>] Not tainted VLI
> Aug 14 22:30:09 ltg01-fedora kernel: EFLAGS: 00010246 (2.6.18-rc4-mm1 #101)
> Aug 14 22:30:09 ltg01-fedora kernel: EIP is at __list_add+0x3d/0x7a
...
> 0xc0205249 is in __list_add (/usr/src/linux-mm/lib/list_debug.c:28).
> 23 if (unlikely(next->prev != prev)) {
> 24 printk("list_add corruption. next->prev should be %p, but was %p\n",
> 25 prev, next->prev);
> 26 BUG();
> 27 }
> 28 if (unlikely(prev->next != next)) {
> 29 printk("list_add corruption. prev->next should be %p, but was %p\n",
> 30 next, prev->next);
> 31 BUG();
> 32 }
>
> I'll revert debug-variants-of-linked-list-macros.patch
__list_add will still be dereferencing prev->next, so you should see exactly
the same gpf. Note that you're not triggering the BUG()'s here, you're hitting
some other fault just walking the list.
Dave
--
http://www.codemonkey.org.uk
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-14 20:56 ` 2.6.18-rc4-mm1 Dave Jones
@ 2006-08-14 21:13 ` Michal Piotrowski
2006-08-14 21:20 ` 2.6.18-rc4-mm1 Dave Jones
0 siblings, 1 reply; 80+ messages in thread
From: Michal Piotrowski @ 2006-08-14 21:13 UTC (permalink / raw)
To: Dave Jones, Michal Piotrowski, john stultz, Andrew Morton,
linux-kernel, Thomas Gleixner, Ingo Molnar, Dinakar Guniguntala
On 14/08/06, Dave Jones <davej@redhat.com> wrote:
> On Mon, Aug 14, 2006 at 10:48:58PM +0200, Michal Piotrowski wrote:
> >
> > Hmmm... It looks a bit different without futex_handle_fault-always-fails.patch
> >
> > Aug 14 22:30:09 ltg01-fedora kernel: general protection fault: 0000 [#1]
> > Aug 14 22:30:09 ltg01-fedora kernel: 4K_STACKS PREEMPT SMP
> > Aug 14 22:30:09 ltg01-fedora kernel: last sysfs file: /devices/platform/i2c-9191/9191-0290/temp2_input
> > Aug 14 22:30:09 ltg01-fedora kernel: Modules linked in: ipv6 w83627hf hwmon_vid hwmon i2c_isa af_packet ip_conntrack_netbios
> > _ns ipt_REJECT xt_state ip_conntrack nfnetlink xt_tcpudp iptable_filter ip_tables x_tables cpufreq_userspace p4_clockmod spe
> > edstep_lib binfmt_misc thermal processor fan container evdev snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_seq_dummy snd_seq_
> > oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm sk98lin skge snd_timer snd soundcore snd_pag
> > e_alloc ide_cd i2c_i801 intel_agp agpgart cdrom rtc unix
> > Aug 14 22:30:09 ltg01-fedora kernel: CPU: 0
> > Aug 14 22:30:09 ltg01-fedora kernel: EIP: 0060:[<c0205249>] Not tainted VLI
> > Aug 14 22:30:09 ltg01-fedora kernel: EFLAGS: 00010246 (2.6.18-rc4-mm1 #101)
> > Aug 14 22:30:09 ltg01-fedora kernel: EIP is at __list_add+0x3d/0x7a
>
> ...
>
> > 0xc0205249 is in __list_add (/usr/src/linux-mm/lib/list_debug.c:28).
> > 23 if (unlikely(next->prev != prev)) {
> > 24 printk("list_add corruption. next->prev should be %p, but was %p\n",
> > 25 prev, next->prev);
> > 26 BUG();
> > 27 }
> > 28 if (unlikely(prev->next != next)) {
> > 29 printk("list_add corruption. prev->next should be %p, but was %p\n",
> > 30 next, prev->next);
> > 31 BUG();
> > 32 }
> >
> > I'll revert debug-variants-of-linked-list-macros.patch
>
> __list_add will still be dereferencing prev->next, so you should see exactly
> the same gpf. Note that you're not triggering the BUG()'s here, you're hitting
> some other fault just walking the list.
How can I debug this?
>
> Dave
>
> --
> http://www.codemonkey.org.uk
>
Regards,
Michal
--
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-14 20:20 ` 2.6.18-rc4-mm1 Dave Jones
@ 2006-08-14 21:13 ` Ben B
2006-08-14 21:22 ` 2.6.18-rc4-mm1 Dave Jones
2006-08-14 21:46 ` 2.6.18-rc4-mm1 Andrew Morton
1 sibling, 1 reply; 80+ messages in thread
From: Ben B @ 2006-08-14 21:13 UTC (permalink / raw)
To: Dave Jones, Andrew Morton, Maciej Rutecki, linux-kernel
Dave Jones <davej@redhat.com> uttered the following thing:
> > > > [ 734.156000] [<e01f2665>] cpufreq_governor_dbs+0x2b5/0x310 [cpufreq_ondemand]
> > >
> > > This makes no sense at all, because in -mm __create_workqueue doesn't
> > > call lock_cpu_hotplug().
> > >
> > > Are you sure this was from a tree with -mm1 applied ?
> >
> > Definitely 2.6.18-rc4-mm1, and I've done a clean rebuild + removal of
> > all modules under /lib/modules beforehand.
>
> It's a real mystery. Andrew ?
This seems to be specific to the ondemand governor - I just tried with
conservative, and alternating it with performance, with no problems, but
as soon as I loaded ondemand, the message appeared. It seems to fire off
the message as soon as I either set the governor to ondemand, or revert
it from ondemand to something else. But going from, eg performance to
conservative, wont give the message, even with ondemand loaded.
I wonder if this might also be related to my 1.83GHz cpu only being set
to a maximum of 1.33GHz via cpufreq? cpuinfo_max_freq is correct, but
scaling_max_freq is wrong. Though doing "cat cpuinfo_max_freq >
scaling_max_freq" has fixed it up, it should be correct already.
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 14
model name : Genuine Intel(R) CPU T2400 @ 1.83GHz
stepping : 8
cpu MHz : 1000.000
cache size : 2048 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov
pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc pni
monitor
vmx est tm2 xtpr
bogomips : 3667.27
processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 14
model name : Genuine Intel(R) CPU T2400 @ 1.83GHz
stepping : 8
cpu MHz : 1333.000
cache size : 2048 KB
physical id : 0
siblings : 2
core id : 1
cpu cores : 2
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov
pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc pni
monitor
vmx est tm2 xtpr
bogomips : 3657.79
Ben
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-14 21:13 ` 2.6.18-rc4-mm1 Michal Piotrowski
@ 2006-08-14 21:20 ` Dave Jones
2006-08-14 22:08 ` 2.6.18-rc4-mm1 Michal Piotrowski
0 siblings, 1 reply; 80+ messages in thread
From: Dave Jones @ 2006-08-14 21:20 UTC (permalink / raw)
To: Michal Piotrowski
Cc: john stultz, Andrew Morton, linux-kernel, Thomas Gleixner,
Ingo Molnar, Dinakar Guniguntala
On Mon, Aug 14, 2006 at 11:13:14PM +0200, Michal Piotrowski wrote:
> On 14/08/06, Dave Jones <davej@redhat.com> wrote:
> > > Aug 14 22:30:09 ltg01-fedora kernel: general protection fault: 0000 [#1]
> > > Aug 14 22:30:09 ltg01-fedora kernel: 4K_STACKS PREEMPT SMP
> > > Aug 14 22:30:09 ltg01-fedora kernel: last sysfs file: /devices/platform/i2c-9191/9191-0290/temp2_input
> > > Aug 14 22:30:09 ltg01-fedora kernel: CPU: 0
> > > Aug 14 22:30:09 ltg01-fedora kernel: EIP: 0060:[<c0205249>] Not tainted VLI
> > > Aug 14 22:30:09 ltg01-fedora kernel: EFLAGS: 00010246 (2.6.18-rc4-mm1 #101)
> > > Aug 14 22:30:09 ltg01-fedora kernel: EIP is at __list_add+0x3d/0x7a
> > > Aug 14 22:30:09 ltg01-fedora kernel: eax: 00000000 ebx: c0670a80 ecx: c038d4dc edx: 00000000
> > > Aug 14 22:30:09 ltg01-fedora kernel: esi: ffffffff edi: f50ebee8 ebp: f50ebed0 esp: f50ebec4
> >
> > __list_add will still be dereferencing prev->next, so you should see exactly
> > the same gpf. Note that you're not triggering the BUG()'s here, you're hitting
> > some other fault just walking the list.
>
> How can I debug this?
Not sure. I'm somewhat puzzled.
Disassembling the Code: of your oops shows that we were trying to dereference esi,
which was -1 for some bizarre reason. (my objdump really hated disassembling that
function, but I think thats my tools rather than breakage in the oops).
Question is how did that list member get to be -1 ?
One pie-in-the-sky possibility is that we've corrupted memory recently, and
this link-list manipulation just stumbled across it. Note that the last file
opened before we blew up was reading i2c. Can you try and reproduce this
(if you can reproduce it at all) without the sensors stuff loaded ?
It's a long-shot, but without further clues, I'm stabbing in the dark.
Dave
--
http://www.codemonkey.org.uk
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-14 21:13 ` 2.6.18-rc4-mm1 Ben B
@ 2006-08-14 21:22 ` Dave Jones
0 siblings, 0 replies; 80+ messages in thread
From: Dave Jones @ 2006-08-14 21:22 UTC (permalink / raw)
To: Ben B; +Cc: Andrew Morton, Maciej Rutecki, linux-kernel
On Mon, Aug 14, 2006 at 11:13:38PM +0200, Ben B wrote:
> Dave Jones <davej@redhat.com> uttered the following thing:
> > > > > [ 734.156000] [<e01f2665>] cpufreq_governor_dbs+0x2b5/0x310 [cpufreq_ondemand]
> > > >
> > > > This makes no sense at all, because in -mm __create_workqueue doesn't
> > > > call lock_cpu_hotplug().
> > > >
> > > > Are you sure this was from a tree with -mm1 applied ?
> > >
> > > Definitely 2.6.18-rc4-mm1, and I've done a clean rebuild + removal of
> > > all modules under /lib/modules beforehand.
> >
> > It's a real mystery. Andrew ?
>
> This seems to be specific to the ondemand governor - I just tried with
> conservative, and alternating it with performance, with no problems, but
> as soon as I loaded ondemand, the message appeared. It seems to fire off
> the message as soon as I either set the governor to ondemand, or revert
> it from ondemand to something else. But going from, eg performance to
> conservative, wont give the message, even with ondemand loaded.
on-demand is unique in the sense that its the only governor that
creates a workqueue.
> I wonder if this might also be related to my 1.83GHz cpu only being set
> to a maximum of 1.33GHz via cpufreq? cpuinfo_max_freq is correct, but
> scaling_max_freq is wrong. Though doing "cat cpuinfo_max_freq >
> scaling_max_freq" has fixed it up, it should be correct already.
That's come up a lot lately. I'm still of the opinion that something
changed in acpi that's the explanation for this.
Dave
--
http://www.codemonkey.org.uk
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-14 18:32 ` 2.6.18-rc4-mm1 David Howells
@ 2006-08-14 21:31 ` Andrew Morton
2006-08-15 9:51 ` 2.6.18-rc4-mm1 David Howells
0 siblings, 1 reply; 80+ messages in thread
From: Andrew Morton @ 2006-08-14 21:31 UTC (permalink / raw)
To: David Howells; +Cc: linux-kernel, Trond Myklebust, Ian Kent
On Mon, 14 Aug 2006 19:32:19 +0100
David Howells <dhowells@redhat.com> wrote:
> Andrew Morton <akpm@osdl.org> wrote:
>
> > sony:/home/akpm> showmount -e bix
> > Export list for bix:
> > / *
> > /usr/src *
> > /mnt/export *
>
> What's in your /etc/exports file?
>
bix:/home/akpm> cat /etc/exports
/ *(rw,async)
/usr/src *(rw,async)
/mnt/export *(rw,async)
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-14 13:45 ` 2.6.18-rc4-mm1 Dmitry Torokhov
@ 2006-08-14 21:44 ` Ben B
2006-08-15 2:23 ` 2.6.18-rc4-mm1 Dmitry Torokhov
0 siblings, 1 reply; 80+ messages in thread
From: Ben B @ 2006-08-14 21:44 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Andrew Morton, Maciej Rutecki, linux-kernel
Dmitry Torokhov <dmitry.torokhov@gmail.com> uttered the following thing:
> On 8/14/06, Ben B <kernel@bb.cactii.net> wrote:
> >I can try to get a full boot log later when I get home.
> >
>
> Please.
It was impossible to get. I set the 'init' kernel option to a dedicated
script to dump dmesg, but even that went way past the messages.
It seems however that I managed to get everything a-ok now, I just
booted with 'i8042.noaux=1' and that seemed to have resolved everything.
This lappy is proving a challenge to get perfect (but I'm getting
there!)
> > 9: 10 0 IO-APIC-level acpi
> > 12: 1796 0 IO-APIC-edge i8042
> ^^^^^^^
>
> It loos like it does (on AUX port)
Fyi, that didn't increment further no matter how much i battered the
kbd or wiggled the touchpad/stick.
Cheers,
BB
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-14 20:20 ` 2.6.18-rc4-mm1 Dave Jones
2006-08-14 21:13 ` 2.6.18-rc4-mm1 Ben B
@ 2006-08-14 21:46 ` Andrew Morton
1 sibling, 0 replies; 80+ messages in thread
From: Andrew Morton @ 2006-08-14 21:46 UTC (permalink / raw)
To: Dave Jones; +Cc: Ben Buxton, Maciej Rutecki, linux-kernel
On Mon, 14 Aug 2006 16:20:04 -0400
Dave Jones <davej@redhat.com> wrote:
> On Mon, Aug 14, 2006 at 01:55:56PM +0200, Ben Buxton wrote:
>
> > > > Also, whenever I echo anything to "scaling_governor", I get the
> > > > following kernel message:
> > > >
> > > > [ 734.156000] BUG: warning at kernel/cpu.c:38/lock_cpu_hotplug()
> > > > [ 734.156000] [<c013c3ec>] lock_cpu_hotplug+0x7c/0x90
> > > > [ 734.156000] [<c01327f4>] __create_workqueue+0x44/0x140
> > > > [ 734.156000] [<c02dcf7b>] mutex_lock+0xb/0x20
> > > > [ 734.156000] [<e01f2665>] cpufreq_governor_dbs+0x2b5/0x310 [cpufreq_ondemand]
> > >
> > > This makes no sense at all, because in -mm __create_workqueue doesn't
> > > call lock_cpu_hotplug().
> > >
> > > Are you sure this was from a tree with -mm1 applied ?
> >
> > Definitely 2.6.18-rc4-mm1, and I've done a clean rebuild + removal of
> > all modules under /lib/modules beforehand.
>
> It's a real mystery. Andrew ?
>
I'm suspecting it's just stack gunk. If Ben could send some more such
traces that'd clear things up. Also, turning on CONFIG_UNWIND_INFO,
CONFIG_STACK_UNWIND and perhaps CONFIG_FRAME_POINTER might give us a
cleaner backtrace.
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-14 21:20 ` 2.6.18-rc4-mm1 Dave Jones
@ 2006-08-14 22:08 ` Michal Piotrowski
0 siblings, 0 replies; 80+ messages in thread
From: Michal Piotrowski @ 2006-08-14 22:08 UTC (permalink / raw)
To: Dave Jones, Michal Piotrowski, john stultz, Andrew Morton,
linux-kernel, Thomas Gleixner, Ingo Molnar, Dinakar Guniguntala
Dave Jones wrote:
> On Mon, Aug 14, 2006 at 11:13:14PM +0200, Michal Piotrowski wrote:
> > On 14/08/06, Dave Jones <davej@redhat.com> wrote:
> > > > Aug 14 22:30:09 ltg01-fedora kernel: general protection fault: 0000 [#1]
> > > > Aug 14 22:30:09 ltg01-fedora kernel: 4K_STACKS PREEMPT SMP
> > > > Aug 14 22:30:09 ltg01-fedora kernel: last sysfs file: /devices/platform/i2c-9191/9191-0290/temp2_input
> > > > Aug 14 22:30:09 ltg01-fedora kernel: CPU: 0
> > > > Aug 14 22:30:09 ltg01-fedora kernel: EIP: 0060:[<c0205249>] Not tainted VLI
> > > > Aug 14 22:30:09 ltg01-fedora kernel: EFLAGS: 00010246 (2.6.18-rc4-mm1 #101)
> > > > Aug 14 22:30:09 ltg01-fedora kernel: EIP is at __list_add+0x3d/0x7a
> > > > Aug 14 22:30:09 ltg01-fedora kernel: eax: 00000000 ebx: c0670a80 ecx: c038d4dc edx: 00000000
> > > > Aug 14 22:30:09 ltg01-fedora kernel: esi: ffffffff edi: f50ebee8 ebp: f50ebed0 esp: f50ebec4
> > >
> > > __list_add will still be dereferencing prev->next, so you should see exactly
> > > the same gpf. Note that you're not triggering the BUG()'s here, you're hitting
> > > some other fault just walking the list.
> >
> > How can I debug this?
>
> Not sure. I'm somewhat puzzled.
> Disassembling the Code: of your oops shows that we were trying to dereference esi,
> which was -1 for some bizarre reason. (my objdump really hated disassembling that
> function, but I think thats my tools rather than breakage in the oops).
>
> Question is how did that list member get to be -1 ?
> One pie-in-the-sky possibility is that we've corrupted memory recently, and
> this link-list manipulation just stumbled across it. Note that the last file
> opened before we blew up was reading i2c.
Or cpufreq
Aug 14 15:35:10 ltg01-fedora kernel: last sysfs file: /devices/platform/i2c-9191/9191-0290/temp2_input
Aug 14 15:39:12 ltg01-fedora kernel: last sysfs file: /devices/system/cpu/cpu0/cpufreq/scaling_setspeed
Aug 14 22:30:09 ltg01-fedora kernel: last sysfs file: /devices/platform/i2c-9191/9191-0290/temp2_input
I haven't seen this bug on previous (2006-08-08) mm snapshot. Here are new i2c patches
apple-motion-sensor-driver-kconfig-fix.patch
kill-include-linux-configh.patch - it's my patch, I'm testing it for tree days.
Aug 14 15:35:11 ltg01-fedora kernel: <6>note: firefox-bin[2210] exited with preempt_count 1
Aug 14 15:39:13 ltg01-fedora kernel: <6>note: sendmail[1719] exited with preempt_count 1
Aug 14 22:30:10 ltg01-fedora kernel: <6>note: thunderbird-bin[2288] exited with preempt_count 1
Is it possible that this is a problem with net stack?
Binary search will take ages - I don't know how to reproduce this bug.
> Can you try and reproduce this
> (if you can reproduce it at all) without the sensors stuff loaded ?
>
> It's a long-shot, but without further clues, I'm stabbing in the dark.
>
> Dave
>
Regards,
Michal
--
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-13 20:39 ` 2.6.18-rc4-mm1 Andrew Morton
` (2 preceding siblings ...)
2006-08-14 18:32 ` 2.6.18-rc4-mm1 David Howells
@ 2006-08-14 22:49 ` Trond Myklebust
2006-08-14 23:51 ` 2.6.18-rc4-mm1 Andrew Morton
` (2 more replies)
3 siblings, 3 replies; 80+ messages in thread
From: Trond Myklebust @ 2006-08-14 22:49 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, David Howells, Ian Kent
On Sun, 2006-08-13 at 13:39 -0700, Andrew Morton wrote:
> On Sun, 13 Aug 2006 01:24:54 -0700
> Andrew Morton <akpm@osdl.org> wrote:
>
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm1/
>
> This kernel breaks autofs /net handling. Bisection shows that the bug is
> introduced by git-nfs.patch.
Could you try pulling afresh from the NFS git tree? I've fixed up a
couple of issues in which rpc_pipefs was corrupting the dcache, as well
as a few dentry leaks that were introduced by David's
nfs_alloc_client().
Cheers,
Trond
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-14 22:49 ` 2.6.18-rc4-mm1 Trond Myklebust
@ 2006-08-14 23:51 ` Andrew Morton
2006-08-15 16:39 ` 2.6.18-rc4-mm1 David Howells
2006-08-15 16:55 ` 2.6.18-rc4-mm1 David Howells
2 siblings, 0 replies; 80+ messages in thread
From: Andrew Morton @ 2006-08-14 23:51 UTC (permalink / raw)
To: Trond Myklebust; +Cc: linux-kernel, David Howells, Ian Kent
On Mon, 14 Aug 2006 18:49:27 -0400
Trond Myklebust <trond.myklebust@fys.uio.no> wrote:
> On Sun, 2006-08-13 at 13:39 -0700, Andrew Morton wrote:
> > On Sun, 13 Aug 2006 01:24:54 -0700
> > Andrew Morton <akpm@osdl.org> wrote:
> >
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm1/
> >
> > This kernel breaks autofs /net handling. Bisection shows that the bug is
> > introduced by git-nfs.patch.
>
> Could you try pulling afresh from the NFS git tree?
Did that - there is no change.
> I've fixed up a
> couple of issues in which rpc_pipefs was corrupting the dcache, as well
> as a few dentry leaks that were introduced by David's
> nfs_alloc_client().
I tested just bare 2.6.18-rc4+git-nfs.patch to eliminate any -mm unknowns.
The problem remains.
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-14 21:44 ` 2.6.18-rc4-mm1 Ben B
@ 2006-08-15 2:23 ` Dmitry Torokhov
0 siblings, 0 replies; 80+ messages in thread
From: Dmitry Torokhov @ 2006-08-15 2:23 UTC (permalink / raw)
To: Ben B; +Cc: Andrew Morton, Maciej Rutecki, linux-kernel
On Monday 14 August 2006 17:44, Ben B wrote:
> Dmitry Torokhov <dmitry.torokhov@gmail.com> uttered the following thing:
> > On 8/14/06, Ben B <kernel@bb.cactii.net> wrote:
> > >I can try to get a full boot log later when I get home.
> > >
> >
> > Please.
>
> It was impossible to get. I set the 'init' kernel option to a dedicated
> script to dump dmesg, but even that went way past the messages.
>
Could you please try increasing the buffer size (using log_buf_len=xxx
option). 131072 shoudl work I think.
Also please try the patch below. Thanks!
--
Dmitry
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
---
drivers/input/serio/i8042.c | 8 +++++++-
1 files changed, 7 insertions(+), 1 deletion(-)
Index: work/drivers/input/serio/i8042.c
===================================================================
--- work.orig/drivers/input/serio/i8042.c
+++ work/drivers/input/serio/i8042.c
@@ -631,8 +631,14 @@ static int __devinit i8042_check_aux(voi
goto out;
if (wait_for_completion_timeout(&i8042_aux_irq_delivered,
- msecs_to_jiffies(250)) == 0)
+ msecs_to_jiffies(250)) == 0) {
+/*
+ * AUX IRQ was never delivered so we need to flush the controller to
+ * get rid of the byte we put there; otherwise keyboard may not work.
+ */
+ i8042_flush();
retval = -1;
+ }
out:
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-14 21:31 ` 2.6.18-rc4-mm1 Andrew Morton
@ 2006-08-15 9:51 ` David Howells
2006-08-15 13:50 ` 2.6.18-rc4-mm1 Andrew Morton
0 siblings, 1 reply; 80+ messages in thread
From: David Howells @ 2006-08-15 9:51 UTC (permalink / raw)
To: Andrew Morton; +Cc: David Howells, linux-kernel, Trond Myklebust, Ian Kent
Andrew Morton <akpm@osdl.org> wrote:
> bix:/home/akpm> cat /etc/exports
> / *(rw,async)
> /usr/src *(rw,async)
> /mnt/export *(rw,async)
Hmmm... I still can't reproduce it.
What happens if you change your /etc/exports file to:
/ *(rw,async,fsid=0)
/usr/src *(rw,async,nohide)
/mnt/export *(rw,async,nohide)
Also, does removing the "/mnt/export" line from /etc/exports mean that the
/mnt reappears in the directory listing?
David
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-15 9:51 ` 2.6.18-rc4-mm1 David Howells
@ 2006-08-15 13:50 ` Andrew Morton
2006-08-15 14:47 ` 2.6.18-rc4-mm1 David Howells
2006-08-15 17:29 ` 2.6.18-rc4-mm1 David Howells
0 siblings, 2 replies; 80+ messages in thread
From: Andrew Morton @ 2006-08-15 13:50 UTC (permalink / raw)
To: David Howells; +Cc: linux-kernel, Trond Myklebust, Ian Kent
On Tue, 15 Aug 2006 10:51:53 +0100
David Howells <dhowells@redhat.com> wrote:
> Andrew Morton <akpm@osdl.org> wrote:
>
> > bix:/home/akpm> cat /etc/exports
> > / *(rw,async)
> > /usr/src *(rw,async)
> > /mnt/export *(rw,async)
>
> Hmmm... I still can't reproduce it.
http://www.zip.com.au/~akpm/linux/patches/stuff/config-sony
> What happens if you change your /etc/exports file to:
>
> / *(rw,async,fsid=0)
> /usr/src *(rw,async,nohide)
> /mnt/export *(rw,async,nohide)
unchanged.
> Also, does removing the "/mnt/export" line from /etc/exports mean that the
> /mnt reappears in the directory listing?
>
That makes /mnt go away:
sony:/home/akpm> l /net/bix
total 1025284
drwxr-xr-x 3 root root 4096 Apr 10 03:19 bin
drwxr-xr-x 2 root root 4096 Mar 10 2004 boot
drwxr-xr-x 23 root root 118784 Jun 26 00:48 dev
drwxr-xr-x 98 root root 8192 Aug 15 06:46 etc
drwxr-xr-x 7 root root 4096 Apr 1 2004 home
drwxr-xr-x 2 root root 4096 Oct 7 2003 initrd
drwxr-xr-x 10 root root 4096 Apr 10 03:19 lib
drwx------ 2 root root 16384 Mar 10 2004 lost+found
drwxr-xr-x 2 root root 4096 Sep 8 2003 misc
drwxr-xr-x 19 root root 4096 Jul 3 15:29 mnt
?--------- ? ? ? ? ? /net/bix/usr
drwxrwxrwx 8 root root 4096 Jul 10 02:50 opt
drwxr-xr-x 2 root root 4096 Mar 10 2004 proc
drwxr-xr-x 20 root root 4096 Aug 7 16:39 root
drwxr-xr-x 2 root root 57344 Apr 24 2004 rpms
drwxr-xr-x 2 root root 8192 Apr 10 03:19 sbin
-rw-r--r-- 1 root root 1048576000 Mar 12 2004 swap
drwxr-xr-x 2 root root 4096 Mar 12 2004 sys
drwxr-xr-x 3 root root 4096 Mar 10 2004 tftpboot
drwxrwxrwt 14 root root 16384 Aug 15 06:42 tmp
drwxr-xr-x 27 root root 4096 Mar 10 2004 var
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-14 17:54 ` 2.6.18-rc4-mm1 Rafael J. Wysocki
2006-08-14 18:15 ` 2.6.18-rc4-mm1 Andrew Morton
@ 2006-08-15 14:07 ` Atsushi Nemoto
2006-08-15 17:14 ` 2.6.18-rc4-mm1 Rafael J. Wysocki
1 sibling, 1 reply; 80+ messages in thread
From: Atsushi Nemoto @ 2006-08-15 14:07 UTC (permalink / raw)
To: rjw; +Cc: akpm, linux-kernel
On Mon, 14 Aug 2006 19:54:29 +0200, "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> simplify-update_times-avoid-jiffies-jiffies_64-aliasing-problem.patch
>
> makes my x86_64 SMP box (dual-core Athlon 64 on an ULi-based AsRock mobo) run
> _very_ slow (it would take tens of minutes to boot the box if I were as
> patient as to wait for that).
>
> Strangely enough, on a non-SMP box I have tested it on it works just fine.
Oh, my fault.
Could you retry with this patch?
diff -urp linux-2.6.18-rc4-mm1.org/arch/x86_64/kernel/time.c linux-2.6.18-rc4-mm1/arch/x86_64/kernel/time.c
--- linux-2.6.18-rc4-mm1.org/arch/x86_64/kernel/time.c 2006-08-13 22:59:27.000000000 +0900
+++ linux-2.6.18-rc4-mm1/arch/x86_64/kernel/time.c 2006-08-15 23:01:55.631372704 +0900
@@ -417,6 +417,8 @@ void main_timer_handler(struct pt_regs *
if (lost > 0)
handle_lost_ticks(lost, regs);
+ else
+ lost = 0;
/*
* Do the timer stuff.
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-15 13:50 ` 2.6.18-rc4-mm1 Andrew Morton
@ 2006-08-15 14:47 ` David Howells
2006-08-15 16:15 ` 2.6.18-rc4-mm1 Andrew Morton
2006-08-15 17:29 ` 2.6.18-rc4-mm1 David Howells
1 sibling, 1 reply; 80+ messages in thread
From: David Howells @ 2006-08-15 14:47 UTC (permalink / raw)
To: Andrew Morton; +Cc: David Howells, linux-kernel, Trond Myklebust, Ian Kent
> http://www.zip.com.au/~akpm/linux/patches/stuff/config-sony
Is this pure 2.6.18-rc4-mm1? This configuration has unsatisfied config
options. I was wondering if you had some other patches too.
David
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-15 14:47 ` 2.6.18-rc4-mm1 David Howells
@ 2006-08-15 16:15 ` Andrew Morton
0 siblings, 0 replies; 80+ messages in thread
From: Andrew Morton @ 2006-08-15 16:15 UTC (permalink / raw)
To: David Howells; +Cc: linux-kernel, Trond Myklebust, Ian Kent
On Tue, 15 Aug 2006 15:47:43 +0100
David Howells <dhowells@redhat.com> wrote:
>
> > http://www.zip.com.au/~akpm/linux/patches/stuff/config-sony
>
> Is this pure 2.6.18-rc4-mm1?
yup.
> This configuration has unsatisfied config
> options.
I rarely update my skeleton configs ($certain_people broke my
support-symlinked-.config patch and no two kernel builds have the same
Kconfig set anyway).
So a
yes '' | make oldconfig
is step 1.
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-14 22:49 ` 2.6.18-rc4-mm1 Trond Myklebust
2006-08-14 23:51 ` 2.6.18-rc4-mm1 Andrew Morton
@ 2006-08-15 16:39 ` David Howells
2006-08-15 16:55 ` 2.6.18-rc4-mm1 David Howells
2 siblings, 0 replies; 80+ messages in thread
From: David Howells @ 2006-08-15 16:39 UTC (permalink / raw)
To: Trond Myklebust; +Cc: Andrew Morton, linux-kernel, David Howells, Ian Kent
Trond Myklebust <trond.myklebust@fys.uio.no> wrote:
> as well as a few dentry leaks that were introduced by David's
> nfs_alloc_client().
I'm really quite surprised that I haven't seen these bugs.
Acked-By: David Howells <dhowells@redhat.com>
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-14 22:49 ` 2.6.18-rc4-mm1 Trond Myklebust
2006-08-14 23:51 ` 2.6.18-rc4-mm1 Andrew Morton
2006-08-15 16:39 ` 2.6.18-rc4-mm1 David Howells
@ 2006-08-15 16:55 ` David Howells
2006-08-15 17:13 ` 2.6.18-rc4-mm1 Trond Myklebust
2 siblings, 1 reply; 80+ messages in thread
From: David Howells @ 2006-08-15 16:55 UTC (permalink / raw)
To: Trond Myklebust; +Cc: Andrew Morton, linux-kernel, David Howells, Ian Kent
Trond Myklebust <trond.myklebust@fys.uio.no> wrote:
> Could you try pulling afresh from the NFS git tree? I've fixed up a couple
> of issues in which rpc_pipefs was corrupting the dcache,
Which patches hold those fixes? I'm seeing:
BUG: atomic counter underflow at:
[<c01d5b05>] _atomic_dec_and_lock+0x1d/0x30
[<c0169bd3>] dput+0x22/0x145
[<c8a2f726>] rpc_destroy_client+0xd9/0xee [sunrpc]
[<c8a2f89e>] rpc_shutdown_client+0xea/0xf1 [sunrpc]
[<c8a2f89e>] rpc_shutdown_client+0xea/0xf1 [sunrpc]
[<c886d842>] nfs_free_client+0x95/0xdd [nfs]
[<c886db38>] nfs_free_server+0xa9/0xd9 [nfs]
[<c8873fae>] nfs_kill_super+0xc/0x14 [nfs]
[<c015c033>] deactivate_super+0x4a/0x5d
[<c016df3e>] sys_umount+0x1d3/0x1f1
[<c016ac98>] destroy_inode+0x36/0x45
[<c0169bd3>] dput+0x22/0x145
[<c0157889>] __fput+0x146/0x170
[<c016cf48>] mntput_no_expire+0x11/0x59
[<c016df73>] sys_oldumount+0x17/0x1a
[<c0102b3f>] syscall_call+0x7/0xb
=======================
And I'm wondering if that's due to that problem.
I've applied the patch to fix the resource counting that's at the head of your
git tree.
David
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-15 16:55 ` 2.6.18-rc4-mm1 David Howells
@ 2006-08-15 17:13 ` Trond Myklebust
2006-08-15 17:22 ` 2.6.18-rc4-mm1 David Howells
0 siblings, 1 reply; 80+ messages in thread
From: Trond Myklebust @ 2006-08-15 17:13 UTC (permalink / raw)
To: David Howells; +Cc: Andrew Morton, linux-kernel, Ian Kent
[-- Attachment #1: Type: text/plain, Size: 1335 bytes --]
On Tue, 2006-08-15 at 17:55 +0100, David Howells wrote:
> Trond Myklebust <trond.myklebust@fys.uio.no> wrote:
>
> > Could you try pulling afresh from the NFS git tree? I've fixed up a couple
> > of issues in which rpc_pipefs was corrupting the dcache,
>
> Which patches hold those fixes? I'm seeing:
>
> BUG: atomic counter underflow at:
> [<c01d5b05>] _atomic_dec_and_lock+0x1d/0x30
> [<c0169bd3>] dput+0x22/0x145
> [<c8a2f726>] rpc_destroy_client+0xd9/0xee [sunrpc]
> [<c8a2f89e>] rpc_shutdown_client+0xea/0xf1 [sunrpc]
> [<c8a2f89e>] rpc_shutdown_client+0xea/0xf1 [sunrpc]
> [<c886d842>] nfs_free_client+0x95/0xdd [nfs]
> [<c886db38>] nfs_free_server+0xa9/0xd9 [nfs]
> [<c8873fae>] nfs_kill_super+0xc/0x14 [nfs]
> [<c015c033>] deactivate_super+0x4a/0x5d
> [<c016df3e>] sys_umount+0x1d3/0x1f1
> [<c016ac98>] destroy_inode+0x36/0x45
> [<c0169bd3>] dput+0x22/0x145
> [<c0157889>] __fput+0x146/0x170
> [<c016cf48>] mntput_no_expire+0x11/0x59
> [<c016df73>] sys_oldumount+0x17/0x1a
> [<c0102b3f>] syscall_call+0x7/0xb
> =======================
>
> And I'm wondering if that's due to that problem.
>
> I've applied the patch to fix the resource counting that's at the head of your
> git tree.
See attached mail. Alex confirmed that it fixes the corruption problems
he is seeing.
Cheers,
Trond
[-- Attachment #2: Attached message - Re: [PATCHv3] sunrpc/auth_gss: NULL pointer deref in gss_pipe_release() --]
[-- Type: message/rfc822, Size: 3868 bytes --]
From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: Alex Polvi <polvi@google.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCHv3] sunrpc/auth_gss: NULL pointer deref in gss_pipe_release()
Date: Mon, 14 Aug 2006 18:46:39 -0400
Message-ID: <1155595592.5656.22.camel@localhost>
On Mon, 2006-08-14 at 16:34 -0400, Alex Polvi wrote:
> On 8/14/06, Alex Polvi <polvi@google.com> wrote:
> > Here is another fix. It is quite silly, but clnt->cl_auth is set to
> > NULL in rpc_destroy_client(), then eventually referenced in
> > gss_release_pipe() via rpc_rmdir(). Simply removing the clnt->cl_auth
> > = NULL from clnt.c fixes the issue. I'm still trying to understand the
> > subsystem, but it seems like rpc_rmdir is being correctly called to
> > clean up because of the weirdness with umount -l and the nfs server
> > being turned on and off. Does that seem correct? Or is this still just
> > covering up some other part of the code being sloppy cleaning up?
>
> Also, I just want to make it clear that I do not think this is the
> proper fix. It is just pointing out that we intentionally set cl_auth
> to NULL, then reference it.
OK. I think I've finally managed to clean up the various interactions
with rpc_pipefs. I've uploaded a series of patches on the NFS client
website. See
http://client.linux-nfs.org/Linux-2.6.x/2.6.18-rc4/
The relevant patches are
linux-2.6.18-006-fix_rpc_unlink.dif:
From: Trond Myklebust <Trond.Myklebust@netapp.com>
SUNRPC: make rpc_unlink() take a dentry argument instead of a
path
Signe-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
linux-2.6.18-007-fix_rpc_rmdir.dif:
From: Trond Myklebust <Trond.Myklebust@netapp.com>
NFS: clean up rpc_rmdir
Make it take a dentry argument instead of a path
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
linux-2.6.18-008-fix_rpc_unlink_rmdir_2.dif:
From: Trond Myklebust <Trond.Myklebust@netapp.com>
SUNRPC: rpc_unlink() must check for unhashed dentries
A prior call to rpc_depopulate() by rpc_rmdir() on the parent
directory may have already called simple_unlink() on this entry.
Add the same check to rpc_rmdir(). Also remove a redundant call
to rpc_close_pipes() in rpc_rmdir.
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
linux-2.6.18-009-fix_rpc_unlink_rmdir_3.dif:
From: Trond Myklebust <Trond.Myklebust@netapp.com>
SUNRPC: Fix dentry refcounting issues with users of rpc_pipefs
rpc_unlink() and rpc_rmdir() will dput the dentry reference for
you.
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
----
In addition, there is one patch that is needed in order to fix up a
related issue in the function nfs_alloc_client(), which was introduced
by David Howells' NFS superblock sharing patches.
Cheers,
Trond
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-15 14:07 ` 2.6.18-rc4-mm1 Atsushi Nemoto
@ 2006-08-15 17:14 ` Rafael J. Wysocki
0 siblings, 0 replies; 80+ messages in thread
From: Rafael J. Wysocki @ 2006-08-15 17:14 UTC (permalink / raw)
To: Atsushi Nemoto; +Cc: akpm, linux-kernel
On Tuesday 15 August 2006 16:07, Atsushi Nemoto wrote:
> On Mon, 14 Aug 2006 19:54:29 +0200, "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> > simplify-update_times-avoid-jiffies-jiffies_64-aliasing-problem.patch
> >
> > makes my x86_64 SMP box (dual-core Athlon 64 on an ULi-based AsRock mobo) run
> > _very_ slow (it would take tens of minutes to boot the box if I were as
> > patient as to wait for that).
> >
> > Strangely enough, on a non-SMP box I have tested it on it works just fine.
>
> Oh, my fault.
>
> Could you retry with this patch?
Yes, the patch helps.
Thanks,
Rafael
--
You never change things by fighting the existing reality.
R. Buckminster Fuller
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-15 17:13 ` 2.6.18-rc4-mm1 Trond Myklebust
@ 2006-08-15 17:22 ` David Howells
0 siblings, 0 replies; 80+ messages in thread
From: David Howells @ 2006-08-15 17:22 UTC (permalink / raw)
To: Trond Myklebust; +Cc: David Howells, Andrew Morton, linux-kernel, Ian Kent
Trond Myklebust <trond.myklebust@fys.uio.no> wrote:
> The relevant patches are
Yes... those fix the atomic counter problem, thanks. It appears that patches
006 & 007 are already in the -mm1 tree.
David
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-15 13:50 ` 2.6.18-rc4-mm1 Andrew Morton
2006-08-15 14:47 ` 2.6.18-rc4-mm1 David Howells
@ 2006-08-15 17:29 ` David Howells
2006-08-15 17:48 ` 2.6.18-rc4-mm1 Andrew Morton
1 sibling, 1 reply; 80+ messages in thread
From: David Howells @ 2006-08-15 17:29 UTC (permalink / raw)
To: Andrew Morton; +Cc: David Howells, linux-kernel, Trond Myklebust, Ian Kent
Next thing to try: Can you do the following:
echo $((0x0200)) >/proc/sys/sunrpc/nfs_debug
ls -l /net/bix
umount /net/bix
That should print some information about the client and server setup procedure
into the kernel dmesg log which can then be captured.
If you follow that up with:
echo $((0x0201)) >/proc/sys/sunrpc/nfs_debug
ls -l /net/bix
umount /net/bix
That'll dump information from the VFS interaction also. It'll be a lot more
information, and it might overrun your dmesg buffer, hence why I'm asking you
to do the client-only debugging separately.
Then do:
echo 0 >/proc/sys/sunrpc/nfs_debug
to turn off debugging again.
David
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-15 17:29 ` 2.6.18-rc4-mm1 David Howells
@ 2006-08-15 17:48 ` Andrew Morton
2006-08-15 18:35 ` 2.6.18-rc4-mm1 David Howells
0 siblings, 1 reply; 80+ messages in thread
From: Andrew Morton @ 2006-08-15 17:48 UTC (permalink / raw)
To: David Howells; +Cc: linux-kernel, Trond Myklebust, Ian Kent
On Tue, 15 Aug 2006 18:29:58 +0100
David Howells <dhowells@redhat.com> wrote:
>
> Next thing to try: Can you do the following:
>
> echo $((0x0200)) >/proc/sys/sunrpc/nfs_debug
> ls -l /net/bix
> umount /net/bix
>
> That should print some information about the client and server setup procedure
> into the kernel dmesg log which can then be captured.
SELinux: initialized (dev 0:15, type nfs), uses genfs_contexts
--> nfs_init_server()
--> nfs_get_client(bix,192.168.2.33:264,3)
--> nfs_get_client() = ea22d000 [new]
<-- nfs_init_server() = 0 [new ea22d000]
--> nfs_probe_fsinfo()
<-- nfs_probe_fsinfo() = 0
Server FSID: 802:0
SELinux: initialized (dev 0:15, type nfs), uses genfs_contexts
--> nfs_free_server()
--> nfs_put_client({1})
--> nfs_free_client(3)
<-- nfs_free_client()
<-- nfs_free_server()
> If you follow that up with:
>
> echo $((0x0201)) >/proc/sys/sunrpc/nfs_debug
> ls -l /net/bix
> umount /net/bix
>
> That'll dump information from the VFS interaction also. It'll be a lot more
> information, and it might overrun your dmesg buffer, hence why I'm asking you
> to do the client-only debugging separately.
--> nfs_init_server()
--> nfs_get_client(bix,192.168.2.33:264,3)
--> nfs_get_client() = ebabd400 [new]
<-- nfs_init_server() = 0 [new ebabd400]
--> nfs_probe_fsinfo()
<-- nfs_probe_fsinfo() = 0
Server FSID: 802:0
NFS: nfs_fhget(0:15/0 ct=1)
NFS: nfs_fhget(0:15/2 ct=1)
SELinux: initialized (dev 0:15, type nfs), uses genfs_contexts
NFS: nfs_update_inode(0:15/2 ct=1 info=0x6)
NFS: permission(0:15/2), mask=0x1, res=0
NFS: permission(0:15/2), mask=0x1, res=0
NFS: lookup(/usr)
NFS: permission(0:15/2), mask=0x3, res=0
NFS: dentry_delete(/usr, 0)
NFS: permission(0:15/2), mask=0x1, res=0
NFS: permission(0:15/2), mask=0x1, res=0
NFS: lookup(/mnt)
NFS: permission(0:15/2), mask=0x3, res=0
NFS: dentry_delete(/mnt, 0)
NFS: nfs_update_inode(0:15/2 ct=1 info=0x6)
NFS: permission(0:15/2), mask=0x4, res=0
NFS: opendir(0:15/2)
NFS: readdir(/) starting at cookie 0
NFS: nfs_fhget(0:15/11 ct=1)
NFS: dentry_delete(/lost+found, 0)
NFS: nfs_fhget(0:15/65537 ct=1)
NFS: dentry_delete(/dev, 0)
NFS: dentry_delete(/usr, 8)
NFS: nfs_fhget(0:15/196609 ct=1)
NFS: dentry_delete(/var, 0)
NFS: nfs_fhget(0:15/245761 ct=1)
NFS: dentry_delete(/tmp, 0)
NFS: nfs_fhget(0:15/262145 ct=1)
NFS: dentry_delete(/etc, 0)
NFS: nfs_fhget(0:15/327681 ct=1)
NFS: dentry_delete(/root, 0)
NFS: nfs_fhget(0:15/753665 ct=1)
NFS: dentry_delete(/lib, 0)
NFS: nfs_fhget(0:15/851969 ct=1)
NFS: dentry_delete(/bin, 0)
NFS: nfs_fhget(0:15/983041 ct=1)
NFS: dentry_delete(/home, 0)
NFS: nfs_fhget(0:15/999425 ct=1)
NFS: dentry_delete(/initrd, 0)
NFS: dentry_delete(/mnt, 8)
NFS: nfs_fhget(0:15/1048577 ct=1)
NFS: dentry_delete(/opt, 0)
NFS: nfs_fhget(0:15/1064961 ct=1)
NFS: dentry_delete(/sbin, 0)
NFS: nfs_fhget(0:15/13811717 ct=1)
NFS: dentry_delete(/misc, 0)
NFS: nfs_fhget(0:15/12877854 ct=1)
NFS: dentry_delete(/.automount, 0)
NFS: nfs_fhget(0:15/9207876 ct=1)
NFS: dentry_delete(/tftpboot, 0)
NFS: nfs_fhget(0:15/12 ct=1)
NFS: dentry_delete(/.autofsck, 0)
NFS: nfs_fhget(0:15/49430 ct=1)
NFS: dentry_delete(/swap, 0)
NFS: nfs_fhget(0:15/13435097 ct=1)
NFS: dentry_delete(/rpms, 0)
NFS: nfs_fhget(0:15/14 ct=1)
NFS: dentry_delete(/.fonts.cache-1, 0)
NFS: readdir(/) returns 0
NFS: permission(0:15/2), mask=0x1, res=0
NFS: dentry_delete(/lost+found, 8)
NFS: permission(0:15/2), mask=0x1, res=0
NFS: lookup(/boot)
NFS: nfs_update_inode(0:15/2 ct=1 info=0x6)
NFS: nfs_fhget(0:15/32769 ct=1)
NFS: dentry_delete(/boot, 0)
NFS: permission(0:15/2), mask=0x1, res=0
NFS: dentry_delete(/dev, 8)
NFS: permission(0:15/2), mask=0x1, res=0
NFS: lookup(/proc)
NFS: nfs_fhget(0:15/131073 ct=1)
NFS: dentry_delete(/proc, 0)
NFS: permission(0:15/2), mask=0x1, res=0
NFS: dentry_delete(/usr, 8)
NFS: permission(0:15/2), mask=0x1, res=0
NFS: dentry_delete(/var, 8)
NFS: permission(0:15/2), mask=0x1, res=0
NFS: dentry_delete(/tmp, 8)
NFS: permission(0:15/2), mask=0x1, res=0
NFS: dentry_delete(/etc, 8)
NFS: permission(0:15/2), mask=0x1, res=0
NFS: dentry_delete(/root, 8)
NFS: permission(0:15/2), mask=0x1, res=0
NFS: dentry_delete(/lib, 8)
NFS: permission(0:15/2), mask=0x1, res=0
NFS: dentry_delete(/bin, 8)
NFS: permission(0:15/2), mask=0x1, res=0
NFS: dentry_delete(/home, 8)
NFS: permission(0:15/2), mask=0x1, res=0
NFS: dentry_delete(/initrd, 8)
NFS: permission(0:15/2), mask=0x1, res=0
NFS: dentry_delete(/mnt, 8)
NFS: permission(0:15/2), mask=0x1, res=0
NFS: dentry_delete(/opt, 8)
NFS: permission(0:15/2), mask=0x1, res=0
NFS: dentry_delete(/sbin, 8)
NFS: permission(0:15/2), mask=0x1, res=0
NFS: dentry_delete(/misc, 8)
NFS: permission(0:15/2), mask=0x1, res=0
NFS: dentry_delete(/tftpboot, 8)
NFS: permission(0:15/2), mask=0x1, res=0
NFS: lookup(/sys)
NFS: nfs_fhget(0:15/17842177 ct=1)
NFS: dentry_delete(/sys, 0)
NFS: permission(0:15/2), mask=0x1, res=0
NFS: dentry_delete(/swap, 8)
NFS: permission(0:15/2), mask=0x1, res=0
NFS: dentry_delete(/rpms, 8)
NFS: readdir(/) starting at cookie 26
NFS: readdir(/) returns 0
--> nfs_free_server()
--> nfs_put_client({1})
--> nfs_free_client(3)
<-- nfs_free_client()
<-- nfs_free_server()
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-15 17:48 ` 2.6.18-rc4-mm1 Andrew Morton
@ 2006-08-15 18:35 ` David Howells
2006-08-15 18:49 ` 2.6.18-rc4-mm1 Andrew Morton
0 siblings, 1 reply; 80+ messages in thread
From: David Howells @ 2006-08-15 18:35 UTC (permalink / raw)
To: Andrew Morton; +Cc: David Howells, linux-kernel, Trond Myklebust, Ian Kent
Andrew Morton <akpm@osdl.org> wrote:
> NFS: nfs_fhget(0:15/0 ct=1)
That's the dummy root dentry (attached to s_root) which we don't actually use
for anything.
> NFS: nfs_fhget(0:15/2 ct=1)
That's the actual root of the subtree for this mount (inode 2).
> SELinux: initialized (dev 0:15, type nfs), uses genfs_contexts
I wonder if this is something to do with it. I run my testbox with SELinux
disabled since it won't boot if it's turned on (udev takes so long to run that
it gets backgrounded and then fsck tries to run, but can't find any blockdev
files). Can you try turning SELinux off (booting with selinux=0 on the kernel
command line might do it).
> NFS: nfs_update_inode(0:15/2 ct=1 info=0x6)
Update the root inode from attributes with NFS_ATTR_FATTR_V3|NFS_ATTR_FATTR.
> NFS: permission(0:15/2), mask=0x1, res=0
> NFS: permission(0:15/2), mask=0x1, res=0
Check MAY_EXEC on root. It all looks reasonable to this point.
> NFS: lookup(/usr)
But _why_? This is very strange. We shouldn't be looking at bix:/usr yet
because we haven't read the directory and we can't know it exists yet.
Also, why isn't there a call to nfs_fhget() for bix:/usr?
> NFS: permission(0:15/2), mask=0x3, res=0
Though it appears we do have permission to write and exec the directory (I
assume that mask=0x3 -> MAY_WRITE|MAY_EXEC), though *why* we'd be trying to do
that, I don't know.
> NFS: dentry_delete(/usr, 0)
> NFS: permission(0:15/2), mask=0x1, res=0
> NFS: permission(0:15/2), mask=0x1, res=0
Again, check MAY_EXEC on the root dir.
> NFS: lookup(/mnt)
And again: _why_? We shouldn't know about bix:/mnt either.
> NFS: permission(0:15/2), mask=0x3, res=0
Again we're asking for MAY_WRITE permission as well as MAY_EXEC.
> NFS: dentry_delete(/mnt, 0)
> NFS: nfs_update_inode(0:15/2 ct=1 info=0x6)
> NFS: permission(0:15/2), mask=0x4, res=0
Check we have MAY_READ on the root dir.
> NFS: opendir(0:15/2)
And open it for reading.
> NFS: readdir(/) starting at cookie 0
Okay... read some entries from the directory.
> NFS: nfs_fhget(0:15/11 ct=1)
> NFS: dentry_delete(/lost+found, 0)
> NFS: nfs_fhget(0:15/65537 ct=1)
> NFS: dentry_delete(/dev, 0)
Go through the first two, which looks fine.
> NFS: dentry_delete(/usr, 8)
And then we read bix:/usr, but don't call nfs_fhget() - which is should be
reasonable since we fetched it earlier. Note that the dentry specifies
DCACHE_REFERENCED in d_flags.
> NFS: nfs_fhget(0:15/196609 ct=1)
> NFS: dentry_delete(/var, 0)
And this looks fine.
> ...
> NFS: permission(0:15/2), mask=0x1, res=0
> NFS: dentry_delete(/usr, 8)
Then we come to stat bix:/usr, and this looks fine.
On the basis of nfs_lookup() apparently not calling nfs_fhget() for the first
lookup of /usr, can you stick a printk() at the end of nfs_lookup() (in
fs/nfs/dir.c), just before the return-statement so that it prints out the
return value. And can you make nfs_lookup() print nd->flags on entry?
I'm wondering if autofs4 is trying to create a couple of directories in the
NFS share, though I can't think why it would. Uncommenting:
/* #define DEBUG */
in fs/autofs4/autofs_i.h might also be informative.
David
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-15 18:35 ` 2.6.18-rc4-mm1 David Howells
@ 2006-08-15 18:49 ` Andrew Morton
2006-08-15 19:20 ` 2.6.18-rc4-mm1 David Howells
2006-08-16 9:34 ` 2.6.18-rc4-mm1 David Howells
0 siblings, 2 replies; 80+ messages in thread
From: Andrew Morton @ 2006-08-15 18:49 UTC (permalink / raw)
To: David Howells; +Cc: linux-kernel, Trond Myklebust, Ian Kent
On Tue, 15 Aug 2006 19:35:20 +0100
David Howells <dhowells@redhat.com> wrote:
> > SELinux: initialized (dev 0:15, type nfs), uses genfs_contexts
>
> I wonder if this is something to do with it.
`echo 0 > /selinux/enforce' "fixes" it.
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-15 18:49 ` 2.6.18-rc4-mm1 Andrew Morton
@ 2006-08-15 19:20 ` David Howells
2006-08-16 9:34 ` 2.6.18-rc4-mm1 David Howells
1 sibling, 0 replies; 80+ messages in thread
From: David Howells @ 2006-08-15 19:20 UTC (permalink / raw)
To: Andrew Morton; +Cc: David Howells, linux-kernel, Trond Myklebust, Ian Kent
Andrew Morton <akpm@osdl.org> wrote:
> > > SELinux: initialized (dev 0:15, type nfs), uses genfs_contexts
> >
> > I wonder if this is something to do with it.
>
> `echo 0 > /selinux/enforce' "fixes" it.
Interesting.........................
Looks like a need to find myself a new testbox - one that can cope with both
SELinux *and* udev.
I wonder what SELinux is doing...
David
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 2.6.18-rc4-mm1
[not found] <fa.nURugTWtyfQKAbvUB0DbTkmyPAY@ifi.uio.no>
@ 2006-08-16 2:57 ` Robert Hancock
2006-08-16 4:26 ` 2.6.18-rc4-mm1 Andrew Morton
2006-08-16 19:41 ` 2.6.18-rc4-mm1 Len Brown
0 siblings, 2 replies; 80+ messages in thread
From: Robert Hancock @ 2006-08-16 2:57 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm1/
Warnings and an oops on suspend to disk:
http://www.roberthancock.com/oops1.jpg
http://www.roberthancock.com/oops2.jpg
http://www.roberthancock.com/oops3.jpg
http://www.roberthancock.com/oops4.jpg
http://www.roberthancock.com/oops5.jpg
http://www.roberthancock.com/oops6.jpg
http://www.roberthancock.com/oops7.jpg
http://www.roberthancock.com/oops8.jpg
Sleeping function called from invalid context in acpi and kernel NULL
pointer dereference in _raw_spin_lock from generic_unplug_device, with
some "DWARF2 unwinder stuck" errors for good measure..
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-16 2:57 ` 2.6.18-rc4-mm1 Robert Hancock
@ 2006-08-16 4:26 ` Andrew Morton
2006-08-16 4:29 ` 2.6.18-rc4-mm1 Dave Jones
2006-08-16 23:18 ` 2.6.18-rc4-mm1 Robert Hancock
2006-08-16 19:41 ` 2.6.18-rc4-mm1 Len Brown
1 sibling, 2 replies; 80+ messages in thread
From: Andrew Morton @ 2006-08-16 4:26 UTC (permalink / raw)
To: Robert Hancock; +Cc: linux-kernel
On Tue, 15 Aug 2006 20:57:13 -0600
Robert Hancock <hancockr@shaw.ca> 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/
>
> Warnings and an oops on suspend to disk:
>
> http://www.roberthancock.com/oops1.jpg
> http://www.roberthancock.com/oops2.jpg
> http://www.roberthancock.com/oops3.jpg
> http://www.roberthancock.com/oops4.jpg
> http://www.roberthancock.com/oops5.jpg
> http://www.roberthancock.com/oops6.jpg
> http://www.roberthancock.com/oops7.jpg
> http://www.roberthancock.com/oops8.jpg
>
> Sleeping function called from invalid context in acpi
Yes. It appears that we've decided to release 2.6.18 with this feature.
> and kernel NULL
> pointer dereference in _raw_spin_lock from generic_unplug_device,
Would you be using swap-over-DM?
> with
> some "DWARF2 unwinder stuck" errors for good measure..
And this one.
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-16 4:26 ` 2.6.18-rc4-mm1 Andrew Morton
@ 2006-08-16 4:29 ` Dave Jones
2006-08-24 19:46 ` 2.6.18-rc4-mm1 Pavel Machek
2006-08-16 23:18 ` 2.6.18-rc4-mm1 Robert Hancock
1 sibling, 1 reply; 80+ messages in thread
From: Dave Jones @ 2006-08-16 4:29 UTC (permalink / raw)
To: Andrew Morton; +Cc: Robert Hancock, linux-kernel
On Tue, Aug 15, 2006 at 09:26:56PM -0700, Andrew Morton wrote:
> On Tue, 15 Aug 2006 20:57:13 -0600
> Robert Hancock <hancockr@shaw.ca> 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/
> >
> > Warnings and an oops on suspend to disk:
> >
> > http://www.roberthancock.com/oops1.jpg
> > http://www.roberthancock.com/oops2.jpg
> > http://www.roberthancock.com/oops3.jpg
> > http://www.roberthancock.com/oops4.jpg
> > http://www.roberthancock.com/oops5.jpg
> > http://www.roberthancock.com/oops6.jpg
> > http://www.roberthancock.com/oops7.jpg
> > http://www.roberthancock.com/oops8.jpg
> >
> > Sleeping function called from invalid context in acpi
>
> Yes. It appears that we've decided to release 2.6.18 with this feature.
Well it's not like it'd be a regression. That thing has been there
for over a year now at least in one form or other.
Dave
--
http://www.codemonkey.org.uk
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-15 18:49 ` 2.6.18-rc4-mm1 Andrew Morton
2006-08-15 19:20 ` 2.6.18-rc4-mm1 David Howells
@ 2006-08-16 9:34 ` David Howells
2006-08-16 10:00 ` 2.6.18-rc4-mm1 David Howells
2006-08-16 12:36 ` 2.6.18-rc4-mm1 Ian Kent
1 sibling, 2 replies; 80+ messages in thread
From: David Howells @ 2006-08-16 9:34 UTC (permalink / raw)
To: Andrew Morton; +Cc: David Howells, linux-kernel, Trond Myklebust, Ian Kent
Andrew Morton <akpm@osdl.org> wrote:
> > > SELinux: initialized (dev 0:15, type nfs), uses genfs_contexts
> >
> > I wonder if this is something to do with it.
>
> `echo 0 > /selinux/enforce' "fixes" it.
Aha!!!!
[root@andromeda ~]# ls -l /net/trash
total 87
drwxr-xr-x 2 root root 3072 Aug 10 04:10 bin/
drwxr-xr-x 2 root root 1024 Aug 1 16:13 boot/
drwxr-xr-x 2 root root 1024 Aug 1 16:13 dev/
drwxr-xr-x 133 root root 10240 Aug 16 10:01 etc/
drwxr-xr-x 2 root root 1024 Jul 12 09:48 home/
drwxr-xr-x 12 root root 7168 Aug 10 04:10 lib/
drwxrwsr-x 2 root cambridge 1024 Aug 1 20:41 local/
drwx------ 2 root root 12288 Aug 1 16:12 lost+found/
drwxr-xr-x 2 root root 1024 Jul 12 09:48 media/
drwxr-xr-x 2 root root 1024 Jul 24 14:17 misc/
dr-xr-xr-x 2 root root 1024 Aug 3 09:35 net/
dr-xr-xr-x 2 root root 1024 Aug 9 16:27 netopt/
?--------- ? ? ? ? ? /net/trash/mnt
?--------- ? ? ? ? ? /net/trash/usr
drwxr-xr-x 2 root root 1024 Jul 12 09:48 opt/
drwxr-xr-x 2 root root 1024 Aug 1 16:13 proc/
dr-xr-xr-x 2 root root 1024 Aug 3 09:26 project/
drwxr-x--- 4 root root 1024 Aug 16 09:59 root/
drwxr-xr-x 2 root root 11264 Aug 10 04:10 sbin/
drwxr-xr-x 2 root root 1024 Aug 1 16:13 selinux/
drwxr-xr-x 2 root root 1024 Jul 12 09:48 srv/
drwxr-xr-x 2 root root 1024 Aug 1 16:13 sys/
drwxr-xr-x 3 root root 1024 Aug 1 20:27 tftpboot/
drwxrwxrwt 4 root root 3072 Aug 16 09:46 tmp/
drwxr-xr-x 29 root root 1024 Aug 1 19:56 var/
drwxr-xr-x 2 root root 1024 Aug 9 11:35 warthog/
Look familiar?
Requires: autofs4, nfs and SELinux in enforcing mode.
Check your audit logs. I knew auditing had to be good for something...
| pid 3500: autofs4_lookup: name = trash
| pid 3500: autofs4_lookup: pid = 3500, pgrp = 3500, catatonic = 0, oz_mode = 0
| pid 3500: try_to_fill_dentry: dentry=c0887354 trash ino=00000000
| pid 3500: try_to_fill_dentry: waiting for mount name=trash
| pid 3500: autofs4_wait: new wait id = 0x00000003, name = trash, nfy=1
|
| pid 3500: autofs4_notify_daemon: wait id = 0x00000003, name = trash, type=0
| audit(1155719601.431:214): avc: denied { read } for pid=3503 comm="showmount" name="cambridge-temp.redhat.com.2" dev=hda2 ino=688243 scontext=root:system_r:automount_t:s0 tcontext=system_u:object_r:var_yp_t:s0 tclass=file
| audit(1155719601.483:215): avc: denied { name_bind } for pid=3503 comm="showmount" src=712 scontext=root:system_r:automount_t:s0 tcontext=system_u:object_r:reserved_port_t:s0 tclass=udp_socket
| audit(1155719601.543:216): avc: denied { read } for pid=3501 comm="automount" name="cambridge-temp.redhat.com.2" dev=hda2 ino=688243 scontext=root:system_r:automount_t:s0 tcontext=system_u:object_r:var_yp_t:s0 tclass=file
| audit(1155719601.567:217): avc: denied { name_bind } for pid=3501 comm="automount" src=710 scontext=root:system_r:automount_t:s0 tcontext=system_u:object_r:reserved_port_t:s0 tclass=udp_socket
| pid 3501: autofs4_dir_mkdir: dentry c0887354, creating trash
| audit(1155719601.627:218): avc: denied { read } for pid=3507 comm="mount" name="cambridge-temp.redhat.com.2" dev=hda2 ino=688243 scontext=root:system_r:mount_t:s0 tcontext=system_u:object_r:var_yp_t:s0 tclass=file
Autofs magic up to this point.
| --> nfs_init_server()
| --> nfs_get_client(trash,172.16.18.103:264,3)
| --> nfs_get_client() = c0703800 [new]
| SELinux: initialized (dev rpc_pipefs, type rpc_pipefs), uses genfs_contexts
| <-- nfs_init_server() = 0 [new c0703800]
That created and initialised an NFS common client and FSID-specific client
struct (struct nfs_server).
| --> nfs_probe_fsinfo()
| <-- nfs_probe_fsinfo() = 0
| Server FSID: 303:0
Determine the FSID.
| NFS: nfs_fhget(0:18/0 ct=1)
Get the dummy root (s_root).
| NFS: nfs_fhget(0:18/2 ct=1)
Get the actual root (inode 2).
| SELinux: initialized (dev 0:18, type nfs), uses genfs_contexts
And that's the NFS superblock set up.
| pid 3507: autofs4_dentry_release: releasing c0c13514
| pid 3507: autofs4_lookup: name = trash:
| pid 3507: autofs4_lookup: pid = 3507, pgrp = 3207, catatonic = 0, oz_mode = 1
| audit(1155719601.775:219): avc: denied { read } for pid=3501 comm="automount" name="cambridge-temp.redhat.com.2" dev=hda2 ino=688243 scontext=root:system_r:automount_t:s0 tcontext=system_u:object_r:var_yp_t:s0 tclass=file
| audit(1155719601.799:220): avc: denied { name_bind } for pid=3501 comm="automount" src=713 scontext=root:system_r:automount_t:s0 tcontext=system_u:object_r:reserved_port_t:s0 tclass=udp_socket
| NFS: nfs_update_inode(0:18/2 ct=1 info=0x6)
| NFS: permission(0:18/2), mask=0x1, res=0
Looks reasonable up to here.
| NFS: permission(0:18/2), mask=0x1, res=0
| NFS: lookup(/usr)
| NFS: permission(0:18/2), mask=0x3, res=0
| audit(1155719601.839:221): avc: denied { write } for pid=3501 comm="automount" name="" dev=0:18 ino=2 scontext=root:system_r:automount_t:s0 tcontext=system_u:object_r:nfs_t:s0 tclass=dir
| NFS: dentry_delete(/usr, 0)
| audit(1155719601.867:222): avc: denied { read } for pid=3501 comm="automount" name="cambridge-temp.redhat.com.2" dev=hda2 ino=688243 scontext=root:system_r:automount_t:s0 tcontext=system_u:object_r:var_yp_t:s0 tclass=file
| audit(1155719601.891:223): avc: denied { name_bind } for pid=3501 comm="automount" src=715 scontext=root:system_r:automount_t:s0 tcontext=system_u:object_r:reserved_port_t:s0 tclass=udp_socket
It seems that the automounter is attempting to do things to /usr.
| NFS: permission(0:18/2), mask=0x1, res=0
| NFS: permission(0:18/2), mask=0x1, res=0
| NFS: lookup(/mnt)
| NFS: permission(0:18/2), mask=0x3, res=0
| audit(1155719601.927:224): avc: denied { write } for pid=3501 comm="automount" name="" dev=0:18 ino=2 scontext=root:system_r:automount_t:s0 tcontext=system_u:object_r:nfs_t:s0 tclass=dir
| NFS: dentry_delete(/mnt, 0)
And /mnt.
| pid 3207: autofs4_root_ioctl: cmd = 0x00009360, arg = 0x00000003, sbi = c54beaa0, pgrp = 3207
| pid 3500: try_to_fill_dentry: mount done status=0
| NFS: nfs_update_inode(0:18/2 ct=1 info=0x6)
| NFS: permission(0:18/2), mask=0x4, res=0
| NFS: opendir(0:18/2)
| NFS: readdir(/) starting at cookie 0
| NFS: nfs_update_inode(0:18/2 ct=1 info=0x6)
| NFS: nfs_fhget(0:18/2502657 ct=1)
| NFS: dentry_delete(/local, 0)
| NFS: nfs_fhget(0:18/10770433 ct=1)
| NFS: dentry_delete(/srv, 0)
| NFS: nfs_fhget(0:18/11 ct=1)
| NFS: dentry_delete(/lost+found, 0)
| NFS: nfs_fhget(0:18/10317825 ct=1)
| NFS: dentry_delete(/tmp, 0)
| NFS: nfs_fhget(0:18/2541569 ct=1)
| NFS: dentry_delete(/bin, 0)
| NFS: nfs_fhget(0:18/7063553 ct=1)
| NFS: dentry_delete(/media, 0)
| NFS: nfs_fhget(0:18/2594817 ct=1)
| NFS: dentry_delete(/lib, 0)
| NFS: nfs_fhget(0:18/10704897 ct=1)
| NFS: dentry_delete(/var, 0)
| NFS: dentry_delete(/usr, 8)
| NFS: dentry_delete(/mnt, 8)
And then it proceeds as normal, barring the fack that the dentried for
trash:/usr and trash:/mnt already exist.
Putting SELinux into permissive mode, I see:
: pid 3376: autofs4_lookup: name = trash
: pid 3376: autofs4_lookup: pid = 3376, pgrp = 3376, catatonic = 0, oz_mode = 0
: pid 3376: try_to_fill_dentry: dentry=c56874b4 trash ino=00000000
: pid 3376: try_to_fill_dentry: waiting for mount name=trash
: pid 3376: autofs4_wait: new wait id = 0x00000001, name = trash, nfy=1
:
: pid 3376: autofs4_notify_daemon: wait id = 0x00000001, name = trash, type=0
: pid 3377: autofs4_dir_mkdir: dentry c56874b4, creating trash
: audit(1155719382.989:183): avc: denied { read } for pid=3383 comm="mount" name="cambridge-temp.redhat.com.2" dev=hda2 ino=688243 scontext=root:system_r:mount_t:s0 tcontext=system_u:object_r:var_yp_t:s0 tclass=file
: --> nfs_init_server()
: --> nfs_get_client(trash,172.16.18.103:264,3)
: --> nfs_get_client() = c752e000 [new]
: SELinux: initialized (dev rpc_pipefs, type rpc_pipefs), uses genfs_contexts
: <-- nfs_init_server() = 0 [new c752e000]
: --> nfs_probe_fsinfo()
: <-- nfs_probe_fsinfo() = 0
: Server FSID: 303:0
: NFS: nfs_fhget(0:18/0 ct=1)
: NFS: nfs_fhget(0:18/2 ct=1)
: SELinux: initialized (dev 0:18, type nfs), uses genfs_contexts
: pid 3383: autofs4_lookup: name = trash:
: pid 3383: autofs4_lookup: pid = 3383, pgrp = 3207, catatonic = 0, oz_mode = 1
: NFS: nfs_update_inode(0:18/2 ct=1 info=0x6)
: NFS: permission(0:18/2), mask=0x1, res=0
Looks okay up to here.
: NFS: permission(0:18/2), mask=0x1, res=0
: NFS: lookup(/usr)
: NFS: permission(0:18/2), mask=0x3, res=0
: audit(1155719383.149:184): avc: denied { write } for pid=3377 comm="automount" name="" dev=0:18 ino=2 scontext=root:system_r:automount_t:s0 tcontext=system_u:object_r:nfs_t:s0 tclass=dir
: audit(1155719383.165:185): avc: denied { add_name } for pid=3377 comm="automount" name="usr" scontext=root:system_r:automount_t:s0 tcontext=system_u:object_r:nfs_t:s0 tclass=dir
: audit(1155719383.181:186): avc: denied { create } for pid=3377 comm="automount" name="usr" scontext=root:system_r:automount_t:s0 tcontext=root:object_r:nfs_t:s0 tclass=dir
: NFS: mkdir(0:18/2), usr
What is going on here?????????????????????????????????????????????????????
stracing the automount daemon, I see:
[pid 3803] mkdir("/net", 0555) = -1 EEXIST (File exists)
[pid 3803] stat64("/net", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
[pid 3803] mkdir("/net/trash", 0555) = -1 EEXIST (File exists)
[pid 3803] stat64("/net/trash", {st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0
[pid 3803] mkdir("/net/trash/usr", 0555) = -1 EACCES (Permission denied)
I think that would be the problem. Ian?
David
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-16 9:34 ` 2.6.18-rc4-mm1 David Howells
@ 2006-08-16 10:00 ` David Howells
2006-08-16 12:23 ` 2.6.18-rc4-mm1 David Howells
2006-08-16 12:36 ` 2.6.18-rc4-mm1 Ian Kent
1 sibling, 1 reply; 80+ messages in thread
From: David Howells @ 2006-08-16 10:00 UTC (permalink / raw)
To: Ian Kent; +Cc: Andrew Morton, linux-kernel, Trond Myklebust, David Howells
Hi Ian,
I think this is probably a problem with the automounter daemon.
What I think happens is this:
(1) I've got an NFS server (trash) with the following configuration:
[root@trash dhowells]# cat /etc/exports
/ *(rw,async)
/usr/src *(rw,async)
/mnt/export *(rw,async)
(2) I do "ls -l" on the client to use the automounter to view the root NFS
share on the machine.
(3) The automounter makes /net/trash and mounts trash:/ on it.
(4) The automount daemon asks the server what other shares it has available.
(5) For each share, the automounter attempts to create the directories on
which to mount it:
SHARE DIRECTORIES TO BE CREATED
======================= =============================================
trash:/usr/src /net/trash/usr, /net/trash/usr/src
trash:/mnt/exports /net/trash/mnt, /net/trash/mnt/exports
(6) The automount daemon issued mkdir() syscalls to create these directories,
_despite_ the fact that it is doing so in a mounted filesystem.
(7) SELinux prohibits the mkdir() syscall by refusing write permission on the
directory.
(8) An unconstructed dentry is left, which causes the "?---------" lines to
appear in the ls -l listing.
With the new internal automounting code in NFS, the automounter shouldn't
attempt to do step (4) onwards for submounts as the NFS filesystem itself will
take care of that.
And, in my opinion, it shouldn't be attempting to create directories on the
server.
However, (8) might well represent a bug in NFS.
David
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-16 10:00 ` 2.6.18-rc4-mm1 David Howells
@ 2006-08-16 12:23 ` David Howells
2006-08-16 12:58 ` 2.6.18-rc4-mm1 Ian Kent
0 siblings, 1 reply; 80+ messages in thread
From: David Howells @ 2006-08-16 12:23 UTC (permalink / raw)
To: David Howells; +Cc: Ian Kent, Andrew Morton, linux-kernel, Trond Myklebust
David Howells <dhowells@redhat.com> wrote:
> ...
> (8) An unconstructed dentry is left, which causes the "?---------" lines to
> appear in the ls -l listing.
> ...
> However, (8) might well represent a bug in NFS.
I've done some investigation into this:
The automount point before mounting has one security label and another after
mounting:
[root@andromeda ~]# ls -Zd /net/trash
dr-xr-xr-x root root system_u:object_r:autofs_t /net/trash/
[root@andromeda ~]# ls -l /net/trash
total 87
drwxr-xr-x 2 root root 3072 Aug 10 04:10 bin/
drwxr-xr-x 2 root root 1024 Aug 1 16:13 boot/
drwxr-xr-x 2 root root 1024 Aug 1 16:13 dev/
drwxr-xr-x 133 root root 10240 Aug 16 12:36 etc/
drwxr-xr-x 2 root root 1024 Jul 12 09:48 home/
drwxr-xr-x 12 root root 7168 Aug 10 04:10 lib/
drwxrwsr-x 2 root cambridge 1024 Aug 1 20:41 local/
drwx------ 2 root root 12288 Aug 1 16:12 lost+found/
drwxr-xr-x 2 root root 1024 Jul 12 09:48 media/
drwxr-xr-x 2 root root 1024 Jul 24 14:17 misc/
dr-xr-xr-x 2 root root 1024 Aug 3 09:35 net/
dr-xr-xr-x 2 root root 1024 Aug 9 16:27 netopt/
?--------- ? ? ? ? ? /net/trash/mnt
?--------- ? ? ? ? ? /net/trash/usr
drwxr-xr-x 2 root root 1024 Jul 12 09:48 opt/
drwxr-xr-x 2 root root 1024 Aug 1 16:13 proc/
dr-xr-xr-x 2 root root 1024 Aug 3 09:26 project/
drwxr-x--- 7 root root 1024 Aug 16 11:49 root/
drwxr-xr-x 2 root root 11264 Aug 10 04:10 sbin/
drwxr-xr-x 2 root root 1024 Aug 1 16:13 selinux/
drwxr-xr-x 2 root root 1024 Jul 12 09:48 srv/
drwxr-xr-x 2 root root 1024 Aug 1 16:13 sys/
drwxr-xr-x 3 root root 1024 Aug 1 20:27 tftpboot/
drwxrwxrwt 4 root root 3072 Aug 16 11:49 tmp/
drwxr-xr-x 29 root root 1024 Aug 1 19:56 var/
drwxr-xr-x 2 root root 1024 Aug 9 11:35 warthog/
[root@andromeda ~]# ls -Zd /net/trash
drwxr-xr-x root root system_u:object_r:nfs_t /net/trash/
Automount daemons all have the automount_t label:
[root@andromeda ~]# ps -Zaux | grep automount
Warning: bad syntax, perhaps a bogus '-'? See /usr/share/doc/procps-3.2.6/FAQ
root:system_r:automount_t root ... /usr/sbin/automount --timeout=60
root:system_r:automount_t root ... /usr/sbin/automount --timeout=60
root:system_r:automount_t root ... /usr/sbin/automount --timeout=60
root:system_r:automount_t root ... /usr/sbin/automount --timeout=60
I added this patch to instrument nfs_lookup():
--- fs/nfs/dir.c.orig 2006-08-14 09:08:28.000000000 +0100
+++ fs/nfs/dir.c 2006-08-16 12:49:20.000000000 +0100
@@ -890,6 +890,10 @@ static struct dentry *nfs_lookup(struct
struct nfs_fh fhandle;
struct nfs_fattr fattr;
+ printk("-->nfs_lookup(%s,%s,{%x,%x,%x})\n",
+ dentry->d_parent->d_name.name, dentry->d_name.name,
+ nd->flags, nd->intent.open.flags, nd->intent.open.create_mode);
+
dfprintk(VFS, "NFS: lookup(%s/%s)\n",
dentry->d_parent->d_name.name, dentry->d_name.name);
nfs_inc_stats(dir, NFSIOS_VFSLOOKUP);
@@ -904,8 +908,10 @@ static struct dentry *nfs_lookup(struct
lock_kernel();
/* If we're doing an exclusive create, optimize away the lookup */
- if (nfs_is_exclusive_create(dir, nd))
+ if (nfs_is_exclusive_create(dir, nd)) {
+ printk("exlusive_create\n");
goto no_entry;
+ }
error = NFS_PROTO(dir)->lookup(dir, &dentry->d_name, &fhandle, &fattr);
if (error == -ENOENT)
@@ -933,6 +939,7 @@ no_entry:
out_unlock:
unlock_kernel();
out:
+ printk("<--nfs_lookup() = %p\n", res);
return res;
}
And saw the following appear in the kernel log around the problem bit for
trash:/usr:
| ...
| SELinux: initialized (dev 0:18, type nfs), uses genfs_contexts
| audit(1155729189.533:468): avc: denied { read } for pid=6472 comm="automount" name="cambridge-temp.redhat.com.2" dev=hda2 ino=688243 scontext=root:system_r:automount_t:s0 tcontext=system_u:object_r:var_yp_t:s0 tclass=file
| audit(1155729189.557:469): avc: denied { name_bind } for pid=6472 comm="automount" src=716 scontext=root:system_r:automount_t:s0 tcontext=system_u:object_r:reserved_port_t:s0 tclass=udp_socket
Not sure what's going on here. The automounter tried to do bind a socket to a
reserved port perhaps and was denied.
| NFS: nfs_update_inode(0:18/2 ct=1 info=0x6)
| NFS: permission(0:18/2), mask=0x1, res=0
sys_mkdirat() calls do_path_lookup(), which checks MAY_EXEC on the dir.
| NFS: permission(0:18/2), mask=0x1, res=0
lookup_create() is called. This calls __lookup_hash(), which checks MAY_EXEC
on the dir.
| -->nfs_lookup(,usr,{200,80,44e3069a})
__lookup_hash() then looks up the new dentry with intent to create:
VARIABLE VALUE
=============================== ===============================
nd->flags LOOKUP_CREATE
nd->intent.open.flags O_EXCL
nd->intent.open.create_mode weird value, even in octal
This means that nfs_lookup() considers this to be "an exclusive create" of
this node, and dispenses with the LOOKUP RPC call to the server.
| NFS: lookup(/usr)
| exlusive_create
Just to confirm that the lookup is skipped.
| <--nfs_lookup() = 00000000
We return the dentry we were given, but don't return an error. The dentry we
were given is left negative (on the assumption it's about to be created), but
does get attached to the directory.
| NFS: permission(0:18/2), mask=0x3, res=0
vfs_mkdir() calls may_create() which checks that the directory has MAY_WRITE
and MAY_EXEC permissions. This firstly calls nfs_permission, which grants
permission.
| audit(1155729189.605:470): avc: denied { write } for pid=6472 comm="automount" name="" dev=0:18 ino=2 scontext=root:system_r:automount_t:s0 tcontext=system_u:object_r:nfs_t:s0 tclass=dir
And secondly calls security_inode_permission() though which SELinux which
_denies_ permission.
| NFS: dentry_delete(/usr, 0)
vfs_mkdir() returns -ENOACCES to sys_mkdirat() which releases its hold on the
dentry, but leaves the negative dentry attached to the directory.
The negative dentry wouldn't normally be a problem, even though it's attached
to its parent directory... except for the small matter that it's subsequently
listed in a directory read operation.
However, the dcache still retains the negative dentry. I'm not sure how to
deal with this. I think nfs_lookup() _must_ contact the server and prefill
the dentry if it can. Trond?
David
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-16 9:34 ` 2.6.18-rc4-mm1 David Howells
2006-08-16 10:00 ` 2.6.18-rc4-mm1 David Howells
@ 2006-08-16 12:36 ` Ian Kent
1 sibling, 0 replies; 80+ messages in thread
From: Ian Kent @ 2006-08-16 12:36 UTC (permalink / raw)
To: David Howells; +Cc: Andrew Morton, linux-kernel, Trond Myklebust
On Wed, 2006-08-16 at 10:34 +0100, David Howells wrote:
> Andrew Morton <akpm@osdl.org> wrote:
>
....
> What is going on here?????????????????????????????????????????????????????
>
> stracing the automount daemon, I see:
>
> [pid 3803] mkdir("/net", 0555) = -1 EEXIST (File exists)
> [pid 3803] stat64("/net", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
> [pid 3803] mkdir("/net/trash", 0555) = -1 EEXIST (File exists)
> [pid 3803] stat64("/net/trash", {st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0
> [pid 3803] mkdir("/net/trash/usr", 0555) = -1 EACCES (Permission denied)
>
> I think that would be the problem. Ian?
I guess, but it's also possible that multi-entry mounts similar to those
generated by the auto.net script need mount point directories created.
The same code is used for all.
I guess that I could check if the fs is autofs4 and only mount the
mounts for directories that exist, as I do in v5. However, people may
have come to rely on this so it would be a regression, for v4 at least.
Thoughts?
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-16 12:23 ` 2.6.18-rc4-mm1 David Howells
@ 2006-08-16 12:58 ` Ian Kent
2006-08-16 13:20 ` 2.6.18-rc4-mm1 David Howells
0 siblings, 1 reply; 80+ messages in thread
From: Ian Kent @ 2006-08-16 12:58 UTC (permalink / raw)
To: David Howells; +Cc: Andrew Morton, linux-kernel, Trond Myklebust
On Wed, 2006-08-16 at 13:23 +0100, David Howells wrote:
> And saw the following appear in the kernel log around the problem bit for
> trash:/usr:
>
> | ...
> | SELinux: initialized (dev 0:18, type nfs), uses genfs_contexts
> | audit(1155729189.533:468): avc: denied { read } for pid=6472 comm="automount" name="cambridge-temp.redhat.com.2" dev=hda2 ino=688243 scontext=root:system_r:automount_t:s0 tcontext=system_u:object_r:var_yp_t:s0 tclass=file
> | audit(1155729189.557:469): avc: denied { name_bind } for pid=6472 comm="automount" src=716 scontext=root:system_r:automount_t:s0 tcontext=system_u:object_r:reserved_port_t:s0 tclass=udp_socket
>
> Not sure what's going on here. The automounter tried to do bind a socket to a
> reserved port perhaps and was denied.
Possibly an RPC ping.
That's about the only thing I do that does net connects.
>
> | NFS: nfs_update_inode(0:18/2 ct=1 info=0x6)
> | NFS: permission(0:18/2), mask=0x1, res=0
>
> sys_mkdirat() calls do_path_lookup(), which checks MAY_EXEC on the dir.
>
> | NFS: permission(0:18/2), mask=0x1, res=0
>
> lookup_create() is called. This calls __lookup_hash(), which checks MAY_EXEC
> on the dir.
>
> | -->nfs_lookup(,usr,{200,80,44e3069a})
>
> __lookup_hash() then looks up the new dentry with intent to create:
>
> VARIABLE VALUE
> =============================== ===============================
> nd->flags LOOKUP_CREATE
> nd->intent.open.flags O_EXCL
> nd->intent.open.create_mode weird value, even in octal
I'm fairly sure there's a race in autofs for the create case. I've tried
to work a solution in the past but haven't been successful yet. In any
case autofs should not allow anyone else besides the daemon to do
anything in the autofs fs. It's been a while but I think this case leads
to a deadlock.
>
> This means that nfs_lookup() considers this to be "an exclusive create" of
> this node, and dispenses with the LOOKUP RPC call to the server.
>
> | NFS: lookup(/usr)
> | exlusive_create
>
> Just to confirm that the lookup is skipped.
>
> | <--nfs_lookup() = 00000000
>
> We return the dentry we were given, but don't return an error. The dentry we
> were given is left negative (on the assumption it's about to be created), but
> does get attached to the directory.
>
> | NFS: permission(0:18/2), mask=0x3, res=0
>
> vfs_mkdir() calls may_create() which checks that the directory has MAY_WRITE
> and MAY_EXEC permissions. This firstly calls nfs_permission, which grants
> permission.
>
> | audit(1155729189.605:470): avc: denied { write } for pid=6472 comm="automount" name="" dev=0:18 ino=2 scontext=root:system_r:automount_t:s0 tcontext=system_u:object_r:nfs_t:s0 tclass=dir
>
> And secondly calls security_inode_permission() though which SELinux which
> _denies_ permission.
>
> | NFS: dentry_delete(/usr, 0)
>
> vfs_mkdir() returns -ENOACCES to sys_mkdirat() which releases its hold on the
> dentry, but leaves the negative dentry attached to the directory.
>
>
> The negative dentry wouldn't normally be a problem, even though it's attached
> to its parent directory... except for the small matter that it's subsequently
> listed in a directory read operation.
Surely this dentry should also be unhashed at some point.
Wouldn't that be a sensible result of the failed operation?
It wouldn't then show up in a listing and the fs should normally be able
to deal with these.
Ian
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-16 12:58 ` 2.6.18-rc4-mm1 Ian Kent
@ 2006-08-16 13:20 ` David Howells
0 siblings, 0 replies; 80+ messages in thread
From: David Howells @ 2006-08-16 13:20 UTC (permalink / raw)
To: Ian Kent; +Cc: David Howells, Andrew Morton, linux-kernel, Trond Myklebust
Ian Kent <raven@themaw.net> wrote:
> > The negative dentry wouldn't normally be a problem, even though it's
> > attached to its parent directory... except for the small matter that it's
> > subsequently listed in a directory read operation.
>
> Surely this dentry should also be unhashed at some point.
> Wouldn't that be a sensible result of the failed operation?
Why? The lookup op succeeded, so obviously there wasn't anything there,
right?
Note that nfs_lookup_revalidate() doesn't cause the dentry to be revalidated
because the mtime on the parent directory hasn't changed.
I'm considering having nfs_readdir_lookup() mark a negative dentry it
encounters as named in a directory listing for explicit revalidation, but I
can't call nfs_mark_for_revalidate() since I don't have an inode.
I think I'll need to add a dentry flag for this purpose.
David
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-16 2:57 ` 2.6.18-rc4-mm1 Robert Hancock
2006-08-16 4:26 ` 2.6.18-rc4-mm1 Andrew Morton
@ 2006-08-16 19:41 ` Len Brown
1 sibling, 0 replies; 80+ messages in thread
From: Len Brown @ 2006-08-16 19:41 UTC (permalink / raw)
To: Robert Hancock; +Cc: Andrew Morton, linux-kernel
On Tuesday 15 August 2006 22:57, Robert Hancock 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/
>
> Warnings and an oops on suspend to disk:
>
> http://www.roberthancock.com/oops1.jpg
> http://www.roberthancock.com/oops2.jpg
> http://www.roberthancock.com/oops3.jpg
> http://www.roberthancock.com/oops4.jpg
> http://www.roberthancock.com/oops5.jpg
> http://www.roberthancock.com/oops6.jpg
> http://www.roberthancock.com/oops7.jpg
> http://www.roberthancock.com/oops8.jpg
Re: acpi_os_wait_sempahore()
please try the patch here:
http://bugzilla.kernel.org/show_bug.cgi?id=6810
thanks,
-Len
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-16 4:26 ` 2.6.18-rc4-mm1 Andrew Morton
2006-08-16 4:29 ` 2.6.18-rc4-mm1 Dave Jones
@ 2006-08-16 23:18 ` Robert Hancock
1 sibling, 0 replies; 80+ messages in thread
From: Robert Hancock @ 2006-08-16 23:18 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
Andrew Morton wrote:
> On Tue, 15 Aug 2006 20:57:13 -0600
> Robert Hancock <hancockr@shaw.ca> 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/
>> Warnings and an oops on suspend to disk:
>>
>> http://www.roberthancock.com/oops1.jpg
>> http://www.roberthancock.com/oops2.jpg
>> http://www.roberthancock.com/oops3.jpg
>> http://www.roberthancock.com/oops4.jpg
>> http://www.roberthancock.com/oops5.jpg
>> http://www.roberthancock.com/oops6.jpg
>> http://www.roberthancock.com/oops7.jpg
>> http://www.roberthancock.com/oops8.jpg
>>
>> Sleeping function called from invalid context in acpi
>
> Yes. It appears that we've decided to release 2.6.18 with this feature.
>
>> and kernel NULL
>> pointer dereference in _raw_spin_lock from generic_unplug_device,
>
> Would you be using swap-over-DM?
Yes, swap is on LVM.. default Fedora Core 5 configuration.
>
>> with
>> some "DWARF2 unwinder stuck" errors for good measure..
>
> And this one.
>
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 2.6.18-rc4-mm1
2022-08-14 8:42 ` 2.6.18-rc4-mm1 Maciej Rutecki
2006-08-14 9:12 ` 2.6.18-rc4-mm1 Rafael J. Wysocki
@ 2006-08-17 12:22 ` Andreas Mohr
2006-08-18 10:30 ` 2.6.18-rc4-mm1 Andy Whitcroft
1 sibling, 1 reply; 80+ messages in thread
From: Andreas Mohr @ 2006-08-17 12:22 UTC (permalink / raw)
To: Maciej Rutecki; +Cc: Andrew Morton, linux-kernel, Dmitry Torokhov
Hi,
On Sun, Aug 14, 2022 at 10:42:18AM +0200, Maciej Rutecki wrote:
> Andrew Morton napisa??(a):
> > Please always do reply-to-all.
> >
>
> Sorry.
>
> >
> >
> > Could be i8042-get-rid-of-polling-timer-v4.patch. Please try the below
> > reversion patch, on top of rc4-mm1, thanks.
> >
> >
>
> Thanks for help.
>
> I try this patch, keyboard works, but I have other problem. When I try:
>
> echo "standby" > /sys/power/state
>
> system goes to standby, but keyboard stop working and CMOS clock was
> corrupted (randomize date and time e.g. Fri Feb 18 2028 13:57:43). So I
> must reset computer.
Thou shalt Not enable no dangerous CMOS corrupting suspend debugging configs ;)
No idea whether "corrupting" the CMOS content with suspend debugging data
has any influence on the keyboard resume, though, but it could easily have.
Andreas Mohr
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-17 12:22 ` 2.6.18-rc4-mm1 Andreas Mohr
@ 2006-08-18 10:30 ` Andy Whitcroft
0 siblings, 0 replies; 80+ messages in thread
From: Andy Whitcroft @ 2006-08-18 10:30 UTC (permalink / raw)
To: Andreas Mohr; +Cc: Maciej Rutecki, Andrew Morton, linux-kernel, Dmitry Torokhov
Andreas Mohr wrote:
> Hi,
>
> On Sun, Aug 14, 2022 at 10:42:18AM +0200, Maciej Rutecki wrote:
>> Andrew Morton napisa??(a):
>>> Please always do reply-to-all.
>>>
>> Sorry.
>>
>>>
>>> Could be i8042-get-rid-of-polling-timer-v4.patch. Please try the below
>>> reversion patch, on top of rc4-mm1, thanks.
>>>
>>>
>> Thanks for help.
>>
>> I try this patch, keyboard works, but I have other problem. When I try:
>>
>> echo "standby" > /sys/power/state
>>
>> system goes to standby, but keyboard stop working and CMOS clock was
>> corrupted (randomize date and time e.g. Fri Feb 18 2028 13:57:43). So I
>> must reset computer.
>
> Thou shalt Not enable no dangerous CMOS corrupting suspend debugging configs ;)
>
> No idea whether "corrupting" the CMOS content with suspend debugging data
> has any influence on the keyboard resume, though, but it could easily have.
If my memory is working correctly, the CMOS and keyboard etc are all out
there on that primative (XC?) bus, off a sort of ISA spur, off the first
PCI bus? So they may be 'near' in address terms.
Anyone got one of those old diagrams?
-apw
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-16 4:29 ` 2.6.18-rc4-mm1 Dave Jones
@ 2006-08-24 19:46 ` Pavel Machek
0 siblings, 0 replies; 80+ messages in thread
From: Pavel Machek @ 2006-08-24 19:46 UTC (permalink / raw)
To: Dave Jones, Andrew Morton, Robert Hancock, linux-kernel
Hi!
> > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm1/
> > >
> > > Warnings and an oops on suspend to disk:
> > >
> > > http://www.roberthancock.com/oops1.jpg
> > > http://www.roberthancock.com/oops2.jpg
> > > http://www.roberthancock.com/oops3.jpg
> > > http://www.roberthancock.com/oops4.jpg
> > > http://www.roberthancock.com/oops5.jpg
> > > http://www.roberthancock.com/oops6.jpg
> > > http://www.roberthancock.com/oops7.jpg
> > > http://www.roberthancock.com/oops8.jpg
> > >
> > > Sleeping function called from invalid context in acpi
> >
> > Yes. It appears that we've decided to release 2.6.18 with this feature.
>
> Well it's not like it'd be a regression. That thing has been there
> for over a year now at least in one form or other.
I believe that we had it fixed at one point...?
Pavel
--
Thanks for all the (sleeping) penguins.
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: 2.6.18-rc4-mm1
2006-08-13 19:11 ` 2.6.18-rc4-mm1 Andrew Morton
2006-08-13 22:44 ` 2.6.18-rc4-mm1 Ben Buxton
@ 2022-08-14 8:42 ` Maciej Rutecki
2006-08-14 9:12 ` 2.6.18-rc4-mm1 Rafael J. Wysocki
2006-08-17 12:22 ` 2.6.18-rc4-mm1 Andreas Mohr
1 sibling, 2 replies; 80+ messages in thread
From: Maciej Rutecki @ 2022-08-14 8:42 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, Dmitry Torokhov
[-- Attachment #1: Type: text/plain, Size: 744 bytes --]
Andrew Morton napisał(a):
> Please always do reply-to-all.
>
Sorry.
>
>
> Could be i8042-get-rid-of-polling-timer-v4.patch. Please try the below
> reversion patch, on top of rc4-mm1, thanks.
>
>
Thanks for help.
I try this patch, keyboard works, but I have other problem. When I try:
echo "standby" > /sys/power/state
system goes to standby, but keyboard stop working and CMOS clock was
corrupted (randomize date and time e.g. Fri Feb 18 2028 13:57:43). So I
must reset computer.
I enclose dmesg with i8042.debug=1 option, config, lsmod and fragment of
syslog, when I tried standby.
Greetings
--
Maciej Rutecki <maciej.rutecki@gmail.com>
http://www.unixy.pl
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)
[-- Attachment #2: config-2.6.18-rc4-mm1.gz --]
[-- Type: application/x-gzip, Size: 14622 bytes --]
[-- Attachment #3: dmesg.gz --]
[-- Type: application/x-gzip, Size: 9956 bytes --]
[-- Attachment #4: lsmod_output.txt.gz --]
[-- Type: application/x-gzip, Size: 817 bytes --]
[-- Attachment #5: syslog.gz --]
[-- Type: application/x-gzip, Size: 2717 bytes --]
^ permalink raw reply [flat|nested] 80+ messages in thread
end of thread, other threads:[~2006-08-24 19:46 UTC | newest]
Thread overview: 80+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <fa.nURugTWtyfQKAbvUB0DbTkmyPAY@ifi.uio.no>
2006-08-16 2:57 ` 2.6.18-rc4-mm1 Robert Hancock
2006-08-16 4:26 ` 2.6.18-rc4-mm1 Andrew Morton
2006-08-16 4:29 ` 2.6.18-rc4-mm1 Dave Jones
2006-08-24 19:46 ` 2.6.18-rc4-mm1 Pavel Machek
2006-08-16 23:18 ` 2.6.18-rc4-mm1 Robert Hancock
2006-08-16 19:41 ` 2.6.18-rc4-mm1 Len Brown
2006-08-13 8:24 2.6.18-rc4-mm1 Andrew Morton
2006-08-13 11:45 ` 2.6.18-rc4-mm1 Maciej Rutecki
2006-08-13 19:11 ` 2.6.18-rc4-mm1 Andrew Morton
2006-08-13 22:44 ` 2.6.18-rc4-mm1 Ben Buxton
2006-08-13 22:58 ` 2.6.18-rc4-mm1 Michal Piotrowski
2006-08-13 23:25 ` 2.6.18-rc4-mm1 Dave Jones
2006-08-14 11:55 ` 2.6.18-rc4-mm1 Ben Buxton
2006-08-14 20:20 ` 2.6.18-rc4-mm1 Dave Jones
2006-08-14 21:13 ` 2.6.18-rc4-mm1 Ben B
2006-08-14 21:22 ` 2.6.18-rc4-mm1 Dave Jones
2006-08-14 21:46 ` 2.6.18-rc4-mm1 Andrew Morton
2006-08-14 0:00 ` 2.6.18-rc4-mm1 Dmitry Torokhov
2006-08-14 12:03 ` 2.6.18-rc4-mm1 Ben B
2006-08-14 13:45 ` 2.6.18-rc4-mm1 Dmitry Torokhov
2006-08-14 21:44 ` 2.6.18-rc4-mm1 Ben B
2006-08-15 2:23 ` 2.6.18-rc4-mm1 Dmitry Torokhov
2022-08-14 8:42 ` 2.6.18-rc4-mm1 Maciej Rutecki
2006-08-14 9:12 ` 2.6.18-rc4-mm1 Rafael J. Wysocki
2006-08-14 11:35 ` 2.6.18-rc4-mm1 Maciej Rutecki
2006-08-17 12:22 ` 2.6.18-rc4-mm1 Andreas Mohr
2006-08-18 10:30 ` 2.6.18-rc4-mm1 Andy Whitcroft
2006-08-13 23:58 ` 2.6.18-rc4-mm1 Dmitry Torokhov
[not found] ` <d120d5000608140643tddd9ce4o986560740ef5dbd7@mail.gmail.com>
2006-08-14 18:24 ` 2.6.18-rc4-mm1 Maciej Rutecki
2006-08-13 12:24 ` 2.6.18-rc4-mm1 Michal Piotrowski
2006-08-14 6:36 ` 2.6.18-rc4-mm1 Reuben Farrelly
2006-08-14 9:06 ` 2.6.18-rc4-mm1 Rafael J. Wysocki
2006-08-13 12:43 ` 2.6.18-rc4-mm1 Rafael J. Wysocki
2006-08-13 17:38 ` 2.6.18-rc4-mm1 Laurent Riffard
2006-08-13 20:39 ` 2.6.18-rc4-mm1 Andrew Morton
2006-08-14 7:58 ` 2.6.18-rc4-mm1 David Howells
2006-08-14 8:06 ` 2.6.18-rc4-mm1 Ian Kent
2006-08-14 9:32 ` 2.6.18-rc4-mm1 David Howells
2006-08-14 17:16 ` 2.6.18-rc4-mm1 Andrew Morton
2006-08-14 18:12 ` 2.6.18-rc4-mm1 David Howells
2006-08-14 18:17 ` 2.6.18-rc4-mm1 David Howells
2006-08-14 18:24 ` 2.6.18-rc4-mm1 Andrew Morton
2006-08-14 18:32 ` 2.6.18-rc4-mm1 David Howells
2006-08-14 21:31 ` 2.6.18-rc4-mm1 Andrew Morton
2006-08-15 9:51 ` 2.6.18-rc4-mm1 David Howells
2006-08-15 13:50 ` 2.6.18-rc4-mm1 Andrew Morton
2006-08-15 14:47 ` 2.6.18-rc4-mm1 David Howells
2006-08-15 16:15 ` 2.6.18-rc4-mm1 Andrew Morton
2006-08-15 17:29 ` 2.6.18-rc4-mm1 David Howells
2006-08-15 17:48 ` 2.6.18-rc4-mm1 Andrew Morton
2006-08-15 18:35 ` 2.6.18-rc4-mm1 David Howells
2006-08-15 18:49 ` 2.6.18-rc4-mm1 Andrew Morton
2006-08-15 19:20 ` 2.6.18-rc4-mm1 David Howells
2006-08-16 9:34 ` 2.6.18-rc4-mm1 David Howells
2006-08-16 10:00 ` 2.6.18-rc4-mm1 David Howells
2006-08-16 12:23 ` 2.6.18-rc4-mm1 David Howells
2006-08-16 12:58 ` 2.6.18-rc4-mm1 Ian Kent
2006-08-16 13:20 ` 2.6.18-rc4-mm1 David Howells
2006-08-16 12:36 ` 2.6.18-rc4-mm1 Ian Kent
2006-08-14 22:49 ` 2.6.18-rc4-mm1 Trond Myklebust
2006-08-14 23:51 ` 2.6.18-rc4-mm1 Andrew Morton
2006-08-15 16:39 ` 2.6.18-rc4-mm1 David Howells
2006-08-15 16:55 ` 2.6.18-rc4-mm1 David Howells
2006-08-15 17:13 ` 2.6.18-rc4-mm1 Trond Myklebust
2006-08-15 17:22 ` 2.6.18-rc4-mm1 David Howells
2006-08-14 14:02 ` 2.6.18-rc4-mm1 Michal Piotrowski
2006-08-14 18:19 ` 2.6.18-rc4-mm1 Andrew Morton
2006-08-14 19:01 ` 2.6.18-rc4-mm1 Michal Piotrowski
2006-08-14 19:20 ` 2.6.18-rc4-mm1 john stultz
2006-08-14 19:27 ` 2.6.18-rc4-mm1 Michal Piotrowski
2006-08-14 19:44 ` 2.6.18-rc4-mm1 john stultz
2006-08-14 20:48 ` 2.6.18-rc4-mm1 Michal Piotrowski
2006-08-14 20:56 ` 2.6.18-rc4-mm1 Dave Jones
2006-08-14 21:13 ` 2.6.18-rc4-mm1 Michal Piotrowski
2006-08-14 21:20 ` 2.6.18-rc4-mm1 Dave Jones
2006-08-14 22:08 ` 2.6.18-rc4-mm1 Michal Piotrowski
2006-08-14 17:54 ` 2.6.18-rc4-mm1 Rafael J. Wysocki
2006-08-14 18:15 ` 2.6.18-rc4-mm1 Andrew Morton
2006-08-15 14:07 ` 2.6.18-rc4-mm1 Atsushi Nemoto
2006-08-15 17:14 ` 2.6.18-rc4-mm1 Rafael J. Wysocki
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox