2.6.18-rc2-mm1

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

- git-klibc has been dropped due to very bad parallel-make problems.

- Added a new line to the boilerplate, below!

- Added Sam's lxdialog tree, as git-lxdialog.patch. You no longer need x-ray spectacles to read the menuconfig screens.

- Lots of random patches. Many of them are bugfixes and I shall, as usual, go through them all identifying 2.6.18 material. But I can miss things, so please don't be afraid to point 2.6.18 candidates out to me.

I also have, as usual, a number of bugfixes agains the git trees. I'll send these to the maintainers until they stick and then I lose track of them. So don't be afraid to send reminders to the subsystem maintainers either.

Boilerplate:

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

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

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

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

echo "subscribe mm-commits" | mail [email protected]

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

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

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

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

- 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-rc2-mm1:

origin.patch
git-alsa.patch
git-agpgart.patch
git-arm.patch
git-cifs.patch
git-cpufreq.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-mtd.patch
git-netdev-all.patch
git-net.patch
git-nfs.patch
git-ocfs2.patch
git-pcmcia.patch
git-powerpc.patch
git-sas.patch
git-s390.patch
git-scsi-target.patch
git-supertrak.patch
git-watchdog.patch
git-xfs.patch
git-cryptodev.patch

git trees

-struct-file-leakage.patch
-struct-file-leakage-tweak.patch -cpufreq-add-__find_governor-helper-and-clean-up-some.patch -cpufreq-demand-load-governor-modules.patch
-videodev-check-return-values.patch -ib-mthca-fix-static-rate-returned-by-mthca_ah_query.patch
-ib-mthca-comment-fix.patch
-ib-cm-drop-req-when-out-of-memory.patch
-ib-addr-gid-structure-alignment-fix.patch
-srp-fix-fmr-error-handling.patch -ib-cm-set-private-data-length-for-reject-messages.patch -fmr-pool-remove-unnecessary-pointer-dereference.patch -ib-core-use-correct-gfp_mask-in-sa_query.patch -git-input-list_for_each_entry-fix.patch
-git-input-list_for_each_entry-fix-fix.patch -input-move-fixp-arithh-to-drivers-input.patch -input-new-force-feedback-interface.patch -input-adapt-hid-force-feedback-drivers-for-the-new-interface.patch -input-adapt-uinput-for-the-new-force-feedback-interface.patch -input-adapt-iforce-driver-for-the-new-force-feedback-interface.patch -input-force-feedback-driver-for-pid-devices.patch -input-force-feedback-driver-for-zeroplus-devices.patch -input-update-documentation-of-force-feedback.patch -input-drop-the-remains-of-the-old-ff-interface.patch -input-drop-the-old-pid-driver.patch -input-fix-comments-and-blank-lines-in-new-ff-code.patch
-input-must_check-fixes.patch -pata-ata_generic-generic-bios-setup-sff-ata-driver.patch
-fixes-for-piix-driver.patch -my-name-is-ingo-molnar-you-killed-my-make-allyesconfig-prepare-to-die.patch -lockdep-annotate-8390c-disable_irq-2.patch -add-lookup-hint-for-network-file-systems.patch
-fs-nfs-make-2-functions-static.patch
-megaraid-gcc-41-warning-fix.patch
-megaraid-dell-cerc-ata100-4ch-support.patch
-NCR_D700-section-fix.patch
-megaraid-fix-warnings-when-config_proc_fs=n.patch
-scsi_debug-must_check-fixes.patch
-mm-fix-oom-roll-back-of-__vmalloc_area_node.patch -ia64-race-flushing-icache-in-cow-path.patch
-x86-re-enable-generic-numa.patch -i386-require-acpi-for-numa-with-generic-architecture.patch -i386-handle_bug-dont-print-garbage-if-debug-info.patch -fix-a-memory-leak-in-the-i386-setup-code.patch -i386-kexec-allow-the-kexec-on-panic-support-to-compile-on-voyager.patch -i386-remove-redundant-might_sleep-in-user-accessors.patch -x86-dont-randomize-stack-unless-current-personality-permits-it.patch -uml-tidy-longjmp-macro.patch
-uml-tidy-biarch-gcc-support.patch
-uml-header-formatting-cleanups.patch -null-terminate-over-long-proc-kallsyms-symbols.patch -null-terminate-over-long-proc-kallsyms-symbols-fix.patch -remove-kernel-kthreadckthread_stop_sem.patch
-del_timer_sync-add-cpu_relax.patch -hdrinstall-remove-asm-irqh-from-user-visibility.patch -hdrinstall-remove-asm-atomich-from-user-visibility.patch -hdrinstall-remove-asm-ioh-from-user-visibility.patch -nommu-export-two-symbols-for-drivers-to-use.patch
-update-ramdisk-documentation.patch
-ramdisk-blocksize-kconfig-entry.patch
-rtc-subsystem-add-isl1208-support.patch -rtc-subsystem-add-isl1208-support-tweaks.patch -lockdep-annotate-the-blkpg_del_partition-ioctl.patch -add-try_to_freeze-to-rt-test-kthreads.patch -drivers-block-cpqarrayc-remove-an-unused-variable.patch
-unexport-open_softirq.patch
-scx200_gpio-1-cdev-for-n-minors-cleanup.patch -scx200_gpio-use-1-cdev-for-n-minors-not-n.patch -improve-timekeeping-resume-robustness.patch -fix-sighand-siglock-usage-in-kernel-acctc.patch
-net48xx-led-cleanups.patch -reiserfs-fix-handling-of-device-names-with-s-in-them.patch -reiserfs-fix-handling-of-device-names-with-s-in-them-tidy.patch -convert-idrs-internal-locking-to-_irqsave-variant.patch -add-function-documentation-for-register_chrdev.patch -add-function-documentation-for-register_chrdev-fix.patch -remove-pci_dac_set_dma_mask-from-documentation-dma-mappingtxt.patch -gpio-drop-vtable-members-gpio_set_high-gpio_set_low.patch -gpio-cosmetics-remove-needless-newlines.patch -gpio-rename-exported-vtables-to-better-match.patch -vfs-fix-accessfile-x_ok-in-the-presence-of-acls.patch -vfs-remove-redundant-open-coded-mode-bit-check-in-prepare_binfmt.patch -vfs-remove-redundant-open-coded-mode-bit-checks-in-open_exec.patch -lockdep-core-fix-rq-lock-handling-on-__arch_want_unlocked_ctxsw.patch -tpm-fix-failure-path-leak.patch
-actual-mailing-list-in-maintainers.patch
-symlink-nesting-level-change.patch
-tpm-interrupt-clear-fix.patch
-tpm-add-force-device-probe-option.patch
-tpm_tis-use-resource_size_t.patch -let-the-the-lockdep-options-depend-on-debug_kernel.patch -fix-security-check-for-joint-context=-and-fscontext=-mount.patch -list_islast-utility.patch
-per-task-delay-accounting-setup.patch -per-task-delay-accounting-sync-block-i-o-and-swapin-delay-collection.patch -per-task-delay-accounting-cpu-delay-collection-via-schedstats.patch -per-task-delay-accounting-utilities-for-genetlink-usage.patch -per-task-delay-accounting-taskstats-interface.patch -per-task-delay-accounting-taskstats-interface-fix.patch -per-task-delay-accounting-delay-accounting-usage-of-taskstats-interface.patch -per-task-delay-accounting-delay-accounting-usage-of-taskstats-interface-fix.patch -per-task-delay-accounting-documentation.patch -per-task-delay-accounting-proc-export-of-aggregated-block-i-o-delays.patch -delay-accounting-taskstats-interface-send-tgid-once.patch -per-task-delay-accounting-taskstats-interface-documentation-fix.patch -per-task-delay-accounting-avoid-send-without-listeners.patch -per-task-delay-accounting-taskstats-interface-control-exit-data-through-cpumasks.patch -per-task-delay-accounting-taskstats-interface-control-exit-data-through-cpumasks-fix.patch -per-task-delay-accounting-taskstats-interface-control-exit-data-through-cpumasks-fix-2.patch -per-task-delay-accounting-taskstats-interface-control-exit-data-through-cpumasks-fix-3.patch -per-task-delay-accounting-taskstats-interface-control-exit-data-through-cpumasks-fix-cleanup.patch -per-task-delay-accounting-taskstats-interface-control-exit-data-through-cpumasks-fix-cleanup-fix.patch -remove-down_write-from-taskstats-code-invoked-on-the-exit-path.patch -mbxfb-add-framebuffer-driver-for-the-intel-2700g.patch

Merged into mainline or a subsystem tree.

+sched-build_sched_domains-fix.patch +ext3-avoid-triggering-ext3_error-on-bad-nfs-file-handle.patch +ext3-avoid-triggering-ext3_error-on-bad-nfs-file-handle-fix.patch +process-events-fix-biarch-compatibility-issue-use-__u64-timestamp.patch +gpio-rename-exported-vtables-to-better-match-tidy.patch +genirq-endisable_irq_wake-need-refcounting-too.patch +make-taskstats-sending-completely-independent-of-delay.patch +taskstats-free-skb-avoid-returns-in.patch +delay-accounting-temporarily-enable-by-default.patch +fix-ppc32-zimage-inflate.patch
+mce-section-fix.patch

2.6.18 queue (partial)

+gregkh-driver-mem-devices.patch
+gregkh-driver-driver-multithread.patch

Driver tree updates

+drivers-base-check-errors-fix.patch
+drivers-base-check-errors-fix-2.patch
+fix-bus_rescan_devices-in-mm.patch
+more-driver-core-fixes-for-mm.patch
+yet-further-driver-core-fixes-for-mm.patch

More driver core error-checking.

+dvb-core-needs-i2c.patch
+git-dvb-radio-sf16fmi-build-fix.patch

DVB fixes

+ieee1394-remove-include-asm-semaphoreh.patch
+ieee1394-sbp2-safer-last_orb-and.patch
+ieee1394-sbp2-discard-return-value-of.patch
+ieee1394-sbp2-optimize-dma-direction-of.patch
+ieee1394-sbp2-safer-initialization-of.patch
+ieee1394-sbp2-more-checks-of-status.patch
+ieee1394-sbp2-convert.patch

1394 updates

+logips2pp-fix-mx300-button-layout.patch
+logips2pp-fix-mx300-button-layout-fix.patch

Input fixes.

-sane-menuconfig-colours.patch

Dropped - git-lxdialog

+remove-rpm_build_root-from-asm-offsetsh.patch

kbuild fix

-git-hdrcleanup-vs-git-klibc-on-ia64.patch
-git-hdrcleanup-vs-git-klibc-on-ia64-2.patch
-make-variables-static-after-klibc-merge.patch

git-klibc droppage side-effects.

+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

IDE cleanups

+fix-the-unlock-addr-lookup-bug-in-mtd-jedec-probe.patch

MTD maybe-fix.

-qla3xxx-nic-driver-updates.patch

Folded into qla3xxx-NIC-driver.patch

+net-add-netconsole-support-to-dm9000-driver.patch +smc911x-re-release-spinlock-on-spurious-interrupt.patch +uli526x-driver-cleanups.patch +via-rhine-napi-support.patch +via-rhine-napi-poll-enable.patch +stop-calling-phy_stop_interrupts-twice.patch

netdev updates

+git-net-selinux_xfrm_decode_session-build-fix.patch

Fix git-net.patch.

+lockdep-split-the-skb_queue_head_init-lock-class-tidy.patch +ppp-handle-kmalloc-failures.patch +ppp-handle-kmalloc-failures-leak-fix.patch +irda-replace-hard-coded-dev_self-array-sizes-with-array_size.patch +acrnet-sohard-pci-support.patch

Networkng things.

+powerpc-use-check_irq_per_cpu.patch

powerpc tweak.

-revert-VIA-quirk-fixup-additional-PCI-IDs.patch -revert-PCI-quirk-VIA-IRQ-fixup-should-only-run-for-VIA-southbridges.patch

Unneeded.

+pci-quirk_via_irq-behaviour-change.patch +pci-hotplug-acpiphp-fix-kconfig-for-dock-dependencies-2.patch

PCI fixes

+git-kbuild-build-fix.patch

Fix git-s390.patch for git-kbuild changes.

+pci_module_init-conversion-in-scsi-subsys-2nd-try.patch +scsi-megaraid_mmmbox-64-bit-dma-capability-checker.patch +scsi-megaraid_mmmbox-a-fix-on-inquiry-with-evpd.patch +scsi-megaraid_mmmbox-a-fix-on-kernel-unaligned-access-address-issue.patch +megaraid-gcc-41-warning-fix.patch +megaraid-fix-warnings-when-config_proc_fs=n.patch +megaraid-dell-cerc-ata100-4ch-support.patch

SCSI updates

+gregkh-usb-usb-ark3116-add-tiocgserial-and-tiocsserial-ioctl-calls.patch +gregkh-usb-usb-ark3116-formatting-cleanups.patch

USB tree updates.

+add-all-wacom-device-to-hid-corec-blacklist.patch +net1080-inherent-pad-length.patch

USB updates

+ieee80211-tkip-requires-crc32.patch
+kthread-airoc.patch
+kthread-airoc-race-fix.patch

Wireless updates

+x86_64-mm-defconfig-update.patch
-x86_64-mm-i386-numa-summit-check.patch -x86_64-mm-x86_64-mm-remove-un-set_nmi_callback-and-reserve-release_lapic_nmi-functions-x86-fix.patch -x86_64-mm-x86_64-mm-remove-un-set_nmi_callback-and-reserve-release_lapic_nmi-functions-x86-fix-fix.patch -x86_64-mm-x86_64-mm-remove-un-set_nmi_callback-and-reserve-release_lapic_nmi-functions-x86_64-fix.patch +x86_64-mm-unknown-nmi-panic.patch
+x86_64-mm-generic-getcpu-syscall.patch
+x86_64-mm-randomize-check.patch
+x86_64-mm-add-user-mode.patch
+x86_64-mm-int80-save-args.patch
+x86_64-mm-i386-profile-pc.patch
+x86_64-mm-simplify-profile-pc.patch
+x86_64-mm-enlarge-debug-stack.patch
+x86_64-mm-backtrace-fallback.patch
+x86_64-mm-backtracer-docs.patch
+x86_64-mm-i386-backtrace-fallback.patch
+x86_64-mm-asm-alternative.patch
+x86_64-mm-rwlock-lock-prefix.patch
+x86_64-mm-rwlock-cleanup.patch
+x86_64-mm-i386-asm-alternative.patch
+x86_64-mm-i386-semaphore-to-asm.patch
+x86_64-mm-remove-thunk-cvs-id.patch
+x86_64-mm-tce-comment.patch
+x86_64-mm-intel-no-tsc-in-c3.patch
+x86_64-mm-remove-apic-ifdefs.patch
+x86_64-mm-remove-apic-mismatch.patch
+x86_64-mm-remove-focus-disabled-workaround.patch +x86_64-mm-calgary-iommu-fix-off-by-one-error.patch +x86_64-mm-calgary-iommu-multi-node-null-pointer-dereference-fix.patch +x86_64-mm-tlb-flush-cleanup.patch
+x86_64-mm-i386-tlbflush-fixes.patch
+x86_64-mm-remove-timer-fallback.patch
+x86_64-mm-entry-comments.patch
+x86_64-mm-remove-pirq.patch
+x86_64-mm-remove-mca-eisa.patch
+x86_64-mm-remove-pic-mode.patch
+x86_64-mm-remove-mpparse-checks.patch
+x86_64-mm-io-apic-access.patch
+x86_64-mm-i386-io-apic-access.patch
+x86_64-mm-remove-apic-renumbering.patch
+x86_64-mm-quirks-own-file.patch
+x86_64-mm-mp-bus-type-bitmap.patch
+x86_64-mm-remove-mpparse-wrapper.patch
+x86_64-mm-remove-acpi-externs-in-mpparse.patch
+x86_64-mm-mpparse-acpi-style.patch
+x86_64-mm-i386-mpparse-acpi-style.patch
+x86_64-mm-apic-build-bug-on.patch
+x86_64-mm-detect-cfi.patch
+x86_64-mm-revert-k8-bus-change.patch
+x86_64-mm-kernel-asm-remove-cvs-id.patch
+x86_64-mm-via-force-dma-mask.patch
+x86_64-mm-fix-swiotlb-force.patch

x86_64 tree updates

+fix-x86_64-mm-via-force-dma-mask-config_pcin-fix.patch +fix-x86_64-mm-i386-backtrace-fallback.patch +fix-x86_64-mm-allow-users-to-force-a-panic-on-nmi.patch

Fix it.

+calgary-iommu-rearrange-struct-iommu_table.patch +calgary-iommu-consolidate-per-bus-data.patch +calgary-iommu-break-out-of.patch +calgary-iommu-fix-error-path-memleak-in.patch +calgary-iommu-fix-reference-counting-of.patch +calgary-iommu.patch +calgary-iommu-save-a-bit-of-space-in-bus_info.patch

Clagary update

+xfs-add-lock-annotations-to-xfs_trans_update_ail-and-xfs_trans_delete_ail.patch

XFS sparse annotation.

+cpu-hotplug-compatible-alloc_percpu.patch

alloc_percpu feature work.

+add-kerneldocs-for-some-functions-in-mm-memoryc.patch

Documentation

+selinux-fix-memory-leak.patch
+selinux-fix-bug-in-security_compute_sid.patch

SELinux fixes

+synchronize_tsc-fixes.patch

Small fixes for x86 TSC synchronisation

+machine_kexecc-fix-the-description-of-segment-handling.patch +add-force-of-use-mmconfig.patch +add-force-of-use-mmconfig-fix.patch +kprobe-booster-disable-in-preemptible-kernel.patch +i386-fix-recursive-faults-during-oops-when-current.patch +i386-show_registers-try-harder-to-print-failing.patch +convert-i386-summit-subarch-to-use-srat-info-for-apicid_to_node-calls.patch +convert-i386-summit-subarch-to-use-srat-info-for-apicid_to_node-calls-tidy.patch +i386-make-config_efi-depend-on-experimental.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 +i386-switch_to-misplaced-parentheses.patch

x86 updates

+arch-alpha-use-array_size-macro.patch

Alpha cleanup

+ia64-kprobe-invalidate-icache-of-jump-buffer-s390-fix.patch

Fix ia64-kprobe-invalidate-icache-of-jump-buffer.patch for s390

-swsusp-try-to-handle-holes-better.patch +make-swsusp-avoid-memory-holes-and-reserved-memory-regions-on-x86_64.patch

Updated.

+v850-remove-symbol-exports-which-duplicate-global-ones.patch +v850-call-init_page_count-instead-of-set_page_count.patch

v850 fixes

+inode_diet-replace-inodeugeneric_ip-with-inodei_private-gfs-fix.patch

Fix gfs2 for inode_diet-replace-inodeugeneric_ip-with-inodei_private.patch

-eisa-bus-modalias-attributes-support-1-fix-git-kbuild-fix-2.patch

Fix eisa-bus-modalias-attributes-support-1 some more.

+pass-io-size-to-batch_write-address-space-operation.patch

Tweak VFS features in -mm.

+invalidate_bdev-speedup.patch +ide-touch-nmi-watchdog-during-resume-from-str.patch +ide-touch-nmi-watchdog-during-resume-from-str-fix.patch +make-touch_nmi_watchdog-imply-touch_softlockup_watchdog-on.patch +remove-unnecessary-barrier-in-rtc_get_rtc_time.patch +drivers-char-scx200_gpioc-make-code-static.patch +drivers-char-pc8736x_gpioc-remove-unused-static-functions.patch +let-warn_on-warn_on_once-return-the-condition.patch +let-warn_on-warn_on_once-return-the-condition-fix.patch +let-warn_on-warn_on_once-return-the-condition-fix-2.patch +net-use-warn_on_once-for-checksum-checks.patch +lockdep-annotate-pktcdvd-natural-device-hierarchy.patch +scx200_gpio-export-cleanups.patch +make-net48xx-led-use-scx200_gpio_ops.patch +nbd-check-magic-before-doing-anything-else.patch +nbd-abort-request-on-data-reception-failure.patch +always-define-irq_per_cpu.patch
+panic_on_oops-remove-ssleep.patch +replace-__devinit-with-__cpuinit-for-cpu-notifications.patch +fix-hotplug-cpu-documentation-for-proper-usage.patch +use-hotplug-version-of-registration-in-late-inits.patch +fix-bad-macro-param-in-timerc.patch
+fix-cond_resched-fix.patch +fix-kernel-api-doc-for-kernel-resourcec.patch +kernel-doc-ignore-__devinit.patch +pci-search-cleanups-add-to-kernel-apitmpl.patch +libfs-remove-page-up-to-date-check-from-simple_readpage.patch +add-docbook-documentation-for-workqueue-functions.patch +doc-submittingpatches-cleanups.patch +kernel-doc-for-relay-interface.patch +kernel-doc-fixes-for-debugfs.patch +kernel-doc-move-filesystems-together.patch +kthread-convert-loopc-to-kthread.patch +fs-conversions-from-kmallocmemset-to-kzcalloc.patch +include-documentation-for-functions-in-drivers-base-classc.patch +fix-parameter-names-in-drivers-base-classc.patch +fs-removing-useless-casts.patch
+sgiioc4-always-share-irq.patch +spinlock_debug-dont-recompute-jiffies_per_loop.patch +omap-add-smc91x-support-for-ti-omap2420-h4-board.patch +omap-add-watchdog-driver-support.patch +omap-add-watchdog-driver-support-tweaks.patch +omap-fix-rng-driver-build.patch +mdacon-fix-__init-section-warnings.patch +pcmcia-fix-ioctl-for-get_status-and-get_configuration_info.patch +pcmcia-fix-ioctl-get_configuration_info-for-pcmcia_cards.patch +use-gcc-o1-in-fs-reiserfs-only-for-ancient-gcc-versions.patch +enable-mac-partition-label-per-default-on-pmac.patch +hide-onboard-graphics-drivers-on-g5.patch +hptiop-wrong-register-used-in-hptiop_reset_hba.patch +pi-futex-robust-futex-exit.patch +pi-futex-missing-pi_waiters-plist-initialization.patch +irq-fixed-coding-style.patch
+irq-removed-a-extra-line.patch
+sgiioc4-fixup-use-of-mmio-ops.patch +add-linux-mm-mailing-list-for-memory-management-in.patch +inotify-fix-deadlock-found-by-lockdep.patch +fix-swsusp-with-pnp-bios.patch +remove-incorrect-unlock_kernel-from-allocation.patch +remove-incorrect-unlock_kernel-from-failure-path-in.patch +add-entry-for-efs-filesystem-to-maintainers-as-orphan.patch +ufs-remove-incorrect-unlock_kernel-from-failure-path-in-ufs_symlink.patch +efi-add-lock-annotations-for-efi_call_phys_prelog-and-efi_call_phys_epilog.patch +mbcache-add-lock-annotation-for-__mb_cache_entry_release_unlock.patch +afs-add-lock-annotations-to-afs_proc_cell_servers_startstop.patch +fuse-add-lock-annotations-to-request_end-and-fuse_read_interrupt.patch +hugetlbfs-add-lock-annotation-to-hugetlbfs_forget_inode.patch +lockdep-dont-pull-in-includes-when-lockdep-disabled.patch +jbd-add-lock-annotation-to-jbd_sync_bh.patch +fix-typo-in-maintainers-s-devics-devices.patch +bluetooth-guard-bt_proto-with-rwlock.patch +typo-in-ub-clause-of-devicestxt.patch +reducing-local_bh_enable-disable-overhead-in-irqtrace.patch +add-parenthesis-around-arguments-in-the-sh_div-macro.patch +reference-rt-mutex-design-in-rtmutexc.patch +fix-kmem_cache_alloc-been-documented-twice.patch +hwrng-fix-intel-probe-error-unwind.patch +hwrng-fix-geode-probe-error-unwind.patch +fs-add-lock-annotation-to-grab_super.patch +rcu-add-lock-annotations-to-rcu_bh_torture_read_lockunlock.patch +vdso-hash-style-fix.patch +kthread-drivers-base-firmware_classc.patch

Misc.

+streamline-generic_file_-interfaces-and-filemap-gfs-fix.patch

Fix gfs2 for streamline-generic_file_-interfaces-and-filemap.patch

-task-watchers-refactor-process-events-fix.patch

Not sure where this went.

+knfsd-knfsd-add-some-missing-newlines-in-printks.patch +knfsd-knfsd-remove-an-unused-variable-from-e_show.patch +knfsd-knfsd-remove-an-unused-variable-from-auth_unix_lookup.patch +knfsd-add-a-callback-for-when-last-rpc-thread-finishes.patch +knfsd-add-a-callback-for-when-last-rpc-thread-finishes-tidy.patch +knfsd-add-a-callback-for-when-last-rpc-thread-finishes-fix.patch +knfsd-be-more-selective-in-which-sockets-lockd-listens-on.patch +knfsd-remove-nfsd_versbits-as-intermediate-storage-for-desired-versions.patch +knfsd-separate-out-some-parts-of-nfsd_svc-which-start-nfs-servers.patch +knfsd-separate-out-some-parts-of-nfsd_svc-which-start-nfs-servers-tweaks.patch +knfsd-define-new-nfsdfs-file-portlist-contains-list-of-ports.patch +knfsd-define-new-nfsdfs-file-portlist-contains-list-of-ports-tidy.patch +knfsd-define-new-nfsdfs-file-portlist-contains-list-of-ports-fix.patch +knfsd-allow-sockets-to-be-passed-to-nfsd-via-portlist.patch +knfsd-use-seq_start_token-instead-of-hardcoded-magic-void1.patch +nfsd-add-lock-annotations-to-e_start-and-e_stop.patch

nfsd updates.

+ecryptfs-mmap-operations-fix.patch

Fix ecryptfs-mmap-operations.patch

+namespaces-utsname-switch-to-using-uts-namespaces-uml-fix.patch

Fix namespaces-utsname-switch-to-using-uts-namespaces.patch for UML

+namespaces-utsname-switch-to-using-uts-namespaces-klibc-bit.patch +namespaces-utsname-use-init_utsname-when-appropriate-klibc-bit.patch +namespaces-utsname-switch-to-using-uts-namespaces-klibc-bit-2.patch +namespaces-utsname-switch-to-using-uts-namespaces-klibc-bit-sparc.patch

Bring these patches back when klibc isn't present.

+reiser4-bug-fixes.patch

Reiser4 update

+ide-remove-dma_base2-field-from-ide_hwif_t.patch

IDE cleanup

+radeonfb-sleep-fixes.patch +powermac-more-powermac-backlight-fixes.patch +powermac-more-powermac-backlight-fixes-fix.patch +nvidiafb-remove-redundant-config_pci-check.patch +rivafb-nvidiafb-race-between-register_framebuffer-and-_bl_init.patch

fbdev updates.

+statistics-use-the-enhanced-percpu-interface.patch

Update stats patches for the new alloc_percpu features.

+genirq-x86_64-irq-make-vector_irq-per-cpu-fix.patch

Fix genirq-x86_64-irq-make-vector_irq-per-cpu.patch

+schedule-obsolete-oss-drivers-for-removal-2nd-round.patch

Put more OSS drivers on death row.

All 909 patches:

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

From: Heiko Carstens <[email protected]>

Remove s390 touch_nmi_watchdog() define to avoid compile warnings.

touch_nmi_watchdog() got converted to touch_softlockup_watchdog() which in case of !CONFIG_DETECT_SOFTLOCKUP is also a nop, just like we want it on s390.

In file included from kernel/sched.c:23:
include/linux/nmi.h:20:1: warning: "touch_nmi_watchdog" redefined In file included from include/linux/nmi.h:8,

                 from kernel/sched.c:23:

include/asm/irq.h:22:1: warning: this is the location of the previous definition

---

 include/asm-s390/irq.h |    3 ---
 1 files changed, 3 deletions(-)

Index: linux-2.6.18-rc2-mm1/include/asm-s390/irq.h
===================================================================
@@ -19,8 +19,5 @@
 	NR_IRQS,
 };
 
-#define touch_nmi_watchdog() do { } while(0)
-
 #endif /* __KERNEL__ */
 #endif
-

Hi,

Compiling on i386 without the CONFIG_EFI enabled complains because it can't find efi_init_e820_map prototype:

arch/i386/kernel/setup.c: In function `setup_arch':
arch/i386/kernel/setup.c:1560: warning: implicit declaration of function `efi_init_e820_map'

The attached corrects this, and also makes efi_init_e820_map static.

Regards,
Frederik

@@ -1453,7 +1453,7 @@ static void set_mca_bus(int x) { }
 /*
  * Make a e820 memory map
  */
-void __init efi_init_e820_map(void)
+static void __init efi_init_e820_map(void)
 {
 	efi_memory_desc_t *md;
 	unsigned long long start = 0;

@@ -1505,7 +1505,9 @@ void __init efi_init_e820_map(void)
 		}
 	}
 }
-#endif
+#else
+static void __init efi_init_e820_map(void) { }
+#endif /* CONFIG_EFI */
 
 /*
  * Determine if we were loaded by an EFI loader.  If so, then we have also been

(Sorry for the resend, I forgot to add a proper subject line) Hi,

Compiling on i386 without the CONFIG_EFI enabled complains because it can't find efi_init_e820_map prototype:

arch/i386/kernel/setup.c: In function `setup_arch':
arch/i386/kernel/setup.c:1560: warning: implicit declaration of function `efi_init_e820_map'

The attached corrects this, and also makes efi_init_e820_map static.

Regards,
Frederik

@@ -1453,7 +1453,7 @@ static void set_mca_bus(int x) { }
 /*
  * Make a e820 memory map
  */
-void __init efi_init_e820_map(void)
+static void __init efi_init_e820_map(void)
 {
 	efi_memory_desc_t *md;
 	unsigned long long start = 0;

@@ -1505,7 +1505,9 @@ void __init efi_init_e820_map(void)
 		}
 	}
 }
-#endif
+#else
+static void __init efi_init_e820_map(void) { }
+#endif /* CONFIG_EFI */
 
 /*
  * Determine if we were loaded by an EFI loader.  If so, then we have also been

I'd like to encourage including the patch:

Cpuset: fix ABBA deadlock with cpu hotplug lock

in 2.6.18-rc2-mmx. This patch was sent to lkml, copied to akpm, 14 July. It was sent again to lkml, in response to a request for a copy from Linus, on 23 July, copied again to akpm.

Granted, the case for including it is not absolute.

The fix is simple enough and fixes a definite deadlock, as verified by testing results on the system that was seeing this deadlock.

However ... only one system, world-wide, has the magic workload to provoke this deadlock, so far. And it involves the cpu hotplug lock, which perhaps Linus would like to nuke entirely.

                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <[email protected]> 1.925.600.0401

Linus merged that four days ago.

Good - thanks.

                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <[email protected]> 1.925.600.0401

Hi Andrew,

It appears while /sbin/start_udev

Jul 27 15:17:17 ltg01-fedora kernel: BUG: unable to handle kernel
paging request at virtual address 6b6b6c07
Jul 27 15:17:17 ltg01-fedora kernel:  printing eip:
Jul 27 15:17:17 ltg01-fedora kernel: c0138722
Jul 27 15:17:17 ltg01-fedora kernel: *pde = 00000000
Jul 27 15:17:17 ltg01-fedora kernel: Oops: 0002 [#1]
Jul 27 15:17:17 ltg01-fedora kernel: 4K_STACKS PREEMPT SMP
Jul 27 15:17:17 ltg01-fedora kernel: last sysfs file:
/devices/pci0000:00/0000:00:1d.7/uevent
Jul 27 15:17:17 ltg01-fedora kernel: Modules linked in: snd_timer snd

soundcore snd_page_alloc intel_agp agpgart ide_cd cdrom ipv6 w83627hf hwmon_vid hwmon i2c_isa i2c_i801 skge 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 speedstep_lib binfmt_misc thermal processor fan container rtc unix

Jul 27 15:17:17 ltg01-fedora kernel: CPU:    0
Jul 27 15:17:17 ltg01-fedora kernel: EIP:    0060:[<c0138722>]    Not
tainted VLI
Jul 27 15:17:17 ltg01-fedora kernel: EFLAGS: 00010046   (2.6.18-rc2-mm1 #78)
Jul 27 15:17:17 ltg01-fedora kernel: EIP is at __lock_acquire+0x362/0xaea
Jul 27 15:17:17 ltg01-fedora kernel: eax: 00000000   ebx: 6b6b6b6b
ecx: c0360358   edx: 00000000
Jul 27 15:17:17 ltg01-fedora kernel: esi: 00000000   edi: 00000000
ebp: f544ddf4   esp: f544ddc0
Jul 27 15:17:17 ltg01-fedora kernel: ds: 007b   es: 007b   ss: 0068
Jul 27 15:17:17 ltg01-fedora kernel: Process udevd (pid: 1353,
ti=f544d000 task=f6fce8f0 task.ti=f544d000)
Jul 27 15:17:17 ltg01-fedora kernel: Stack: 00000000 00000000 00000000
c7749ea4 f6fce8f0 c0138e74 000001e8 00000000
Jul 27 15:17:17 ltg01-fedora kernel:        00000000 f6653fa4 00000246
00000000 00000000 f544de1c c0139214 00000000
Jul 27 15:17:17 ltg01-fedora kernel:        00000002 00000000 c014fe3a
c7749ea4 c7749e90 f6fce8f0 f5b19b04 f544de34
Jul 27 15:17:17 ltg01-fedora kernel: Call Trace:
Jul 27 15:17:17 ltg01-fedora kernel:  [<c0139214>] lock_acquire+0x71/0x91
Jul 27 15:17:17 ltg01-fedora kernel:  [<c02f2bfb>] _spin_lock+0x23/0x32
Jul 27 15:17:17 ltg01-fedora kernel:  [<c014fe3a>]
__delayacct_blkio_ticks+0x16/0x67
Jul 27 15:17:17 ltg01-fedora kernel:  [<c01a4f76>] do_task_stat+0x3df/0x6c1
Jul 27 15:17:17 ltg01-fedora kernel:  [<c01a5265>] proc_tgid_stat+0xd/0xf
Jul 27 15:17:17 ltg01-fedora kernel:  [<c01a29dd>] proc_info_read+0x50/0xb3
Jul 27 15:17:17 ltg01-fedora kernel:  [<c0171cbb>] vfs_read+0xcb/0x177
Jul 27 15:17:17 ltg01-fedora kernel:  [<c017217c>] sys_read+0x3b/0x71
Jul 27 15:17:17 ltg01-fedora kernel:  [<c0103119>] sysenter_past_esp+0x56/0x8d
Jul 27 15:17:17 ltg01-fedora kernel: DWARF2 unwinder stuck at
sysenter_past_esp+0x56/0x8d
Jul 27 15:17:17 ltg01-fedora kernel: Leftover inexact backtrace:
Jul 27 15:17:17 ltg01-fedora kernel:  [<c0104318>] show_stack_log_lvl+0x8c/0x97
Jul 27 15:17:17 ltg01-fedora kernel:  [<c010447f>] show_registers+0x15c/0x1ed
Jul 27 15:17:17 ltg01-fedora kernel:  [<c01046c2>] die+0x1b2/0x2b7
Jul 27 15:17:17 ltg01-fedora kernel:  [<c0116f5f>] do_page_fault+0x410/0x4f0
Jul 27 15:17:17 ltg01-fedora kernel:  [<c0103d1d>] error_code+0x39/0x40
Jul 27 15:17:17 ltg01-fedora kernel:  [<c0139214>] lock_acquire+0x71/0x91
Jul 27 15:17:17 ltg01-fedora kernel:  [<c02f2bfb>] _spin_lock+0x23/0x32
Jul 27 15:17:17 ltg01-fedora kernel:  [<c014fe3a>]
__delayacct_blkio_ticks+0x16/0x67
Jul 27 15:17:17 ltg01-fedora kernel:  [<c01a4f76>] do_task_stat+0x3df/0x6c1
Jul 27 15:17:17 ltg01-fedora kernel:  [<c01a5265>] proc_tgid_stat+0xd/0xf
Jul 27 15:17:17 ltg01-fedora kernel:  [<c01a29dd>] proc_info_read+0x50/0xb3
Jul 27 15:17:17 ltg01-fedora kernel:  [<c0171cbb>] vfs_read+0xcb/0x177
Jul 27 15:17:17 ltg01-fedora kernel:  [<c017217c>] sys_read+0x3b/0x71
Jul 27 15:17:17 ltg01-fedora kernel:  [<c0103119>] sysenter_past_esp+0x56/0x8d
Jul 27 15:17:17 ltg01-fedora kernel: Code: 68 4b 75 2f c0 68 d5 04 00
00 68 b9 75 31 c0 68 e3 06 31 c0 e8 ce 7e fe ff e8 87 c2 fc ff 83 c4
10 eb 08 85 db 0f 84 6b 07 00 00 <f0> ff 83 9c 00 00 00 8b 55 dc 8b 92
5c 05 00 00 89 55 e4 83 fa
Jul 27 15:17:17 ltg01-fedora kernel: EIP: [<c0138722>]
__lock_acquire+0x362/0xaea SS:ESP 0068:f544ddc0
Jul 27 15:17:17 ltg01-fedora kernel:  <3>BUG: sleeping function called
from invalid context at /usr/src/linux-mm/kernel/rwsem.c:20
Jul 27 15:17:17 ltg01-fedora kernel: in_atomic():1, irqs_disabled():1
Jul 27 15:17:17 ltg01-fedora kernel:  [<c0104192>] show_trace_log_lvl+0x58/0x152
Jul 27 15:17:17 ltg01-fedora kernel:  [<c0104896>] show_trace+0xd/0x10
Jul 27 15:17:17 ltg01-fedora kernel:  [<c01049b5>] dump_stack+0x19/0x1b
Jul 27 15:17:17 ltg01-fedora kernel:  [<c0118d37>] __might_sleep+0x8d/0x95
Jul 27 15:17:17 ltg01-fedora kernel:  [<c013595d>] down_read+0x15/0x3b
Jul 27 15:17:17 ltg01-fedora kernel:  [<c012cd93>]
blocking_notifier_call_chain+0x11/0x2d
Jul 27 15:17:17 ltg01-fedora kernel:  [<c012cdc6>] notify_watchers+0x17/0x53
Jul 27 15:17:17 ltg01-fedora kernel:  [<c0122961>] do_exit+0x26/0xa4f
Jul 27 15:17:18 ltg01-fedora kernel:  [<c01047a1>] die+0x291/0x2b7
Jul 27 15:17:18 ltg01-fedora kernel:  [<c0116f5f>] do_page_fault+0x410/0x4f0
Jul 27 15:17:18 ltg01-fedora kernel:  [<c0103d1d>] error_code+0x39/0x40
Jul 27 15:17:18 ltg01-fedora kernel: DWARF2 unwinder stuck at
error_code+0x39/0x40
Jul 27 15:17:18 ltg01-fedora kernel: Leftover inexact backtrace:
Jul 27 15:17:18 ltg01-fedora kernel:  [<c0104896>] show_trace+0xd/0x10
Jul 27 15:17:18 ltg01-fedora kernel:  [<c01049b5>] dump_stack+0x19/0x1b
Jul 27 15:17:18 ltg01-fedora kernel:  [<c0118d37>] __might_sleep+0x8d/0x95
Jul 27 15:17:18 ltg01-fedora kernel:  [<c013595d>] down_read+0x15/0x3b
Jul 27 15:17:18 ltg01-fedora kernel:  [<c012cd93>]
blocking_notifier_call_chain+0x11/0x2d
Jul 27 15:17:18 ltg01-fedora kernel:  [<c012cdc6>] notify_watchers+0x17/0x53
Jul 27 15:17:18 ltg01-fedora kernel:  [<c0122961>] do_exit+0x26/0xa4f
Jul 27 15:17:18 ltg01-fedora kernel:  [<c01047a1>] die+0x291/0x2b7
Jul 27 15:17:18 ltg01-fedora kernel:  [<c0116f5f>] do_page_fault+0x410/0x4f0
Jul 27 15:17:18 ltg01-fedora kernel:  [<c0103d1d>] error_code+0x39/0x40
Jul 27 15:17:18 ltg01-fedora kernel:  [<c0139214>] lock_acquire+0x71/0x91
Jul 27 15:17:18 ltg01-fedora kernel:  [<c02f2bfb>] _spin_lock+0x23/0x32
Jul 27 15:17:18 ltg01-fedora kernel:  [<c014fe3a>]
__delayacct_blkio_ticks+0x16/0x67
Jul 27 15:17:18 ltg01-fedora kernel:  [<c01a4f76>] do_task_stat+0x3df/0x6c1
Jul 27 15:17:18 ltg01-fedora kernel:  [<c01a5265>] proc_tgid_stat+0xd/0xf
Jul 27 15:17:18 ltg01-fedora kernel:  [<c01a29dd>] proc_info_read+0x50/0xb3
Jul 27 15:17:18 ltg01-fedora kernel:  [<c0171cbb>] vfs_read+0xcb/0x177
Jul 27 15:17:18 ltg01-fedora kernel:  [<c017217c>] sys_read+0x3b/0x71
Jul 27 15:17:18 ltg01-fedora kernel:  [<c0103119>] sysenter_past_esp+0x56/0x8d
Jul 27 15:17:18 ltg01-fedora kernel: note: udevd[1353] exited with
preempt_count 1
Jul 27 15:17:18 ltg01-fedora kernel: BUG: scheduling while atomic:
udevd/0x00000001/1353
Jul 27 15:17:18 ltg01-fedora kernel:  [<c0104192>] show_trace_log_lvl+0x58/0x152
Jul 27 15:17:18 ltg01-fedora kernel:  [<c0104896>] show_trace+0xd/0x10
Jul 27 15:17:18 ltg01-fedora kernel:  [<c01049b5>] dump_stack+0x19/0x1b
Jul 27 15:17:18 ltg01-fedora kernel:  [<c02ef76f>] __sched_text_start+0x5f/0xc95
Jul 27 15:17:18 ltg01-fedora kernel:  [<c02f2977>] __down+0xaf/0xc3
Jul 27 15:17:18 ltg01-fedora kernel:  [<c02f275e>] __down_failed+0xa/0xe
Jul 27 15:17:18 ltg01-fedora kernel: DWARF2 unwinder stuck at
__down_failed+0xa/0xe
Jul 27 15:17:18 ltg01-fedora kernel: Leftover inexact backtrace:
Jul 27 15:17:18 ltg01-fedora kernel:  [<c0104896>] show_trace+0xd/0x10
Jul 27 15:17:18 ltg01-fedora kernel:  [<c01049b5>] dump_stack+0x19/0x1b
Jul 27 15:17:18 ltg01-fedora kernel:  [<c02ef76f>] __sched_text_start+0x5f/0xc95
Jul 27 15:17:18 ltg01-fedora kernel:  [<c02f2977>] __down+0xaf/0xc3
Jul 27 15:17:18 ltg01-fedora kernel:  [<c02f275e>] __down_failed+0xa/0xe
Jul 27 15:17:18 ltg01-fedora kernel:  [<c02f32aa>]
.text.lock.kernel_lock+0x1b/0x3d
Jul 27 15:17:18 ltg01-fedora kernel:  [<c023c881>] disassociate_ctty+0xd/0x16e
Jul 27 15:17:18 ltg01-fedora kernel:  [<c0122d8d>] do_exit+0x452/0xa4f
Jul 27 15:17:18 ltg01-fedora kernel:  [<c01047a1>] die+0x291/0x2b7
Jul 27 15:17:18 ltg01-fedora kernel:  [<c0116f5f>] do_page_fault+0x410/0x4f0
Jul 27 15:17:18 ltg01-fedora kernel:  [<c0103d1d>] error_code+0x39/0x40
Jul 27 15:17:18 ltg01-fedora kernel:  [<c0139214>] lock_acquire+0x71/0x91
Jul 27 15:17:18 ltg01-fedora kernel:  [<c02f2bfb>] _spin_lock+0x23/0x32
Jul 27 15:17:18 ltg01-fedora kernel:  [<c014fe3a>]
__delayacct_blkio_ticks+0x16/0x67
Jul 27 15:17:18 ltg01-fedora kernel:  [<c01a4f76>] do_task_stat+0x3df/0x6c1
Jul 27 15:17:18 ltg01-fedora kernel:  [<c01a5265>] proc_tgid_stat+0xd/0xf
Jul 27 15:17:18 ltg01-fedora kernel:  [<c01a29dd>] proc_info_read+0x50/0xb3
Jul 27 15:17:18 ltg01-fedora kernel:  [<c0171cbb>] vfs_read+0xcb/0x177
Jul 27 15:17:18 ltg01-fedora kernel:  [<c017217c>] sys_read+0x3b/0x71
Jul 27 15:17:18 ltg01-fedora kernel:  [<c0103119>] sysenter_past_esp+0x56/0x8d
Jul 27 15:17:18 ltg01-fedora kernel: slab error in
verify_redzone_free(): cache `delayacct_cache': double free detected
Jul 27 15:17:18 ltg01-fedora kernel:  [<c0104192>] show_trace_log_lvl+0x58/0x152
Jul 27 15:17:18 ltg01-fedora kernel:  [<c0104896>] show_trace+0xd/0x10
Jul 27 15:17:18 ltg01-fedora kernel:  [<c01049b5>] dump_stack+0x19/0x1b
Jul 27 15:17:18 ltg01-fedora kernel:  [<c016bdb4>] __slab_error+0x17/0x1c
Jul 27 15:17:18 ltg01-fedora kernel:  [<c016be85>]
cache_free_debugcheck+0xcc/0x1c7
Jul 27 15:17:18 ltg01-fedora kernel:  [<c016c74f>] kmem_cache_free+0xa0/0xff
Jul 27 15:17:18 ltg01-fedora kernel:  [<c014ff3e>]
__delayacct_tsk_exit+0x38/0x3d
Jul 27 15:17:18 ltg01-fedora kernel:  [<c0150281>]
delayacct_watch_task+0x5a/0x65
Jul 27 15:17:18 ltg01-fedora kernel:  [<c012ca03>] notifier_call_chain+0x20/0x31
Jul 27 15:17:18 ltg01-fedora kernel:  [<c012cd9f>]
blocking_notifier_call_chain+0x1d/0x2d
Jul 27 15:17:18 ltg01-fedora kernel:  [<c012cdc6>] notify_watchers+0x17/0x53
Jul 27 15:17:18 ltg01-fedora kernel:  [<c0122bf4>] do_exit+0x2b9/0xa4f
Jul 27 15:17:18 ltg01-fedora kernel:  [<c0123415>] sys_exit_group+0x0/0x11
Jul 27 15:17:18 ltg01-fedora kernel:  [<c0104896>] show_trace+0xd/0x10
Jul 27 15:17:18 ltg01-fedora kernel:  [<c01049b5>] dump_stack+0x19/0x1b
Jul 27 15:17:18 ltg01-fedora kernel:  [<c016bdb4>] __slab_error+0x17/0x1c
Jul 27 15:17:18 ltg01-fedora kernel:  [<c016be85>]
cache_free_debugcheck+0xcc/0x1c7
Jul 27 15:17:18 ltg01-fedora kernel:  [<c016c74f>] kmem_cache_free+0xa0/0xff
Jul 27 15:17:18 ltg01-fedora kernel:  [<c014ff3e>]
__delayacct_tsk_exit+0x38/0x3d
Jul 27 15:17:18 ltg01-fedora kernel:  [<c0150281>]
delayacct_watch_task+0x5a/0x65
Jul 27 15:17:18 ltg01-fedora kernel:  [<c012ca03>] notifier_call_chain+0x20/0x31
Jul 27 15:17:18 ltg01-fedora kernel:  [<c012cd9f>]
blocking_notifier_call_chain+0x1d/0x2d
Jul 27 15:17:18 ltg01-fedora kernel:  [<c012cdc6>] notify_watchers+0x17/0x53
Jul 27 15:17:18 ltg01-fedora kernel:  [<c0122bf4>] do_exit+0x2b9/0xa4f
Jul 27 15:17:18 ltg01-fedora kernel:  [<c0123415>] sys_exit_group+0x0/0x11
Jul 27 15:17:18 ltg01-fedora kernel:  [<c0123424>] sys_exit_group+0xf/0x11
Jul 27 15:17:18 ltg01-fedora kernel:  [<c0103119>] sysenter_past_esp+0x56/0x8d

list *0xc0138722
0xc0138722 is in __lock_acquire (include2/asm/atomic.h:96).

91       *
92       * Atomically increments @v by 1.
93       */

94 static __inline__ void atomic_inc(atomic_t *v)
95 {
96 __asm__ __volatile__(
97 LOCK_PREFIX "incl %0"
98 :"+m" (v->counter));
99 }
100

http://www.stardust.webpages.pl/files/mm/2.6.18-rc2-mm1/mm-config

Regards,
Michal

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

Bug is between reducing-local_bh_enable-disable-overhead-in-irqtrace.patch and reiserfs-use-generic_file_open-for-open-checks.patch (we could reject 5 reiserfs patches from suspects list)

Between remove-incorrect-unlock_kernel-from-failure-path-in.patch and reiserfs-use-generic_file_open-for-open-checks.patch I have noticed a lot of this bugs

Netfilter messages via NETLINK v0.30.
ip_conntrack version 2.4 (8192 buckets, 65536 max) - 224 bytes per conntrack

BUG: warning at /usr/src/linux-work1/kernel/cpu.c:51/unlock_cpu_hotplug()
[<c0103f0a>] show_trace_log_lvl+0x58/0x152
[<c010460e>] show_trace+0xd/0x10
[<c010472d>] dump_stack+0x19/0x1b
[<c013991e>] unlock_cpu_hotplug+0x2f/0x59
[<f98fe1e8>] store_speed+0x8f/0x9b [cpufreq_userspace]
[<c0287c7e>] store+0x37/0x48
[<c0199cd3>] sysfs_write_file+0xa6/0xcc
[<c0167567>] vfs_write+0xab/0x157
[<c0167baa>] sys_write+0x3b/0x60
[<c0102ea1>] sysenter_past_esp+0x56/0x8d
DWARF2 unwinder stuck at sysenter_past_esp+0x56/0x8d
Leftover inexact backtrace:
[<c010460e>] show_trace+0xd/0x10
[<c010472d>] dump_stack+0x19/0x1b
[<c013991e>] unlock_cpu_hotplug+0x2f/0x59
[<f98fe1e8>] store_speed+0x8f/0x9b [cpufreq_userspace]
[<c0287c7e>] store+0x37/0x48
[<c0199cd3>] sysfs_write_file+0xa6/0xcc
[<c0167567>] vfs_write+0xab/0x157
[<c0167baa>] sys_write+0x3b/0x60
[<c0102ea1>] sysenter_past_esp+0x56/0x8d

I'll finish this bisection later.

Regards,
Michal

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

Hi Dave,

I was wrong (as usually :)

git-cpufreq.patch is causing this error

Regards,
Michal

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

http://www.stardust.webpages.pl/files/mm/2.6.18-rc2-mm1/mm-config

Regards,
Michal

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

Hi,

Matt, can you look at this?

My hunt file shows me, that this patches are causing oops. GOOD
#
#
task-watchers-task-watchers.patch task-watchers-register-process-events-task-watcher.patch task-watchers-refactor-process-events.patch task-watchers-make-process-events-configurable-as.patch task-watchers-allow-task-watchers-to-block.patch task-watchers-register-audit-task-watcher.patch task-watchers-register-per-task-delay-accounting.patch task-watchers-register-profile-as-a-task-watcher.patch task-watchers-add-support-for-per-task-watchers.patch task-watchers-register-semundo-task-watcher.patch task-watchers-register-per-task-semundo-watcher.patch BAD

Regards,
Michal

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

Thanks for working that out.

I've actually been thinking that we shouldn't proceed with those patches.

They're a nice cleanup and make the kernel code _look_ better and I really like them because of this. But the cost is potentially significant. We replace N direct calls with a walk of a notifier chain, more than N indirect calls, demultiplexing at the other end and then a direct call. That's a significant amount of additional overhead to make the kernel source look nicer.

Plus, ugly though it is, you can look at the current code and see what it's doing. With a notifier chain you have to grep around the tree and work out what might be hooking into the chain, which is harder.

Finally, the consolidation into a notifier chain forces all the fork/exit/exec hooks into an one-size-fits-all model. What happens if one subsystem wants to hook in before exit_mmap() and another one wants to hook in after exit_mmap() (for example)?

I noticed the delay accounting functions in the stack trace. Perhaps
task-watchers-register-per-task-delay-accounting.patch is causing the problem. With all of the recent churn in per-task delay accounting I'm wondering if that patch is still correct. Balbir, Shailabh, what do you think?

OK. The multiple notifier chain approach you suggested gets rid of demultiplexing. We'd replace N direct calls with a walk of a notifier chain and (more than??) N indirect calls.

An alternative suggested to me by Al Viro is to handle these functions
much like the *_initcall() macros in include/linux/init.h. This replaces N direct calls with an array walk and N indirect calls. Unfortunately, this does not work for modules.

The same is true when using function pointers in other areas of the
kernel. They make the code harder to trace but have advantages you can't get by simply pasting the function call into the path.

That said, I think walking the code is a bit easier with the multichain
approach. Lastly, at each invocation I could put in a comment explaining how to find users of the chain.

As I see it there's not much I can do about the one-size-fits-all
model. So I tried to find the one size that fits most.

I think many systems that place calls in these paths aren't as
sensitive to their precise location as you might imagine. Many need to initialize their per-task data and clean it up. They tend to depend on a valid task structure and little else. Fewer systems -- profile for instance -- have very specific requirements for when/where they get called. Yet even profile can use some of task watchers.

I considered some obvious alternatives but they had worse problems.
Adding more notifications will run into naming problems. Using notifier block priorities would have similar problems and be even harder to trace by hand.

For those special systems that don't fit this "size" I think leaving
them in these paths is the best approach.

Cheers,
-Matt Helsley

Confirmed.

Regards,
Michal

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

Excellent, thanks for the rapid confirmation. I'll work with Shailabh and Balbir to fix this. In the meantime perhaps task-watchers-register-per-task-delay-accounting.patch should be dropped from -mm.

Cheers,
-Matt Helsley

I think the whole patch series should be dropped, sorry. We will occasionally add more runtime overhead to gain code maintainability or readability or to squach warnings. But I do think this patchset goes too far.

I finished a bisect on -mm - I ca confirm that this one patch is also responsible for the solid lockups I was seeing on a Dell C840. Am now up and running on -rc2-mm1 with this one reverted.

The error is almost certainly because delayacct_tsk_init is being called at WATCH_TASK_CLONE (which is triggered after the task has been added to the tasklist) rather than WATCH_INIT (before).

__delayacct_tsk_init, which gets notified by WATCH_TASK_* initializes the spinlock tsk->delays_lock which could get used as soon as task is present in tasklist. The lockup is very likely due to use of this uninitialized spinlock.

So the fix should be to change WATCH_TASK_CLONE to WATCH_TASK_INIT in the delayacct_watch_task function created by this patch.

--Shailabh

Hi,

Problem solved. Thanks.

Regards,
Michal

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

Sure. Thanks for the report.

Cheers,
-Matt Helsley

Seems that this one is eating /dev/null's during 'make' phase of a build. Am trying to track down whats changed.

-apw

Ok, this seems to be related to the changes in:

vdso-hash-style-fix.patch

Backing this out reverses the new behaviour.

It looks like the check to see if the options are valid, use -o /dev/null -xc /dev/null and that is causing the compiler to remove /dev/null.

The machines affected do not seem to have such old compilers:

	gcc version 3.3.4 (Debian 1:3.3.4-3)

Yeah, yeah I know I should not be running my builds as root, but then we should not be eating it either.

-apw

Hi Andrew,

Andrew Morton wrote:
[snipped]

[snipped]

The following patch provides better protection against people exploiting stuff in /proc and I hope you consider it for upstream inclusion.

Thanks.

Eugene

[PATCH] Require mmap handler for a.out executables

Files supported by fs/proc/base.c, i.e. /proc/<pid>/*, are not capable of meeting the validity checks in ELF load_elf_*() handling because they have no mmap handler which is required by ELF. In order to stop a.out executables being used as part of an exploit attack against /proc-related vulnerabilities, we make a.out executables depend on ->mmap() existing.

---
commit 1597cf8405734e4747c808bb7e04115a6670dccf
tree 49050549aee6406dab0c021c5aa4e9bfc337bd8f
parent 44eb123126d289bac398cac0232309c228386671
author Marcel Holtmann <[email protected]> Wed, 26 Jul 2006 12:12:14 +0200 committer Marcel Holtmann <[email protected]> Wed, 26 Jul 2006 12:12:14 +0200

 fs/binfmt_aout.c |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

index f312103..5638acf 100644
@@ -278,6 +278,9 @@ static int load_aout_binary(struct linux
 		return -ENOEXEC;
 	}
 
+	if (!bprm->file->f_op || !bprm->file->f_op->mmap)
+		return -ENOEXEC;
+
 	fd_offset = N_TXTOFF(ex);
 
 	/* Check initial limits. This avoids letting people circumvent

@@ -476,6 +479,9 @@ static int load_aout_library(struct file
 		goto out;
 	}
 
+	if (!file->f_op || !file->f_op->mmap)
+		goto out;
+
 	if (N_FLAGS(ex))
 		goto out;
 

eteo redhat.com  ph: +65 6490 4142  http://www.kernel.org/~eugeneteo
gpg fingerprint:  47B9 90F6 AE4A 9C51 37E0  D6E1 EA84 C6A2 58DF 8823

Hi,

This patch has fixed following build error.
This error occurred in relation to reduce-max_nr_zones-move-highmem-counters-into-highmemc-h.patch .

CC arch/mips/sgi-ip27/ip27-memory.o
arch/mips/sgi-ip27/ip27-memory.c: In function `mem_init':
arch/mips/sgi-ip27/ip27-memory.c:582: error: `totalhigh_pages' undeclared (first use in this function) arch/mips/sgi-ip27/ip27-memory.c:582: error: (Each undeclared identifier is reported only once arch/mips/sgi-ip27/ip27-memory.c:582: error: for each function it appears in.) make[1]: *** [arch/mips/sgi-ip27/ip27-memory.o] Error 1
make: *** [arch/mips/sgi-ip27] Error 2

Yoichi

diff -pruN -X linux-2.6.18-rc2-mm1/Documentation/dontdiff linux-2.6.18-rc2-mm1-orig/arch/mips/sgi-ip27/ip27-memory.c linux-2.6.18-rc2-mm1/arch/mips/sgi-ip27/ip27-memory.c
@@ -19,6 +19,7 @@
 #include <linux/swap.h>
 #include <linux/bootmem.h>
 #include <linux/pfn.h>
+#include <linux/highmem.h>
 #include <asm/page.h>
 #include <asm/sections.h>
 

This patch contains the following fixes:
- add an #include <asm/setup.h> for getting the prototype of add_memory_region()
since add_memory_region() has two "long long" parameters, it's possible this might fix runtime corruption problems
- make the needlessly global pci_mmcfg_force() static

---

 arch/i386/pci/mmconfig.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

@@ -15,6 +15,7 @@
 #include <linux/dmi.h>
 #include <linux/efi.h>
 #include <asm/e820.h>
+#include <asm/setup.h>
 #include "pci.h"
 
 /* aperture is up to 256MB but BIOS may reserve less */

@@ -225,7 +226,7 @@
  * Check force MMCONFIG.
  */
 
-int __init pci_mmcfg_force(void)
+static int __init pci_mmcfg_force(void)
 {
 	if (efi_enabled) {
 		if (dmi_check_system(pci_mmcfg_dmi_system_apple)) {

Hello,

Some change between -rc1-mm2 and -rc2-mm1 broke Kubuntu's udev (079-0ubuntu34). In particular /dev/mem went missing, and /dev/null had bogus permissions (crw-------). I've kludged around the problem by populating /lib/udev/devices from a good /dev, but I'm assuming the breakage was unintentional.

Andrew Wade

/dev/null damage is due to a combination of vdso-hash-style-fix.patch and doing the kernel build as root (don't do that).

I don't know what happened to /dev/mem.

Me either. Look in /sys/class/mem/ Is it full of symlinks or real directories?

If symlinks, your version of udev should be able to handle it properly, but might have a bug somehow.

Try running udevmonitor and echo a "1" to /sys/class/mem/mem/uevent and see if udev creates the device properly or not.

thanks,

greg k-h

Symlinks.

udevmonitor prints the received event from the kernel [UEVENT] and the event which udev sends out after rule processing [UDEV]

UEVENT[1154093169.330045] add@/devices/mem
UDEV [1154093169.331914] add@/devices/mem

The device node was not created.

udev.log for 2.6.18-rc1-mm2 (which does work) has these lines:

UEVENT[1154105360.092631] add@/class/mem/mem
ACTION=add
DEVPATH=/class/mem/mem
SUBSYSTEM=mem
SEQNUM=589
MAJOR=1
MINOR=1

...

UDEV [1154105363.575086] add@/class/mem/mem
UDEV_LOG=3
ACTION=add
DEVPATH=/class/mem/mem
SUBSYSTEM=mem
SEQNUM=589
MAJOR=1
MINOR=1
UDEVD_EVENT=1
DEVNAME=/dev/mem

The Changelog for udev v081 has:
"prepare moving of /sys/class devices to /sys/devices" Is this related?

Thanks,
Andrew Wade

gregkh-driver-mem-devices.patch seems to be the culprit.

With this patch, /sys/class/mem/ looks like this:

/sys/class/mem/

|-- full -> ../../devices/full
|-- kmem -> ../../devices/kmem
|-- kmsg -> ../../devices/kmsg
|-- mem -> ../../devices/mem
|-- null -> ../../devices/null
|-- port -> ../../devices/port
|-- random -> ../../devices/random
|-- urandom -> ../../devices/urandom

`-- zero -> ../../devices/zero

9 directories, 0 files

And /sys/class/mem/*/ look like this:

/sys/class/mem/full/

|-- dev
|-- power
|   |-- state
|   `-- wakeup
|-- subsystem -> ../../class/mem
`-- uevent
/sys/class/mem/kmem/
|-- dev
|-- power
|   |-- state
|   `-- wakeup
|-- subsystem -> ../../class/mem
`-- uevent
/sys/class/mem/kmsg/
|-- dev
|-- power
|   |-- state
|   `-- wakeup
|-- subsystem -> ../../class/mem
`-- uevent
/sys/class/mem/mem/
|-- dev
|-- power
|   |-- state
|   `-- wakeup
|-- subsystem -> ../../class/mem
`-- uevent
/sys/class/mem/null/
|-- dev
|-- power
|   |-- state
|   `-- wakeup
|-- subsystem -> ../../class/mem
`-- uevent
/sys/class/mem/port/
|-- dev
|-- power
|   |-- state
|   `-- wakeup
|-- subsystem -> ../../class/mem
`-- uevent
/sys/class/mem/random/
|-- dev
|-- power
|   |-- state
|   `-- wakeup
|-- subsystem -> ../../class/mem
`-- uevent
/sys/class/mem/urandom/
|-- dev
|-- power
|   |-- state
|   `-- wakeup
|-- subsystem -> ../../class/mem
`-- uevent
/sys/class/mem/zero/
|-- dev
|-- power
|   |-- state
|   `-- wakeup
|-- subsystem -> ../../class/mem

`-- uevent

18 directories, 36 files

In this situation, udev (version 096 here) is unable to create these device files (/dev/full, /dev/kmem, /dev/kmsg, etc.). /dev/null does exist (with wrong permissions) because it has been created by the initrd script.

In order to get back the device files, I have to run the following command:

# for f in /sys/class/mem/*/uevent; do echo 1 > $f; done

After gregkh-driver-mem-devices.patch been reverted, all is working fine and /sys/class/mem/ looks like this:

/sys/class/mem/

|-- full
|   |-- dev
|   |-- subsystem -> ../../../class/mem
|   `-- uevent
|-- kmem
|   |-- dev
|   |-- subsystem -> ../../../class/mem
|   `-- uevent
|-- kmsg
|   |-- dev
|   |-- subsystem -> ../../../class/mem
|   `-- uevent
|-- mem
|   |-- dev
|   |-- subsystem -> ../../../class/mem
|   `-- uevent
|-- null
|   |-- dev
|   |-- subsystem -> ../../../class/mem
|   `-- uevent
|-- port
|   |-- dev
|   |-- subsystem -> ../../../class/mem
|   `-- uevent
|-- random
|   |-- dev
|   |-- subsystem -> ../../../class/mem
|   `-- uevent
|-- urandom
|   |-- dev
|   |-- subsystem -> ../../../class/mem
|   `-- uevent
`-- zero
    |-- dev
    |-- subsystem -> ../../../class/mem
    `-- uevent

18 directories, 18 files

~~
laurent

Something's really broken with that version of udev then, because the 094 version I have running here works just fine with these symlinks.

Ah, ok, it sounds like it's not a bug in udev itself, but rather a bug in the way your distro does it's initialization of udev, at boot. I suggest you file a bug with them, as they are known for doing this a bit differently than any other distro (and different from how the udev developers recommend), so they can fix it. It's probably just a shell script issue.

thanks,

greg k-h

Maybe, but some really odd things were happening in /sys with the patch. I could still follow the bogus symlinks. More than that

/sys/class/mem/mem$ cd ../../class
and
/sys/class/mem/mem$ cd ../..

_both_ ended up with a $PWD of /sys/class.

With the patch reverted, udev now works correctly (thanks, Laurent), and /sys/class/mem/mem$ cd ../../class
fails with the expected error.

Andrew Wade

Ick, ok, the problem is that my "virtual device" patch isn't in my "public" patch set that Andrew pulls from. It will fix this issue up. I'll work on cleaning it up to be used by everyone tomorrow and move it to the tree that Andrew pulls from. Then the next -mm release should have this issue fixed.

If you want to verify this, please apply the patch at:
http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/patches/device-virtual.patch
and let me know if it solves your issue (note that the reference counting is not completly correct in that patch, that's why I haven't unleashed it on -mm yet.)

thanks,

greg k-h

Mutter. This stuff breaks my FC3 test box and there is, afaict, no clear way for users to upgrade udev to unbreak it.

As a developer I could of course bang on things until it works, but that's not the point. The point is that these patches break Linux on a major release from a major vendor only two years after its release. That's not a minor problem, is it?

Well, yes, it is. That distro is unsupported now, right?

How long do you expect the kernel to support unsupported, community based distros that thrive on the fact that they are quickly updated?

Look at Documentation/Changes for the version of udev that the kernel now requires. It's 071 due to the input layer code (which was released in October of 2005). Odds are you have just gotten lucky that FC3 is not working for you right now.

And yes, I will revert the patch in mainline that causes people to have to upgrade to a udev that is in FC5, and wait till the next release for that to happen (the minimum will be 081, which was released in January, 2006, by the time 2.6.19 is out, that will be about 10 months old.)

Debian and Gentoo already support new enough versions of udev, and so does OpenSuSE and Fedora with their latest, supported versions. How long should the kernel be forced to lag behind?

I'm also going to fix up older versions of SuSE (10.0, which is no longer supported by the vendor) so that it will support this kernel change too, it's only a few lines of patch to udev, but don't have the ability to do the same for Fedora, sorry.

Remember, most distros tie their kernel to their userspace very tightly, so the ability to upgrade the kernel without some userspace packages does not always work (HAL stopped working long ago in FC3 with newer kernels I imagine.) If you are a kernel developer, who updates kernels often, choose a distro that allows that flexibility (Gentoo and Debian are two that I know of, FC Rawhide and OpenSuSE Factory are two others that should also do it.)

Remember, FC3 is now in Legacy support mode, not something the mainline kernel should have to worry about.

thanks,

greg k-h

It's not specifically related to FC3. It's udev - we've broken _any_ distribution which uses a two-year-old udev. In fact we're proposing breaking any distro which has an older-than-ten-month udev. That's really bad.

It's worse on FC3 because there is, as far as I can tell, no rpm or srpm which can be used to unbreak it. And pointing at Documentation/Changes doesn't alter that, does it?

Personally, there's no way I'm upgrading this box because I _want_ to run old distros to catch things like this. So I'll hack it around to work somehow. I can do that, because I'm a developer.

Are we going to stop doing this soon?

Why? What do you propose we do then? Wait a year? Two years? I've already stated that I'm going to wait 3 more months in order to be able to fix up the currently supported distros to handle the changes needed. I'll even dig up RC4 to get that working, as it shouldn't be that hard to do so. What more can I do?

No, but it does show that you are running on an unsupported distro. Why should the kernel developers have to support this? When is the cut-off date?

And that's the only group of people who would try to do this. Seriously, I don't see the complaint here. It's an unsupported distro by the very makers of that distro. How long should the community have to care about a distro after the creators of it have abandonded it?

Not if we want to keep on making things better. The real reason I made these changes is to get power management working better. We need to get the devices into the proper place in the sysfs tree in order to handle suspend/resume for classes of devices properly. That's what Linus's patch did, and now I'm moving the devices to allow it to really happen.

thanks,

greg k-h

Greg, once we put an interface into the kernel and expose it to userspace, that's it - we support it forever. At least, that's the model. Yes, sometimes in cases of necessity where we cannot feasibly support old userspace we'll break things, with long notice and considerable thought and care.

The impact is lower in this case because we've already trained our long-suffering users to expect udev to regularly break.

Please stop going on about FC3. My (repeat) point is that we're proposing to break _all_ distros which are older than ten months. We don't play the "oh, that isn't supported any more" game.

This sucks. Do you know what machines we'll be breaking out there? I sure don't.

It has broken, even in 2.6.18-rc3, see http://lkml.org/lkml/2006/7/30/163
'2.6.18-rc3 does not like an old udev (071)' and beyond.

It now requires udev 079, in disaccordance with the Documentation/Changes file.

This breaks Ubuntu LTS, which for some reason chose to ship udev 071.

Thanks.

http://www.PowerDNS.com      Open source, database driven DNS Software 
http://netherlabs.nl              Open and Closed source services

It'll probably also cause trouble for the upcomming release of Slackware. Slackware 11 is just around the corner and slackware-current currently has udev 071. The kernel is 2.4.32 or 2.6.17.7 (user choice), but I'll bet many people will want to install newer kernels.

Jesper Juhl <[email protected]>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

Ar Sul, 2006-07-30 am 23:00 -0700, ysgrifennodd Andrew Morton:

Greg, this changeset should get ripped out and thrown away. Its wrong. Its an API breakage and it is going to catch a lot of people. People said at the kernel summit the sysfs had serious problems because of the structure it exposes and you said you could use symlinks and the like to work around it, or fix the code.

How about proving it or doing the work to make it possible rather than continuing to break everything repeatedly.

Alan

device-virtual.patch won't apply on top of 2.6.18-rc2-mm1:

linux-2.6-mm$ head -4 Makefile
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 18
EXTRAVERSION = -rc2-mm1

linux-2.6-mm$ quilt pop -a
Aucun patch retiré

linux-2.6-mm$ quilt push
Application de patches/device-virtual.patch
patching file drivers/base/Makefile
patching file drivers/base/base.h
Hunk #1 succeeded at 44 (offset 1 line).
patching file drivers/base/core.c
Hunk #1 succeeded at 434 (offset 60 lines).
Hunk #2 FAILED at 486.
Hunk #3 succeeded at 615 (offset 61 lines).
1 out of 3 hunks FAILED -- rejects in file drivers/base/core.c patching file drivers/base/virtual.c
patching file include/linux/device.h
Hunk #1 succeeded at 356 (offset 5 lines).
Le patch patches/device-virtual.patch ne s'applique pas proprement (forcez l'application avec -f)

laurent

Sorry for the false alarm: I didn't note the previous level of symlinks in /sys/class/mem, and the subsystem symlinks were actually correct. The strange behaviour of cd was the result of my shell being to clever for my own good.

...

Unfortunately not. I hand-applied the one reject like so:

diff -rupN 2.6.18-rc2-mm1/drivers/base/core.c linux/drivers/base/core.c
@@ -368,7 +368,7 @@ static int device_add_class_symlinks(str
 				  dev->bus_id);
 	if (error)
 		goto out_subsys;
-	if (dev->parent) {
+	if ((dev->parent) && (!dev->virtual)) {
 		error = sysfs_create_link(&dev->kobj, &dev->parent->kobj,
 					  "device");
 		if (error)

but udev (79-0ubuntu34) did not work with the patch applied.

thanks,
Andrew Wade

Hmm... I thought the vdso-hash whoops caused /dev/null to get removed and thus recreated as a regular file - Andrew Wade is showing it as being mode 600 - but still a 'char special'?

Or did udev get there before somebody managed to recreate it, and it stuck funky permissions on it?

Still seeing breakage with the e1000/NAT. Now the problem isn't so much that the bug exists, but that unlike in -rc1-mm2, the trace scrolls over and over and over (with some variation down into it) until the kernel completely panics and the box has to be rebooted.

http://www.ussg.iu.edu/hypermail/linux/kernel/0607.1/2689.html from Herbert Xu talks about the original problem.

It's a regression from the previous -mm whereby the trace would print out just once.

Starting Dovecot Imap: [ OK ]
Starting clamd: [ OK ]
Starting amavisd: BUG: warning at net/core/dev.c:1168/skb_checksum_help()

Call Trace:
 [<ffffffff80269c65>] show_trace+0xb5/0x324
 [<ffffffff80269ee9>] dump_stack+0x15/0x1c
 [<ffffffff8043d4e8>] skb_checksum_help+0x63/0x13b
 [<ffffffff8802f35f>] :iptable_nat:ip_nat_fn+0x5f/0x1d2
 [<ffffffff8802f71b>] :iptable_nat:ip_nat_local_fn+0x33/0xbc
 [<ffffffff80234c9e>] nf_iterate+0x5a/0x9b
 [<ffffffff80258960>] nf_hook_slow+0x60/0xcd
 [<ffffffff80235174>] ip_queue_xmit+0x444/0x4c0
 [<ffffffff8022157f>] tcp_transmit_skb+0x68f/0x6cf
 [<ffffffff80233b67>] __tcp_push_pending_frames+0x867/0x95a
 [<ffffffff8021b9fc>] tcp_rcv_established+0x72c/0x7c4
 [<ffffffff8023c60e>] tcp_v4_do_rcv+0x2e/0x317
 [<ffffffff8022719c>] tcp_v4_rcv+0x9fc/0xa79
 [<ffffffff80235389>] ip_local_deliver+0x199/0x270
 [<ffffffff802363c3>] ip_rcv+0x4d3/0x52b
 [<ffffffff8021fdcb>] netif_receive_skb+0x1eb/0x27b
 [<ffffffff803c9491>] e1000_clean_rx_irq_ps+0x5c1/0x6a0
 [<ffffffff803c7b45>] e1000_clean+0x325/0x45b
 [<ffffffff8020c9b7>] net_rx_action+0x8e/0x147
 [<ffffffff80211663>] __do_softirq+0x78/0x105
 [<ffffffff80260716>] call_softirq+0x1e/0x28
DWARF2 unwinder stuck at call_softirq+0x1e/0x28
Leftover inexact backtrace:
 <IRQ> [<ffffffff8026b679>] do_softirq+0x39/0xa4
 [<ffffffff802888b8>] irq_exit+0x58/0x5a
 [<ffffffff8026b798>] do_IRQ+0xb4/0xbe
 [<ffffffff8025f9a1>] ret_from_intr+0x0/0xf
 <EOI><1>Unable to handle kernel paging request at ffffffff82800000 RIP:
 [<ffffffff80269e6f>] show_trace+0x2bf/0x324
PGD 203027 PUD 205027 PMD 0
Oops: 0000 [1] SMP
last sysfs file: /class/net/sit0/address
CPU 0
Modules linked in: hidp rfcomm l2cap bluetooth ipv6 ip_gre iptable_filter iptable_nat ip_nat ip_conntrack nfnetlink iptable_mangle

ip_tables binfmt_misc iTCO_wdt i2c_i801 serio_raw
Pid: 2127, comm: imap Not tainted 2.6.18-rc2-mm1 #1

RIP: 0010:[<ffffffff80269e6f>]  [<ffffffff80269e6f>] show_trace+0x2bf/0x324
RSP: 0000:ffffffff806366f0  EFLAGS: 00010206
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000004
RDX: 0000000000000010 RSI: ffff81003d95c840 RDI: ffff81003d95c140
RBP: ffffffff806367f0 R08: 0000000000000001 R09: 0000000000000001
R10: 0000000000000002 R11: 0000000000000001 R12: ffffffff827ffff9
R13: 0000000000000000 R14: 0000000000000000 R15: ffffffff80907000
FS:  00002ab5ab544860(0000) GS:ffffffff808b2000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: ffffffff82800000 CR3: 0000000029dea000 CR4: 00000000000006e0
Process imap (pid: 2127, threadinfo ffff810029e62000, task ffff81003d95c140)
Stack:  ffffffff806cec48 ffffffff80636fc0 0000000000000001 ffff81002c9d78f8
 0000000000000000 0000000000000000 00007fffff571020 ffff810029e63f58
 ffffffff80636f80 0000000000000046 0000000000000000 0000000000000000
Call Trace:
 [<ffffffff80269ee9>] dump_stack+0x15/0x1c
 [<ffffffff8043d4e8>] skb_checksum_help+0x63/0x13b
 [<ffffffff8802f35f>] :iptable_nat:ip_nat_fn+0x5f/0x1d2
 [<ffffffff8802f71b>] :iptable_nat:ip_nat_local_fn+0x33/0xbc
 [<ffffffff80234c9e>] nf_iterate+0x5a/0x9b
 [<ffffffff80258960>] nf_hook_slow+0x60/0xcd
 [<ffffffff80235174>] ip_queue_xmit+0x444/0x4c0
 [<ffffffff8022157f>] tcp_transmit_skb+0x68f/0x6cf
 [<ffffffff80233b67>] __tcp_push_pending_frames+0x867/0x95a
 [<ffffffff8021b9fc>] tcp_rcv_established+0x72c/0x7c4
 [<ffffffff8023c60e>] tcp_v4_do_rcv+0x2e/0x317
 [<ffffffff8022719c>] tcp_v4_rcv+0x9fc/0xa79
 [<ffffffff80235389>] ip_local_deliver+0x199/0x270
 [<ffffffff802363c3>] ip_rcv+0x4d3/0x52b
 [<ffffffff8021fdcb>] netif_receive_skb+0x1eb/0x27b
 [<ffffffff803c9491>] e1000_clean_rx_irq_ps+0x5c1/0x6a0
 [<ffffffff803c7b45>] e1000_clean+0x325/0x45b
 [<ffffffff8020c9b7>] net_rx_action+0x8e/0x147
 [<ffffffff80211663>] __do_softirq+0x78/0x105
 [<ffffffff80260716>] call_softirq+0x1e/0x28
DWARF2 unwinder stuck at call_softirq+0x1e/0x28
Leftover inexact backtrace:
 <IRQ> [<ffffffff8026b679>] do_softirq+0x39/0xa4
 [<ffffffff802888b8>] irq_exit+0x58/0x5a
 [<ffffffff8026b798>] do_IRQ+0xb4/0xbe
 [<ffffffff8025f9a1>] ret_from_intr+0x0/0xf
 <EOI><1>Unable to handle kernel paging request at ffffffff82800000 RIP:
 [<ffffffff80269e6f>] show_trace+0x2bf/0x324
PGD 203027 PUD 205027 PMD 0
Oops: 0000 [2] SMP
last sysfs file: /class/net/sit0/address
CPU 0
Modules linked in: hidp rfcomm l2cap bluetooth ipv6 ip_gre iptable_filter iptable_nat ip_nat ip_conntrack nfnetlink iptable_mangle

ip_tables binfmt_misc iTCO_wdt i2c_i801 serio_raw
Pid: 2127, comm: imap Not tainted 2.6.18-rc2-mm1 #1

RIP: 0010:[<ffffffff80269e6f>]  [<ffffffff80269e6f>] show_trace+0x2bf/0x324
RSP: 0000:ffffffff80636378  EFLAGS: 00010006
RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff880a3808
RDX: ffff81003d95c140 RSI: 0000000000000001 RDI: 0000000000000000
RBP: ffffffff80636478 R08: 0000000000000000 R09: 0000000000000001
R10: ffffffff8029fae0 R11: 0000000000000000 R12: ffffffff827ffff9
R13: 0000000000000000 R14: 0000000000000000 R15: ffffffff80907000
FS:  00002ab5ab544860(0000) GS:ffffffff808b2000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: ffffffff82800000 CR3: 0000000029dea000 CR4: 00000000000006e0
Process imap (pid: 2127, threadinfo ffff810029e62000, task ffff81003d95c140)
Stack:  000000000000000b ffffffff80636fc0 0000000080632fc0 0000000000000000
 0000000000000000 0000000000000000 00007fffff571020 ffff810029e63f58
 ffffffff80636f80 0000000000000046 0000000000000001 0000000000000002
Call Trace:
 [<ffffffff80269fdf>] _show_stack+0xef/0xfe
 [<ffffffff8026a07a>] show_registers+0x8c/0x101
 [<ffffffff8026a18f>] __die+0xa0/0xe3
 [<ffffffff8020af95>] do_page_fault+0x785/0x89d
 [<ffffffff802601ed>] error_exit+0x0/0x96
DWARF2 unwinder stuck at error_exit+0x0/0x96
Leftover inexact backtrace:
 <IRQ> [<ffffffff80269e6f>] show_trace+0x2bf/0x324
 [<ffffffff80260716>] call_softirq+0x1e/0x28
 [<ffffffff80269ee9>] dump_stack+0x15/0x1c
 [<ffffffff8043d4e8>] skb_checksum_help+0x63/0x13b
 [<ffffffff8802f35f>] :iptable_nat:ip_nat_fn+0x5f/0x1d2
 [<ffffffff8802f71b>] :iptable_nat:ip_nat_local_fn+0x33/0xbc
 [<ffffffff80234c9e>] nf_iterate+0x5a/0x9b
 [<ffffffff804579a6>] dst_output+0x0/0x10
 [<ffffffff80258960>] nf_hook_slow+0x60/0xcd
 [<ffffffff804579a6>] dst_output+0x0/0x10
 [<ffffffff80265999>] _spin_unlock_irqrestore+0x3f/0x47
 [<ffffffff80235174>] ip_queue_xmit+0x444/0x4c0
 [<ffffffff8024bc5d>] tso_fragment+0x5d/0x20e
 [<ffffffff80210009>] __kmalloc_track_caller+0x109/0x11b
 [<ffffffff8022157f>] tcp_transmit_skb+0x68f/0x6cf
 [<ffffffff8024bda6>] tso_fragment+0x1a6/0x20e
 [<ffffffff80233b67>] __tcp_push_pending_frames+0x867/0x95a
 [<ffffffff80228ef8>] __kfree_skb+0xfc/0x101
 [<ffffffff80236fe1>] tcp_data_queue+0x651/0xc39
 [<ffffffff8021b9fc>] tcp_rcv_established+0x72c/0x7c4
 [<ffffffff8023c60e>] tcp_v4_do_rcv+0x2e/0x317
 [<ffffffff8022719c>] tcp_v4_rcv+0x9fc/0xa79
 [<ffffffff80258960>] nf_hook_slow+0x60/0xcd
 [<ffffffff804552b0>] ip_local_deliver_finish+0x0/0x1fb
 [<ffffffff80235389>] ip_local_deliver+0x199/0x270
 [<ffffffff802363c3>] ip_rcv+0x4d3/0x52b
 [<ffffffff80439ccc>] kfree_skb+0x2c/0x31
 [<ffffffff8021fdcb>] netif_receive_skb+0x1eb/0x27b
 [<ffffffff803c9491>] e1000_clean_rx_irq_ps+0x5c1/0x6a0
 [<ffffffff803c7b45>] e1000_clean+0x325/0x45b
 [<ffffffff8020c9b7>] net_rx_action+0x8e/0x147
 [<ffffffff8021164f>] __do_softirq+0x64/0x105
 [<ffffffff80211663>] __do_softirq+0x78/0x105
 [<ffffffff80260716>] call_softirq+0x1e/0x28
 [<ffffffff8026b679>] do_softirq+0x39/0xa4
 [<ffffffff802888b8>] irq_exit+0x58/0x5a
 [<ffffffff8026b798>] do_IRQ+0xb4/0xbe
 [<ffffffff8025f9a1>] ret_from_intr+0x0/0xf
 <EOI><1>Unable to handle kernel paging request at ffffffff82800000 RIP:
 [<ffffffff80269e6f>] show_trace+0x2bf/0x324
PGD 203027 PUD 205027 PMD 0
Oops: 0000 [3] SMP
last sysfs file: /class/net/sit0/address
CPU 0
Modules linked in: hidp rfcomm l2cap bluetooth ipv6 ip_gre iptable_filter iptable_nat ip_nat ip_conntrack nfnetlink iptable_mangle

ip_tables binfmt_misc iTCO_wdt i2c_i801 serio_raw
Pid: 2127, comm: imap Not tainted 2.6.18-rc2-mm1 #1

RIP: 0010:[<ffffffff80269e6f>]  [<ffffffff80269e6f>] show_trace+0x2bf/0x324
RSP: 0000:ffffffff80635ff8  EFLAGS: 00010006
RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff880a3808
RDX: ffff81003d95c140 RSI: 0000000000000001 RDI: 0000000000000000
RBP: ffffffff806360f8 R08: 0000000000000000 R09: 0000000000000001
R10: ffffffff8029fae0 R11: 0000000000000000 R12: ffffffff827ffff9
R13: 0000000000000000 R14: 0000000000000000 R15: ffffffff80907000
FS:  00002ab5ab544860(0000) GS:ffffffff808b2000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: ffffffff82800000 CR3: 0000000029dea000 CR4: 00000000000006e0
Process imap (pid: 2127, threadinfo ffff810029e62000, task ffff81003d95c140)
Stack:  000000000000000b ffffffff80636fc0 0000000080632fc0 0000000000000000
 ffffffff80907000 0000000000000000 0000000000000000 ffffffff827ffff9
 000000008025fa27 0000000000000001 0000000000000000 ffffffff8029fae0
Call Trace:
 [<ffffffff80269fdf>] _show_stack+0xef/0xfe
 [<ffffffff8026a07a>] show_registers+0x8c/0x101
 [<ffffffff8026a18f>] __die+0xa0/0xe3
 [<ffffffff8020af95>] do_page_fault+0x785/0x89d
 [<ffffffff802601ed>] error_exit+0x0/0x96
DWARF2 unwinder stuck at error_exit+0x0/0x96
Leftover inexact backtrace:
 <IRQ> [<ffffffff8029fae0>] module_text_address+0x16/0x46
 [<ffffffff80269e6f>] show_trace+0x2bf/0x324
 [<ffffffff80269e7b>] show_trace+0x2cb/0x324
 [<ffffffff80260716>] call_softirq+0x1e/0x28
 [<ffffffff80269fdf>] _show_stack+0xef/0xfe
 [<ffffffff8026a07a>] show_registers+0x8c/0x101
 [<ffffffff8026a18f>] __die+0xa0/0xe3
 [<ffffffff8020af95>] do_page_fault+0x785/0x89d
 [<ffffffff8029a627>] mark_held_locks+0x5d/0x96
 [<ffffffff8029a7e7>] trace_hardirqs_on+0xec/0x12c
 [<ffffffff802601ed>] error_exit+0x0/0x96
 [<ffffffff80269e6f>] show_trace+0x2bf/0x324
 [<ffffffff80260716>] call_softirq+0x1e/0x28
 [<ffffffff80269ee9>] dump_stack+0x15/0x1c
 [<ffffffff8043d4e8>] skb_checksum_help+0x63/0x13b
 [<ffffffff8802f35f>] :iptable_nat:ip_nat_fn+0x5f/0x1d2
 [<ffffffff8802f71b>] :iptable_nat:ip_nat_local_fn+0x33/0xbc
 [<ffffffff80234c9e>] nf_iterate+0x5a/0x9b
 [<ffffffff804579a6>] dst_output+0x0/0x10
 [<ffffffff80258960>] nf_hook_slow+0x60/0xcd
 [<ffffffff804579a6>] dst_output+0x0/0x10
 [<ffffffff80265999>] _spin_unlock_irqrestore+0x3f/0x47
 [<ffffffff80235174>] ip_queue_xmit+0x444/0x4c0
 [<ffffffff8024bc5d>] tso_fragment+0x5d/0x20e
 [<ffffffff80210009>] __kmalloc_track_caller+0x109/0x11b
 [<ffffffff8022157f>] tcp_transmit_skb+0x68f/0x6cf
 [<ffffffff8024bda6>] tso_fragment+0x1a6/0x20e
 [<ffffffff80233b67>] __tcp_push_pending_frames+0x867/0x95a
 [<ffffffff80228ef8>] __kfree_skb+0xfc/0x101
 [<ffffffff80236fe1>] tcp_data_queue+0x651/0xc39
 [<ffffffff8021b9fc>] tcp_rcv_established+0x72c/0x7c4
 [<ffffffff8023c60e>] tcp_v4_do_rcv+0x2e/0x317
 [<ffffffff8022719c>] tcp_v4_rcv+0x9fc/0xa79
 [<ffffffff80258960>] nf_hook_slow+0x60/0xcd
 [<ffffffff804552b0>] ip_local_deliver_finish+0x0/0x1fb
 [<ffffffff80235389>] ip_local_deliver+0x199/0x270
 [<ffffffff802363c3>] ip_rcv+0x4d3/0x52b
 [<ffffffff80439ccc>] kfree_skb+0x2c/0x31
 [<ffffffff8021fdcb>] netif_receive_skb+0x1eb/0x27b
 [<ffffffff803c9491>] e1000_clean_rx_irq_ps+0x5c1/0x6a0
 [<ffffffff803c7b45>] e1000_clean+0x325/0x45b
 [<ffffffff8020c9b7>] net_rx_action+0x8e/0x147
 [<ffffffff8021164f>] __do_softirq+0x64/0x105
 [<ffffffff80211663>] __do_softirq+0x78/0x105
 [<ffffffff80260716>] call_softirq+0x1e/0x28
 [<ffffffff8026b679>] do_softirq+0x39/0xa4
 [<ffffffff802888b8>] irq_exit+0x58/0x5a
 [<ffffffff8026b798>] do_IRQ+0xb4/0xbe
 [<ffffffff8025f9a1>] ret_from_intr+0x0/0xf
 <EOI><1>Unable to handle kernel paging request at ffffffff82800000 RIP:
 [<ffffffff80269e6f>] show_trace+0x2bf/0x324
PGD 203027 PUD 205027 PMD 0
Oops: 0000 [4] SMP
last sysfs file: /class/net/sit0/address
CPU 0
Modules linked in: hidp rfcomm l2cap bluetooth ipv6 ip_gre iptable_filter iptable_nat ip_nat ip_conntrack nfnetlink iptable_mangle

ip_tables binfmt_misc iTCO_wdt i2c_i801 serio_raw
Pid: 2127, comm: imap Not tainted 2.6.18-rc2-mm1 #1

RIP: 0010:[<ffffffff80269e6f>]  [<ffffffff80269e6f>] show_trace+0x2bf/0x324
RSP: 0000:ffffffff80635c78  EFLAGS: 00010006
RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff880a3808
RDX: ffff81003d95c140 RSI: 0000000000000001 RDI: 0000000000000000
RBP: ffffffff80635d78 R08: 0000000000000000 R09: 0000000000000001
R10: ffffffff8029fae0 R11: 0000000000000000 R12: ffffffff827ffff9
R13: 0000000000000000 R14: 0000000000000000 R15: ffffffff80907000
FS:  00002ab5ab544860(0000) GS:ffffffff808b2000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: ffffffff82800000 CR3: 0000000029dea000 CR4: 00000000000006e0
Process imap (pid: 2127, threadinfo ffff810029e62000, task ffff81003d95c140)
Stack:  000000000000000b ffffffff80636fc0 0000000080632fc0 0000000000000000
 ffffffff80907000 0000000000000000 0000000000000000 ffffffff827ffff9
 000000008025fa27 0000000000000001 0000000000000000 ffffffff8029fae0
Call Trace:
 [<ffffffff80269fdf>] _show_stack+0xef/0xfe
 [<ffffffff8026a07a>] show_registers+0x8c/0x101
 [<ffffffff8026a18f>] __die+0xa0/0xe3
 [<ffffffff8020af95>] do_page_fault+0x785/0x89d
 [<ffffffff802601ed>] error_exit+0x0/0x96
DWARF2 unwinder stuck at error_exit+0x0/0x96
Leftover inexact backtrace:
 <IRQ> [<ffffffff8029fae0>] module_text_address+0x16/0x46
 [<ffffffff80269e6f>] show_trace+0x2bf/0x324
 [<ffffffff80269e7b>] show_trace+0x2cb/0x324
 [<ffffffff8029fae0>] module_text_address+0x16/0x46
 [<ffffffff802601ed>] error_exit+0x0/0x96
 [<ffffffff80269fdf>] _show_stack+0xef/0xfe
 [<ffffffff8026a07a>] show_registers+0x8c/0x101
 [<ffffffff8026a18f>] __die+0xa0/0xe3
 [<ffffffff8020af95>] do_page_fault+0x785/0x89d
 [<ffffffff80285f9f>] vprintk+0x30f/0x35d
 [<ffffffff802a2f8a>] kallsyms_lookup+0xea/0x1b5
 [<ffffffff80260716>] call_softirq+0x1e/0x28
 [<ffffffff8025f9a1>] ret_from_intr+0x0/0xf
 [<ffffffff8025f9a1>] ret_from_intr+0x0/0xf
 [<ffffffff802601ed>] error_exit+0x0/0x96
 [<ffffffff8029fae0>] module_text_address+0x16/0x46
 [<ffffffff80269e6f>] show_trace+0x2bf/0x324
 [<ffffffff80269e7b>] show_trace+0x2cb/0x324
 [<ffffffff80260716>] call_softirq+0x1e/0x28
 [<ffffffff80269fdf>] _show_stack+0xef/0xfe
 [<ffffffff8026a07a>] show_registers+0x8c/0x101
 [<ffffffff8026a18f>] __die+0xa0/0xe3
 [<ffffffff8020af95>] do_page_fault+0x785/0x89d
 [<ffffffff8029a627>] mark_held_locks+0x5d/0x96
 [<ffffffff8029a7e7>] trace_hardirqs_on+0xec/0x12c
 [<ffffffff802601ed>] error_exit+0x0/0x96
 [<ffffffff80269e6f>] show_trace+0x2bf/0x324
 [<ffffffff80260716>] call_softirq+0x1e/0x28
 [<ffffffff80269ee9>] dump_stack+0x15/0x1c
 [<ffffffff8043d4e8>] skb_checksum_help+0x63/0x13b
 [<ffffffff8802f35f>] :iptable_nat:ip_nat_fn+0x5f/0x1d2
 [<ffffffff8802f71b>] :iptable_nat:ip_nat_local_fn+0x33/0xbc
 [<ffffffff80234c9e>] nf_iterate+0x5a/0x9b
 [<ffffffff804579a6>] dst_output+0x0/0x10
 [<ffffffff80258960>] nf_hook_slow+0x60/0xcd
 [<ffffffff804579a6>] dst_output+0x0/0x10
 [<ffffffff80265999>] _spin_unlock_irqrestore+0x3f/0x47
 [<ffffffff80235174>] ip_queue_xmit+0x444/0x4c0
 [<ffffffff8024bc5d>] tso_fragment+0x5d/0x20e
 [<ffffffff80210009>] __kmalloc_track_caller+0x109/0x11b
 [<ffffffff8022157f>] tcp_transmit_skb+0x68f/0x6cf
 [<ffffffff8024bda6>] tso_fragment+0x1a6/0x20e
 [<ffffffff80233b67>] __tcp_push_pending_frames+0x867/0x95a
 [<ffffffff80228ef8>] __kfree_skb+0xfc/0x101
 [<ffffffff80236fe1>] tcp_data_queue+0x651/0xc39
 [<ffffffff8021b9fc>] tcp_rcv_established+0x72c/0x7c4
 [<ffffffff8023c60e>] tcp_v4_do_rcv+0x2e/0x317
 [<ffffffff8022719c>] tcp_v4_rcv+0x9fc/0xa79
 [<ffffffff80258960>] nf_hook_slow+0x60/0xcd
 [<ffffffff804552b0>] ip_local_deliver_finish+0x0/0x1fb
 [<ffffffff80235389>] ip_local_deliver+0x199/0x270
 [<ffffffff802363c3>] ip_rcv+0x4d3/0x52b
 [<ffffffff80439ccc>] kfree_skb+0x2c/0x31
 [<ffffffff8021fdcb>] netif_receive_skb+0x1eb/0x27b
 [<ffffffff803c9491>] e1000_clean_rx_irq_ps+0x5c1/0x6a0
 [<ffffffff803c7b45>] e1000_clean+0x325/0x45b
 [<ffffffff8020c9b7>] net_rx_action+0x8e/0x147
 [<ffffffff8021164f>] __do_softirq+0x64/0x105
 [<ffffffff80211663>] __do_softirq+0x78/0x105
 [<ffffffff80260716>] call_softirq+0x1e/0x28
 [<ffffffff8026b679>] do_softirq+0x39/0xa4
 [<ffffffff802888b8>] irq_exit+0x58/0x5a
 [<ffffffff8026b798>] do_IRQ+0xb4/0xbe
 [<ffffffff8025f9a1>] ret_from_intr+0x0/0xf
 <EOI><1>Unable to handle kernel paging request at ffffffff82800000 RIP:
 [<ffffffff80269e6f>] show_trace+0x2bf/0x324
PGD 203027 PUD 205027 PMD 0
Oops: 0000 [5] SMP
last sysfs file: /class/net/sit0/address
CPU 0
Modules linked in: hidp rfcomm l2cap bluetooth ipv6 ip_gre iptable_filter iptable_nat ip_nat ip_conntrack nfnetlink iptable_mangle

ip_tables binfmt_misc iTCO_wdt i2c_i801 serio_raw
Pid: 2127, comm: imap Not tainted 2.6.18-rc2-mm1 #1

RIP: 0010:[<ffffffff80269e6f>]  [<ffffffff80269e6f>] show_trace+0x2bf/0x324
RSP: 0000:ffffffff806358f8  EFLAGS: 00010006
RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff880a3808
RDX: ffff81003d95c140 RSI: 0000000000000001 RDI: 0000000000000000
RBP: ffffffff806359f8 R08: 0000000000000000 R09: 0000000000000001
R10: ffffffff8029fae0 R11: 0000000000000000 R12: ffffffff827ffff9
R13: 0000000000000000 R14: 0000000000000000 R15: ffffffff80907000
FS:  00002ab5ab544860(0000) GS:ffffffff808b2000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: ffffffff82800000 CR3: 0000000029dea000 CR4: 00000000000006e0
Process imap (pid: 2127, threadinfo ffff810029e62000, task ffff81003d95c140)
Stack:  000000000000000b ffffffff80636fc0 0000000080632fc0 0000000000000000
 ffffffff80907000 0000000000000000 0000000000000000 ffffffff827ffff9
 000000008025fa27 0000000000000001 0000000000000000 ffffffff8029fae0
Call Trace:
 [<ffffffff80269fdf>] _show_stack+0xef/0xfe
 [<ffffffff8026a07a>] show_registers+0x8c/0x101
 [<ffffffff8026a18f>] __die+0xa0/0xe3
 [<ffffffff8020af95>] do_page_fault+0x785/0x89d
 [<ffffffff802601ed>] error_exit+0x0/0x96
DWARF2 unwinder stuck at error_exit+0x0/0x96
Leftover inexact backtrace:
 <IRQ> [<ffffffff8029fae0>] module_text_address+0x16/0x46
 [<ffffffff80269e6f>] show_trace+0x2bf/0x324
 [<ffffffff80269e7b>] show_trace+0x2cb/0x324
 [<ffffffff8029fae0>] module_text_address+0x16/0x46
 [<ffffffff802601ed>] error_exit+0x0/0x96
 [<ffffffff80269fdf>] _show_stack+0xef/0xfe
 [<ffffffff8026a07a>] show_registers+0x8c/0x101
 [<ffffffff8026a18f>] __die+0xa0/0xe3
 [<ffffffff8020af95>] do_page_fault+0x785/0x89d
 [<ffffffff80285f9f>] vprintk+0x30f/0x35d
 [<ffffffff8802f71b>] :iptable_nat:ip_nat_local_fn+0x33/0xbc
 [<ffffffff8025f9a1>] ret_from_intr+0x0/0xf
 [<ffffffff8025f9a1>] ret_from_intr+0x0/0xf
 [<ffffffff802601ed>] error_exit+0x0/0x96
 [<ffffffff8029fae0>] module_text_address+0x16/0x46
 [<ffffffff80269e6f>] show_trace+0x2bf/0x324
 [<ffffffff80269e7b>] show_trace+0x2cb/0x324
 [<ffffffff8029fae0>] module_text_address+0x16/0x46
 [<ffffffff802601ed>] error_exit+0x0/0x96
 [<ffffffff80269fdf>] _show_stack+0xef/0xfe
 [<ffffffff8026a07a>] show_registers+0x8c/0x101
 [<ffffffff8026a18f>] __die+0xa0/0xe3
 [<ffffffff8020af95>] do_page_fault+0x785/0x89d
 [<ffffffff80285f9f>] vprintk+0x30f/0x35d
 [<ffffffff802a2f8a>] kallsyms_lookup+0xea/0x1b5
 [<ffffffff80260716>] call_softirq+0x1e/0x28
 [<ffffffff8025f9a1>] ret_from_intr+0x0/0xf
 [<ffffffff8025f9a1>] ret_from_intr+0x0/0xf
 [<ffffffff802601ed>] error_exit+0x0/0x96
 [<ffffffff8029fae0>] module_text_address+0x16/0x46
 [<ffffffff80269e6f>] show_trace+0x2bf/0x324
 [<ffffffff80269e7b>] show_trace+0x2cb/0x324
 [<ffffffff80260716>] call_softirq+0x1e/0x28
 [<ffffffff80269fdf>] _show_stack+0xef/0xfe
 [<ffffffff8026a07a>] show_registers+0x8c/0x101
 [<ffffffff8026a18f>] __die+0xa0/0xe3
 [<ffffffff8020af95>] do_page_fault+0x785/0x89d
 [<ffffffff8029a627>] mark_held_locks+0x5d/0x96
 [<ffffffff8029a7e7>] trace_hardirqs_on+0xec/0x12c
 [<ffffffff802601ed>] error_exit+0x0/0x96
 [<ffffffff80269e6f>] show_trace+0x2bf/0x324
 [<ffffffff80260716>] call_softirq+0x1e/0x28
 [<ffffffff80269ee9>] dump_stack+0x15/0x1c
 [<ffffffff8043d4e8>] skb_checksum_help+0x63/0x13b
 [<ffffffff8802f35f>] :iptable_nat:ip_nat_fn+0x5f/0x1d2
 [<ffffffff8802f71b>] :iptable_nat:ip_nat_local_fn+0x33/0xbc
 [<ffffffff80234c9e>] nf_iterate+0x5a/0x9b
 [<ffffffff804579a6>] dst_output+0x0/0x10
 [<ffffffff80258960>] nf_hook_slow+0x60/0xcd
 [<ffffffff804579a6>] dst_output+0x0/0x10
 [<ffffffff80265999>] _spin_unlock_irqrestore+0x3f/0x47
 [<ffffffff80235174>] ip_queue_xmit+0x444/0x4c0
 [<ffffffff8024bc5d>] tso_fragment+0x5d/0x20e
 [<ffffffff80210009>] __kmalloc_track_caller+0x109/0x11b
 [<ffffffff8022157f>] tcp_transmit_skb+0x68f/0x6cf
 [<ffffffff8024bda6>] tso_fragment+0x1a6/0x20e
 [<ffffffff80233b67>] __tcp_push_pending_frames+0x867/0x95a
 [<ffffffff80228ef8>] __kfree_skb+0xfc/0x101
 [<ffffffff80236fe1>] tcp_data_queue+0x651/0xc39
 [<ffffffff8021b9fc>] tcp_rcv_established+0x72c/0x7c4
 [<ffffffff8023c60e>] tcp_v4_do_rcv+0x2e/0x317
 [<ffffffff8022719c>] tcp_v4_rcv+0x9fc/0xa79
 [<ffffffff80258960>] nf_hook_slow+0x60/0xcd
 [<ffffffff804552b0>] ip_local_deliver_finish+0x0/0x1fb
 [<ffffffff80235389>] ip_local_deliver+0x199/0x270
 [<ffffffff802363c3>] ip_rcv+0x4d3/0x52b
 [<ffffffff80439ccc>] kfree_skb+0x2c/0x31
 [<ffffffff8021fdcb>] netif_receive_skb+0x1eb/0x27b
 [<ffffffff803c9491>] e1000_clean_rx_irq_ps+0x5c1/0x6a0
 [<ffffffff803c7b45>] e1000_clean+0x325/0x45b
 [<ffffffff8020c9b7>] net_rx_action+0x8e/0x147
 [<ffffffff8021164f>] __do_softirq+0x64/0x105
 [<ffffffff80211663>] __do_softirq+0x78/0x105
 [<ffffffff80260716>] call_softirq+0x1e/0x28
 [<ffffffff8026b679>] do_softirq+0x39/0xa4
 [<ffffffff802888b8>] irq_exit+0x58/0x5a
 [<ffffffff8026b798>] do_IRQ+0xb4/0xbe
 [<ffffffff8025f9a1>] ret_from_intr+0x0/0xf
 <EOI><1>Unable to handle kernel paging request at ffffffff82800000 RIP:
 [<ffffffff80269e6f>] show_trace+0x2bf/0x324
PGD 203027 PUD 205027 PMD 0
Oops: 0000 [6] SMP
last sysfs file: /class/net/sit0/address
CPU 0
Modules linked in: hidp rfcomm l2cap bluetooth ipv6 ip_gre iptable_filter iptable_nat ip_nat ip_conntrack nfnetlink iptable_mangle

ip_tables binfmt_misc iTCO_wdt i2c_i801 serio_raw
Pid: 2127, comm: imap Not tainted 2.6.18-rc2-mm1 #1

RIP: 0010:[<ffffffff80269e6f>]  [<ffffffff80269e6f>] show_trace+0x2bf/0x324
RSP: 0000:ffffffff80635578  EFLAGS: 00010006
RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff880a3808
RDX: ffff81003d95c140 RSI: 0000000000000001 RDI: 0000000000000000
RBP: ffffffff80635678 R08: 0000000000000000 R09: 0000000000000001
R10: ffffffff8029fae0 R11: 0000000000000000 R12: ffffffff827ffff9
R13: 0000000000000000 R14: 0000000000000000 R15: ffffffff80907000
FS:  00002ab5ab544860(0000) GS:ffffffff808b2000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: ffffffff82800000 CR3: 0000000029dea000 CR4: 00000000000006e0
Process imap (pid: 2127, threadinfo ffff810029e62000, task ffff81003d95c140)
Stack:  000000000000000b ffffffff80636fc0 0000000080632fc0 0000000000000000
 ffffffff80907000 0000000000000000 0000000000000000 ffffffff827ffff9
 000000008025fa27 0000000000000001 0000000000000000 ffffffff8029fae0
Call Trace:
 [<ffffffff80269fdf>] _show_stack+0xef/0xfe
 [<ffffffff8026a07a>] show_registers+0x8c/0x101
 [<ffffffff8026a18f>] __die+0xa0/0xe3
 [<ffffffff8020af95>] do_page_fault+0x785/0x89d
 [<ffffffff802601ed>] error_exit+0x0/0x96
DWARF2 unwinder stuck at error_exit+0x0/0x96
Leftover inexact backtrace:
 <IRQ> [<ffffffff8029fae0>] module_text_address+0x16/0x46
 [<ffffffff80269e6f>] show_trace+0x2bf/0x324
 [<ffffffff80269e7b>] show_trace+0x2cb/0x324
 [<ffffffff8029fae0>] module_text_address+0x16/0x46
 [<ffffffff802601ed>] error_exit+0x0/0x96
 [<ffffffff80269fdf>] _show_stack+0xef/0xfe
 [<ffffffff8026a07a>] show_registers+0x8c/0x101
 [<ffffffff8026a18f>] __die+0xa0/0xe3
 [<ffffffff8020af95>] do_page_fault+0x785/0x89d
 [<ffffffff80285f9f>] vprintk+0x30f/0x35d
 [<ffffffff8802f71b>] :iptable_nat:ip_nat_local_fn+0x33/0xbc
 [<ffffffff8025f9a1>] ret_from_intr+0x0/0xf
 [<ffffffff8025f9a1>] ret_from_intr+0x0/0xf
 [<ffffffff802601ed>] error_exit+0x0/0x96
 [<ffffffff8029fae0>] module_text_address+0x16/0x46
 [<ffffffff80269e6f>] show_trace+0x2bf/0x324
 [<ffffffff80269e7b>] show_trace+0x2cb/0x324
 [<ffffffff8029fae0>] module_text_address+0x16/0x46
 [<ffffffff802601ed>] error_exit+0x0/0x96
 [<ffffffff80269fdf>] _show_stack+0xef/0xfe
 [<ffffffff8026a07a>] show_registers+0x8c/0x101
 [<ffffffff8026a18f>] __die+0xa0/0xe3
 [<ffffffff8020af95>] do_page_fault+0x785/0x89d
 [<ffffffff80285f9f>] vprintk+0x30f/0x35d
 [<ffffffff8802f71b>] :iptable_nat:ip_nat_local_fn+0x33/0xbc
 [<ffffffff8025f9a1>] ret_from_intr+0x0/0xf
 [<ffffffff8025f9a1>] ret_from_intr+0x0/0xf
 [<ffffffff802601ed>] error_exit+0x0/0x96
 [<ffffffff8029fae0>] module_text_address+0x16/0x46
 [<ffffffff80269e6f>] show_trace+0x2bf/0x324
 [<ffffffff80269e7b>] show_trace+0x2cb/0x324
 [<ffffffff8029fae0>] module_text_address+0x16/0x46
 [<ffffffff802601ed>] error_exit+0x0/0x96
 [<ffffffff80269fdf>] _show_stack+0xef/0xfe
 [<ffffffff8026a07a>] show_registers+0x8c/0x101
 [<ffffffff8026a18f>] __die+0xa0/0xe3
 [<ffffffff8020af95>] do_page_fault+0x785/0x89d
 [<ffffffff80285f9f>] vprintk+0x30f/0x35d
 [<ffffffff802a2f8a>] kallsyms_lookup+0xea/0x1b5
 [<ffffffff80260716>] call_softirq+0x1e/0x28
 [<ffffffff8025f9a1>] ret_from_intr+0x0/0xf
 [<ffffffff8025f9a1>] ret_from_intr+0x0/0xf
 [<ffffffff802601ed>] error_exit+0x0/0x96
 [<ffffffff8029fae0>] module_text_address+0x16/0x46
 [<ffffffff80269e6f>] show_trace+0x2bf/0x324
 [<ffffffff80269e7b>] show_trace+0x2cb/0x324
 [<ffffffff80260716>] call_softirq+0x1e/0x28
 [<ffffffff80269fdf>] _show_stack+0xef/0xfe
 [<ffffffff8026a07a>] show_registers+0x8c/0x101
 [<ffffffff8026a18f>] __die+0xa0/0xe3
 [<ffffffff8020af95>] do_page_fault+0x785/0x89d
 [<ffffffff8029a627>] mark_held_locks+0x5d/0x96
 [<ffffffff8029a7e7>] trace_hardirqs_on+0xec/0x12c
 [<ffffffff802601ed>] error_exit+0x0/0x96
 [<ffffffff80269e6f>] show_trace+0x2bf/0x324
 [<ffffffff80260716>] call_softirq+0x1e/0x28
 [<ffffffff80269ee9>] dump_stack+0x15/0x1c
 [<ffffffff8043d4e8>] skb_checksum_help+0x63/0x13b
 [<ffffffff8802f35f>] :iptable_nat:ip_nat_fn+0x5f/0x1d2
 [<ffffffff8802f71b>] :iptable_nat:ip_nat_local_fn+0x33/0xbc
 [<ffffffff80234c9e>] nf_iterate+0x5a/0x9b
 [<ffffffff804579a6>] dst_output+0x0/0x10
 [<ffffffff80258960>] nf_hook_slow+0x60/0xcd
 [<ffffffff804579a6>] dst_output+0x0/0x10
 [<ffffffff80265999>] _spin_unlock_irqrestore+0x3f/0x47
 [<ffffffff80235174>] ip_queue_xmit+0x444/0x4c0
 [<ffffffff8024bc5d>] tso_fragment+0x5d/0x20e
 [<ffffffff80210009>] __kmalloc_track_caller+0x109/0x11b
 [<ffffffff8022157f>] tcp_transmit_skb+0x68f/0x6cf
 [<ffffffff8024bda6>] tso_fragment+0x1a6/0x20e
 [<ffffffff80233b67>] __tcp_push_pending_frames+0x867/0x95a
 [<ffffffff80228ef8>] __kfree_skb+0xfc/0x101
 [<ffffffff80236fe1>] tcp_data_queue+0x651/0xc39
 [<ffffffff8021b9fc>] tcp_rcv_established+0x72c/0x7c4
 [<ffffffff8023c60e>] tcp_v4_do_rcv+0x2e/0x317
 [<ffffffff8022719c>] tcp_v4_rcv+0x9fc/0xa79
 [<ffffffff80258960>] nf_hook_slow+0x60/0xcd
 [<ffffffff804552b0>] ip_local_deliver_finish+0x0/0x1fb
 [<ffffffff80235389>] ip_local_deliver+0x199/0x270
 [<ffffffff802363c3>] ip_rcv+0x4d3/0x52b
 [<ffffffff80439ccc>] kfree_skb+0x2c/0x31
 [<ffffffff8021fdcb>] netif_receive_skb+0x1eb/0x27b
 [<ffffffff803c9491>] e1000_clean_rx_irq_ps+0x5c1/0x6a0
 [<ffffffff803c7b45>] e1000_clean+0x325/0x45b
 [<ffffffff8020c9b7>] net_rx_action+0x8e/0x147
 [<ffffffff8021164f>] __do_softirq+0x64/0x105
 [<ffffffff80211663>] __do_softirq+0x78/0x105
 [<ffffffff80260716>] call_softirq+0x1e/0x28
 [<ffffffff8026b679>] do_softirq+0x39/0xa4
 [<ffffffff802888b8>] irq_exit+0x58/0x5a
 [<ffffffff8026b798>] do_IRQ+0xb4/0xbe
 [<ffffffff8025f9a1>] ret_from_intr+0x0/0xf
 <EOI>

Thanks,
Reuben

Hi,

I think that the bluetooth-guard-bt_proto-with-rwlock.patch introduced the following BUG:

[   43.232000] BUG: sleeping function called from invalid context at mm/slab.c:2903
[   43.232000] in_atomic():1, irqs_disabled():0
[   43.232000]  [<c0104114>] show_trace_log_lvl+0x197/0x1ba
[   43.232000]  [<c010415e>] show_trace+0x27/0x29
[   43.232000]  [<c010426e>] dump_stack+0x26/0x28
[   43.232000]  [<c011ad1c>] __might_sleep+0xa2/0xaa
[   43.232000]  [<c0173085>] __kmalloc+0x9c/0xb3
[   43.232000]  [<c02f9295>] sk_alloc+0x1bc/0x1de
[   43.232000]  [<c036d689>] hci_sock_create+0x42/0x8a
[   43.236000]  [<c0366f40>] bt_sock_create+0xb5/0x154
[   43.236000]  [<c02f69dc>] __sock_create+0x131/0x356
[   43.236000]  [<c02f6c2f>] sock_create+0x2e/0x30
[   43.236000]  [<c02f6c88>] sys_socket+0x27/0x53
[   43.240000]  [<c02f7db5>] sys_socketcall+0xa9/0x277
[   43.240000]  [<c0103131>] sysenter_past_esp+0x56/0x8d
[   43.240000]  [<b7f38410>] 0xb7f38410

This patch makes sk_alloc GFP_ATOMIC, because we are holding the bt_proto_rwlock, for the following functions:
- bnep_sock_create
- cmtp_sock_create
- hci_sock_create
- hidp_sock_create
- l2cap_sock_create
- rfcomm_sock_create
- sco_sock_create

Regards,
Frederik

diff -x'*.o' -pruN v2.6.18-rc2-mm1~ori/net/bluetooth/bnep/sock.c v2.6.18-rc2-mm1/net/bluetooth/bnep/sock.c
@@ -181,7 +181,7 @@ static int bnep_sock_create(struct socke
 	if (sock->type != SOCK_RAW)
 		return -ESOCKTNOSUPPORT;
 
-	sk = sk_alloc(PF_BLUETOOTH, GFP_KERNEL, &bnep_proto, 1);
+	sk = sk_alloc(PF_BLUETOOTH, GFP_ATOMIC, &bnep_proto, 1);
 	if (!sk)
 		return -ENOMEM;
 

diff -x'*.o' -pruN v2.6.18-rc2-mm1~ori/net/bluetooth/cmtp/sock.c v2.6.18-rc2-mm1/net/bluetooth/cmtp/sock.c
@@ -172,7 +172,7 @@ static int cmtp_sock_create(struct socke
 	if (sock->type != SOCK_RAW)
 		return -ESOCKTNOSUPPORT;
 
-	sk = sk_alloc(PF_BLUETOOTH, GFP_KERNEL, &cmtp_proto, 1);
+	sk = sk_alloc(PF_BLUETOOTH, GFP_ATOMIC, &cmtp_proto, 1);
 	if (!sk)
 		return -ENOMEM;
 

diff -x'*.o' -pruN v2.6.18-rc2-mm1~ori/net/bluetooth/hci_sock.c v2.6.18-rc2-mm1/net/bluetooth/hci_sock.c
@@ -618,7 +618,7 @@ static int hci_sock_create(struct socket
 
 	sock->ops = &hci_sock_ops;
 
-	sk = sk_alloc(PF_BLUETOOTH, GFP_KERNEL, &hci_sk_proto, 1);
+	sk = sk_alloc(PF_BLUETOOTH, GFP_ATOMIC, &hci_sk_proto, 1);
 	if (!sk)
 		return -ENOMEM;
 

diff -x'*.o' -pruN v2.6.18-rc2-mm1~ori/net/bluetooth/hidp/sock.c v2.6.18-rc2-mm1/net/bluetooth/hidp/sock.c
@@ -178,7 +178,7 @@ static int hidp_sock_create(struct socke
 	if (sock->type != SOCK_RAW)
 		return -ESOCKTNOSUPPORT;
 
-	sk = sk_alloc(PF_BLUETOOTH, GFP_KERNEL, &hidp_proto, 1);
+	sk = sk_alloc(PF_BLUETOOTH, GFP_ATOMIC, &hidp_proto, 1);
 	if (!sk)
 		return -ENOMEM;
 

diff -x'*.o' -pruN v2.6.18-rc2-mm1~ori/net/bluetooth/l2cap.c v2.6.18-rc2-mm1/net/bluetooth/l2cap.c
@@ -559,7 +559,7 @@ static int l2cap_sock_create(struct sock
 
 	sock->ops = &l2cap_sock_ops;
 
-	sk = l2cap_sock_alloc(sock, protocol, GFP_KERNEL);
+	sk = l2cap_sock_alloc(sock, protocol, GFP_ATOMIC);
 	if (!sk)
 		return -ENOMEM;
 

diff -x'*.o' -pruN v2.6.18-rc2-mm1~ori/net/bluetooth/rfcomm/sock.c v2.6.18-rc2-mm1/net/bluetooth/rfcomm/sock.c
@@ -336,7 +336,7 @@ static int rfcomm_sock_create(struct soc
 
 	sock->ops = &rfcomm_sock_ops;
 
-	if (!(sk = rfcomm_sock_alloc(sock, protocol, GFP_KERNEL)))
+	if (!(sk = rfcomm_sock_alloc(sock, protocol, GFP_ATOMIC)))
 		return -ENOMEM;
 
 	rfcomm_sock_init(sk, NULL);

diff -x'*.o' -pruN v2.6.18-rc2-mm1~ori/net/bluetooth/sco.c v2.6.18-rc2-mm1/net/bluetooth/sco.c
@@ -452,7 +452,7 @@ static int sco_sock_create(struct socket
 
 	sock->ops = &sco_sock_ops;
 
-	if (!(sk = sco_sock_alloc(sock, protocol, GFP_KERNEL)))
+	if (!(sk = sco_sock_alloc(sock, protocol, GFP_ATOMIC)))
 		return -ENOMEM;
 
 	sco_sock_init(sk, NULL);

Hi Frederik,

the comment from Max Krasnyansky (the original author) I got was this:

As far as I remember there was some upper level locking that ensured that protected registration stuff. But it's been awhile so I may be completely wrong.

And Masatake YAMATO mentioned:

It seems that lock_kernel/unlock_kernel was used in sys_init_module. However, now it is gone.

I haven't looked at the new module loading code to verify if we really need to protect our socket registration or not.

Regards

Marcel

I'm really not an expert here, but from what I read, the only obvious locking done in sys_init_module is involves 'module_mutex'. And that mutex is released at the time 'mod->init()' is called.

Regards,
Frederik

There is very similar code in i net/socket.c(I guess some part of bluetooth/af_bluetooth.c is derived from net/socket.c):

    static int __sock_create(int family, int type, int protocol, struct socket **res, int kern)
    {
	    ...
	    net_family_read_lock();
	    ...
	    if ((err = net_families[family]->create(sock, protocol)) < 0) {
		    sock->ops = NULL;
		    goto out_module_put;
	    }
	    ...	
	    net_family_read_unlock();
	    return err;
    }

I can find GFP_KERNEL is used to allocate object in net_families[family]->create(sock, protocol). e.g.:

    net/ipv4/af_inet.c:
    static int inet_create(struct socket *sock, int protocol)
    {
    ...
	    sk = sk_alloc(PF_INET, GFP_KERNEL, answer_prot, 1);
    ...
    }

Tricks are in net_family_read_lock and net_family_read_unlock:

    net/socket.c:
    static __inline__ void net_family_read_lock(void)
    {
	    atomic_inc(&net_family_lockct);
	    spin_unlock_wait(&net_family_lock);
    }

    static __inline__ void net_family_read_unlock(void)
    {
	    atomic_dec(&net_family_lockct);
    }

So there are two ways to avoid the bug:
1. As proposed by Frederik, use sk_alloc with GFP_ATOMIC or
2. use net_family_{read|writ}_{lock|unlock} in af_bluetooth.c.

I wonder which is better.

Masatake YAMATO

[... skip net/socket.c code ...]

I'd say that using a net_family_* like function set is much better, if only in terms of preemptibility.

I'll write an implementation that allows to use the same code in socket.c and in af_bluetooth.c

Regards,
Frederik

Hi,

I found one more similar code set at net/dccp/ccid.c for the same purpose:

    /*
     * The strategy is: modifications ccids vector are short, do not sleep and
     * veeery rare, but read access should be free of any exclusive locks.
     */
    static void ccids_write_lock(void)
    {
	    spin_lock(&ccids_lock);
	    while (atomic_read(&ccids_lockct) != 0) {
		    spin_unlock(&ccids_lock);
		    yield();
		    spin_lock(&ccids_lock);
	    }
    }

    static inline void ccids_write_unlock(void)
    {
	    spin_unlock(&ccids_lock);
    }

    static inline void ccids_read_lock(void)
    {
	    atomic_inc(&ccids_lockct);
	    spin_unlock_wait(&ccids_lock);
    }

    static inline void ccids_read_unlock(void)
    {
	    atomic_dec(&ccids_lockct);
    }

I'm new to the kernel, however, I think it is better to unify them into one and to give a good name.

Masatake YAMATO

OK, thanks, I modified it too.

The following set of patches adds a struct lw_rwlock (for lightweight rwlock) which contains a spin_lock_t and an atomic_t. It is defined in include/linux/lw_rwlock.h.

This lw_rwlock aims at protecting structures that are modified very rarely and quickly. This assumptions allow the reader to merely increment the atomic_t, allowing it to sleep why the lw_rwlock is help.

There were already two users of this kind of API: net/socket.c to protect 'net_families' and net/dccp/ccid.c to protect 'ccids'. As suggested by Masatake YAMATO, this looked like good way to protect 'bt_proto' in net/bluetooth/af_bluetooth.c as well. This patchset aims at having only one implementation in the kernel.

 include/linux/lw_rwlock.h    |   71 +++++++++++++++++++++++++++++++++++++++++++
 net/bluetooth/af_bluetooth.c |   15 ++++-----
 net/dccp/ccid.c              |   63 +++++++-------------------------------
 net/socket.c                 |   58 ++++-------------------------------
 4 files changed, 100 insertions(+), 107 deletions(-)

@@ -0,0 +1,71 @@
+#ifndef __LINUX_LW_RWLOCK_H
+#define __LINUX_LW_RWLOCK_H
+
+/*
+ * LightWeight readwriter lock.
+ * The strategy is: modifications while the lock is held are short, do not
+ * sleep and veeery rare, but read access should be free of any exclusive
+ * locks.
+ * The original implementation was written for net/socket.c
+ */
+
+#include <linux/spinlock.h>
+
+
+struct lw_rwlock {
+	/* tracks down the number of current readers */
+	atomic_t readers;
+	/* the actual lock, only held by writers */
+	spinlock_t lock;
+};
+
+#define __LW_RWLOCK_UNLOCKED(lockname) \
+		 { { 0 }, __SPIN_LOCK_UNLOCKED(lockname) }
+
+#define lw_rwlock_init(x) \
+		do { *(x) = (lw_rwlock_t) __LW_RWLOCK_UNLOCKED(x); } while (0)
+
+#define DEFINE_LW_RWLOCK(x) \
+		struct lw_rwlock x = __LW_RWLOCK_UNLOCKED(x)
+
+#if defined(CONFIG_SMP) || defined(CONFIG_PREEMPT)
+
+static inline void lw_write_lock(struct lw_rwlock *l)
+{
+	spin_lock(&l->lock);
+	while (atomic_read(&l->readers) != 0) {
+		spin_unlock(&l->lock);
+
+		yield();
+
+		spin_lock(&l->lock);
+	}
+}	
+
+static inline void lw_write_unlock(struct lw_rwlock *l) 
+{
+	spin_unlock(&l->lock);
+}
+
+static inline void lw_read_lock(struct lw_rwlock *l)
+{
+	atomic_inc(&l->readers);
+	spin_unlock_wait(&l->lock);
+}
+
+static inline void lw_read_unlock(struct lw_rwlock *l)
+{
+	atomic_dec(&l->readers);
+}
+
+#else
+
+#define lw_write_lock(x) do { } while(0)
+#define lw_write_unlock(x) do { } while(0)
+#define lw_read_lock(x) do { } while(0)
+#define lw_read_unlock() do { } while(0)
+
+#endif /* CONFIG_SMP || CONFIG_PREEMPT */
+
+
+#endif /* __LINUX_LW_RWLOCK_H */

This patch is part of the lw_rwlock patchset, it removes the net_family_{read,write}_{lock,unlock} functions which have been moved to linux/lw_rwlock.h and made more generic.

@@ -85,6 +85,7 @@
 #include <linux/kmod.h>
 #include <linux/audit.h>
 #include <linux/wireless.h>
+#include <linux/lw_rwlock.h>
 
 #include <asm/uaccess.h>
 #include <asm/unistd.h>

@@ -143,50 +144,7 @@ static struct file_operations socket_fil
 
 static struct net_proto_family *net_families[NPROTO];
 
-#if defined(CONFIG_SMP) || defined(CONFIG_PREEMPT)
-static atomic_t net_family_lockct = ATOMIC_INIT(0);
-static DEFINE_SPINLOCK(net_family_lock);
-
-/* The strategy is: modifications net_family vector are short, do not
-   sleep and veeery rare, but read access should be free of any exclusive
-   locks.
- */
-
-static void net_family_write_lock(void)
-{
-	spin_lock(&net_family_lock);
-	while (atomic_read(&net_family_lockct) != 0) {
-		spin_unlock(&net_family_lock);
-
-		yield();
-
-		spin_lock(&net_family_lock);
-	}
-}
-
-static __inline__ void net_family_write_unlock(void)
-{
-	spin_unlock(&net_family_lock);
-}
-
-static __inline__ void net_family_read_lock(void)
-{
-	atomic_inc(&net_family_lockct);
-	spin_unlock_wait(&net_family_lock);
-}
-
-static __inline__ void net_family_read_unlock(void)
-{
-	atomic_dec(&net_family_lockct);
-}
-
-#else
-#define net_family_write_lock() do { } while(0)
-#define net_family_write_unlock() do { } while(0)
-#define net_family_read_lock() do { } while(0)
-#define net_family_read_unlock() do { } while(0)
-#endif
-
+static DEFINE_LW_RWLOCK(net_family_lock);
 
 /*
  *	Statistics counters of the socket lists

@@ -1125,7 +1083,7 @@ static int __sock_create(int family, int
 	}
 #endif
 
-	net_family_read_lock();
+	lw_read_lock(&net_family_lock);
 	if (net_families[family] == NULL) {
 		err = -EAFNOSUPPORT;
 		goto out;

@@ -1176,7 +1134,7 @@ static int __sock_create(int family, int
 	security_socket_post_create(sock, family, type, protocol, kern);
 
 out:
-	net_family_read_unlock();
+	lw_read_unlock(&net_family_lock);
 	return err;
 out_module_put:
 	module_put(net_families[family]->owner);

@@ -2025,13 +1983,13 @@ int sock_register(struct net_proto_famil
 		printk(KERN_CRIT "protocol %d >= NPROTO(%d)\n", ops->family, NPROTO);
 		return -ENOBUFS;
 	}
-	net_family_write_lock();
+	lw_write_lock(&net_family_lock);
 	err = -EEXIST;
 	if (net_families[ops->family] == NULL) {
 		net_families[ops->family]=ops;
 		err = 0;
 	}
-	net_family_write_unlock();
+	lw_write_unlock(&net_family_lock);
 	printk(KERN_INFO "NET: Registered protocol family %d\n",
 	       ops->family);
 	return err;

@@ -2048,9 +2006,9 @@ int sock_unregister(int family)
 	if (family < 0 || family >= NPROTO)
 		return -1;
 
-	net_family_write_lock();
+	lw_write_lock(&net_family_lock);
 	net_families[family]=NULL;
-	net_family_write_unlock();
+	lw_write_unlock(&net_family_lock);
 	printk(KERN_INFO "NET: Unregistered protocol family %d\n",
 	       family);
 	return 0;

This patch is part of the lw_rwlock patchset, it removes the ccids_{read,write}_{lock,unlock} functions which have been moved to linux/lw_rwlock.h and made more generic.

@@ -12,48 +12,11 @@
  */
 
 #include "ccid.h"
+#include <linux/lw_rwlock.h>
 
 static struct ccid_operations *ccids[CCID_MAX];
-#if defined(CONFIG_SMP) || defined(CONFIG_PREEMPT)
-static atomic_t ccids_lockct = ATOMIC_INIT(0);
-static DEFINE_SPINLOCK(ccids_lock);
-
-/*
- * The strategy is: modifications ccids vector are short, do not sleep and
- * veeery rare, but read access should be free of any exclusive locks.
- */
-static void ccids_write_lock(void)
-{
-	spin_lock(&ccids_lock);
-	while (atomic_read(&ccids_lockct) != 0) {
-		spin_unlock(&ccids_lock);
-		yield();
-		spin_lock(&ccids_lock);
-	}
-}
-
-static inline void ccids_write_unlock(void)
-{
-	spin_unlock(&ccids_lock);
-}
+static DEFINE_LW_RWLOCK(ccids_lock);
 
-static inline void ccids_read_lock(void)
-{
-	atomic_inc(&ccids_lockct);
-	spin_unlock_wait(&ccids_lock);
-}
-
-static inline void ccids_read_unlock(void)
-{
-	atomic_dec(&ccids_lockct);
-}
-
-#else
-#define ccids_write_lock() do { } while(0)
-#define ccids_write_unlock() do { } while(0)
-#define ccids_read_lock() do { } while(0)
-#define ccids_read_unlock() do { } while(0)
-#endif
 
 static kmem_cache_t *ccid_kmem_cache_create(int obj_size, const char *fmt,...)
 {

@@ -103,13 +66,13 @@ int ccid_register(struct ccid_operations
 	if (ccid_ops->ccid_hc_tx_slab == NULL)
 		goto out_free_rx_slab;
 
-	ccids_write_lock();
+	lw_write_lock(&ccids_lock);
 	err = -EEXIST;
 	if (ccids[ccid_ops->ccid_id] == NULL) {
 		ccids[ccid_ops->ccid_id] = ccid_ops;
 		err = 0;
 	}
-	ccids_write_unlock();
+	lw_write_unlock(&ccids_lock);
 	if (err != 0)
 		goto out_free_tx_slab;
 

@@ -131,9 +94,9 @@ EXPORT_SYMBOL_GPL(ccid_register);
 
 int ccid_unregister(struct ccid_operations *ccid_ops)
 {
-	ccids_write_lock();
+	lw_write_lock(&ccids_lock);
 	ccids[ccid_ops->ccid_id] = NULL;
-	ccids_write_unlock();
+	lw_write_unlock(&ccids_lock);
 
 	ccid_kmem_cache_destroy(ccid_ops->ccid_hc_tx_slab);
 	ccid_ops->ccid_hc_tx_slab = NULL;

@@ -152,15 +115,15 @@ struct ccid *ccid_new(unsigned char id, 
 	struct ccid_operations *ccid_ops;
 	struct ccid *ccid = NULL;
 
-	ccids_read_lock();
+	lw_read_lock(&ccids_lock);
 #ifdef CONFIG_KMOD
 	if (ccids[id] == NULL) {
 		/* We only try to load if in process context */
-		ccids_read_unlock();
+		lw_read_unlock(&ccids_lock);
 		if (gfp & GFP_ATOMIC)
 			goto out;
 		request_module("net-dccp-ccid-%d", id);
-		ccids_read_lock();
+		lw_read_lock(&ccids_lock);
 	}
 #endif
 	ccid_ops = ccids[id];

@@ -170,7 +133,7 @@ struct ccid *ccid_new(unsigned char id, 
 	if (!try_module_get(ccid_ops->ccid_owner))
 		goto out_unlock;
 
-	ccids_read_unlock();
+	lw_read_unlock(&ccids_lock);
 
 	ccid = kmem_cache_alloc(rx ? ccid_ops->ccid_hc_rx_slab :
 				     ccid_ops->ccid_hc_tx_slab, gfp);

@@ -191,7 +154,7 @@ struct ccid *ccid_new(unsigned char id, 
 out:
 	return ccid;
 out_unlock:
-	ccids_read_unlock();
+	lw_read_unlock(&ccids_lock);
 	goto out;
 out_free_ccid:
 	kmem_cache_free(rx ? ccid_ops->ccid_hc_rx_slab :

@@ -235,10 +198,10 @@ static void ccid_delete(struct ccid *cci
 			ccid_ops->ccid_hc_tx_exit(sk);
 		kmem_cache_free(ccid_ops->ccid_hc_tx_slab,  ccid);
 	}
-	ccids_read_lock();
+	lw_read_lock(&ccids_lock);
 	if (ccids[ccid_ops->ccid_id] != NULL)
 		module_put(ccid_ops->ccid_owner);
-	ccids_read_unlock();
+	lw_read_unlock(&ccids_lock);
 }
 
 void ccid_hc_rx_delete(struct ccid *ccid, struct sock *sk)

This patch is part of the lw_rwlock patchset, it removes the bt_proto_rwlock lock from af_bluetooth.c and uses the newly available linux/lw_rwlock.h

@@ -27,6 +27,7 @@
 #include <linux/module.h>
 
 #include <linux/spinlock.h>
+#include <linux/lw_rwlock.h>
 #include <linux/types.h>
 #include <linux/list.h>
 #include <linux/errno.h>

@@ -54,7 +55,7 @@
 /* Bluetooth sockets */
 #define BT_MAX_PROTO	8
 static struct net_proto_family *bt_proto[BT_MAX_PROTO];
-static DEFINE_RWLOCK(bt_proto_rwlock);
+static DEFINE_LW_RWLOCK(bt_proto_rwlock);
 
 int bt_sock_register(int proto, struct net_proto_family *ops)
 {

@@ -65,12 +66,12 @@ int bt_sock_register(int proto, struct n
 
 	err = -EEXIST;
 
-	write_lock(&bt_proto_rwlock);
+	lw_write_lock(&bt_proto_rwlock);
 	if (bt_proto[proto] == NULL) {
 		err = 0;
 		bt_proto[proto] = ops;
 	}
-	write_unlock(&bt_proto_rwlock);
+	lw_write_unlock(&bt_proto_rwlock);
 
 	return err;
 }

@@ -84,12 +85,12 @@ int bt_sock_unregister(int proto)
 		return -EINVAL;
 
 	err = -ENOENT;
-	write_lock(&bt_proto_rwlock);
+	lw_write_lock(&bt_proto_rwlock);
 	if (bt_proto[proto]) {
 		err = 0;
 		bt_proto[proto] = NULL;
 	}
-	write_unlock(&bt_proto_rwlock);
+	lw_write_unlock(&bt_proto_rwlock);
 
 	return err;
 }

@@ -108,12 +109,12 @@ static int bt_sock_create(struct socket 
 	}
 #endif
 	err = -EPROTONOSUPPORT;
-	read_lock(&bt_proto_rwlock);
+	lw_read_lock(&bt_proto_rwlock);
 	if (bt_proto[proto] && try_module_get(bt_proto[proto]->owner)) {
 		err = bt_proto[proto]->create(sock, proto);
 		module_put(bt_proto[proto]->owner);
 	}
-	read_unlock(&bt_proto_rwlock);
+	lw_read_unlock(&bt_proto_rwlock);
 	return err; 
 }
 

Hi,

I think the name, "lightweight" is too generic. It implies just lw_rwlock is better than rwlock. The name may lead that people use lw_rwlock rather than rwlock any place through there are places where rwlock is better than lw_rwlock. So I looked for the name:

sw_rwlock: seldom writing rwlock
wp_rwlock: write pricey rwlock
rp_rwlock: read prioritized rwlock

If you could find good one, plesae use it instead.

Masatake YAMATO

On Mon, Jul 31, 2006 at 04:06:15PM +0900, Masatake YAMATO wrote:
Hi,

Fair enough.

write expensive, we_rwlock? I like your idea of stressing the fact that the protected data has to be seldom modified if you intend to use this kind of lock.

I'll re-submit the patch with a proper naming for the rc3-mm1. However, I'd like to get some feedback on the code itself: the current whatever_rwlock code won't be debuggable with lockdep, and I'm not sure there's not some more clever way to do it.

Thanks,
Frederik

[snip]

Andrew, have you considered switching that tree to git? IMHO git-bisect is a killer-app.

Regards,
Michal

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

There are many known-to-be-broken bisection points in a -mm tree. I'd expect git-style bisection wouldn't be very successful. quilt-style bisection is more straightforward. Plus you can make intelligent decisions to help it converge faster.

Building with -Werror-implicit-function-declaration fails:

CC arch/i386/pci/mmconfig.o
arch/i386/pci/mmconfig.c: In function 'pci_mmcfg_force':
arch/i386/pci/mmconfig.c:232: error: implicit declaration of function 'add_memory_region'

Problem is a missing #include, patch attached. Problem was introduced by add-force-of-use-mmconfig.patch. This is a bug even without the -Werror, as the implicit declaration doesn't match the real one.

Patch attached.

@@ -15,6 +15,7 @@
 #include <linux/dmi.h>
 #include <linux/efi.h>
 #include <asm/e820.h>
+#include <asm/setup.h>
 #include "pci.h"
 
 /* aperture is up to 256MB but BIOS may reserve less */

I'm seeing pseudorandom hard lockups soon after boot on a Dell Latitude C840. It just siezes up, even alt-sysrq is totally wedged, need to power cycle to recover. There doesn't seem to be a really obvious trigger - the first time it died after all the /etc/rc5.d scripts, while trying to start the X server. The second, I brought it up single-user, and it didn't even live long enough to give me a prompt. Multiple attempts hung at different places, but always within 2-3 minutes.

2.6.18-rc1-mm1 works fine, as does 2.6.18-rc2 plus origin.patch and git-libata-all.patch (vanilla -rc2 won't recognize my piix controller, not in a mood to reconfigure to use ide rather than libata).

Off to go play bisect-the-mm, though it may be later in weekend before I finish that...

2.6.18-rc2-mm1 causes boot to fail early with:
kernel panic: IO_APIC timer interrupt 0 doesn't work

2.6.18-rc2 works.

2.6.18-rc2-mm1 kernel config located at:
http://www.microgate.com/ftp/linux/test/config

syslog from working 2.6.18-rc2 located at:
http://www.microgate.com/ftp/linux/test/syslog

Paul Fulghum
Microgate Systems, Ltd

I don't know what would have caused this. Was 2.6.18-rc1-mm2 OK?

Patches which touch arch/i386/kernel/io_apic.c are:

x86_64-mm-i386-up-generic-arch.patch x86_64-mm-i386-io-apic-access.patch genirq-convert-the-i386-architecture-to-irq-chips.patch initial-generic-hypertransport-interrupt-support.patch genirq-i386-irq-remove-the-msi-assumption-that-irq-==-vector.patch genirq-i386-irq-move-msi-message-composition-into-io_apicc.patch genirq-i386-irq-dynamic-irq-support.patch

The developers of those patches are cc'ed.

A bisection search would be useful, if you have the time. I'd zero in on the x86_64 tree initially. Perhaps x86_64-mm-i386-io-apic-access.patch.

Or it could be something else altogether.

I have not tried that combination.

The machine in question is at the office so I won't be able to test that particular setup this weekend. I will test removing the listed patches as time permits starting on Monday.

It happens every time so there is no problem in reproducing it. I will also test 2.6.18-rc2-mm1 on my home machine which is AMDx2 as well (but a different chipset/MB).

--
Paul

What happened to the new lines? It looks like a bad alphabet soup

Do you perhaps have a boot log from before 2.6.17 (e.g. 2.6.16)? Preferably with newlines.

It's remove-timer-fallback likely. I was working on that already.

Some boards go into the timer fallback path since 2.6.17/64bit for so far unknown reasons and that doesn't work anymore because I removed the fallback path.

-Andi

When I download and edit syslog from the specified URL, it has newlines.

I can get a syslog from < 2.6.17
but not right now as that machine is at the office.

I might burn some time tomorrow and go into the office to try removing that patch. By Monday at the latest.

I'm doing a build on my home machine now to see if it happens there also.

--
Paul

Well, the timer int 0 problem does not happen on my home machine. However, it still crashes in early boot for a different reason.

2.6.18-rc2 works fine with same config.

In this case the error is:

No per-cpu room for modules
...
insmod:error interting '/lib/scsi_mod.ko' -1 cannot allocate memory
...
[other modules depending on scsi_mod.ko fail to load]
...
kernel panic - Attempted to kill init - d000

Woof! (said the dog because the cow said moo)

syslog from working 2.6.18-rc2 below:

Jul 28 20:01:23 localhost kernel: Linux version 2.6.18-rc2 ([email protected]) (gcc version 4.1.1 20060525 (Red Hat 4.1.1-1)) #1 SMP Fri Jul 28 19:52:34 CDT 2006
Jul 28 20:01:23 localhost kernel: BIOS-provided physical RAM map:
Jul 28 20:01:23 localhost kernel:  BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
Jul 28 20:01:23 localhost kernel:  BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
Jul 28 20:01:23 localhost kernel:  BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
Jul 28 20:01:23 localhost kernel:  BIOS-e820: 0000000000100000 - 000000007fff0000 (usable)
Jul 28 20:01:23 localhost kernel:  BIOS-e820: 000000007fff0000 - 000000007fff3000 (ACPI NVS)
Jul 28 20:01:23 localhost kernel:  BIOS-e820: 000000007fff3000 - 0000000080000000 (ACPI data)
Jul 28 20:01:23 localhost kernel:  BIOS-e820: 00000000d0000000 - 00000000e0000000 (reserved)
Jul 28 20:01:23 localhost kernel:  BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved)
Jul 28 20:01:23 localhost kernel: DMI 2.3 present.
Jul 28 20:01:24 localhost rpc.statd[1926]: Version 1.0.8-rc2 Starting
Jul 28 20:01:25 localhost kernel: Scanning NUMA topology in Northbridge 24
Jul 28 20:01:25 localhost kernel: Number of nodes 1
Jul 28 20:01:25 localhost kernel: Node 0 MemBase 0000000000000000 Limit 000000007fff0000
Jul 28 20:01:25 localhost kernel: Using node hash shift of 63
Jul 28 20:01:25 localhost kernel: Bootmem setup node 0 0000000000000000-000000007fff0000
Jul 28 20:01:25 localhost kernel: Nvidia board detected. Ignoring ACPI timer override.
Jul 28 20:01:25 localhost kernel: ACPI: PM-Timer IO Port: 0x1008
Jul 28 20:01:25 localhost kernel: ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
Jul 28 20:01:25 localhost kernel: Processor #0 15:11 APIC version 16
Jul 28 20:01:25 localhost kernel: ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
Jul 28 20:01:25 localhost kernel: Processor #1 15:11 APIC version 16
Jul 28 20:01:25 localhost kernel: ACPI: LAPIC_NMI (acpi_id[0x00] dfl dfl lint[0x1])
Jul 28 20:01:25 localhost kernel: ACPI: LAPIC_NMI (acpi_id[0x01] dfl dfl lint[0x1])
Jul 28 20:01:25 localhost kernel: ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
Jul 28 20:01:25 localhost kernel: IOAPIC[0]: apic_id 2, version 17, address 0xfec00000, GSI 0-23
Jul 28 20:01:25 localhost kernel: ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
Jul 28 20:01:25 localhost kernel: ACPI: BIOS IRQ0 pin2 override ignored.
Jul 28 20:01:25 localhost kernel: ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
Jul 28 20:01:25 localhost kernel: ACPI: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 14 high edge)
Jul 28 20:01:25 localhost kernel: ACPI: INT_SRC_OVR (bus 0 bus_irq 15 global_irq 15 high edge)
Jul 28 20:01:25 localhost kernel: Setting APIC routing to physical flat
Jul 28 20:01:25 localhost kernel: Using ACPI (MADT) for SMP configuration information
Jul 28 20:01:25 localhost kernel: Allocating PCI resources starting at 88000000 (gap: 80000000:50000000)
Jul 28 20:01:25 localhost kernel: SMP: Allowing 2 CPUs, 0 hotplug CPUs
Jul 28 20:01:25 localhost kernel: Built 1 zonelists.  Total pages: 514549
Jul 28 20:01:25 localhost kernel: Kernel command line: ro root=LABEL=/1 rhgb quiet
Jul 28 20:01:25 localhost kernel: Initializing CPU#0
Jul 28 20:01:25 localhost kernel: PID hash table entries: 4096 (order: 12, 32768 bytes)
Jul 28 20:01:25 localhost kernel: Disabling vsyscall due to use of PM timer
Jul 28 20:01:25 localhost kernel: time.c: Using 3.579545 MHz WALL PM GTOD PM timer.
Jul 28 20:01:25 localhost kernel: time.c: Detected 2010.330 MHz processor.
Jul 28 20:01:25 localhost kernel: Console: colour VGA+ 80x25
Jul 28 20:01:25 localhost kernel: Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes)
Jul 28 20:01:25 localhost kernel: Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes)
Jul 28 20:01:25 localhost kernel: Checking aperture...
Jul 28 20:01:25 localhost kernel: CPU 0: aperture @ 2ea0000000 size 32 MB
Jul 28 20:01:25 localhost kernel: Aperture too small (32 MB)
Jul 28 20:01:25 localhost kernel: No AGP bridge found
Jul 28 20:01:25 localhost kernel: Memory: 2053824k/2097088k available (2316k kernel code, 42876k reserved, 1238k data, 204k init)
Jul 28 20:01:25 localhost kernel: Calibrating delay using timer specific routine.. 4023.90 BogoMIPS (lpj=8047819)
Jul 28 20:01:25 localhost kernel: Security Framework v1.0.0 initialized
Jul 28 20:01:25 localhost kernel: SELinux:  Initializing.
Jul 28 20:01:25 localhost kernel: SELinux:  Starting in permissive mode
Jul 28 20:01:25 localhost kernel: selinux_register_security:  Registering secondary module capability
Jul 28 20:01:25 localhost kernel: Capability LSM initialized as secondary
Jul 28 20:01:25 localhost kernel: Mount-cache hash table entries: 256
Jul 28 20:01:25 localhost kernel: CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
Jul 28 20:01:25 localhost kernel: CPU: L2 Cache: 512K (64 bytes/line)
Jul 28 20:01:25 localhost kernel: CPU 0/0 -> Node 0
Jul 28 20:01:25 localhost kernel: CPU: Physical Processor ID: 0
Jul 28 20:01:25 localhost kernel: CPU: Processor Core ID: 0
Jul 28 20:01:25 localhost kernel: SMP alternatives: switching to UP code
Jul 28 20:01:25 localhost kernel: ACPI: Core revision 20060707
Jul 28 20:01:25 localhost kernel: Using local APIC timer interrupts.
Jul 28 20:01:25 localhost kernel: result 12564579
Jul 28 20:01:25 localhost kernel: Detected 12.564 MHz APIC timer.
Jul 28 20:01:25 localhost kernel: SMP alternatives: switching to SMP code
Jul 28 20:01:25 localhost kernel: Booting processor 1/2 APIC 0x1
Jul 28 20:01:25 localhost kernel: Initializing CPU#1
Jul 28 20:01:25 localhost kernel: Calibrating delay using timer specific routine.. 4020.89 BogoMIPS (lpj=8041781)
Jul 28 20:01:25 localhost kernel: CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
Jul 28 20:01:25 localhost kernel: CPU: L2 Cache: 512K (64 bytes/line)
Jul 28 20:01:25 localhost kernel: CPU 1/1 -> Node 0
Jul 28 20:01:25 localhost kernel: CPU: Physical Processor ID: 0
Jul 28 20:01:25 localhost kernel: CPU: Processor Core ID: 1
Jul 28 20:01:25 localhost kernel: AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ stepping 01
Jul 28 20:01:25 localhost kernel: CPU 1: Syncing TSC to CPU 0.
Jul 28 20:01:25 localhost kernel: CPU 1: synchronized TSC with CPU 0 (last diff 0 cycles, maxerr 566 cycles)
Jul 28 20:01:25 localhost kernel: Brought up 2 CPUs
Jul 28 20:01:25 localhost kernel: testing NMI watchdog ... OK.
Jul 28 20:01:25 localhost kernel: migration_cost=253
Jul 28 20:01:25 localhost kernel: checking if image is initramfs... it is
Jul 28 20:01:25 localhost kernel: Freeing initrd memory: 1078k freed
Jul 28 20:01:25 localhost kernel: NET: Registered protocol family 16
Jul 28 20:01:25 localhost kernel: ACPI: bus type pci registered
Jul 28 20:01:25 localhost kernel: PCI: Using MMCONFIG at d0000000
Jul 28 20:01:25 localhost kernel: PCI: No mmconfig possible on device 0:18
Jul 28 20:01:25 localhost kernel: ACPI: Interpreter enabled
Jul 28 20:01:25 localhost kernel: ACPI: Using IOAPIC for interrupt routing
Jul 28 20:01:25 localhost kernel: ACPI: PCI Root Bridge [PCI0] (0000:00)
Jul 28 20:01:25 localhost kernel: PCI: Transparent bridge - 0000:00:09.0
Jul 28 20:01:25 localhost kernel: ACPI: PCI Interrupt Link [LNK1] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, disabled.
Jul 28 20:01:25 localhost kernel: ACPI: PCI Interrupt Link [LNK2] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, disabled.
Jul 28 20:01:25 localhost kernel: ACPI: PCI Interrupt Link [LNK3] (IRQs 3 4 5 7 9 *10 11 12 14 15)
Jul 28 20:01:25 localhost kernel: ACPI: PCI Interrupt Link [LNK4] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, disabled.
Jul 28 20:01:25 localhost kernel: ACPI: PCI Interrupt Link [LNK5] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, disabled.
Jul 28 20:01:25 localhost kernel: ACPI: PCI Interrupt Link [LUBA] (IRQs 3 4 5 7 9 10 *11 12 14 15)
Jul 28 20:01:25 localhost kernel: ACPI: PCI Interrupt Link [LUBB] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, disabled.
Jul 28 20:01:25 localhost kernel: ACPI: PCI Interrupt Link [LMAC] (IRQs 3 4 *5 7 9 10 11 12 14 15)
Jul 28 20:01:25 localhost kernel: ACPI: PCI Interrupt Link [LACI] (IRQs 3 4 5 7 9 10 11 *12 14 15)
Jul 28 20:01:25 localhost kernel: ACPI: PCI Interrupt Link [LMCI] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, disabled.
Jul 28 20:01:25 localhost kernel: ACPI: PCI Interrupt Link [LSMB] (IRQs 3 4 5 7 9 *10 11 12 14 15)
Jul 28 20:01:25 localhost kernel: ACPI: PCI Interrupt Link [LUB2] (IRQs *3 4 5 7 9 10 11 12 14 15)
Jul 28 20:01:25 localhost kernel: ACPI: PCI Interrupt Link [LIDE] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, disabled.
Jul 28 20:01:25 localhost kernel: ACPI: PCI Interrupt Link [LSID] (IRQs 3 4 5 7 9 10 *11 12 14 15)
Jul 28 20:01:25 localhost kernel: ACPI: PCI Interrupt Link [LFID] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, disabled.
Jul 28 20:01:25 localhost kernel: ACPI: PCI Interrupt Link [LPCA] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, disabled.
Jul 28 20:01:25 localhost kernel: ACPI: PCI Interrupt Link [APC1] (IRQs 16) *0, disabled.
Jul 28 20:01:25 localhost kernel: ACPI: PCI Interrupt Link [APC2] (IRQs 17) *0, disabled.
Jul 28 20:01:25 localhost kernel: ACPI: PCI Interrupt Link [APC3] (IRQs 18) *0, disabled.
Jul 28 20:01:25 localhost kernel: ACPI: PCI Interrupt Link [APC4] (IRQs 19) *0, disabled.
Jul 28 20:01:25 localhost kernel: ACPI: PCI Interrupt Link [APC5] (IRQs *16), disabled.
Jul 28 20:01:25 localhost kernel: ACPI: PCI Interrupt Link [APCF] (IRQs 20 21 22 23) *0, disabled.
Jul 28 20:01:25 localhost kernel: ACPI: PCI Interrupt Link [APCG] (IRQs 20 21 22 23) *0, disabled.
Jul 28 20:01:25 localhost kernel: ACPI: PCI Interrupt Link [APCH] (IRQs 20 21 22 23) *0, disabled.
Jul 28 20:01:25 localhost kernel: ACPI: PCI Interrupt Link [APCJ] (IRQs 20 21 22 23) *0, disabled.
Jul 28 20:01:25 localhost kernel: ACPI: PCI Interrupt Link [APCK] (IRQs 20 21 22 23) *0, disabled.
Jul 28 20:01:25 localhost kernel: ACPI: PCI Interrupt Link [APCS] (IRQs 20 21 22 23) *0, disabled.
Jul 28 20:01:25 localhost kernel: ACPI: PCI Interrupt Link [APCL] (IRQs 20 21 22 23) *0, disabled.
Jul 28 20:01:25 localhost kernel: ACPI: PCI Interrupt Link [APCZ] (IRQs 20 21 22 23) *0, disabled.
Jul 28 20:01:25 localhost kernel: ACPI: PCI Interrupt Link [APSI] (IRQs 20 21 22 23) *0, disabled.
Jul 28 20:01:25 localhost kernel: ACPI: PCI Interrupt Link [APSJ] (IRQs 20 21 22 23) *0, disabled.
Jul 28 20:01:25 localhost kernel: ACPI: PCI Interrupt Link [APCP] (IRQs 20 21 22 23) *0, disabled.
Jul 28 20:01:25 localhost kernel: Linux Plug and Play Support v0.97 (c) Adam Belay
Jul 28 20:01:25 localhost kernel: pnp: PnP ACPI init
Jul 28 20:01:25 localhost kernel: pnp: PnP ACPI: found 12 devices
Jul 28 20:01:25 localhost kernel: usbcore: registered new driver usbfs
Jul 28 20:01:25 localhost kernel: usbcore: registered new driver hub
Jul 28 20:01:25 localhost kernel: PCI: Using ACPI for IRQ routing
Jul 28 20:01:25 localhost kernel: PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post a report
Jul 28 20:01:25 localhost kernel: PCI-DMA: Disabling IOMMU.
Jul 28 20:01:25 localhost kernel: pnp: 00:01: ioport range 0x1000-0x107f could not be reserved
Jul 28 20:01:25 localhost kernel: pnp: 00:01: ioport range 0x1080-0x10ff has been reserved
Jul 28 20:01:25 localhost kernel: pnp: 00:01: ioport range 0x1400-0x147f has been reserved
Jul 28 20:01:25 localhost kernel: pnp: 00:01: ioport range 0x1480-0x14ff could not be reserved
Jul 28 20:01:25 localhost kernel: pnp: 00:01: ioport range 0x1800-0x187f has been reserved
Jul 28 20:01:25 localhost kernel: pnp: 00:01: ioport range 0x1880-0x18ff has been reserved
Jul 28 20:01:25 localhost kernel: PCI: Bridge: 0000:00:09.0
Jul 28 20:01:25 localhost kernel:   IO window: disabled.
Jul 28 20:01:25 localhost kernel:   MEM window: f3000000-f30fffff
Jul 28 20:01:25 localhost kernel:   PREFETCH window: disabled.
Jul 28 20:01:25 localhost kernel: PCI: Bridge: 0000:00:0b.0
Jul 28 20:01:25 localhost kernel:   IO window: a000-afff
Jul 28 20:01:25 localhost kernel:   MEM window: disabled.
Jul 28 20:01:25 localhost kernel:   PREFETCH window: disabled.
Jul 28 20:01:25 localhost kernel: PCI: Bridge: 0000:00:0c.0
Jul 28 20:01:25 localhost kernel:   IO window: 9000-9fff
Jul 28 20:01:25 localhost kernel:   MEM window: disabled.
Jul 28 20:01:25 localhost kernel:   PREFETCH window: disabled.
Jul 28 20:01:25 localhost kernel: PCI: Bridge: 0000:00:0d.0
Jul 28 20:01:25 localhost kernel:   IO window: 8000-8fff
Jul 28 20:01:25 localhost kernel:   MEM window: disabled.
Jul 28 20:01:25 localhost kernel:   PREFETCH window: disabled.
Jul 28 20:01:25 localhost kernel: PCI: Bridge: 0000:00:0e.0
Jul 28 20:01:25 localhost kernel:   IO window: b000-bfff
Jul 28 20:01:25 localhost kernel:   MEM window: f0000000-f2ffffff
Jul 28 20:01:25 localhost kernel:   PREFETCH window: e0000000-efffffff
Jul 28 20:01:25 localhost kernel: NET: Registered protocol family 2
Jul 28 20:01:25 localhost kernel: IP route cache hash table entries: 65536 (order: 7, 524288 bytes)
Jul 28 20:01:25 localhost kernel: TCP established hash table entries: 131072 (order: 10, 4194304 bytes)
Jul 28 20:01:25 localhost kernel: TCP bind hash table entries: 65536 (order: 9, 2097152 bytes)
Jul 28 20:01:25 localhost kernel: TCP: Hash tables configured (established 131072 bind 65536)
Jul 28 20:01:25 localhost kernel: TCP reno registered
Jul 28 20:01:25 localhost kernel: audit: initializing netlink socket (disabled)
Jul 28 20:01:25 localhost kernel: audit(1154116852.688:1): initialized
Jul 28 20:01:25 localhost kernel: Total HugeTLB memory allocated, 0
Jul 28 20:01:25 localhost kernel: VFS: Disk quotas dquot_6.5.1
Jul 28 20:01:25 localhost kernel: Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
Jul 28 20:01:25 localhost kernel: SELinux:  Registering netfilter hooks
Jul 28 20:01:25 localhost kernel: Initializing Cryptographic API
Jul 28 20:01:25 localhost kernel: io scheduler noop registered
Jul 28 20:01:25 localhost kernel: io scheduler anticipatory registered
Jul 28 20:01:25 localhost kernel: io scheduler deadline registered
Jul 28 20:01:25 localhost kernel: io scheduler cfq registered (default)
Jul 28 20:01:25 localhost kernel: PCI: Linking AER extended capability on 0000:00:0b.0
Jul 28 20:01:25 localhost kernel: PCI: Linking AER extended capability on 0000:00:0c.0
Jul 28 20:01:25 localhost kernel: PCI: Linking AER extended capability on 0000:00:0d.0
Jul 28 20:01:25 localhost kernel: PCI: Linking AER extended capability on 0000:00:0e.0
Jul 28 20:01:25 localhost kernel: pcie_portdrv_probe->Dev[005d:10de] has invalid IRQ. Check vendor BIOS
Jul 28 20:01:25 localhost kernel: assign_interrupt_mode Found MSI capability
Jul 28 20:01:25 localhost kernel: pcie_portdrv_probe->Dev[005d:10de] has invalid IRQ. Check vendor BIOS
Jul 28 20:01:25 localhost kernel: assign_interrupt_mode Found MSI capability
Jul 28 20:01:25 localhost kernel: pcie_portdrv_probe->Dev[005d:10de] has invalid IRQ. Check vendor BIOS
Jul 28 20:01:25 localhost kernel: assign_interrupt_mode Found MSI capability
Jul 28 20:01:25 localhost kernel: pcie_portdrv_probe->Dev[005d:10de] has invalid IRQ. Check vendor BIOS
Jul 28 20:01:25 localhost kernel: assign_interrupt_mode Found MSI capability
Jul 28 20:01:25 localhost kernel: pci_hotplug: PCI Hot Plug PCI Core version: 0.5
Jul 28 20:01:25 localhost kernel: Real Time Clock Driver v1.12ac
Jul 28 20:01:25 localhost kernel: Linux agpgart interface v0.101 (c) Dave Jones
Jul 28 20:01:25 localhost kernel: Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
Jul 28 20:01:25 localhost kernel: serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
Jul 28 20:01:25 localhost kernel: 00:07: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
Jul 28 20:01:25 localhost kernel: RAMDISK driver initialized: 16 RAM disks of 16384K size 1024 blocksize
Jul 28 20:01:25 localhost kernel: Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
Jul 28 20:01:25 localhost kernel: ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
Jul 28 20:01:25 localhost kernel: NFORCE-CK804: IDE controller at PCI slot 0000:00:06.0
Jul 28 20:01:25 localhost kernel: NFORCE-CK804: chipset revision 162
Jul 28 20:01:25 localhost kernel: NFORCE-CK804: not 100% native mode: will probe irqs later
Jul 28 20:01:25 localhost kernel: NFORCE-CK804: 0000:00:06.0 (rev a2) UDMA133 controller
Jul 28 20:01:25 localhost kernel:     ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:DMA
Jul 28 20:01:25 localhost kernel: hda: _NEC DVD_RW ND-3540A, ATAPI CD/DVD-ROM drive
Jul 28 20:01:25 localhost kernel: ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Jul 28 20:01:25 localhost kernel: hda: ATAPI 48X DVD-ROM DVD-R CD-R/RW drive, 2048kB Cache, UDMA(33)
Jul 28 20:01:25 localhost kernel: Uniform CD-ROM driver Revision: 3.20
Jul 28 20:01:25 localhost kernel: ide-floppy driver 0.99.newide
Jul 28 20:01:25 localhost kernel: usbcore: registered new driver libusual
Jul 28 20:01:25 localhost kernel: usbcore: registered new driver hiddev
Jul 28 20:01:25 localhost kernel: usbcore: registered new driver usbhid
Jul 28 20:01:25 localhost kernel: drivers/usb/input/hid-core.c: v2.6:USB HID core driver
Jul 28 20:01:25 localhost kernel: PNP: PS/2 Controller [PNP0303:PS2K] at 0x60,0x64 irq 1
Jul 28 20:01:25 localhost kernel: PNP: PS/2 controller doesn't have AUX irq; using default 12
Jul 28 20:01:25 localhost kernel: serio: i8042 AUX port at 0x60,0x64 irq 12
Jul 28 20:01:25 localhost kernel: serio: i8042 KBD port at 0x60,0x64 irq 1
Jul 28 20:01:25 localhost kernel: mice: PS/2 mouse device common for all mice
Jul 28 20:01:25 localhost kernel: md: md driver 0.90.3 MAX_MD_DEVS=256, MD_SB_DISKS=27
Jul 28 20:01:25 localhost kernel: md: bitmap version 4.39
Jul 28 20:01:25 localhost kernel: TCP bic registered
Jul 28 20:01:25 localhost kernel: Initializing IPsec netlink socket
Jul 28 20:01:25 localhost kernel: NET: Registered protocol family 1
Jul 28 20:01:25 localhost kernel: NET: Registered protocol family 17
Jul 28 20:01:25 localhost kernel: powernow-k8: Found 2 AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ processors (version 2.00.00)
Jul 28 20:01:25 localhost kernel: powernow-k8: invalid freq entries 3900000 kHz vs. 65535000 kHz
Jul 28 20:01:25 localhost last message repeated 3 times
Jul 28 20:01:25 localhost kernel: powernow-k8:    0 : fid 0xc (2000 MHz), vid 0x8
Jul 28 20:01:25 localhost kernel: powernow-k8:    1 : fid 0x2 (1000 MHz), vid 0x12
Jul 28 20:01:25 localhost kernel: ACPI: (supports S0 S1 S4 S5)
Jul 28 20:01:25 localhost kernel: Freeing unused kernel memory: 204k freed
Jul 28 20:01:25 localhost kernel: Write protecting the kernel read-only data: 464k
Jul 28 20:01:25 localhost kernel: SCSI subsystem initialized
Jul 28 20:01:25 localhost kernel: ACPI: PCI Interrupt Link [APSI] enabled at IRQ 23
Jul 28 20:01:25 localhost kernel: GSI 16 sharing vector 0xB1 and IRQ 16
Jul 28 20:01:25 localhost kernel: ACPI: PCI Interrupt 0000:00:07.0[A] -> Link [APSI] -> GSI 23 (level, low) -> IRQ 16
Jul 28 20:01:25 localhost kernel: ata1: SATA max UDMA/133 cmd 0x9F0 ctl 0xBF2 bmdma 0xE000 irq 16
Jul 28 20:01:25 localhost kernel: ata2: SATA max UDMA/133 cmd 0x970 ctl 0xB72 bmdma 0xE008 irq 16
Jul 28 20:01:25 localhost kernel: scsi0 : sata_nv
Jul 28 20:01:25 localhost kernel: input: AT Translated Set 2 keyboard as /class/input/input0
Jul 28 20:01:25 localhost kernel: ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
Jul 28 20:01:25 localhost kernel: ata1.00: ATA-7, max UDMA/133, 586114704 sectors: LBA48 NCQ (depth 0/32)
Jul 28 20:01:25 localhost kernel: ata1.00: ata1: dev 0 multi count 16
Jul 28 20:01:25 localhost kernel: ata1.00: configured for UDMA/133
Jul 28 20:01:25 localhost kernel: scsi1 : sata_nv
Jul 28 20:01:25 localhost kernel: ata2: SATA link down (SStatus 0 SControl 300)
Jul 28 20:01:25 localhost kernel:   Vendor: ATA       Model: Maxtor 7L300S0    Rev: BANC
Jul 28 20:01:25 localhost kernel:   Type:   Direct-Access                      ANSI SCSI revision: 05
Jul 28 20:01:25 localhost kernel: SCSI device sda: 586114704 512-byte hdwr sectors (300091 MB)
Jul 28 20:01:25 localhost kernel: sda: Write Protect is off
Jul 28 20:01:25 localhost kernel: SCSI device sda: drive cache: write back
Jul 28 20:01:25 localhost kernel: SCSI device sda: 586114704 512-byte hdwr sectors (300091 MB)
Jul 28 20:01:25 localhost kernel: sda: Write Protect is off
Jul 28 20:01:25 localhost kernel: SCSI device sda: drive cache: write back
Jul 28 20:01:25 localhost kernel:  sda: sda1 sda2 < sda5 sda6 sda7 sda8 sda9 >
Jul 28 20:01:25 localhost kernel: sd 0:0:0:0: Attached scsi disk sda
Jul 28 20:01:25 localhost kernel: kjournald starting.  Commit interval 5 seconds
Jul 28 20:01:25 localhost kernel: EXT3-fs: mounted filesystem with ordered data mode.
Jul 28 20:01:25 localhost kernel: audit(1154116856.620:2): enforcing=1 old_enforcing=0 auid=4294967295
Jul 28 20:01:25 localhost kernel: security:  3 users, 6 roles, 1417 types, 151 bools, 1 sens, 256 cats
Jul 28 20:01:25 localhost kernel: security:  57 classes, 41080 rules
Jul 28 20:01:25 localhost kernel: SELinux:  Completing initialization.
Jul 28 20:01:25 localhost kernel: SELinux:  Setting up existing superblocks.
Jul 28 20:01:25 localhost kernel: SELinux: initialized (dev sda8, type ext3), uses xattr
Jul 28 20:01:25 localhost kernel: SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
Jul 28 20:01:25 localhost kernel: SELinux: initialized (dev debugfs, type debugfs), uses genfs_contexts
Jul 28 20:01:25 localhost kernel: SELinux: initialized (dev selinuxfs, type selinuxfs), uses genfs_contexts
Jul 28 20:01:25 localhost kernel: SELinux: initialized (dev mqueue, type mqueue), uses transition SIDs
Jul 28 20:01:25 localhost kernel: SELinux: initialized (dev hugetlbfs, type hugetlbfs), uses genfs_contexts
Jul 28 20:01:25 localhost kernel: SELinux: initialized (dev devpts, type devpts), uses transition SIDs
Jul 28 20:01:25 localhost kernel: SELinux: initialized (dev eventpollfs, type eventpollfs), uses genfs_contexts
Jul 28 20:01:25 localhost kernel: SELinux: initialized (dev inotifyfs, type inotifyfs), uses genfs_contexts
Jul 28 20:01:25 localhost kernel: SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
Jul 28 20:01:25 localhost kernel: SELinux: initialized (dev futexfs, type futexfs), uses genfs_contexts
Jul 28 20:01:25 localhost kernel: SELinux: initialized (dev pipefs, type pipefs), uses task SIDs
Jul 28 20:01:25 localhost kernel: SELinux: initialized (dev sockfs, type sockfs), uses task SIDs
Jul 28 20:01:25 localhost kernel: SELinux: initialized (dev cpuset, type cpuset), not configured for labeling
Jul 28 20:01:25 localhost kernel: SELinux: initialized (dev proc, type proc), uses genfs_contexts
Jul 28 20:01:25 localhost kernel: SELinux: initialized (dev bdev, type bdev), uses genfs_contexts
Jul 28 20:01:25 localhost kernel: SELinux: initialized (dev rootfs, type rootfs), uses genfs_contexts
Jul 28 20:01:25 localhost kernel: SELinux: initialized (dev sysfs, type sysfs), uses genfs_contexts
Jul 28 20:01:25 localhost kernel: audit(1154116856.892:3): policy loaded auid=4294967295
Jul 28 20:01:25 localhost kernel: SELinux: initialized (dev usbfs, type usbfs), uses genfs_contexts
Jul 28 20:01:25 localhost kernel: audit(1154134859.998:4): avc:  denied  { audit_write } for  pid=469 comm="hwclock" capability=29 scontext=system_u:system_r:hwclock_t:s0 tcontext=system_u:system_r:hwclock_t:s0 tclass=capability
Jul 28 20:01:25 localhost kernel: input: PC Speaker as /class/input/input1
Jul 28 20:01:25 localhost kernel: forcedeth.c: Reverse Engineered nForce ethernet driver. Version 0.56.
Jul 28 20:01:25 localhost kernel: ACPI: PCI Interrupt Link [APCH] enabled at IRQ 22
Jul 28 20:01:25 localhost kernel: GSI 17 sharing vector 0xB9 and IRQ 17
Jul 28 20:01:25 localhost kernel: ACPI: PCI Interrupt 0000:00:0a.0[A] -> Link [APCH] -> GSI 22 (level, low) -> IRQ 17
Jul 28 20:01:25 localhost kernel: forcedeth: using HIGHDMA
Jul 28 20:01:25 localhost kernel: eth0: forcedeth.c: subsystem: 01458:e000 bound to 0000:00:0a.0
Jul 28 20:01:25 localhost kernel: i2c_adapter i2c-0: nForce2 SMBus adapter at 0x1c00
Jul 28 20:01:25 localhost kernel: i2c_adapter i2c-1: nForce2 SMBus adapter at 0x1c40
Jul 28 20:01:25 localhost kernel: ACPI: PCI Interrupt Link [APCJ] enabled at IRQ 21
Jul 28 20:01:25 localhost kernel: GSI 18 sharing vector 0xC1 and IRQ 18
Jul 28 20:01:25 localhost kernel: ACPI: PCI Interrupt 0000:00:04.0[A] -> Link [APCJ] -> GSI 21 (level, low) -> IRQ 18
Jul 28 20:01:25 localhost kernel: intel8x0_measure_ac97_clock: measured 58545 usecs
Jul 28 20:01:25 localhost kernel: intel8x0: clocking to 46966
Jul 28 20:01:25 localhost kernel: ACPI: PCI Interrupt Link [APC3] enabled at IRQ 18
Jul 28 20:01:25 localhost kernel: GSI 19 sharing vector 0xC9 and IRQ 19
Jul 28 20:01:25 localhost kernel: ACPI: PCI Interrupt 0000:01:0a.0[A] -> Link [APC3] -> GSI 18 (level, low) -> IRQ 19
Jul 28 20:01:25 localhost kernel: ACPI: PCI Interrupt Link [APCL] enabled at IRQ 20
Jul 28 20:01:25 localhost kernel: GSI 20 sharing vector 0xD1 and IRQ 20
Jul 28 20:01:25 localhost kernel: ACPI: PCI Interrupt 0000:00:02.1[B] -> Link [APCL] -> GSI 20 (level, low) -> IRQ 20
Jul 28 20:01:25 localhost kernel: ehci_hcd 0000:00:02.1: EHCI Host Controller
Jul 28 20:01:25 localhost kernel: ehci_hcd 0000:00:02.1: new USB bus registered, assigned bus number 1
Jul 28 20:01:25 localhost kernel: ehci_hcd 0000:00:02.1: debug port 1
Jul 28 20:01:25 localhost kernel: ehci_hcd 0000:00:02.1: irq 20, io mem 0xfeb00000
Jul 28 20:01:25 localhost kernel: ehci_hcd 0000:00:02.1: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
Jul 28 20:01:25 localhost kernel: usb usb1: configuration #1 chosen from 1 choice
Jul 28 20:01:25 localhost kernel: hub 1-0:1.0: USB hub found
Jul 28 20:01:25 localhost kernel: hub 1-0:1.0: 10 ports detected
Jul 28 20:01:25 localhost kernel: ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[19]  MMIO=[f3004000-f30047ff]  Max Packet=[4096]  IR/IT contexts=[4/8]
Jul 28 20:01:25 localhost kernel: sd 0:0:0:0: Attached scsi generic sg0 type 0
Jul 28 20:01:25 localhost kernel: ACPI: PCI Interrupt Link [APCF] enabled at IRQ 23
Jul 28 20:01:25 localhost kernel: ACPI: PCI Interrupt 0000:00:02.0[A] -> Link [APCF] -> GSI 23 (level, low) -> IRQ 16
Jul 28 20:01:25 localhost kernel: ohci_hcd 0000:00:02.0: OHCI Host Controller
Jul 28 20:01:25 localhost kernel: ohci_hcd 0000:00:02.0: new USB bus registered, assigned bus number 2
Jul 28 20:01:25 localhost kernel: ohci_hcd 0000:00:02.0: irq 16, io mem 0xf3101000
Jul 28 20:01:25 localhost kernel: usb usb2: configuration #1 chosen from 1 choice
Jul 28 20:01:25 localhost kernel: hub 2-0:1.0: USB hub found
Jul 28 20:01:25 localhost kernel: hub 2-0:1.0: 10 ports detected
Jul 28 20:01:25 localhost kernel: usb 1-6: new high speed USB device using ehci_hcd and address 2
Jul 28 20:01:25 localhost kernel: usb 1-6: configuration #1 chosen from 1 choice
Jul 28 20:01:25 localhost kernel: hub 1-6:1.0: USB hub found
Jul 28 20:01:25 localhost kernel: hub 1-6:1.0: 4 ports detected
Jul 28 20:01:25 localhost kernel: ohci_hcd 0000:00:02.0: wakeup
Jul 28 20:01:25 localhost kernel: Non-volatile memory driver v1.2
Jul 28 20:01:25 localhost kernel: usb 1-6.1: new full speed USB device using ehci_hcd and address 5
Jul 28 20:01:25 localhost kernel: usb 1-6.1: configuration #1 chosen from 1 choice

yeah, sorry, that's a known problem which nobody appears to be doing anything about. The expansion of NR_IRQS gobbles all the percpu memory in the kstat structure.

I assume you have a large NR_CPUS? Decreasing it should help.

It was using the Fedora Core 5 default of 255.
Reducing it to 2 makes it work.

So the timer int 0 problem is specific to the machine. I'm guessing that the cheap HP machine using the ATI chipset is one of the boards Andi was talking about.

--
Paul

Sorry I didn't realize it was so easy to trip over. It's on my todo list for sometime in the next couple of days.

Eric

while the fundamental issue is the NR_IRQS problem which we'll fix separately, Steve has a patchset to make percpu room dynamic:

http://lkml.org/lkml/2006/4/14/137

Ingo

That implementation was doomed because it added another dereference that would kill numa implementations. I implemented another version that used page tables, but some people said that this would waste TLB entries. See here

http://lwn.net/Articles/184103/

Perhaps another version that might be beneficial is one that mixes the current approach with this one. That is to have a dynamic page case that would happen only after a default was exhausted. And then we could even warn about it if we don't like that. This way we can warn the user if they don't like having the module's per_cpu files dynamically allocated, which might slow down the system do to another TLB line taken.

-- Steve

Yes, it only happens on a few machines.

That's also a known problem, but a different one.

-Andi

remove-timer-fallback did not reverse cleanly against 2.6.18-rc2-mm1

I tried to patch it up and got it to compile without errors or warnings. The result was a hard freeze early in the boot, so I suspect more is necessary to restore that function.

Paul Fulghum
Microgate Systems, Ltd

Any chance you can post the your reversed version of remove-timer-fallback so we can have a clue about what happened.

Eric

While I'm taking the time to post my attempt at a reveresed patch, it would also be useful for the person who originated the patch to do the same. I'm not an expert on the code in question, so the participation of the original author would help speed things along.

--
Paul

I dropped the patch now - when Andrew resyncs his tree with mine next time it should be fixed.

Still need to figure out the root cause though.

-Andi

OK

I have a machine that exhibits the problem
should you want me to test a patch.

Paul Fulghum
Microgate Systems, Ltd.

This patch makes four needlessly global functions static.

---

 security/selinux/hooks.c |   12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)

@@ -3576,7 +3576,7 @@
 	}
 }
 
-void selinux_sock_graft(struct sock* sk, struct socket *parent)
+static void selinux_sock_graft(struct sock* sk, struct socket *parent)
 {
 	struct inode_security_struct *isec = SOCK_INODE(parent)->i_security;
 	struct sk_security_struct *sksec = sk->sk_security;

@@ -3584,8 +3584,8 @@
 	isec->sid = sksec->sid;
 }
 
-int selinux_inet_conn_request(struct sock *sk, struct sk_buff *skb, 
-					   struct request_sock *req)
+static int selinux_inet_conn_request(struct sock *sk, struct sk_buff *skb, 
+				     struct request_sock *req)
 {
 	struct sk_security_struct *sksec = sk->sk_security;
 	int err;

@@ -3603,7 +3603,8 @@
 	return 0;
 }
 
-void selinux_inet_csk_clone(struct sock *newsk, const struct request_sock *req)
+static void selinux_inet_csk_clone(struct sock *newsk,
+				   const struct request_sock *req)
 {
 	struct sk_security_struct *newsksec = newsk->sk_security;
 

@@ -3614,7 +3615,8 @@
 	   time it will have been created and available. */
 }
 
-void selinux_req_classify_flow(const struct request_sock *req, struct flowi *fl)
+static void selinux_req_classify_flow(const struct request_sock *req,
+				      struct flowi *fl)
 {
 	fl->secid = req->secid;
 }

Andrew Morton napsal(a):

Hello,

I have problems with swsusp again. While suspending, the very last thing kernel writes is 'restoring higmem' and then hangs, hardly. No sysrq response at all. Here is a snapshot of the screen:
http://www.fi.muni.cz/~xslaby/sklad/swsusp_higmem.gif

It's SMP system (HT), higmem enabled (1 gig of ram).

regards,

<a href="http://www.fi.muni.cz/~xslaby/">Jiri Slaby</a>
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8  22A0 32CC 55C3 39D4 7A7E

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Hi,

Most probably it hangs in device_power_up(), so the problem seems to be with one of the devices that are resumed with IRQs off.

Does vanila .18-rc2 work?

Rafael

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Rafael J. Wysocki napsal(a):

Yup, it does.

regards,

<a href="http://www.fi.muni.cz/~xslaby/">Jiri Slaby</a>
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8  22A0 32CC 55C3 39D4 7A7E

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Hm, in fact this may be a problem with any device driver.

Could you please boot the system with init=/bin/bash and try to suspend?

Rafael

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Rafael J. Wysocki napsal(a):

No change.

regards,

<a href="http://www.fi.muni.cz/~xslaby/">Jiri Slaby</a>
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8  22A0 32CC 55C3 39D4 7A7E

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Rafael J. Wysocki napsal(a):

Note 1: 2.6.18-rc1-mm2 was(is) working just fine.
Note 2: when I was going through these -mm diff, the culprit may be radeon driver -- there are some PM changes... Or if you want to go on your own, here is lspci output:
00:00.0 Host bridge: Intel Corporation 82865G/PE/P DRAM Controller/Host-Hub Interface (rev 02)
00:01.0 PCI bridge: Intel Corporation 82865G/PE/P PCI to AGP Controller (rev 02) 00:1d.0 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #1 (rev 02)
00:1d.1 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #2 (rev 02)
00:1d.2 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #3 (rev 02)
00:1d.3 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #4 (rev 02)
00:1d.7 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB2 EHCI Controller (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev c2) 00:1f.0 ISA bridge: Intel Corporation 82801EB/ER (ICH5/ICH5R) LPC Interface Bridge (rev 02)
00:1f.1 IDE interface: Intel Corporation 82801EB/ER (ICH5/ICH5R) IDE Controller (rev 02)
00:1f.2 IDE interface: Intel Corporation 82801EB (ICH5) SATA Controller (rev 02) 00:1f.3 SMBus: Intel Corporation 82801EB/ER (ICH5/ICH5R) SMBus Controller (rev 02) 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon RV250 If [Radeon 9000] (rev 01)
01:00.1 Display controller: ATI Technologies Inc Radeon RV250 [Radeon 9000] (Secondary) (rev 01)
02:02.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 0a) 02:02.1 Input device controller: Creative Labs SB Live! Game Port (rev 0a) 02:05.0 FireWire (IEEE 1394): Texas Instruments TSB43AB23 IEEE-1394a-2000 Controller (PHY/Link)
02:08.0 Ethernet controller: Intel Corporation 82562EZ 10/100 Ethernet Controller (rev 02)

with -n:
00:00.0 0600: 8086:2570 (rev 02)
00:01.0 0604: 8086:2571 (rev 02)
00:1d.0 0c03: 8086:24d2 (rev 02)
00:1d.1 0c03: 8086:24d4 (rev 02)
00:1d.2 0c03: 8086:24d7 (rev 02)
00:1d.3 0c03: 8086:24de (rev 02)
00:1d.7 0c03: 8086:24dd (rev 02)
00:1e.0 0604: 8086:244e (rev c2)
00:1f.0 0601: 8086:24d0 (rev 02)
00:1f.1 0101: 8086:24db (rev 02)
00:1f.2 0101: 8086:24d1 (rev 02)
00:1f.3 0c05: 8086:24d3 (rev 02)
01:00.0 0300: 1002:4966 (rev 01)
01:00.1 0380: 1002:496e (rev 01)
02:02.0 0401: 1102:0002 (rev 0a)
02:02.1 0980: 1102:7002 (rev 0a)
02:05.0 0c00: 104c:8024
02:08.0 0200: 8086:1050 (rev 02)

regards,

<a href="http://www.fi.muni.cz/~xslaby/">Jiri Slaby</a>
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8  22A0 32CC 55C3 39D4 7A7E

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Hi!

Can you try up kernel, no highmem? (mem=512M)?
Pavel

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

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Pavel Machek napsal(a):

It writes then:
p16v: status 0xffffffff, mask 0x00001000, pvoice f7c04a20, use 0 in endless loop when resuming -- after reading from swap.

regards,

<a href="http://www.fi.muni.cz/~xslaby/">Jiri Slaby</a>
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8  22A0 32CC 55C3 39D4 7A7E

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Hi!

Okay, so we have two different problems here.

One is "hang during suspend" with smp/highmem mode, and one is probably driver problem with p16v (whatever it is).

/data/l/linux/sound/pci/emu10k1/irq.c:
snd_printk(KERN_ERR "p16v: status: 0x%08x, mask=0x%08x, pvoice=%p, use=%d\n", status2, mask, pvoice, pvoice->use);

...aha, so you may want to unload emu10k1 for testing.

Since you mention radeon in one of your other mails, just try it in vesafb mode...
Pavel

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

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

That one is "interesting". I've no idea why the restoration of highmem would have caused the box to hang like that. Jiri, could you please post the output of dmesg after a fresh boot?

Yes. Or just don't compile the radeon driver and see what happens.

Rafael

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Rafael J. Wysocki napsal(a):

higmem is ok. ioapic0 is the culprit -- its class resume dies:

        if (cls->resume)
                cls->resume(dev); <----

in __sysdev_resume

Sure, this helped.

Doesn't matter. I do not use graphics (fb) in console -- radeon was not inited at all, it was bad tip.

regards,

<a href="http://www.fi.muni.cz/~xslaby/">Jiri Slaby</a>
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8  22A0 32CC 55C3 39D4 7A7E

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Ah, so my first guess was actually correct. :-)

So, we have two different regressions here.

Please try to revert git-alsa.patch and see if the emu10k1-related problem goes away.

As far as the first one is concerned, the genirq-* patches look suspicious.

Greetings,
Rafael

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Uncc: linux-mm
Cc: alsa-devel
Cc: mingo

[snip]

Wow, it didn't helped, I find out there is a difference between in-kernel and modules version of the driver. When compiled as modules (loaded/unloaded) suspending (and resuming) is working ok (enabled higmem and preempt back -- still no smp), when compiled in-kernel (see the config diff below), it doesn't resume.
@@ -1263,8 +1263,8 @@
CONFIG_SND=y
CONFIG_SND_TIMER=y
CONFIG_SND_PCM=y
-CONFIG_SND_HWDEP=m
-CONFIG_SND_RAWMIDI=m
+CONFIG_SND_HWDEP=y
+CONFIG_SND_RAWMIDI=y
CONFIG_SND_SEQUENCER=y
# CONFIG_SND_SEQ_DUMMY is not set
CONFIG_SND_OSSEMUL=y
@@ -1282,8 +1282,8 @@
#
# Generic devices
#
-CONFIG_SND_AC97_CODEC=m
-CONFIG_SND_AC97_BUS=m
+CONFIG_SND_AC97_CODEC=y
+CONFIG_SND_AC97_BUS=y
# CONFIG_SND_DUMMY is not set
# CONFIG_SND_VIRMIDI is not set
# CONFIG_SND_MTPAV is not set
@@ -1347,7 +1347,7 @@
# CONFIG_SND_INDIGO is not set
# CONFIG_SND_INDIGOIO is not set
# CONFIG_SND_INDIGODJ is not set
-CONFIG_SND_EMU10K1=m
+CONFIG_SND_EMU10K1=y
# CONFIG_SND_EMU10K1X is not set
# CONFIG_SND_ENS1370 is not set
# CONFIG_SND_ENS1371 is not set

Hmm, what to do?

regards,

<a href="http://www.fi.muni.cz/~xslaby/">Jiri Slaby</a>
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8  22A0 32CC 55C3 39D4 7A7E

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Hi!

Yes, that sometimes happens. You could work around it by catching PM_EVENT_PRETHAW message and resetting the hardware in this case. Or just fix the resume routine.
Pavel

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

I would try to revert them altogether and see what happens. If that doesn't help, the only thing that comes to mind is to carry out a binary search for the offending patch. :-(

Greetings,
Rafael

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

At Sun, 30 Jul 2006 13:34:38 +0200,

Hm, do we need such inconsitent behavior? I mean, for most drivers, it doesn't matter whether it's built-in or a module: simply shutdown at suspend, and initialize at resume.

Takashi

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Hi!

That's of course the other (and better) solution.
Pavel

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

The p16v chip is present on some creative sound cards, so this is an ALSA snd-emu10k1 driver that is causing the endless loop. I will change the code to force it to recover from the unexpected status 0xffffffff value. The recovery will just consist of reducing the message to a single message, instead of an endless loop. That value is never present during normal operations, and the only case of it occurring that I know about was during a pcmcia card unplug. If it occurs during insertion or power resume, then I will have to think about some work around. Is there any reason that an IRQ routine will be called before the associated PCI IOPORTs have been configured. I did not think it was the responsibility of the driver to redo all the initialisation PCI calls to claim DMA and IOPORTs at power resume. To me it seems that the IRQ routine is being called before PCI DMA and IOPORTs have been initialised.

James

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

After rebooting "normally" through init 6, or by hitting sysrq-b, the backlight won't come back on and BIOS seems to hang at POST or something. After a power cycle, it runs the extensive POST instead of the quick one. Same goes for -rc1-mm2, btw. kexec runs fine, as long as I provide the "implicit" initramfs file required by the newer -mm releases at load time.

Any recent changes related to the way i386 machines are kicked to reboot?

In case anyone needs any info, I'll provide that asap, but right now I don't have a clue at all. Afraid I cannot test on my workstation, since my screen died and I don't have a replacement/cannot afford a purchase right now.

TIA,
Chris

Just had this come out on the console:

(x86_64 - maybe unwinder related?)

Jul 31 16:35:01 tornado kernel: kjournald starting.  Commit interval 5 seconds
Jul 31 16:35:01 tornado kernel: EXT3 FS on sdb1, internal journal
Jul 31 16:35:01 tornado kernel: EXT3-fs: mounted filesystem with ordered data mode.
Jul 31 16:35:01 tornado kernel: php[28644]: segfault at 00007fff064edfe8 rip 0000003852a718a8 rsp 00007fff064edfd0 error 6
Jul 31 16:35:01 tornado kernel: general protection fault: 0000 [1] SMP
Jul 31 16:35:01 tornado kernel: last sysfs file: /block/fd0/dev
Jul 31 16:35:01 tornado kernel: CPU 1
Jul 31 16:35:01 tornado kernel: Modules linked in: hidp rfcomm l2cap bluetooth ipv6 ip_gre iptable_filter iptable_nat ip_nat i
p_conntrack nfnetlink iptable_mangle ip_tables binfmt_misc i2c_i801 serio_raw iTCO_wdt
Jul 31 16:35:01 tornado kernel: Pid: 15189, comm: nagios Not tainted 2.6.18-rc2-mm1 #2
Jul 31 16:35:01 tornado kernel: RIP: 0010:[<ffffffff8028f1d1>] [<ffffffff8028f1d1>] notifier_call_chain+0x1e/0x45
Jul 31 16:35:01 tornado kernel: RSP: 0018:ffff810020d35d58  EFLAGS: 00010202
Jul 31 16:35:01 tornado kernel: RAX: 6b6b6b6b6b6b6b6b RBX: ffff81003913f100 RCX: 6b6b6b6b6b6b6b6b
Jul 31 16:35:01 tornado kernel: RDX: ffff81003913f100 RSI: 0000000000000001 RDI: ffff81001fd8cec0
Jul 31 16:35:01 tornado kernel: RBP: ffff810020d35d78 R08: 0000000000000000 R09: 0000000000000001
Jul 31 16:35:01 tornado kernel: R10: 0000000000000001 R11: 0000000000000001 R12: ffff81003913f100
Jul 31 16:35:01 tornado kernel: R13: 0000000000000001 R14: ffff81003913f100 R15: ffff81003913f100
Jul 31 16:35:01 tornado kernel: FS:  00002b1be57ae450(0000) GS:ffff81003f6eb430(0000) knlGS:0000000000000000
Jul 31 16:35:01 tornado kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
Jul 31 16:35:01 tornado kernel: CR2: 0000000000884ab0 CR3: 0000000034634000 CR4: 00000000000006e0
Jul 31 16:35:01 tornado kernel: Process nagios (pid: 15189, threadinfo ffff810020d34000, task ffff81002ff8c0c0)
Jul 31 16:35:01 tornado kernel: Stack:  ffff810020d35d88 ffff81003913f100 0000000000000001 0000000001200011
Jul 31 16:35:01 tornado kernel:  ffff810020d35d88 ffffffff8028f226 ffff810020d35da8 ffffffff8028f61f
Jul 31 16:35:01 tornado kernel:  ffff810020d36000 ffff81002ff8c0c0 ffff810020d35e78 ffffffff8021eafc
Jul 31 16:35:01 tornado kernel: Call Trace:
Jul 31 16:35:01 tornado kernel:  [<ffffffff8028f226>] raw_notifier_call_chain+0x9/0xb
Jul 31 16:35:01 tornado kernel:  [<ffffffff8028f61f>] notify_watchers+0x64/0x69
Jul 31 16:35:01 tornado kernel:  [<ffffffff8021eafc>] copy_process+0x4dc/0x15c0
Jul 31 16:35:01 tornado kernel:  [<ffffffff80231867>] do_fork+0xf7/0x210
Jul 31 16:35:01 tornado kernel:  [<ffffffff802692f7>] sys_clone+0x23/0x25
Jul 31 16:35:01 tornado kernel:  [<ffffffff8025f7af>] ptregscall_common+0x67/0xac
Jul 31 16:35:01 tornado kernel: DWARF2 unwinder stuck at ptregscall_common+0x67/0xac
Jul 31 16:35:01 tornado kernel: Leftover inexact backtrace:
Jul 31 16:35:01 tornado kernel:
Jul 31 16:35:01 tornado kernel:
Jul 31 16:35:02 tornado kernel: Code: 48 8b 59 08 4c 89 e2 4c 89 ee 48 89 cf ff 11 66 85 c0 78 08
Jul 31 16:35:02 tornado kernel: RIP  [<ffffffff8028f1d1>] notifier_call_chain+0x1e/0x45
Jul 31 16:35:02 tornado kernel:  RSP <ffff810020d35d58>

I've applied only one patch to the generic -rc2-mm1 that is in the newer -mm - the x86_64-unwinder-fix.patch. That fixed the problem I had with the backtraces repeating over and over until the kernel panicked.

Reuben

Please watch the wrodwrapping - it makes things harder to read.

That looks like the task-watchers versus delay-accounting bug. The word on the street is "change WATCH_TASK_CLONE to WATCH_TASK_INIT in the delayacct_watch_task function", but nobody has done a patch.

I'm angling to drop the task-watchers patches from next -mm.

I think Jan has a fix for that in the works.

OK, thanks. But the "DWARF2 unwinder stuck" problem remains.

It will be a long time until it is all solved correctly, because it requires adding correct CFI to a code a lot all over. I estimate it will need several major releases at least.

-Andi

This means people who observed a compile error will now have the DVB support silently removed from their kernel.

Please replace it with the patch below.

cu
Adrian

<-- snip -->

DVB_CORE=y, I2C=n resulted in the following compile error reported by Bernd Buschinski in kernel Bugzilla #6843:

<-- snip -->

...
LD .tmp_vmlinux1
drivers/built-in.o: In function `dvb_pll_sleep':
dvb-pll.c:(.text+0x80020): undefined reference to i2c_transfer' drivers/built-in.o: In function dvb_pll_set_params':
dvb-pll.c:(.text+0x80326): undefined reference to `i2c_transfer'
make: *** [.tmp_vmlinux1] Error 1

<-- snip -->

@@ -1,6 +1,7 @@
 config DVB_CORE
 	tristate "DVB Core Support"
 	depends on DVB
+	select I2C
 	select CRC32
 	help
 	  DVB core utility functions for device handling, software fallbacks etc.

DVB_CORE should never depend on I2C, the reason being DVB_CORE does not use anything of I2C but, the drivers which depend on I2C should be made depend on I2C. That would be the right way to go.

Manu

This has been fixed differently already. dvb-core.ko doesn't actually use I2C, only dvb-pll.ko does. Now the dvb-pll.ko module is no longer turned on by DVB_CORE, but under a new option, DVB_PLL. That option depends on I2C.

Hmm...
Em Qui, 2006-08-03 às 09:30 -0700, Trent Piepho escreveu:

I think Adrian's idea of selecting I2C, instead of depend on would be a better approach for DVB_PLL.

Cheers,
Mauro.