LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* 2.6.18-rc6-mm1
@ 2006-09-08  8:13 Andrew Morton
  2006-09-08 11:49 ` 2.6.18-rc6-mm1 Andy Whitcroft
                   ` (10 more replies)
  0 siblings, 11 replies; 114+ messages in thread
From: Andrew Morton @ 2006-09-08  8:13 UTC (permalink / raw)
  To: linux-kernel


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

- autofs4 mounting of NFS is still sick.



Boilerplate:

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

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

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

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

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

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

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

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

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

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


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

 git trees

-zvc-overstep-counters.patch
-zvc-scale-thresholds-depending-on-the-size-of-the-system.patch
-md-fix-issues-with-referencing-rdev-in-md-raid1.patch
-synclink_gt-fix-receive-tty-error-handling.patch
-fix-faulty-hpet-clocksource-usage-fix-for-bug-7062.patch
-task-delay-accounting-fixes.patch
-xtensa-ptrace-exit_zombie-fix.patch
-x86-increase-max_mp_busses-on-default-arch.patch
-exit-early-in-floppy_init-when-no-floppy-exists.patch
-sbc8360-module_param-permission-fixes.patch
-kerneldoc-for-handle_bad_irq.patch
-ipmi-fix-occasional-oops-on-module-unload.patch
-schedule-obsolete-oss-drivers-for-removal-2nd-round.patch
-md-work-around-mempool_alloc-bio_alloc_bioset-deadlocks.patch
-powerpc-more-via-pmu-backlight-fixes.patch
-powerpc-fix-powermac-irq-handling-bug.patch
-alsa-ac97-correct-some-mic-mixer-elements.patch
-sgiioc4-fixup-use-of-mmio-ops.patch
-fix-numa-interleaving-for-huge-pages.patch
-manage-jbd-its-own-slab-fix.patch
-backlight-last-round-of-fixes.patch
-scsi-improve-endian-handling-in-lsi-fusion-firmware-mpt_downloadboot.patch
-agph-constify-struct-agp_bridge_dataversion.patch
-ks0127-wire-up-i2c_add_driver-return-value.patch
-amso1100-build-fix.patch
-forcedeth-decouple-vlan-and-rx-checksum-dependency.patch
-gregkh-usb-samsung-unusual-floppy.patch
-gregkh-usb-hid-core.c-adds-all-gtco-calcomp-digitizers-and-interwrite-school-products-to-blacklist.patch
-gregkh-usb-usb-gadget-g_ether-spinlock-recursion-fix.patch
-gregkh-usb-uhci-don-t-stop-at-an-iso-error.patch
-gregkh-usb-usb-storage-remove-the-finecam3-unusual_devs-entry.patch
-gregkh-usb-usb-storage-unusual_devs.h-for-sony-ericsson-m600i.patch
-gregkh-usb-usb-rtl8150_disconnect-needs-tasklet_kill.patch
-gregkh-usb-usb-support-for-elecom-ld-usb20-in-pegasus.patch
-gregkh-usb-uhci-hcd-fix-list-access-bug.patch
-gregkh-usb-usb-add-all-wacom-device-to-hid-core.c-blacklist.patch
-gregkh-usb-adutux-fix-printk-format-warnings.patch
-kthread-airoc.patch
-x86_64-mm-x86-nmi-fix.patch
-x86_64-mm-x86-nmi-fix-2.patch
-x86_64-mm-rwlock-cleanup.patch
-x86_64-mm-cleanup-spinlock.patch
-x86_64-mm-i386-early-exception.patch
-x86_64-mm-rwlock-cleanup-fix.patch
-x86_64-mm-remove-e820-fallback-fix.patch
-mm-x86_64-mm-generic-getcpu-syscall-tweaks.patch
-hot-add-mem-x86_64-acpi-motherboard-fix.patch
-x86-allow-a-kernel-to-not-be-in-ring-0.patch
-x86-allow-a-kernel-to-not-be-in-ring-0-tidy.patch
-x86-replace-sensitive-instructions-with-macros.patch
-x86-use-asm-offsets-for-offsets-into-struct-pt_regs.patch
-pm-add-sys-power-documentation-to-documentation-abi.patch
-device_suspend-resume-may-sleep.patch
-remove-open_max-check-from-poll-syscall.patch
-ide-hpa-resume-fix.patch

 Merged into mainline or a subsystem tree.

+use-the-correct-restart-option-for-futex_lock_pi.patch
+optical-proc-ide-media.patch
+sh-fix-fpn_start-typo.patch
+sis5513-add-sis-south-bridge-id-0x966.patch
+ext3_getblk-should-handle-hole-correctly.patch
+invalidate_complete_page-race-fix.patch
+nfs-large-non-page-aligned-direct-i-o-clobbers-memory.patch

 2.6.18 queue.

+acpi-check-if-parent-is-on-dock.patch
+acpi-add-removable-drive-bay-support.patch

 ACPI

+gregkh-driver-pm-update-docs-for-writing-...-power-state.patch
+gregkh-driver-pm-add-kconfig-option-for-deprecated-...-power-state-files.patch
+gregkh-driver-pm-schedule-sys-devices-...-power-state-for-removal.patch
+gregkh-driver-pm-no-suspend_prepare-phase.patch
+gregkh-driver-pm-add-sys-power-documentation-to-documentation-abi.patch
+gregkh-driver-pm-device_suspend-resume-may-sleep.patch
+gregkh-driver-pm-platform_bus-and-late_suspend-early_resume.patch
-gregkh-driver-iio.patch
+gregkh-driver-uio.patch

 Driver tree updates

+gregkh-i2c-i2c-dev-attach-detach-adapter-cleanups.patch
+gregkh-i2c-i2c-chips-__must_check-fixes.patch
+gregkh-i2c-i2c-isa-return-attach_adapter.patch
+gregkh-i2c-i2c-algo-bit-cleanups.patch
+gregkh-i2c-i2c-algo-pcf-kill-mdelay.patch
+gregkh-i2c-i2c-drop-useless-masking.patch
+gregkh-i2c-i2c-warn-on-failed-client-attach.patch
+gregkh-i2c-i2c-viapro-add-VT8251-VT8237A.patch
+gregkh-i2c-i2c-isa-restore-driver-owner.patch
+gregkh-i2c-i2c-constify-i2c_algorithm.patch
+gregkh-i2c-i2c-algos-constify-i2c_algorithm.patch
+gregkh-i2c-i2c-busses-constify-i2c_algorithm.patch
+gregkh-i2c-i2c-drop-slave-functions.patch

 I2C tree updates

-ieee1394-sbp2-workaround-for-write-protect-bit-of.patch
+ieee1394-nodemgr-fix-rwsem-recursion.patch
+ieee1394-nodemgr-grab-classsubsysrwsem-in.patch
+ieee1394-sbp2-dont-prefer-mode-sense-10.patch
+ieee1394-ohci1394-fix-endianess-bug-in-debug-message.patch
+ieee1394-ohci1394-more-obvious-endianess-handling.patch

 ieee1394 tree updates

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

 Dropped

+input-i8042-disable-keyboard-port-when-panicking-and-blinking.patch
+i8042-activate-panic-blink-only-in-x.patch

 input updates

+fail-kernel-compilation-in-case-of-unresolved-symbols-v2.patch

 kbuild update

+libata-ignore-cfa-signature-while-sanity-checking-an-atapi-device.patch
+kerneldoc-error-on-ata_piixc.patch
+libata-add-40pin-short-cable-support-honour-drive-fix.patch
+2-of-2-jmicron-driver-plumbing-and-quirk-cleanup.patch

 sata/pata updates

+fix-possible-null-ptr-deref-in-forcedeth.patch

 netdev fix

-gregkh-pci-msi-01-merge_msi_disabling_quirks.patch
-gregkh-pci-msi-02-factorize_pci_msi_supported.patch
-gregkh-pci-msi-03-add_pci_device_exp_type.patch
-gregkh-pci-msi-04-use_root_chipset_dev_no_msi_instead_of_pci_bus_flags.patch
-gregkh-pci-msi-05-add_no_msi_to_sysfs.patch
-gregkh-pci-msi-06-rename_pci_cap_id_ht_irqconf.patch
-gregkh-pci-msi-07-check_hypertransport_msi_capabilities.patch
-gregkh-pci-msi-08-drop_pci_msi_quirk.patch
-gregkh-pci-msi-09-drop_pci_bus_flags.patch
+gregkh-pci-msi-cleanup-existing-msi-quirks.patch
+gregkh-pci-msi-factorize-common-code-in-pci_msi_supported.patch
+gregkh-pci-msi-export-the-pci_bus_flags_no_msi-flag-in-sysfs.patch
+gregkh-pci-msi-blacklist-pci-e-chipsets-depending-on-hypertransport-msi-capability.patch
+gregkh-pci-pci-hotplug-cleanup-pcihp-skeleton-code.patch

 PCI tree updates

+fix-gregkh-pci-msi-blacklist-pci-e-chipsets-depending-on-hypertransport-msi-capability.patch

 Fix it

-pci-quirk_via_irq-behaviour-change.patch
+via-irq-quirk-behaviour-change.patch

 Updated

+git-scsi-misc-nlmsg_multicast-fix.patch

 SCSI fixes

+gregkh-usb-usb-hid-core.c-fix-duplicate-usb_device_id_gtco_404.patch
+gregkh-usb-usb-support-for-usb20svga-wh-usb20svga-dg.patch
+gregkh-usb-usb-new-device-id-for-ftdi_sio-usb-serial-driver.patch
+gregkh-usb-usb-usbtouchscreen-fix-itm-data-reading.patch
+gregkh-usb-usb-phidgets-should-check-create_device_file-return-value.patch
+gregkh-usb-usb-remove-struct-usb_operations.patch
+gregkh-usb-usbcore-add-flag-for-whether-a-host-controller-uses-dma.patch
+gregkh-usb-usbcore-trim-down-usb_bus-structure.patch
+gregkh-usb-usbmon-don-t-call-mon_dmapeek-if-dma-isn-t-being-used.patch
+gregkh-usb-usb-ethernet-gadget-avoids-zlps-for-musb_hdrc.patch
+gregkh-usb-usb-ehci-whitespace-fixes.patch
+gregkh-usb-gadgetfs-patch-for-ep0out.patch
+gregkh-usb-usb-replace-kernel_thread-with-kthread_run-in-libusual.c.patch
+gregkh-usb-usb-usb-serial-gadget-smp-related-bug.patch
+gregkh-usb-usb-net2280-update-dma-buffer-allocation.patch
+gregkh-usb-usb-ohci-at91-two-one-liners.patch
+gregkh-usb-usb-usb-input-usbmouse.c-whitespace-cleanup.patch
+gregkh-usb-usb-introduce-usb_reenumerate_device.patch
+gregkh-usb-usbcore-store-each-usb_device-s-level-in-the-tree.patch
+gregkh-usb-usbcore-add-autosuspend-autoresume-infrastructure.patch
+gregkh-usb-usbcore-non-hub-specific-uses-of-autosuspend.patch
+gregkh-usb-usbcore-remove-usb_suspend_root_hub.patch
+gregkh-usb-usb-moschip-7840-usb-serial-driver.patch

 USB tree updates

+fix-gregkh-usb-usbcore-add-autosuspend-autoresume-infrastructure.patch

 Fix it.

+usb-storage-unusual_devsh-entry-for-sony.patch

 USB fix

-git-supertrak.patch
-git-supertrak-fixup.patch
-stex-adjust-command-timeout-in-slave_config-routine.patch
-stex-use-more-efficient-method-for-unload-shutdown-flush.patch

 git-supertrak was moved into the scsi tree

+x86_64-mm-defconfig-update.patch
+x86_64-mm-x86-nmi-watchdog-suspend.patch
+x86_64-mm-rwlock-to-asm.patch
+x86_64-mm-i386-remove-const-rwlock.patch
+x86_64-mm-spinlock-cleanup.patch
+x86_64-mm-i386-spinlock-cleanup.patch
+x86_64-mm-stacktrace-terminate.patch
+x86_64-mm-i386-stacktrace-terminate.patch
+x86_64-mm-i386-backtrace-ebp-fallback.patch
+x86_64-mm-stack-protector-annotate-the-pda-offsets.patch
+x86_64-mm-stack-protector-add-the-kconfig-option.patch
+x86_64-mm-stack-protector-add-canary.patch
+x86_64-mm-stack-protector-add_stack_chk_fail.patch
+x86_64-mm-stack-protector-cflags.patch
+x86_64-mm-fix-irqcount-comment.patch
+x86_64-mm-pda-use-c-output-modifier.patch
+x86_64-mm-type-checking-for-write_pda.patch
+x86_64-mm-fix-pda-warning.patch
+x86_64-mm-i386-replace-sensitive-instructions.patch
+x86_64-mm-i386-allow-a-kernel-to-not-be-in-ring0.patch
+x86_64-mm-i386-pda-asm-offsets.patch
+x86_64-mm-i386-pda-basics.patch
+x86_64-mm-i386-pda-init-pda.patch
+x86_64-mm-i386-pda-use-gs.patch
+x86_64-mm-i386-pda-user-abi.patch
+x86_64-mm-i386-pda-vm86.patch
+x86_64-mm-i386-pda-smp-processorid.patch
+x86_64-mm-i386-pda-current.patch
+x86_64-mm-i386-early-fault.patch
+x86_64-mm-insert-ioapics-and-local-apic-into-resource-map.patch
+x86_64-mm-acpi-add-hpet-into-resource-map.patch
+x86_64-mm-copy-user-nocache.patch
+x86_64-mm-copy-user-zeroing.patch
+x86_64-mm-copy-user-mustcheck.patch
+x86_64-mm-copy-user-style.patch
+x86_64-mm-pda-style.patch
+x86_64-mm-remove-mmx.patch
+x86_64-mm-init-per-cpu-data-again.patch
+x86_64-mm-core-2-oprofile-identification.patch
+x86_64-mm-i386-kexec-not-experimental.patch
+x86_64-mm-kexec-not-experimental.patch

 x86_64 tree updates

+fix-x86_64-mm-i386-backtrace-ebp-fallback.patch
+fix-x86_64-mm-i386-pda-smp-processorid.patch
+fix-x86_64-mm-spinlock-cleanup.patch

 fix bugs in it.

-git-cryptodev.patch
-git-cryptodev-fixup.patch
-git-cryptodev-fixup-2.patch
-git-cryptodev-broke-geode-aes.patch

 git-cryptodev is suffering a reject storm.

+mm-tracking-shared-dirty-pages-nommu-fix-2.patch

 Fix mm-tracking-shared-dirty-pages.patch

+account-for-memmap-and-optionally-the-kernel-image-as-holes-fix.patch
+account-for-holes-that-are-outside-the-range-of-physical-memory.patch
+allow-an-arch-to-expand-node-boundaries.patch

 Fix mm patches in -mm.

+hugepages-use-page_to_nid-rather-than-traversing-zone-pointers.patch
+numa-add-zone_to_nid-function.patch

 More MM updates

+nommu-check-vma-protections.patch
+nommu-make-futexes-work-under-nommu-conditions.patch
+nommu-make-futexes-work-under-nommu-conditions-doc.patch
+nommu-move-the-fallback-arch_vma_name-to-a-sensible-place.patch

 NOMMU updates

-split-i386-and-x86_64-ptraceh.patch
-uml-use-ptrace-abih-instead-of-ptraceh.patch

 These broke.

+pm-make-it-possible-to-disable-console-suspending-fix-2.patch

 Fix pm-make-it-possible-to-disable-console-suspending.patch

+x86-microcode-dont-check-the-size.patch

 Fix x86-microcode-add-sysfs-and-hotplug-support.patch some more.

+fix-conflict-with-the-is_init-identifier-on-parisc.patch

 Preparation for pidspace-is_init.patch

+lockdep-core-add-enable-disable_irq_irqsave-irqrestore-apis-frv-fix.patch

 Fix lockdep-core-add-enable-disable_irq_irqsave-irqrestore-apis.patch

+oom-dont-kill-current-when-another-oom-in-progress.patch

 Fix oom_kill_task-cleanup-mm-checks.patch

+cpuset-top_cpuset-tracks-hotplug-changes-to-node_online_map-fix-2.patch

 Fix cpuset-top_cpuset-tracks-hotplug-changes-to-node_online_map.patch some
 more.

+enforce-rlimit_nofile-in-poll.patch
+generic-infrastructure-for-acls.patch
+generic-infrastructure-for-acls-update.patch
+access-control-lists-for-tmpfs.patch
+access-control-lists-for-tmpfs-cleanup.patch
+ext3-wrong-error-behavior.patch
+stop_machinec-copyright.patch
+build-sound-sound_firmwarec-only-for-oss.patch
+build-sound-sound_firmwarec-only-for-oss-doc.patch
+rtc-more-xstp-vdet-support-for-rtc-rs5c348-driver.patch
+generic_serial-remove-private-decoding-of-baud-rate-bits.patch
+istallion-remove-private-baud-rate-decoding-which-is.patch
+specialix-remove-private-speed-decoding.patch
+fix-locking-for-tty-drivers-when-doing-urgent-characters.patch
+audit-accounting-tty-locking.patch
+documentation-submittingdrivers-minor-update.patch
+clean-up-expand_fdtable-and-expand_files-take-2.patch
+expand_fdtable-remove-pointless-unlocklock.patch
+kcore-elf-note-namesz-field-fix.patch
+lockdep-core-improve-the-lock-chain-hash.patch
+linux-kernel-dump-test-module.patch

 Misc.

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

 Folded into kill-wall_jiffies.patch

+generic-ioremap_page_range-implementation-fix.patch
+generic-ioremap_page_range-implementation-nommu-fix.patch

 Fix generic-ioremap_page_range-implementation.patch

+proc-readdir-race-fix-take-3.patch
+proc-readdir-race-fix-take-3-race-fix.patch
+proc-readdir-race-fix-take-3-fix-1.patch
+proc-readdir-race-fix-take-3-fix-2.patch

 Fix /proc reading races.

+kprobes-handle-symbol-resolution-when-modulesymbol-is-specified.patch
+kprobes-handle-symbol-resolution-when-modulesymbol-is-specified-tidy.patch

 kprobes updates

+knfsd-lockd-introduce-nsm_handle-fix.patch

 Fix knfsd-lockd-introduce-nsm_handle.patch

+knfsd-lockd-introduce-nsm_handle-sem2mutex.patch
+knfsd-svcrpc-gss-factor-out-some-common-wrapping-code.patch
+knfsd-svcrpc-gss-fix-failure-on-svc_denied-in-integrity-case.patch
+knfsd-svcrpc-use-consistent-variable-name-for-the-reply-state.patch
+knfsd-nfsd4-refactor-exp_pseudoroot.patch
+knfsd-nfsd4-clean-up-exp_pseudoroot.patch
+knfsd-nfsd4-acls-relax-the-nfsv4-posix-mapping.patch
+knfsd-nfsd4-acls-fix-inheritance.patch
+knfsd-nfsd4-acls-simplify-nfs4_acl_nfsv4_to_posix-interface.patch
+knfsd-nfsd4-acls-fix-handling-of-zero-length-acls.patch

 nfsd updates

+sched-fixing-wrong-comment-for-find_idlest_cpu.patch

 sched comment fix

+numa-add-zone_to_nid-function-swap_prefetch.patch

 Fix swap-prefetch for other patches in -mm.

+ecryptfs-inode-numbering-fixes.patch

 ecryptfs update

+namespaces-incorporate-fs-namespace-into-nsproxy-whitespace.patch

 Clean up namespaces-incorporate-fs-namespace-into-nsproxy.patch

+rename-the-provided-execve-functions-to-kernel_execve-fixes.patch

 Fix rename-the-provided-execve-functions-to-kernel_execve.patch

+provide-kernel_execve-on-all-architectures-fix-2.patch
+provide-kernel_execve-on-all-architectures-fix-3.patch
+provide-kernel_execve-on-all-architectures-m68knommu-fix.patch
+avr32-implement-kernel_execve.patch

 Fix provide-kernel_execve-on-all-architectures.patch some more.


+proc-make-the-generation-of-the-self-symlink-table-driven.patch
+proc-factor-out-an-instantiate-method-from-every-lookup-method.patch
+proc-remove-the-hard-coded-inode-numbers.patch
+proc-merge-proc_tid_attr-and-proc_tgid_attr.patch
+proc-use-pid_task-instead-of-open-coding-it.patch

 /proc cleanups

+reiser4-possible-cleanups-2.patch

 reiser4 fix

+ide-fix-crash-on-repeated-reset.patch

 IDE fix

+pci_module_init-convertion-in-ata_genericc.patch
+pci_module_init-convertion-in-ata_genericc-fix.patch
+pci_module_init-convertion-in-amso1100-driver.patch
+pci_module_init-convertion-for-k8_edacc.patch
+pci_module_init-convertion-in-the-legacy-megaraid-driver.patch
+nozomi-pci_module_init-conversion.patch
+pci_module_init-convertion-in-olympicc.patch
+pci_module_init-conversion-for-pata_pdc2027x.patch
+pci_module_init-convertion-in-tmscsimc.patch
+mark-pci_module_init-deprecated.patch

 PCI cleanups




All 1835 patches:

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



^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: 2.6.18-rc6-mm1
  2006-09-08  8:13 2.6.18-rc6-mm1 Andrew Morton
@ 2006-09-08 11:49 ` Andy Whitcroft
  2006-09-08 12:07 ` 2.6.18-rc6-mm1 Frederik Deweerdt
                   ` (9 subsequent siblings)
  10 siblings, 0 replies; 114+ messages in thread
From: Andy Whitcroft @ 2006-09-08 11:49 UTC (permalink / raw)
  To: James Bottomley; +Cc: Andrew Morton, linux-kernel, Steve Fox

Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc6/2.6.18-rc6-mm1/
> 
> - autofs4 mounting of NFS is still sick.
> 
> 
> 
> Boilerplate:
> 
> - See the `hot-fixes' directory for any important updates to this patchset.
> 
> - To fetch an -mm tree using git, use (for example)
> 
>   git fetch git://git.kernel.org/pub/scm/linux/kernel/git/smurf/linux-trees.git v2.6.16-rc2-mm1
> 
> - -mm kernel commit activity can be reviewed by subscribing to the
>   mm-commits mailing list.
> 
>         echo "subscribe mm-commits" | mail majordomo@vger.kernel.org
> 
> - If you hit a bug in -mm and it is not obvious which patch caused it, it is
>   most valuable if you can perform a bisection search to identify which patch
>   introduced the bug.  Instructions for this process are at
> 
>         http://www.zip.com.au/~akpm/linux/patches/stuff/bisecting-mm-trees.txt
> 
>   But beware that this process takes some time (around ten rebuilds and
>   reboots), so consider reporting the bug first and if we cannot immediately
>   identify the faulty patch, then perform the bisection search.
> 
> - When reporting bugs, please try to Cc: the relevant maintainer and mailing
>   list on any email.
> 
> - Semi-daily snapshots of the -mm lineup are uploaded to
>   ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/mm/ and are announced on
>   the mm-commits list.
> 
> 
>  origin.patch
>  git-acpi.patch
>  git-alsa.patch
>  git-agpgart.patch
>  git-arm.patch
>  git-block.patch
>  git-cifs.patch
>  git-cpufreq.patch
>  git-drm.patch
>  git-dvb.patch
>  git-geode.patch
>  git-gfs2.patch
>  git-ia64.patch
>  git-ieee1394.patch
>  git-infiniband.patch
>  git-input.patch
>  git-intelfb.patch
>  git-kbuild.patch
>  git-libata-all.patch
>  git-lxdialog.patch
>  git-mmc.patch
>  git-mtd.patch
>  git-netdev-all.patch
>  git-net.patch
>  git-nfs.patch
>  git-ocfs2.patch
>  git-parisc.patch
>  git-pcmcia.patch
>  git-powerpc.patch
>  git-r8169.patch
>  git-s390.patch
>  git-scsi-misc.patch

Seems that -mm fails to compile when CONFIG_MODULES is set but
CONFIG_MODULE_UNLOAD is not.

   LD      .tmp_vmlinux1
  drivers/built-in.o(.text+0x47724): In function `scsi_device_put':
  drivers/scsi/scsi.c:887: undefined reference to `module_refcount'

Config fragment:
  CONFIG_MODULES=y
  # CONFIG_MODULE_UNLOAD is not set
  # CONFIG_MODULE_SRCVERSION_ALL is not set

This seems to be caused by changes in the scsi-misc git tree, from the
changes in the two commits below:

  [SCSI] sd: fix cache flushing on module removal
				(and individual device removal)
  [SCSI] fix up non-modular SCSI

  85b6c720b0931101c8bcc3a5abdc2b8514b0fb4b
  f479ab87936563a286b8aa0e39003c40fa31c6da

It looks very much like module_refcount is really not meant to be an
external interface, cirtainly its not available in all module
'load/unload modes'.

-apw

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: 2.6.18-rc6-mm1
  2006-09-08  8:13 2.6.18-rc6-mm1 Andrew Morton
  2006-09-08 11:49 ` 2.6.18-rc6-mm1 Andy Whitcroft
@ 2006-09-08 12:07 ` Frederik Deweerdt
  2006-09-08 12:16 ` [patch -mm] s390: fix save_stack_trace Heiko Carstens
                   ` (8 subsequent siblings)
  10 siblings, 0 replies; 114+ messages in thread
From: Frederik Deweerdt @ 2006-09-08 12:07 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel

On Fri, Sep 08, 2006 at 01:13:17AM -0700, Andrew Morton wrote:
> 
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc6/2.6.18-rc6-mm1/
> 
Hi,

2.6.18-rc6-mm1 fails to build on x86 with !CONFIG_SMP with the following
message:
  CHK     include/linux/version.h
  CHK     include/linux/utsrelease.h
  CHK     include/linux/compile.h
  UPD     include/linux/compile.h
  CC      init/version.o
  LD      init/built-in.o
  CC      arch/i386/kernel/cpu/common.o
arch/i386/kernel/cpu/common.c: In function `init_gdt':
arch/i386/kernel/cpu/common.c:667: warning: implicit declaration of function `early_smp_processor_id'
  LD      arch/i386/kernel/cpu/built-in.o
  LD      arch/i386/kernel/built-in.o
  GEN     .version
  CHK     include/linux/compile.h
  UPD     include/linux/compile.h
  CC      init/version.o
  LD      init/built-in.o
  LD      .tmp_vmlinux1
arch/i386/kernel/built-in.o: In function `init_gdt':
arch/i386/kernel/cpu/common.c:667: undefined reference to `early_smp_processor_id'
arch/i386/kernel/built-in.o: In function `cpu_init':
arch/i386/kernel/cpu/common.c:737: undefined reference to `early_smp_processor_id'
make: *** [.tmp_vmlinux1] Error 1

We need to include <asm/smp.h> to define early_smp_processor_id().

Regards,
Frederik


Signed-off-by: Frederik Deweerdt <frederik.deweerdt@gmail.com>

--- arch/i386/kernel/cpu/common.c~	2006-09-08 11:57:09.000000000 +0200
+++ arch/i386/kernel/cpu/common.c	2006-09-08 11:57:24.000000000 +0200
@@ -13,6 +13,7 @@
 #include <asm/mmu_context.h>
 #include <asm/mtrr.h>
 #include <asm/mce.h>
+#include <asm/smp.h>
 #ifdef CONFIG_X86_LOCAL_APIC
 #include <asm/mpspec.h>
 #include <asm/apic.h>

^ permalink raw reply	[flat|nested] 114+ messages in thread

* [patch -mm] s390: fix save_stack_trace
  2006-09-08  8:13 2.6.18-rc6-mm1 Andrew Morton
  2006-09-08 11:49 ` 2.6.18-rc6-mm1 Andy Whitcroft
  2006-09-08 12:07 ` 2.6.18-rc6-mm1 Frederik Deweerdt
@ 2006-09-08 12:16 ` Heiko Carstens
  2006-09-09 13:36   ` Andi Kleen
  2006-09-08 12:23 ` 2.6.18-rc6-mm1 - x86_64-mm-lockdep-dont-force-framepointer.patch Heiko Carstens
                   ` (7 subsequent siblings)
  10 siblings, 1 reply; 114+ messages in thread
From: Heiko Carstens @ 2006-09-08 12:16 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel, Andi Kleen, Martin Schwidefsky

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

x86_64-mm-stacktrace-cleanup.patch reverses the logic in s390's
save_stack_trace incorrectly. Fix this.

Cc: Andi Kleen <ak@suse.de>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
From: Heiko Carstens <heiko.carstens@de.ibm.com>
---

 arch/s390/kernel/stacktrace.c |    5 ++---
 1 files changed, 2 insertions(+), 3 deletions(-)

Index: linux-2.6.17/arch/s390/kernel/stacktrace.c
===================================================================
--- linux-2.6.17.orig/arch/s390/kernel/stacktrace.c	2006-09-08 13:44:44.000000000 +0200
+++ linux-2.6.17/arch/s390/kernel/stacktrace.c	2006-09-08 14:00:36.000000000 +0200
@@ -70,12 +70,12 @@
 	sp = save_context_stack(trace, &trace->skip, sp,
 				S390_lowcore.panic_stack - PAGE_SIZE,
 				S390_lowcore.panic_stack);
-	if ((sp != orig_sp) && trace->all_contexts)
+	if ((sp != orig_sp) && !trace->all_contexts)
 		return;
 	sp = save_context_stack(trace, &trace->skip, sp,
 				S390_lowcore.async_stack - ASYNC_SIZE,
 				S390_lowcore.async_stack);
-	if ((sp != orig_sp) && trace->all_contexts)
+	if ((sp != orig_sp) && !trace->all_contexts)
 		return;
 	if (task)
 		save_context_stack(trace, &trace->skip, sp,
@@ -85,5 +85,4 @@
 		save_context_stack(trace, &trace->skip, sp,
 				   S390_lowcore.thread_info,
 				   S390_lowcore.thread_info + THREAD_SIZE);
-	return;
 }

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: 2.6.18-rc6-mm1 - x86_64-mm-lockdep-dont-force-framepointer.patch
  2006-09-08  8:13 2.6.18-rc6-mm1 Andrew Morton
                   ` (2 preceding siblings ...)
  2006-09-08 12:16 ` [patch -mm] s390: fix save_stack_trace Heiko Carstens
@ 2006-09-08 12:23 ` Heiko Carstens
  2006-09-09 13:39   ` Andi Kleen
  2006-09-08 14:26 ` 2.6.18-rc6-mm1 Rafael J. Wysocki
                   ` (6 subsequent siblings)
  10 siblings, 1 reply; 114+ messages in thread
From: Heiko Carstens @ 2006-09-08 12:23 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel, Martin Schwidefsky, Andi Kleen

x86_64-mm-lockdep-dont-force-framepointer.patch does this:

> Don't force frame pointers for lockdep
>
> Now that stacktrace supports dwarf2 don't force frame pointers for lockdep anymore
>
> Cc: mingo@elte.hu
> Signed-off-by: Andi Kleen <ak@suse.de>
>
> ---
>  lib/Kconfig.debug |    1 -
>  1 files changed, 1 deletion(-)
>
> Index: linux/lib/Kconfig.debug
> ===================================================================
> --- linux.orig/lib/Kconfig.debug
> +++ linux/lib/Kconfig.debug
> @@ -218,7 +218,6 @@ config LOCKDEP
>         bool
>         depends on DEBUG_KERNEL && TRACE_IRQFLAGS_SUPPORT && STACKTRACE_SUPPORT && LOCKDEP_SUPPORT
>         select STACKTRACE
> -       select FRAME_POINTER

This patch affects all architecture. I'd like to keep the "select FRAME_POINTER"
for s390, since we don't support dwarf2.
So this patch should be dropped.

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: 2.6.18-rc6-mm1
  2006-09-08  8:13 2.6.18-rc6-mm1 Andrew Morton
                   ` (3 preceding siblings ...)
  2006-09-08 12:23 ` 2.6.18-rc6-mm1 - x86_64-mm-lockdep-dont-force-framepointer.patch Heiko Carstens
@ 2006-09-08 14:26 ` Rafael J. Wysocki
  2006-09-08 20:44   ` [linux-usb-devel] 2.6.18-rc6-mm1 Alan Stern
  2006-09-08 17:43 ` 2.6.18-rc6-mm1 Stefan Richter
                   ` (5 subsequent siblings)
  10 siblings, 1 reply; 114+ messages in thread
From: Rafael J. Wysocki @ 2006-09-08 14:26 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel, USB development list

On Friday, 8 September 2006 10:13, Andrew Morton wrote:
> 
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc6/2.6.18-rc6-mm1/

ohci_hcd doesn't work after a resume from disk on HPC nx6325, worked on
2.6.18-rc5-mm1.

It helps if I rmmod and modprobe it after the resume.

Here's the relevant part of the dmesg output:

usb usb1: resuming
 usbdev1.1_ep00: PM: resume from 0, parent usb1 still 1
hub 1-0:1.0: PM: resume from 0, parent usb1 still 1
hub 1-0:1.0: resuming
 usbdev1.1: PM: resume from 0, parent usb1 still 1
usb usb2: resuming
usb usb2: root hub lost power or was reset
 usbdev2.1_ep00: PM: resume from 0, parent usb2 still 1
hub 2-0:1.0: PM: resume from 0, parent usb2 still 1
hub 2-0:1.0: resuming
 usbdev2.1: PM: resume from 0, parent usb2 still 1
usb usb3: resuming
usb usb3: root hub lost power or was reset
 usbdev3.1_ep00: PM: resume from 0, parent usb3 still 1
hub 3-0:1.0: PM: resume from 0, parent usb3 still 1
hub 3-0:1.0: resuming
 usbdev3.1: PM: resume from 0, parent usb3 still 1
usb 2-2: PM: resume from 1, parent usb2 still 1
usb 2-2: resuming
 usbdev2.2_ep00: PM: resume from 0, parent 2-2 still 1
hci_usb 2-2:1.0: PM: resume from 1, parent 2-2 still 1
hci_usb 2-2:1.0: resuming
 usbdev2.2_ep81: PM: resume from 0, parent 2-2:1.0 still 1
 usbdev2.2_ep82: PM: resume from 0, parent 2-2:1.0 still 1
 usbdev2.2_ep02: PM: resume from 0, parent 2-2:1.0 still 1
hci_usb 2-2:1.1: PM: resume from 1, parent 2-2 still 1
hci_usb 2-2:1.1: resuming
usb 2-2:1.2: PM: resume from 1, parent 2-2 still 1
usb 2-2:1.2: resuming
 usbdev2.2_ep84: PM: resume from 0, parent 2-2:1.2 still 1
 usbdev2.2_ep04: PM: resume from 0, parent 2-2:1.2 still 1
usb 2-2:1.3: PM: resume from 1, parent 2-2 still 1
usb 2-2:1.3: resuming
 usbdev2.2: PM: resume from 0, parent 2-2 still 1
platform bluetooth: resuming
usb 3-1: PM: resume from 1, parent usb3 still 1
usb 3-1: resuming
 usbdev3.2_ep00: PM: resume from 0, parent 3-1 still 1
usb 3-1:1.0: PM: resume from 1, parent 3-1 still 1
usb 3-1:1.0: resuming
 usbdev3.2_ep81: PM: resume from 0, parent 3-1:1.0 still 1
 usbdev3.2_ep02: PM: resume from 0, parent 3-1:1.0 still 1
 usbdev3.2: PM: resume from 0, parent 3-1 still 1
usb 3-4: PM: resume from 1, parent usb3 still 1
usb 3-4: resuming
 usbdev3.3_ep00: PM: resume from 0, parent 3-4 still 1
usbhid 3-4:1.0: PM: resume from 1, parent 3-4 still 1
usbhid 3-4:1.0: resuming
 usbdev3.3_ep81: PM: resume from 0, parent 3-4:1.0 still 1
 usbdev3.3: PM: resume from 0, parent 3-4 still 1
 usbdev2.2_ep83: PM: resume from 0, parent 2-2:1.1 still 1
 usbdev2.2_ep03: PM: resume from 0, parent 2-2:1.1 still 1
 hci0: PM: resume from 0, parent 2-2:1.0 still 1

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: 2.6.18-rc6-mm1
  2006-09-08  8:13 2.6.18-rc6-mm1 Andrew Morton
                   ` (4 preceding siblings ...)
  2006-09-08 14:26 ` 2.6.18-rc6-mm1 Rafael J. Wysocki
@ 2006-09-08 17:43 ` Stefan Richter
  2006-09-08 18:04   ` 2.6.18-rc6-mm1 Andrew Morton
  2006-09-08 19:23 ` 2.6.18-rc6-mm1 Michal Piotrowski
                   ` (4 subsequent siblings)
  10 siblings, 1 reply; 114+ messages in thread
From: Stefan Richter @ 2006-09-08 17:43 UTC (permalink / raw)
  To: David Howells; +Cc: Andrew Morton, linux-kernel, Ingo Molnar

Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc6/2.6.18-rc6-mm1/
...
> +nommu-move-the-fallback-arch_vma_name-to-a-sensible-place.patch
...

I get

	kernel/signal.c:2742: warning: weak declaration of
	'arch_vma_name' after first use results in unspecified behavior

on X86_32, gcc 3.4.1-4mdk.

nommu-move-the-fallback-arch_vma_name-to-a-sensible-place.patch moves
arch_vma_name() into kernel/signal.c, near its end.

vdso-improve-print_fatal_signals-support-by-adding-memory-maps.patch
inserts a call to arch_vma_name() into kernel/signal.c, in the first
half of signal.c.
-- 
Stefan Richter
-=====-=-==- =--= -=---
http://arcgraph.de/sr/

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: 2.6.18-rc6-mm1
  2006-09-08 17:43 ` 2.6.18-rc6-mm1 Stefan Richter
@ 2006-09-08 18:04   ` Andrew Morton
  2006-09-08 18:36     ` 2.6.18-rc6-mm1 Stefan Richter
  0 siblings, 1 reply; 114+ messages in thread
From: Andrew Morton @ 2006-09-08 18:04 UTC (permalink / raw)
  To: Stefan Richter; +Cc: David Howells, linux-kernel, Ingo Molnar

On Fri, 08 Sep 2006 19:43:19 +0200
Stefan Richter <stefanr@s5r6.in-berlin.de> wrote:

> Andrew Morton wrote:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc6/2.6.18-rc6-mm1/
> ...
> > +nommu-move-the-fallback-arch_vma_name-to-a-sensible-place.patch
> ...
> 
> I get
> 
> 	kernel/signal.c:2742: warning: weak declaration of
> 	'arch_vma_name' after first use results in unspecified behavior
> 
> on X86_32, gcc 3.4.1-4mdk.
> 
> nommu-move-the-fallback-arch_vma_name-to-a-sensible-place.patch moves
> arch_vma_name() into kernel/signal.c, near its end.
> 
> vdso-improve-print_fatal_signals-support-by-adding-memory-maps.patch
> inserts a call to arch_vma_name() into kernel/signal.c, in the first
> half of signal.c.

Thanks.   Does this fix it?

--- a/include/linux/mm.h~nommu-move-the-fallback-arch_vma_name-to-a-sensible-place-fix
+++ a/include/linux/mm.h
@@ -1266,7 +1266,7 @@ void drop_slab(void);
 extern int randomize_va_space;
 #endif
 
-const char *arch_vma_name(struct vm_area_struct *vma);
+__attribute__((weak)) const char *arch_vma_name(struct vm_area_struct *vma);
 
 #endif /* __KERNEL__ */
 #endif /* _LINUX_MM_H */
_


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: 2.6.18-rc6-mm1
  2006-09-08 18:04   ` 2.6.18-rc6-mm1 Andrew Morton
@ 2006-09-08 18:36     ` Stefan Richter
  0 siblings, 0 replies; 114+ messages in thread
From: Stefan Richter @ 2006-09-08 18:36 UTC (permalink / raw)
  To: Andrew Morton; +Cc: David Howells, linux-kernel, Ingo Molnar

Andrew Morton wrote:
> On Fri, 08 Sep 2006 19:43:19 +0200
> Stefan Richter <stefanr@s5r6.in-berlin.de> wrote:
...
>> 	kernel/signal.c:2742: warning: weak declaration of
>> 	'arch_vma_name' after first use results in unspecified behavior
...
> Thanks.   Does this fix it?
> 
> --- a/include/linux/mm.h~nommu-move-the-fallback-arch_vma_name-to-a-sensible-place-fix
> +++ a/include/linux/mm.h
> @@ -1266,7 +1266,7 @@ void drop_slab(void);
>  extern int randomize_va_space;
>  #endif
>  
> -const char *arch_vma_name(struct vm_area_struct *vma);
> +__attribute__((weak)) const char *arch_vma_name(struct vm_area_struct *vma);
>  
>  #endif /* __KERNEL__ */
>  #endif /* _LINUX_MM_H */

Yes. gcc approves.
-- 
Stefan Richter
-=====-=-==- =--= -=---
http://arcgraph.de/sr/

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: 2.6.18-rc6-mm1
  2006-09-08  8:13 2.6.18-rc6-mm1 Andrew Morton
                   ` (5 preceding siblings ...)
  2006-09-08 17:43 ` 2.6.18-rc6-mm1 Stefan Richter
@ 2006-09-08 19:23 ` Michal Piotrowski
  2006-09-08 19:43   ` 2.6.18-rc6-mm1 Andrew Morton
  2006-09-08 19:30 ` 2.6.18-rc6-mm1 thunder7
                   ` (3 subsequent siblings)
  10 siblings, 1 reply; 114+ messages in thread
From: Michal Piotrowski @ 2006-09-08 19:23 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel, Ingo Molnar

Hi,

Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc6/2.6.18-rc6-mm1/
> 
> - autofs4 mounting of NFS is still sick.

BUG: unable to handle kernel paging request at virtual address fdb52df8
 printing eip:
 c013894c
*pde = 37c85067
*pte = 00000000
Oops: 0000 [#1]
4K_STACKS PREEMPT SMP
last sysfs file: /devices/platform/i2c-9191/9191-0290/temp2_input
Modules linked in: ipv6 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 proces
sor fan container evdev snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_se
q_device sk98lin snd_pcm_oss snd_mixer_oss snd_pcm skge snd_timer snd soundcore snd_page_alloc ide_cd i2c_i801 iTCO_wdt inte
l_agp cdrom agpgart rtc unix
CPU:    0
EIP:    0060:[<c013894c>]    Not tainted VLI
EFLAGS: 00210212   (2.6.18-rc6-mm1 #115)
EIP is at __module_text_address+0xf/0x5c
eax: fdb54000   ebx: fdb67c04   ecx: f7c10000   edx: fdb52d00
esi: 000000fa   edi: f7c10f9c   ebp: 00000005   esp: f7c10e68
ds: 007b   es: 007b   ss: 0068
Process udevd (pid: 20250, ti=f7c10000 task=f7c21000 task.ti=f7c10000)
Stack: f7c10000 c5f36030 c012fb6c f7c10000 c014f61b c0341710 000284d0 00000010
       f7c21000 00000002 f7c10000 00200202 f57ce3c0 f52a8bfc f57ce3c0 f76a6ca4
      f4a3c800 c01575e4 f52a8bfc f7d31ec0 f76a6ca4 80010000 c015894c f76a6ca4
Call Trace:
[<c012fb6c>] __kernel_text_address+0x18/0x23
[<c014f61b>] __alloc_pages+0x301/0x313
[<c01575e4>] __pte_alloc+0xf/0x78
[<c015894c>] copy_page_range+0x139/0x3dd
[<c011e67b>] copy_process+0xc1e/0x13cf
[<c011f001>] do_fork+0xb6/0x1d2
[<c017cdfa>] mntput_no_expire+0x11/0x81
[<c010122e>] sys_clone+0x28/0x2d
[<c0102fc6>] sysenter_past_esp+0x5f/0x85
[<c0110033>] wakeup_pmode_return+0x33/0x55
=======================
Code: 31 c0 5b 5e 5f 5d c3 83 01 01 83 51 04 00 8b 12 31 c0 81 fa 10 eb 33 c0 0f 45 c2 c3 5
6 53 89 c1 8b 15 10 eb 33 c0 83 ea 04 eb 20 <8b> b2 f8 00 00 00 8b 82 e8 00 00 00 39 c1 72 23 01 f0 39 c1 73
Sep  8 20:23:34 euridica kernel: EIP: [<c013894c>] __module_text_address+0xf/0x5c SS:ESP 0068:f7c10e68

config file -> http://www.stardust.webpages.pl/files/mm/2.6.18-rc6-mm1/mm-config
Unfortunately, this kernel was build without debugging symbols. I'll try to reproduce this oops with CONFIG_DEBUG_*=y.

Ingo, can you take a look at this?

BUG: warning at /usr/src/linux-mm/kernel/lockdep.c:2359/check_flags()
 [<c01041ca>] dump_trace+0x63/0x1ca
 [<c0104343>] show_trace_log_lvl+0x12/0x25
 [<c01049a3>] show_trace+0xd/0x10
 [<c0104a68>] dump_stack+0x16/0x18
 [<c0138553>] check_flags+0x92/0x220
 [<c013b033>] lock_acquire+0x3a/0x88
 [<c0136d32>] down_write+0x28/0x43
 [<c0164a9b>] sys_brk+0x20/0xd6
 [<c0103166>] sysenter_past_esp+0x5f/0x99
DWARF2 unwinder stuck at sysenter_past_esp+0x5f/0x99

Leftover inexact backtrace:

 =======================
irq event stamp: 603424
hardirqs last  enabled at (603423): [<c0103238>] restore_nocheck+0x12/0x15
hardirqs last disabled at (603424): [<c0103173>] sysenter_past_esp+0x6c/0x99
softirqs last  enabled at (603376): [<c0126a61>] __do_softirq+0xe4/0xea
softirqs last disabled at (603371): [<c0105b3b>] do_softirq+0x6d/0x11f

config file -> http://www.stardust.webpages.pl/files/mm/2.6.18-rc6-mm1/mm-config2
http://www.stardust.webpages.pl/files/mm/2.6.18-rc6-mm1/mm-dmesg

Regards,
Michal

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

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: 2.6.18-rc6-mm1
  2006-09-08  8:13 2.6.18-rc6-mm1 Andrew Morton
                   ` (6 preceding siblings ...)
  2006-09-08 19:23 ` 2.6.18-rc6-mm1 Michal Piotrowski
@ 2006-09-08 19:30 ` thunder7
  2006-09-08 19:44   ` 2.6.18-rc6-mm1 Andrew Morton
  2006-09-09  8:35 ` lockdep warning in check_flags() Frederik Deweerdt
                   ` (2 subsequent siblings)
  10 siblings, 1 reply; 114+ messages in thread
From: thunder7 @ 2006-09-08 19:30 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel

From: Andrew Morton <akpm@osdl.org>
Date: Fri, Sep 08, 2006 at 01:13:17AM -0700
> 
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc6/2.6.18-rc6-mm1/
> 
This throws an oops on my IBM Thinkpad T23 notebook. Some parts scroll
off the screen, but the visible stack trace goes like this:

savagefb_probe_i2c_connector
savagefb_probe
pci_match_device
....
EIP: fb_ddc_read ....

.config and dmesg attached. 2.6.18-rc2-mm1 works just fine here.


#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.18-rc6-mm1
# Fri Sep  8 21:10:44 2006
#
CONFIG_X86_32=y
CONFIG_GENERIC_TIME=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_SEMAPHORE_SLEEPERS=y
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_DMI=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"

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

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

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

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

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

#
# Processor type and features
#
# CONFIG_SMP is not set
CONFIG_X86_PC=y
# CONFIG_X86_ELAN is not set
# CONFIG_X86_VOYAGER is not set
# CONFIG_X86_NUMAQ is not set
# CONFIG_X86_SUMMIT is not set
# CONFIG_X86_BIGSMP is not set
# CONFIG_X86_VISWS is not set
# CONFIG_X86_GENERICARCH is not set
# CONFIG_X86_ES7000 is not set
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMII is not set
CONFIG_MPENTIUMIII=y
# CONFIG_MPENTIUMM is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MEFFICEON is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MGEODEGX1 is not set
# CONFIG_MGEODE_LX is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_X86_GENERIC is not set
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_L1_CACHE_SHIFT=5
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_CMPXCHG64=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_TSC=y
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
CONFIG_PREEMPT=y
CONFIG_PREEMPT_BKL=y
CONFIG_X86_UP_APIC=y
CONFIG_X86_UP_IOAPIC=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_MCE=y
# CONFIG_X86_MCE_NONFATAL is not set
# CONFIG_X86_MCE_P4THERMAL is not set
CONFIG_VM86=y
# CONFIG_TOSHIBA is not set
# CONFIG_I8K is not set
# CONFIG_X86_REBOOTFIXUPS is not set
CONFIG_MICROCODE=y
CONFIG_MICROCODE_OLD_INTERFACE=y
CONFIG_X86_MSR=y
CONFIG_X86_CPUID=y

#
# Firmware Drivers
#
# CONFIG_EDD is not set
# CONFIG_DELL_RBU is not set
# CONFIG_DCDBAS is not set
# CONFIG_NOHIGHMEM is not set
CONFIG_HIGHMEM4G=y
# CONFIG_HIGHMEM64G is not set
CONFIG_PAGE_OFFSET=0xC0000000
CONFIG_HIGHMEM=y
CONFIG_ARCH_FLATMEM_ENABLE=y
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_SELECT_MEMORY_MODEL=y
CONFIG_ARCH_POPULATES_NODE_MAP=y
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y
# CONFIG_DISCONTIGMEM_MANUAL is not set
# CONFIG_SPARSEMEM_MANUAL is not set
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
CONFIG_SPARSEMEM_STATIC=y
CONFIG_SPLIT_PTLOCK_CPUS=4
# CONFIG_RESOURCES_64BIT is not set
CONFIG_ADAPTIVE_READAHEAD=y
# CONFIG_READAHEAD_ALLOW_OVERHEADS is not set
CONFIG_HIGHPTE=y
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
# CONFIG_EFI is not set
# CONFIG_REGPARM is not set
CONFIG_SECCOMP=y
# CONFIG_SECCOMP_DISABLE_TSC is not set
# CONFIG_VGA_NOPROBE is not set
# CONFIG_HZ_100 is not set
CONFIG_HZ_250=y
# CONFIG_HZ_1000 is not set
CONFIG_HZ=250
# CONFIG_KEXEC is not set
# CONFIG_CRASH_DUMP is not set
CONFIG_PHYSICAL_START=0x100000
CONFIG_COMPAT_VDSO=y
CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y

#
# Power management options (ACPI, APM)
#
CONFIG_PM=y
CONFIG_PM_LEGACY=y
# CONFIG_PM_DEBUG is not set
# CONFIG_PM_SYSFS_DEPRECATED is not set
# CONFIG_SOFTWARE_SUSPEND is not set

#
# ACPI (Advanced Configuration and Power Interface) Support
#
CONFIG_ACPI=y
CONFIG_ACPI_SLEEP=y
CONFIG_ACPI_SLEEP_PROC_FS=y
# CONFIG_ACPI_SLEEP_PROC_SLEEP is not set
CONFIG_ACPI_AC=y
CONFIG_ACPI_BATTERY=y
CONFIG_ACPI_BUTTON=y
CONFIG_ACPI_VIDEO=y
CONFIG_ACPI_HOTKEY=y
CONFIG_ACPI_FAN=y
# CONFIG_ACPI_DOCK is not set
# CONFIG_ACPI_BAY is not set
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_THERMAL=y
# CONFIG_ACPI_ASUS is not set
CONFIG_ACPI_IBM=y
# CONFIG_ACPI_IBM_DOCK is not set
# CONFIG_ACPI_TOSHIBA is not set
# CONFIG_ACPI_SONY is not set
# CONFIG_ACPI_CUSTOM_DSDT is not set
CONFIG_ACPI_BLACKLIST_YEAR=0
CONFIG_ACPI_DEBUG=y
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_SYSTEM=y
CONFIG_X86_PM_TIMER=y
# CONFIG_ACPI_CONTAINER is not set
# CONFIG_ACPI_SBS is not set

#
# APM (Advanced Power Management) BIOS Support
#
# CONFIG_APM is not set

#
# CPU Frequency scaling
#
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_TABLE=y
# CONFIG_CPU_FREQ_DEBUG is not set
CONFIG_CPU_FREQ_STAT=y
CONFIG_CPU_FREQ_STAT_DETAILS=y
CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y
# CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set
CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
CONFIG_CPU_FREQ_GOV_POWERSAVE=y
CONFIG_CPU_FREQ_GOV_USERSPACE=y
# CONFIG_CPU_FREQ_GOV_ONDEMAND is not set
# CONFIG_CPU_FREQ_GOV_CONSERVATIVE is not set

#
# CPUFreq processor drivers
#
# CONFIG_X86_ACPI_CPUFREQ is not set
# CONFIG_X86_POWERNOW_K6 is not set
# CONFIG_X86_POWERNOW_K7 is not set
# CONFIG_X86_POWERNOW_K8 is not set
# CONFIG_X86_GX_SUSPMOD is not set
# CONFIG_X86_SPEEDSTEP_CENTRINO is not set
CONFIG_X86_SPEEDSTEP_ICH=y
# CONFIG_X86_SPEEDSTEP_SMI is not set
# CONFIG_X86_P4_CLOCKMOD is not set
# CONFIG_X86_CPUFREQ_NFORCE2 is not set
# CONFIG_X86_LONGRUN is not set
# CONFIG_X86_LONGHAUL is not set

#
# shared options
#
CONFIG_X86_SPEEDSTEP_LIB=y
# CONFIG_X86_SPEEDSTEP_RELAXED_CAP_CHECK is not set

#
# Bus options (PCI, PCMCIA, EISA, MCA, ISA)
#
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GOMMCONFIG is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_MMCONFIG=y
# CONFIG_PCIEPORTBUS is not set
# CONFIG_PCI_MSI is not set
# CONFIG_PCI_MULTITHREAD_PROBE is not set
CONFIG_ISA_DMA_API=y
CONFIG_ISA=y
# CONFIG_EISA is not set
# CONFIG_MCA is not set
# CONFIG_SCx200 is not set

#
# PCCARD (PCMCIA/CardBus) support
#
# CONFIG_PCCARD is not set

#
# PCI Hotplug Support
#
# CONFIG_HOTPLUG_PCI is not set

#
# Executable file formats
#
CONFIG_BINFMT_ELF=y
# CONFIG_BINFMT_AOUT is not set
# CONFIG_BINFMT_MISC is not set

#
# Networking
#
CONFIG_NET=y

#
# Networking options
#
# CONFIG_NETDEBUG is not set
# CONFIG_PACKET is not set
CONFIG_UNIX=y
CONFIG_XFRM=y
# CONFIG_XFRM_USER is not set
# CONFIG_XFRM_SUB_POLICY is not set
# CONFIG_NET_KEY is not set
CONFIG_INET=y
# CONFIG_IP_MULTICAST is not set
CONFIG_IP_ADVANCED_ROUTER=y
CONFIG_ASK_IP_FIB_HASH=y
# CONFIG_IP_FIB_TRIE is not set
CONFIG_IP_FIB_HASH=y
# CONFIG_IP_MULTIPLE_TABLES is not set
# CONFIG_IP_ROUTE_MULTIPATH is not set
CONFIG_IP_ROUTE_VERBOSE=y
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_ARPD is not set
CONFIG_SYN_COOKIES=y
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
# CONFIG_INET_IPCOMP is not set
# CONFIG_INET_XFRM_TUNNEL is not set
# CONFIG_INET_TUNNEL is not set
CONFIG_INET_XFRM_MODE_TRANSPORT=y
CONFIG_INET_XFRM_MODE_TUNNEL=y
CONFIG_INET_DIAG=y
CONFIG_INET_TCP_DIAG=y
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_BIC=y
# CONFIG_IPV6 is not set
# CONFIG_INET6_XFRM_TUNNEL is not set
# CONFIG_INET6_TUNNEL is not set
# CONFIG_NETWORK_SECMARK is not set
# CONFIG_NETFILTER is not set

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

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

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

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

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_HAMRADIO is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
# CONFIG_IEEE80211 is not set

#
# Device Drivers
#

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

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

#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set

#
# Parallel port support
#
# CONFIG_PARPORT is not set

#
# Plug and Play support
#
# CONFIG_PNP is not set

#
# Block devices
#
CONFIG_BLK_DEV_FD=y
# CONFIG_BLK_DEV_XD is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=y
# CONFIG_BLK_DEV_CRYPTOLOOP is not set
CONFIG_BLK_DEV_NBD=y
# CONFIG_BLK_DEV_SX8 is not set
# CONFIG_BLK_DEV_UB is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=4096
CONFIG_BLK_DEV_RAM_BLOCKSIZE=1024
CONFIG_BLK_DEV_INITRD=y
# CONFIG_CDROM_PKTCDVD is not set
# CONFIG_ATA_OVER_ETH is not set

#
# ATA/ATAPI/MFM/RLL support
#
CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y

#
# Please see Documentation/ide.txt for help/info on IDE drives
#
# CONFIG_BLK_DEV_IDE_SATA is not set
# CONFIG_BLK_DEV_HD_IDE is not set
CONFIG_BLK_DEV_IDEDISK=y
# CONFIG_IDEDISK_MULTI_MODE is not set
CONFIG_BLK_DEV_IDECD=y
CONFIG_BLK_DEV_IDETAPE=y
# CONFIG_BLK_DEV_IDEFLOPPY is not set
# CONFIG_BLK_DEV_IDESCSI is not set
# CONFIG_IDE_TASK_IOCTL is not set

#
# IDE chipset support/bugfixes
#
CONFIG_IDE_GENERIC=y
# CONFIG_BLK_DEV_CMD640 is not set
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
# CONFIG_BLK_DEV_OFFBOARD is not set
CONFIG_BLK_DEV_GENERIC=y
# CONFIG_BLK_DEV_OPTI621 is not set
# CONFIG_BLK_DEV_RZ1000 is not set
CONFIG_BLK_DEV_IDEDMA_PCI=y
# CONFIG_BLK_DEV_IDEDMA_FORCED is not set
# CONFIG_IDEDMA_PCI_AUTO is not set
# CONFIG_BLK_DEV_AEC62XX is not set
# CONFIG_BLK_DEV_ALI15X3 is not set
# CONFIG_BLK_DEV_AMD74XX is not set
# CONFIG_BLK_DEV_ATIIXP is not set
# CONFIG_BLK_DEV_CMD64X is not set
# CONFIG_BLK_DEV_TRIFLEX is not set
# CONFIG_BLK_DEV_CY82C693 is not set
# CONFIG_BLK_DEV_CS5520 is not set
# CONFIG_BLK_DEV_CS5530 is not set
# CONFIG_BLK_DEV_CS5535 is not set
# CONFIG_BLK_DEV_HPT34X is not set
# CONFIG_BLK_DEV_HPT366 is not set
# CONFIG_BLK_DEV_JMICRON is not set
# CONFIG_BLK_DEV_SC1200 is not set
CONFIG_BLK_DEV_PIIX=y
# CONFIG_BLK_DEV_IT821X is not set
# CONFIG_BLK_DEV_NS87415 is not set
# CONFIG_BLK_DEV_PDC202XX_OLD is not set
# CONFIG_BLK_DEV_PDC202XX_NEW is not set
# CONFIG_BLK_DEV_SVWKS is not set
# CONFIG_BLK_DEV_SIIMAGE is not set
# CONFIG_BLK_DEV_SIS5513 is not set
# CONFIG_BLK_DEV_SLC90E66 is not set
# CONFIG_BLK_DEV_TRM290 is not set
# CONFIG_BLK_DEV_VIA82CXXX is not set
# CONFIG_IDE_ARM is not set
# CONFIG_IDE_CHIPSETS is not set
CONFIG_BLK_DEV_IDEDMA=y
# CONFIG_IDEDMA_IVB is not set
# CONFIG_IDEDMA_AUTO is not set
# CONFIG_BLK_DEV_HD is not set

#
# SCSI device support
#
# CONFIG_RAID_ATTRS is not set
CONFIG_SCSI=m
CONFIG_SCSI_NETLINK=y
# CONFIG_SCSI_TGT is not set
CONFIG_SCSI_PROC_FS=y

#
# SCSI support type (disk, tape, CD-ROM)
#
# CONFIG_BLK_DEV_SD is not set
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
# CONFIG_BLK_DEV_SR is not set
# CONFIG_CHR_DEV_SG is not set
# CONFIG_CHR_DEV_SCH is not set

#
# Some SCSI devices (e.g. CD jukebox) support multiple LUNs
#
# CONFIG_SCSI_MULTI_LUN is not set
# CONFIG_SCSI_CONSTANTS is not set
# CONFIG_SCSI_LOGGING is not set

#
# SCSI Transports
#
# CONFIG_SCSI_SPI_ATTRS is not set
CONFIG_SCSI_FC_ATTRS=m
# CONFIG_SCSI_ISCSI_ATTRS is not set
# CONFIG_SCSI_SAS_ATTRS is not set
# CONFIG_SCSI_SAS_LIBSAS is not set

#
# SCSI low-level drivers
#
# CONFIG_ISCSI_TCP is not set
# CONFIG_BLK_DEV_3W_XXXX_RAID is not set
# CONFIG_SCSI_3W_9XXX is not set
# CONFIG_SCSI_7000FASST is not set
# CONFIG_SCSI_ACARD is not set
# CONFIG_SCSI_AHA152X is not set
# CONFIG_SCSI_AHA1542 is not set
# CONFIG_SCSI_AACRAID is not set
# CONFIG_SCSI_AIC7XXX is not set
# CONFIG_SCSI_AIC7XXX_OLD is not set
# CONFIG_SCSI_AIC79XX is not set
# CONFIG_SCSI_AIC94XX is not set
# CONFIG_SCSI_DPT_I2O is not set
# CONFIG_SCSI_ADVANSYS is not set
# CONFIG_SCSI_IN2000 is not set
# CONFIG_SCSI_ARCMSR is not set
# CONFIG_MEGARAID_NEWGEN is not set
# CONFIG_MEGARAID_LEGACY is not set
# CONFIG_MEGARAID_SAS is not set
# CONFIG_SCSI_HPTIOP is not set
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_DTC3280 is not set
# CONFIG_SCSI_EATA is not set
# CONFIG_SCSI_FUTURE_DOMAIN is not set
# CONFIG_SCSI_GDTH is not set
# CONFIG_SCSI_GENERIC_NCR5380 is not set
# CONFIG_SCSI_GENERIC_NCR5380_MMIO is not set
# CONFIG_SCSI_IPS is not set
# CONFIG_SCSI_INITIO is not set
# CONFIG_SCSI_INIA100 is not set
# CONFIG_SCSI_NCR53C406A is not set
# CONFIG_SCSI_STEX is not set
# CONFIG_SCSI_SYM53C8XX_2 is not set
# CONFIG_SCSI_IPR is not set
# CONFIG_SCSI_PAS16 is not set
# CONFIG_SCSI_PSI240I is not set
# CONFIG_SCSI_QLOGIC_FAS is not set
# CONFIG_SCSI_QLOGIC_1280 is not set
# CONFIG_SCSI_QLA_FC is not set
# CONFIG_SCSI_LPFC is not set
# CONFIG_SCSI_SYM53C416 is not set
# CONFIG_SCSI_DC395x is not set
# CONFIG_SCSI_DC390T is not set
# CONFIG_SCSI_T128 is not set
# CONFIG_SCSI_U14_34F is not set
# CONFIG_SCSI_ULTRASTOR is not set
# CONFIG_SCSI_NSP32 is not set
# CONFIG_SCSI_DEBUG is not set
# CONFIG_SCSI_SRP is not set

#
# Serial ATA (prod) and Parallel ATA (experimental) drivers
#
# CONFIG_ATA is not set

#
# Old CD-ROM drivers (not SCSI, not IDE)
#
# CONFIG_CD_NO_IDESCSI is not set

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

#
# Fusion MPT device support
#
# CONFIG_FUSION is not set
# CONFIG_FUSION_SPI is not set
# CONFIG_FUSION_FC is not set
# CONFIG_FUSION_SAS is not set

#
# IEEE 1394 (FireWire) support
#
# CONFIG_IEEE1394 is not set

#
# I2O device support
#
# CONFIG_I2O is not set

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

#
# ARCnet devices
#
# CONFIG_ARCNET is not set

#
# PHY device support
#
# CONFIG_PHYLIB is not set

#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
CONFIG_MII=y
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
# CONFIG_CASSINI is not set
# CONFIG_NET_VENDOR_3COM is not set
# CONFIG_LANCE is not set
# CONFIG_NET_VENDOR_SMC is not set
# CONFIG_NET_VENDOR_RACAL is not set

#
# Tulip family network device support
#
# CONFIG_NET_TULIP is not set
# CONFIG_AT1700 is not set
# CONFIG_DEPCA is not set
# CONFIG_HP100 is not set
# CONFIG_NET_ISA is not set
CONFIG_NET_PCI=y
# CONFIG_PCNET32 is not set
# CONFIG_AMD8111_ETH is not set
# CONFIG_ADAPTEC_STARFIRE is not set
# CONFIG_AC3200 is not set
# CONFIG_APRICOT is not set
# CONFIG_B44 is not set
# CONFIG_FORCEDETH is not set
# CONFIG_CS89x0 is not set
# CONFIG_DGRS is not set
# CONFIG_EEPRO100 is not set
CONFIG_E100=y
# CONFIG_FEALNX is not set
# CONFIG_NATSEMI is not set
# CONFIG_NE2K_PCI is not set
# CONFIG_8139CP is not set
# CONFIG_8139TOO is not set
# CONFIG_SIS900 is not set
# CONFIG_EPIC100 is not set
# CONFIG_SUNDANCE is not set
# CONFIG_TLAN is not set
# CONFIG_VIA_RHINE is not set

#
# Ethernet (1000 Mbit)
#
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
# CONFIG_E1000 is not set
# CONFIG_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
# CONFIG_R8169 is not set
# CONFIG_SIS190 is not set
# CONFIG_SKGE is not set
# CONFIG_SKY2 is not set
# CONFIG_SK98LIN is not set
# CONFIG_VIA_VELOCITY is not set
# CONFIG_TIGON3 is not set
# CONFIG_BNX2 is not set
# CONFIG_QLA3XXX is not set

#
# Ethernet (10000 Mbit)
#
# CONFIG_CHELSIO_T1 is not set
# CONFIG_IXGB is not set
# CONFIG_S2IO is not set
# CONFIG_MYRI10GE is not set

#
# Token Ring devices
#
# CONFIG_TR is not set

#
# Wireless LAN (non-hamradio)
#
# CONFIG_NET_RADIO is not set

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

#
# ISDN subsystem
#
# CONFIG_ISDN is not set

#
# Telephony Support
#
# CONFIG_PHONE is not set

#
# Input device support
#
CONFIG_INPUT=y
# CONFIG_INPUT_FF_MEMLESS is not set

#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_PSAUX=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not set
# CONFIG_INPUT_TSDEV is not set
CONFIG_INPUT_EVDEV=y
# CONFIG_INPUT_EVBUG is not set

#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_LKKBD is not set
# CONFIG_KEYBOARD_XTKBD is not set
# CONFIG_KEYBOARD_NEWTON is not set
# CONFIG_KEYBOARD_STOWAWAY is not set
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
# CONFIG_MOUSE_SERIAL is not set
# CONFIG_MOUSE_INPORT is not set
# CONFIG_MOUSE_LOGIBM is not set
# CONFIG_MOUSE_PC110PAD is not set
# CONFIG_MOUSE_VSXXXAA is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
# CONFIG_INPUT_MISC is not set

#
# Hardware I/O ports
#
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
CONFIG_SERIO_SERPORT=y
# CONFIG_SERIO_CT82C710 is not set
# CONFIG_SERIO_PCIPS2 is not set
CONFIG_SERIO_LIBPS2=y
# CONFIG_SERIO_RAW is not set
# CONFIG_GAMEPORT is not set

#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
# CONFIG_VT_HW_CONSOLE_BINDING is not set
# CONFIG_SERIAL_NONSTANDARD is not set
# CONFIG_NOZOMI is not set

#
# Serial drivers
#
CONFIG_SERIAL_8250=y
# CONFIG_SERIAL_8250_CONSOLE is not set
CONFIG_SERIAL_8250_PCI=y
CONFIG_SERIAL_8250_NR_UARTS=4
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
# CONFIG_SERIAL_8250_EXTENDED is not set

#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
# CONFIG_SERIAL_JSM is not set
CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256

#
# IPMI
#
# CONFIG_IPMI_HANDLER is not set

#
# Watchdog Cards
#
# CONFIG_WATCHDOG is not set
CONFIG_HW_RANDOM=y
CONFIG_HW_RANDOM_INTEL=y
CONFIG_HW_RANDOM_AMD=y
# CONFIG_HW_RANDOM_GEODE is not set
# CONFIG_HW_RANDOM_VIA is not set
CONFIG_NVRAM=y
CONFIG_RTC=y
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
# CONFIG_SONYPI is not set

#
# Ftape, the floppy tape device driver
#
# CONFIG_FTAPE is not set
CONFIG_AGP=y
# CONFIG_AGP_ALI is not set
# CONFIG_AGP_ATI is not set
# CONFIG_AGP_AMD is not set
# CONFIG_AGP_AMD64 is not set
CONFIG_AGP_INTEL=y
# CONFIG_AGP_NVIDIA is not set
# CONFIG_AGP_SIS is not set
# CONFIG_AGP_SWORKS is not set
# CONFIG_AGP_VIA is not set
# CONFIG_AGP_EFFICEON is not set
CONFIG_DRM=y
# CONFIG_DRM_TDFX is not set
# CONFIG_DRM_R128 is not set
# CONFIG_DRM_RADEON is not set
# CONFIG_DRM_I810 is not set
# CONFIG_DRM_I830 is not set
# CONFIG_DRM_I915 is not set
# CONFIG_DRM_MGA is not set
# CONFIG_DRM_SIS is not set
# CONFIG_DRM_VIA is not set
CONFIG_DRM_SAVAGE=y
# CONFIG_MWAVE is not set
# CONFIG_PC8736x_GPIO is not set
# CONFIG_NSC_GPIO is not set
# CONFIG_CS5535_GPIO is not set
# CONFIG_RAW_DRIVER is not set
# CONFIG_HPET is not set
CONFIG_HANGCHECK_TIMER=y

#
# TPM devices
#
# CONFIG_TCG_TPM is not set
# CONFIG_TELCLOCK is not set

#
# I2C support
#
CONFIG_I2C=y
# CONFIG_I2C_CHARDEV is not set

#
# I2C Algorithms
#
CONFIG_I2C_ALGOBIT=y
CONFIG_I2C_ALGOPCF=y
# CONFIG_I2C_ALGOPCA is not set

#
# I2C Hardware Bus support
#
# CONFIG_I2C_ALI1535 is not set
# CONFIG_I2C_ALI1563 is not set
# CONFIG_I2C_ALI15X3 is not set
# CONFIG_I2C_AMD756 is not set
# CONFIG_I2C_AMD8111 is not set
# CONFIG_I2C_ELEKTOR is not set
CONFIG_I2C_I801=y
CONFIG_I2C_I810=y
CONFIG_I2C_PIIX4=y
CONFIG_I2C_ISA=y
# CONFIG_I2C_NFORCE2 is not set
# CONFIG_I2C_OCORES is not set
# CONFIG_I2C_PARPORT_LIGHT is not set
# CONFIG_I2C_PROSAVAGE is not set
# CONFIG_I2C_SAVAGE4 is not set
# CONFIG_SCx200_ACB is not set
# CONFIG_I2C_SIS5595 is not set
# CONFIG_I2C_SIS630 is not set
# CONFIG_I2C_SIS96X is not set
# CONFIG_I2C_STUB is not set
# CONFIG_I2C_VIA is not set
# CONFIG_I2C_VIAPRO is not set
# CONFIG_I2C_VOODOO3 is not set
# CONFIG_I2C_PCA_ISA is not set

#
# Miscellaneous I2C Chip support
#
# CONFIG_SENSORS_DS1337 is not set
# CONFIG_SENSORS_DS1374 is not set
CONFIG_SENSORS_EEPROM=y
# CONFIG_SENSORS_PCF8574 is not set
# CONFIG_SENSORS_PCA9539 is not set
# CONFIG_SENSORS_PCF8591 is not set
# CONFIG_SENSORS_MAX6875 is not set
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
# CONFIG_I2C_DEBUG_CHIP is not set

#
# SPI support
#
# CONFIG_SPI is not set
# CONFIG_SPI_MASTER is not set

#
# Dallas's 1-wire bus
#
# CONFIG_W1 is not set

#
# Hardware Monitoring support
#
CONFIG_HWMON=y
CONFIG_HWMON_VID=y
# CONFIG_SENSORS_ABITUGURU is not set
CONFIG_SENSORS_ADM1021=y
CONFIG_SENSORS_ADM1025=y
# CONFIG_SENSORS_ADM1026 is not set
CONFIG_SENSORS_ADM1031=y
# CONFIG_SENSORS_ADM9240 is not set
# CONFIG_SENSORS_K8TEMP is not set
CONFIG_SENSORS_ASB100=y
# CONFIG_SENSORS_ATXP1 is not set
CONFIG_SENSORS_DS1621=y
# CONFIG_SENSORS_F71805F is not set
CONFIG_SENSORS_FSCHER=y
# CONFIG_SENSORS_FSCPOS is not set
CONFIG_SENSORS_GL518SM=y
# CONFIG_SENSORS_GL520SM is not set
CONFIG_SENSORS_IT87=y
CONFIG_SENSORS_LM63=y
CONFIG_SENSORS_LM75=y
CONFIG_SENSORS_LM77=y
CONFIG_SENSORS_LM78=y
CONFIG_SENSORS_LM80=y
CONFIG_SENSORS_LM83=y
CONFIG_SENSORS_LM85=y
CONFIG_SENSORS_LM87=y
CONFIG_SENSORS_LM90=y
# CONFIG_SENSORS_LM92 is not set
CONFIG_SENSORS_MAX1619=y
CONFIG_SENSORS_PC87360=y
# CONFIG_SENSORS_SIS5595 is not set
CONFIG_SENSORS_SMSC47M1=y
# CONFIG_SENSORS_SMSC47M192 is not set
# CONFIG_SENSORS_SMSC47B397 is not set
CONFIG_SENSORS_VIA686A=y
# CONFIG_SENSORS_VT8231 is not set
CONFIG_SENSORS_W83781D=y
# CONFIG_SENSORS_W83791D is not set
# CONFIG_SENSORS_W83792D is not set
CONFIG_SENSORS_W83L785TS=y
CONFIG_SENSORS_W83627HF=y
# CONFIG_SENSORS_W83627EHF is not set
# CONFIG_SENSORS_HDAPS is not set
# CONFIG_HWMON_DEBUG_CHIP is not set

#
# Misc devices
#
# CONFIG_IBM_ASM is not set

#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set
CONFIG_VIDEO_V4L2=y

#
# Digital Video Broadcasting Devices
#
# CONFIG_DVB is not set
# CONFIG_USB_DABUSB is not set

#
# Graphics support
#
CONFIG_FIRMWARE_EDID=y
CONFIG_FB=y
CONFIG_FB_DDC=y
CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y
# CONFIG_FB_MACMODES is not set
# CONFIG_FB_BACKLIGHT is not set
CONFIG_FB_MODE_HELPERS=y
CONFIG_FB_TILEBLITTING=y
# CONFIG_FB_CIRRUS is not set
# CONFIG_FB_PM2 is not set
# CONFIG_FB_CYBER2000 is not set
# CONFIG_FB_ARC is not set
# CONFIG_FB_ASILIANT is not set
# CONFIG_FB_IMSTT is not set
# CONFIG_FB_VGA16 is not set
# CONFIG_FB_VESA is not set
# CONFIG_FB_HGA is not set
# CONFIG_FB_S1D13XXX is not set
# CONFIG_FB_NVIDIA is not set
# CONFIG_FB_RIVA is not set
# CONFIG_FB_I810 is not set
# CONFIG_FB_INTEL is not set
# CONFIG_FB_MATROX is not set
# CONFIG_FB_RADEON is not set
# CONFIG_FB_ATY128 is not set
# CONFIG_FB_ATY is not set
CONFIG_FB_SAVAGE=y
CONFIG_FB_SAVAGE_I2C=y
CONFIG_FB_SAVAGE_ACCEL=y
# CONFIG_FB_SIS is not set
# CONFIG_FB_NEOMAGIC is not set
# CONFIG_FB_KYRO is not set
# CONFIG_FB_3DFX is not set
# CONFIG_FB_VOODOO1 is not set
# CONFIG_FB_CYBLA is not set
# CONFIG_FB_TRIDENT is not set
# CONFIG_FB_GEODE is not set
# CONFIG_FB_VIRTUAL is not set

#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
# CONFIG_VGACON_SOFT_SCROLLBACK is not set
CONFIG_VIDEO_SELECT=y
# CONFIG_MDA_CONSOLE is not set
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
# CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set
CONFIG_FONTS=y
# CONFIG_FONT_8x8 is not set
# CONFIG_FONT_8x16 is not set
# CONFIG_FONT_6x11 is not set
CONFIG_FONT_7x14=y
# CONFIG_FONT_PEARL_8x8 is not set
# CONFIG_FONT_ACORN_8x8 is not set
# CONFIG_FONT_MINI_4x6 is not set
# CONFIG_FONT_SUN8x16 is not set
# CONFIG_FONT_SUN12x22 is not set
# CONFIG_FONT_10x18 is not set

#
# Logo configuration
#
CONFIG_LOGO=y
CONFIG_LOGO_LINUX_MONO=y
CONFIG_LOGO_LINUX_VGA16=y
CONFIG_LOGO_LINUX_CLUT224=y
# CONFIG_BACKLIGHT_LCD_SUPPORT is not set

#
# Sound
#
CONFIG_SOUND=y

#
# Advanced Linux Sound Architecture
#
CONFIG_SND=y
CONFIG_SND_TIMER=y
CONFIG_SND_PCM=y
CONFIG_SND_SEQUENCER=y
CONFIG_SND_SEQ_DUMMY=y
CONFIG_SND_OSSEMUL=y
CONFIG_SND_MIXER_OSS=y
CONFIG_SND_PCM_OSS=y
CONFIG_SND_PCM_OSS_PLUGINS=y
CONFIG_SND_SEQUENCER_OSS=y
CONFIG_SND_RTCTIMER=y
CONFIG_SND_SEQ_RTCTIMER_DEFAULT=y
# CONFIG_SND_DYNAMIC_MINORS is not set
# CONFIG_SND_SUPPORT_OLD_API is not set
CONFIG_SND_VERBOSE_PROCFS=y
CONFIG_SND_VERBOSE_PRINTK=y
# CONFIG_SND_DEBUG is not set

#
# Generic devices
#
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
# CONFIG_SND_SERIAL_U16550 is not set
# CONFIG_SND_MPU401 is not set
# CONFIG_SND_AC97_POWER_SAVE is not set

#
# ISA devices
#
# CONFIG_SND_ADLIB is not set
# CONFIG_SND_AD1848 is not set
# CONFIG_SND_CMI8330 is not set
# CONFIG_SND_CS4231 is not set
# CONFIG_SND_CS4232 is not set
# CONFIG_SND_CS4236 is not set
# CONFIG_SND_ES1688 is not set
# CONFIG_SND_ES18XX is not set
# CONFIG_SND_GUSCLASSIC is not set
# CONFIG_SND_GUSEXTREME is not set
# CONFIG_SND_GUSMAX is not set
# CONFIG_SND_OPL3SA2 is not set
# CONFIG_SND_OPTI92X_AD1848 is not set
# CONFIG_SND_OPTI92X_CS4231 is not set
# CONFIG_SND_OPTI93X is not set
# CONFIG_SND_MIRO is not set
# CONFIG_SND_SB8 is not set
# CONFIG_SND_SB16 is not set
# CONFIG_SND_SBAWE is not set
# CONFIG_SND_SGALAXY is not set
# CONFIG_SND_SSCAPE is not set
# CONFIG_SND_WAVEFRONT is not set

#
# PCI devices
#
# CONFIG_SND_AD1889 is not set
# CONFIG_SND_ALS300 is not set
# CONFIG_SND_ALS4000 is not set
# CONFIG_SND_ALI5451 is not set
# CONFIG_SND_ATIIXP is not set
# CONFIG_SND_ATIIXP_MODEM is not set
# CONFIG_SND_AU8810 is not set
# CONFIG_SND_AU8820 is not set
# CONFIG_SND_AU8830 is not set
# CONFIG_SND_AZT3328 is not set
# CONFIG_SND_BT87X is not set
# CONFIG_SND_CA0106 is not set
# CONFIG_SND_CMIPCI is not set
# CONFIG_SND_CS4281 is not set
# CONFIG_SND_CS46XX is not set
# CONFIG_SND_CS5535AUDIO is not set
# CONFIG_SND_DARLA20 is not set
# CONFIG_SND_GINA20 is not set
# CONFIG_SND_LAYLA20 is not set
# CONFIG_SND_DARLA24 is not set
# CONFIG_SND_GINA24 is not set
# CONFIG_SND_LAYLA24 is not set
# CONFIG_SND_MONA is not set
# CONFIG_SND_MIA is not set
# CONFIG_SND_ECHO3G is not set
# CONFIG_SND_INDIGO is not set
# CONFIG_SND_INDIGOIO is not set
# CONFIG_SND_INDIGODJ is not set
# CONFIG_SND_EMU10K1 is not set
# CONFIG_SND_EMU10K1X is not set
# CONFIG_SND_ENS1370 is not set
# CONFIG_SND_ENS1371 is not set
# CONFIG_SND_ES1938 is not set
# CONFIG_SND_ES1968 is not set
# CONFIG_SND_FM801 is not set
# CONFIG_SND_HDA_INTEL is not set
# CONFIG_SND_HDSP is not set
# CONFIG_SND_HDSPM is not set
# CONFIG_SND_ICE1712 is not set
# CONFIG_SND_ICE1724 is not set
CONFIG_SND_INTEL8X0=y
# CONFIG_SND_INTEL8X0M is not set
# CONFIG_SND_KORG1212 is not set
# CONFIG_SND_MAESTRO3 is not set
# CONFIG_SND_MIXART is not set
# CONFIG_SND_NM256 is not set
# CONFIG_SND_PCXHR is not set
# CONFIG_SND_RIPTIDE is not set
# CONFIG_SND_RME32 is not set
# CONFIG_SND_RME96 is not set
# CONFIG_SND_RME9652 is not set
# CONFIG_SND_SONICVIBES is not set
# CONFIG_SND_TRIDENT is not set
# CONFIG_SND_VIA82XX is not set
# CONFIG_SND_VIA82XX_MODEM is not set
# CONFIG_SND_VX222 is not set
# CONFIG_SND_YMFPCI is not set

#
# USB devices
#
# CONFIG_SND_USB_AUDIO is not set
# CONFIG_SND_USB_USX2Y is not set

#
# Open Sound System
#
# CONFIG_SOUND_PRIME is not set

#
# USB support
#
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB_ARCH_HAS_EHCI=y
CONFIG_USB=m
# CONFIG_USB_DEBUG is not set

#
# Miscellaneous USB options
#
CONFIG_USB_DEVICEFS=y
# CONFIG_USB_BANDWIDTH is not set
# CONFIG_USB_DYNAMIC_MINORS is not set
# CONFIG_USB_SUSPEND is not set
# CONFIG_USB_MULTITHREAD_PROBE is not set
# CONFIG_USB_OTG is not set

#
# USB Host Controller Drivers
#
CONFIG_USB_EHCI_HCD=m
# CONFIG_USB_EHCI_SPLIT_ISO is not set
# CONFIG_USB_EHCI_ROOT_HUB_TT is not set
# CONFIG_USB_EHCI_TT_NEWSCHED is not set
# CONFIG_USB_ISP116X_HCD is not set
# CONFIG_USB_OHCI_HCD is not set
CONFIG_USB_UHCI_HCD=m
# CONFIG_USB_SL811_HCD is not set

#
# USB Device Class drivers
#
# CONFIG_USB_ACM is not set
# CONFIG_USB_PRINTER is not set

#
# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support'
#

#
# may also be needed; see USB_STORAGE Help for more information
#
CONFIG_USB_STORAGE=m
# CONFIG_USB_STORAGE_DEBUG is not set
# CONFIG_USB_STORAGE_DATAFAB is not set
# CONFIG_USB_STORAGE_FREECOM is not set
# CONFIG_USB_STORAGE_ISD200 is not set
# CONFIG_USB_STORAGE_DPCM is not set
# CONFIG_USB_STORAGE_USBAT is not set
# CONFIG_USB_STORAGE_SDDR09 is not set
# CONFIG_USB_STORAGE_SDDR55 is not set
# CONFIG_USB_STORAGE_JUMPSHOT is not set
# CONFIG_USB_STORAGE_ALAUDA is not set
# CONFIG_USB_STORAGE_KARMA is not set
# CONFIG_USB_LIBUSUAL is not set

#
# USB Input Devices
#
# CONFIG_USB_HID is not set

#
# USB HID Boot Protocol drivers
#
# CONFIG_USB_KBD is not set
# CONFIG_USB_MOUSE is not set
# CONFIG_USB_AIPTEK is not set
# CONFIG_USB_WACOM is not set
# CONFIG_USB_ACECAD is not set
# CONFIG_USB_KBTAB is not set
# CONFIG_USB_POWERMATE is not set
# CONFIG_USB_TOUCHSCREEN is not set
# CONFIG_USB_YEALINK is not set
# CONFIG_USB_XPAD is not set
# CONFIG_USB_ATI_REMOTE is not set
# CONFIG_USB_ATI_REMOTE2 is not set
# CONFIG_USB_KEYSPAN_REMOTE is not set
# CONFIG_USB_APPLETOUCH is not set
# CONFIG_USB_TRANCEVIBRATOR is not set

#
# USB Imaging devices
#
# CONFIG_USB_MDC800 is not set
# CONFIG_USB_MICROTEK is not set

#
# USB Network Adapters
#
CONFIG_USB_CATC=m
CONFIG_USB_KAWETH=m
CONFIG_USB_PEGASUS=m
CONFIG_USB_RTL8150=m
CONFIG_USB_USBNET=m
CONFIG_USB_NET_AX8817X=m
CONFIG_USB_NET_CDCETHER=m
CONFIG_USB_NET_GL620A=m
CONFIG_USB_NET_NET1080=m
CONFIG_USB_NET_PLUSB=m
CONFIG_USB_NET_RNDIS_HOST=m
CONFIG_USB_NET_CDC_SUBSET=m
CONFIG_USB_ALI_M5632=y
CONFIG_USB_AN2720=y
CONFIG_USB_BELKIN=y
CONFIG_USB_ARMLINUX=y
CONFIG_USB_EPSON2888=y
CONFIG_USB_NET_ZAURUS=m
CONFIG_USB_MON=y

#
# USB port drivers
#

#
# USB Serial Converter support
#
CONFIG_USB_SERIAL=m
# CONFIG_USB_SERIAL_GENERIC is not set
# CONFIG_USB_SERIAL_AIRCABLE is not set
# CONFIG_USB_SERIAL_AIRPRIME is not set
# CONFIG_USB_SERIAL_ARK3116 is not set
# CONFIG_USB_SERIAL_BELKIN is not set
# CONFIG_USB_SERIAL_WHITEHEAT is not set
# CONFIG_USB_SERIAL_DIGI_ACCELEPORT is not set
# CONFIG_USB_SERIAL_CP2101 is not set
# CONFIG_USB_SERIAL_CYPRESS_M8 is not set
# CONFIG_USB_SERIAL_EMPEG is not set
# CONFIG_USB_SERIAL_FTDI_SIO is not set
# CONFIG_USB_SERIAL_FUNSOFT is not set
# CONFIG_USB_SERIAL_VISOR is not set
# CONFIG_USB_SERIAL_IPAQ is not set
# CONFIG_USB_SERIAL_IR is not set
# CONFIG_USB_SERIAL_EDGEPORT is not set
# CONFIG_USB_SERIAL_EDGEPORT_TI is not set
# CONFIG_USB_SERIAL_GARMIN is not set
# CONFIG_USB_SERIAL_IPW is not set
# CONFIG_USB_SERIAL_KEYSPAN_PDA is not set
# CONFIG_USB_SERIAL_KEYSPAN is not set
# CONFIG_USB_SERIAL_KLSI is not set
# CONFIG_USB_SERIAL_KOBIL_SCT is not set
# CONFIG_USB_SERIAL_MCT_U232 is not set
# CONFIG_USB_SERIAL_MOS7720 is not set
# CONFIG_USB_SERIAL_MOS7840 is not set
# CONFIG_USB_SERIAL_NAVMAN is not set
# CONFIG_USB_SERIAL_PL2303 is not set
# CONFIG_USB_SERIAL_QUATECH_ESU100 is not set
# CONFIG_USB_SERIAL_HP4X is not set
# CONFIG_USB_SERIAL_SAFE is not set
# CONFIG_USB_SERIAL_SIERRAWIRELESS is not set
# CONFIG_USB_SERIAL_TI is not set
# CONFIG_USB_SERIAL_CYBERJACK is not set
# CONFIG_USB_SERIAL_XIRCOM is not set
# CONFIG_USB_SERIAL_OPTION is not set
# CONFIG_USB_SERIAL_OMNINET is not set

#
# USB Miscellaneous drivers
#
# CONFIG_USB_EMI62 is not set
# CONFIG_USB_EMI26 is not set
# CONFIG_USB_ADUTUX is not set
# CONFIG_USB_AUERSWALD is not set
# CONFIG_USB_RIO500 is not set
# CONFIG_USB_LEGOTOWER is not set
# CONFIG_USB_LCD is not set
# CONFIG_USB_LED is not set
# CONFIG_USB_CYPRESS_CY7C63 is not set
# CONFIG_USB_CYTHERM is not set
# CONFIG_USB_PHIDGET is not set
# CONFIG_USB_IDMOUSE is not set
# CONFIG_USB_APPLEDISPLAY is not set
# CONFIG_USB_SISUSBVGA is not set
# CONFIG_USB_LD is not set
# CONFIG_USB_TEST is not set
# CONFIG_USB_GOTEMP is not set

#
# USB DSL modem support
#

#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set

#
# MMC/SD Card support
#
# CONFIG_MMC is not set

#
# LED devices
#
# CONFIG_NEW_LEDS is not set

#
# LED drivers
#

#
# LED Triggers
#

#
# InfiniBand support
#
# CONFIG_INFINIBAND is not set

#
# EDAC - error detection and reporting (RAS) (EXPERIMENTAL)
#
# CONFIG_EDAC is not set

#
# Real Time Clock
#
# CONFIG_RTC_CLASS is not set

#
# DMA Engine support
#
# CONFIG_DMA_ENGINE is not set

#
# DMA Clients
#

#
# DMA Devices
#

#
# Userspace I/O
#
# CONFIG_UIO is not set

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

#
# Caches
#
# CONFIG_FSCACHE is not set

#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
CONFIG_ZISOFS_FS=y
CONFIG_UDF_FS=y
CONFIG_UDF_NLS=y

#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=y
CONFIG_VFAT_FS=y
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
# CONFIG_NTFS_FS is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_PROC_SYSCTL=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
# CONFIG_TMPFS_POSIX_ACL is not set
CONFIG_HUGETLBFS=y
CONFIG_HUGETLB_PAGE=y
CONFIG_RAMFS=y
# CONFIG_CONFIGFS_FS is not set

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

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

#
# Partition Types
#
# CONFIG_PARTITION_ADVANCED is not set
CONFIG_MSDOS_PARTITION=y

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

#
# Distributed Lock Manager
#

#
# Instrumentation Support
#
# CONFIG_PROFILING is not set
# CONFIG_KPROBES is not set

#
# Kernel hacking
#
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
# CONFIG_PRINTK_TIME is not set
CONFIG_ENABLE_MUST_CHECK=y
# CONFIG_MAGIC_SYSRQ is not set
CONFIG_UNUSED_SYMBOLS=y
# CONFIG_DEBUG_KERNEL is not set
CONFIG_LOG_BUF_SHIFT=14
CONFIG_DEBUG_BUGVERBOSE=y
# CONFIG_DEBUG_FS is not set
# CONFIG_UNWIND_INFO is not set
# CONFIG_PROFILE_LIKELY is not set
CONFIG_EARLY_PRINTK=y
CONFIG_4KSTACKS=y
CONFIG_X86_FIND_SMP_CONFIG=y
CONFIG_X86_MPPARSE=y
CONFIG_DOUBLEFAULT=y

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

#
# Cryptographic options
#
# CONFIG_CRYPTO is not set

#
# Hardware crypto devices
#

#
# Library routines
#
# CONFIG_CRC_CCITT is not set
# CONFIG_CRC16 is not set
CONFIG_CRC32=y
CONFIG_LIBCRC32C=y
CONFIG_ZLIB_INFLATE=y
CONFIG_PLIST=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_X86_BIOS_REBOOT=y
CONFIG_KTIME_SCALAR=y

Linux version 2.6.18-rc2-mm1 (jurriaan@thinkpad) (gcc version 4.1.2 20060729 (prerelease) (Debian 4.1.1-10)) #1 PREEMPT Wed Aug 2 11:37:02 CEST 2006
BIOS-provided physical RAM map:
sanitize start
sanitize end
copy_e820_map() start: 0000000000000000 size: 000000000009f000 end: 000000000009f000 type: 1
copy_e820_map() type is E820_RAM
copy_e820_map() start: 000000000009f000 size: 0000000000001000 end: 00000000000a0000 type: 2
copy_e820_map() start: 00000000000dc000 size: 0000000000024000 end: 0000000000100000 type: 2
copy_e820_map() start: 0000000000100000 size: 000000003fe70000 end: 000000003ff70000 type: 1
copy_e820_map() type is E820_RAM
copy_e820_map() start: 000000003ff70000 size: 000000000000e000 end: 000000003ff7e000 type: 3
copy_e820_map() start: 000000003ff7e000 size: 0000000000002000 end: 000000003ff80000 type: 4
copy_e820_map() start: 000000003ff80000 size: 0000000000080000 end: 0000000040000000 type: 2
copy_e820_map() start: 00000000ff800000 size: 0000000000800000 end: 0000000100000000 type: 2
 BIOS-e820: 0000000000000000 - 000000000009f000 (usable)
 BIOS-e820: 000000000009f000 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000dc000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000003ff70000 (usable)
 BIOS-e820: 000000003ff70000 - 000000003ff7e000 (ACPI data)
 BIOS-e820: 000000003ff7e000 - 000000003ff80000 (ACPI NVS)
 BIOS-e820: 000000003ff80000 - 0000000040000000 (reserved)
 BIOS-e820: 00000000ff800000 - 0000000100000000 (reserved)
127MB HIGHMEM available.
896MB LOWMEM available.
On node 0 totalpages: 262000
  DMA zone: 4096 pages, LIFO batch:0
  Normal zone: 225280 pages, LIFO batch:31
  HighMem zone: 32624 pages, LIFO batch:7
DMI present.
ACPI: RSDP (v002 IBM                                   ) @ 0x000f7450
ACPI: XSDT (v001 IBM    TP-1A    0x00001170  LTP 0x00000000) @ 0x3ff73af9
ACPI: FADT (v001 IBM    TP-1A    0x00001170 IBM  0x00000001) @ 0x3ff73c00
ACPI: SSDT (v001 IBM    TP-1A    0x00001170 MSFT 0x0100000d) @ 0x3ff73cb4
ACPI: ECDT (v001 IBM    TP-1A    0x00001170 IBM  0x00000001) @ 0x3ff7deca
ACPI: BOOT (v001 IBM    TP-1A    0x00001170  LTP 0x00000001) @ 0x3ff7dfd8
ACPI: DSDT (v001 IBM    TP-1A    0x00001170 MSFT 0x0100000d) @ 0x00000000
ACPI: PM-Timer IO Port: 0x1008
Allocating PCI resources starting at 50000000 (gap: 40000000:bf800000)
Detected 1132.405 MHz processor.
Built 1 zonelists.  Total pages: 262000
Kernel command line: root=/dev/hda1 video=savagefb:1024x768@60 atkbd.softrepeat=1
Local APIC disabled by BIOS -- you can enable it with "lapic"
mapped APIC to ffffd000 (01803000)
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Initializing CPU#0
CPU 0 irqstacks, hard=c0442000 soft=c0441000
PID hash table entries: 4096 (order: 12, 16384 bytes)
Console: colour VGA+ 80x25
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 1034796k/1048000k available (2268k kernel code, 12576k reserved, 864k data, 172k init, 130496k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay using timer specific routine.. 2266.27 BogoMIPS (lpj=4532547)
Mount-cache hash table entries: 512
CPU: After generic identify, caps: 0383f9ff 00000000 00000000 00000000 00000000 00000000 00000000
CPU: After vendor identify, caps: 0383f9ff 00000000 00000000 00000000 00000000 00000000 00000000
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 512K
CPU: After all inits, caps: 0383f9ff 00000000 00000000 00000040 00000000 00000000 00000000
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
Compat vDSO mapped to ffffe000.
CPU: Intel(R) Pentium(R) III Mobile CPU      1133MHz stepping 01
Checking 'hlt' instruction... OK.
ACPI: Core revision 20060707
 tbxface-0107 [01] load_tables           : ACPI Tables successfully acquired
Parsing all Control Methods:
Table [DSDT](id 0006) - 1206 Objects with 60 Devices 363 Methods 18 Regions
Parsing all Control Methods:
Table [SSDT](id 0004) - 1 Objects with 0 Devices 1 Methods 0 Regions
ACPI Namespace successfully loaded at root c0460e70
ACPI: setting ELCR to 0200 (from 0e20)
evxfevnt-0089 [02] enable                : Transition to ACPI mode successful
NET: Registered protocol family 16
ACPI: bus type pci registered
PCI: PCI BIOS revision 2.10 entry at 0xfd8fe, last bus=8
Setting up standard PCI resources
evgpeblk-0951 [04] ev_create_gpe_block   : GPE 00 to 0F [_GPE] 2 regs on int 0x9
evgpeblk-0951 [04] ev_create_gpe_block   : GPE 10 to 1F [_GPE] 2 regs on int 0x9
evgpeblk-1048 [03] ev_initialize_gpe_bloc: Found 6 Wake, Enabled 0 Runtime GPEs in this block
evgpeblk-1048 [03] ev_initialize_gpe_bloc: Found 2 Wake, Enabled 0 Runtime GPEs in this block
ACPI: Found ECDT
Completing Region/Field/Buffer/Package initialization:....................................................................................................................................................................................................................................
Initialized 17/18 Regions 124/124 Fields 61/61 Buffers 26/34 Packages (1216 nodes)
Initializing Device/Processor/Thermal objects by executing _INI methods:........
Executed 8 _INI methods requiring 2 _STA executions (examined 64 objects)
ACPI: Interpreter enabled
ACPI: Using PIC for interrupt routing
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 *5 6 7 9 10 11)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 *9 10 11)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 *9 10 11)
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 9 *10 11)
ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 9 10 11) *0, disabled.
ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 9 10 11) *0, disabled.
ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 9 10 11) *0, disabled.
ACPI: PCI Root Bridge [PCI0] (0000:00)
PCI: Probing PCI hardware (bus 00)
PCI quirk: region 1000-107f claimed by ICH4 ACPI/GPIO/TCO
PCI quirk: region 1180-11bf claimed by ICH4 GPIO
PCI: Ignoring BAR0-3 of IDE controller 0000:00:1f.1
Boot video device is 0000:01:00.0
PCI: Firmware left 0000:02:08.0 e100 interrupts enabled, disabling
PCI: Transparent bridge - 0000:00:1e.0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: Embedded Controller [EC] (gpe 28) interrupt mode.
ACPI: Power Resource [PUBS] (on)
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.AGP_._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCI1._PRT]
Intel 82802 RNG detected
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post a report
PCI: Bridge: 0000:00:01.0
  IO window: disabled.
  MEM window: c0100000-c01fffff
  PREFETCH window: e0000000-ebffffff
PCI: Bus 3, cardbus bridge: 0000:02:00.0
  IO window: 00002000-000020ff
  IO window: 00002400-000024ff
  PREFETCH window: f0000000-f1ffffff
  MEM window: c2000000-c3ffffff
PCI: Bus 7, cardbus bridge: 0000:02:00.1
  IO window: 00002800-000028ff
  IO window: 00002c00-00002cff
  PREFETCH window: f2000000-f3ffffff
  MEM window: c4000000-c5ffffff
PCI: Bridge: 0000:00:1e.0
  IO window: 2000-6fff
  MEM window: c0200000-cfffffff
  PREFETCH window: f0000000-f7ffffff
PCI: Setting latency timer of device 0000:00:1e.0 to 64
ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 11
PCI: setting IRQ 11 as level-triggered
ACPI: PCI Interrupt 0000:02:00.0[A] -> Link [LNKA] -> GSI 11 (level, low) -> IRQ 11
ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 5
PCI: setting IRQ 5 as level-triggered
ACPI: PCI Interrupt 0000:02:00.1[B] -> Link [LNKB] -> GSI 5 (level, low) -> IRQ 5
NET: Registered protocol family 2
IP route cache hash table entries: 32768 (order: 5, 131072 bytes)
TCP established hash table entries: 131072 (order: 7, 524288 bytes)
TCP bind hash table entries: 65536 (order: 6, 262144 bytes)
TCP: Hash tables configured (established 131072 bind 65536)
TCP reno registered
Simple Boot Flag at 0x35 set to 0x1
speedstep: frequency transition measured seems out of range (0 nSec), falling back to a safe one of 500000 nSec.
IA-32 Microcode Update Driver: v1.14a <tigran@veritas.com>
highmem bounce pool size: 64 pages
Total HugeTLB memory allocated, 0
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
ACPI: PCI Interrupt 0000:01:00.0[A] -> Link [LNKA] -> GSI 11 (level, low) -> IRQ 11
savagefb: mapped io at f8880000
savagefb: probed videoram:  16384k
savagefb: Detected current MCLK value of 286364 kHz
savagefb: 1024x768 TFT LCD panel detected and active
savagefb: Limiting video mode to 1024x768
savagefb: mapped framebuffer at f8980000, pbase == e8000000
savagefb v0.4.0_2.6: 16256kB VRAM, using 1024x768, 48.364kHz, 60Hz
Console: switching to colour frame buffer device 146x54
fb: S3 SuperSavage frame buffer device
ACPI: AC Adapter [AC] (on-line)
ACPI: Battery Slot [BAT0] (battery present)
ACPI: Power Button (FF) [PWRF]
ACPI: Lid Switch [LID]
ACPI: Sleep Button (CM) [SLPB]
ACPI: Video Device [VID] (multi-head: yes  rom: no  post: no)
Using specific hotkey driver
ACPI: CPU0 (power states: C1[C1] C2[C2] C3[C3])
ACPI: Thermal Zone [THM0] (59 C)
ibm_acpi: IBM ThinkPad ACPI Extras v0.12a
ibm_acpi: http://ibm-acpi.sf.net/
Real Time Clock Driver v1.12ac
Non-volatile memory driver v1.2
Linux agpgart interface v0.101 (c) Dave Jones
agpgart: Detected an Intel 830M Chipset.
agpgart: AGP aperture is 256M @ 0xd0000000
[drm] Initialized drm 1.0.1 20051102
[drm] Initialized savage 2.4.1 20050313 on minor 0
Hangcheck: starting hangcheck timer 0.9.0 (tick is 180 seconds, margin is 60 seconds).
Hangcheck: Using get_cycles().
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a NS16550A
Floppy drive(s): fd0 is 1.44M
FDC 0 is a National Semiconductor PC87306
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
loop: loaded (max 8 devices)
nbd: registered device at major 43
e100: Intel(R) PRO/100 Network Driver, 3.5.10-k2-NAPI
e100: Copyright(c) 1999-2005 Intel Corporation
ACPI: PCI Interrupt Link [LNKE] enabled at IRQ 10
PCI: setting IRQ 10 as level-triggered
ACPI: PCI Interrupt 0000:02:08.0[A] -> Link [LNKE] -> GSI 10 (level, low) -> IRQ 10
e100: eth0: e100_probe: addr 0xc0200000, irq 10, MAC addr 00:D0:59:DA:B0:69
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ICH3M: IDE controller at PCI slot 0000:00:1f.1
PCI: Enabling device 0000:00:1f.1 (0005 -> 0007)
ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 9
PCI: setting IRQ 9 as level-triggered
ACPI: PCI Interrupt 0000:00:1f.1[A] -> Link [LNKC] -> GSI 9 (level, low) -> IRQ 9
ICH3M: chipset revision 2
ICH3M: not 100% native mode: will probe irqs later
    ide0: BM-DMA at 0x1860-0x1867, BIOS settings: hda:DMA, hdb:pio
    ide1: BM-DMA at 0x1868-0x186f, BIOS settings: hdc:DMA, hdd:pio
Probing IDE interface ide0...
hda: IC25N030ATCS04-0, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Probing IDE interface ide1...
hdc: DW-28E, ATAPI CD/DVD-ROM drive
ide1 at 0x170-0x177,0x376 on irq 15
hda: max request size: 128KiB
hda: 58605120 sectors (30005 MB) w/1768KiB Cache, CHS=62016/15/63
hda: cache flushes not supported
 hda: hda1 hda2
hdc: ATAPI 24X DVD-ROM CD-R/RW drive, 1658kB Cache
Uniform CD-ROM driver Revision: 3.20
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
mice: PS/2 mouse device common for all mice
i2c /dev entries driver
ACPI: PCI Interrupt 0000:00:1f.3[B] -> Link [LNKB] -> GSI 5 (level, low) -> IRQ 5
input: AT Translated Set 2 keyboard as /class/input/input0
IBM TrackPoint firmware: 0x0e, buttons: 3/3
input: TPPS/2 IBM TrackPoint as /class/input/input1
pc87360: PC8736x not detected, module not inserted.
Advanced Linux Sound Architecture Driver Version 1.0.12rc1 (Thu Jun 22 13:55:50 2006 UTC).
PCI: Enabling device 0000:00:1f.5 (0000 -> 0001)
ACPI: PCI Interrupt 0000:00:1f.5[B] -> Link [LNKB] -> GSI 5 (level, low) -> IRQ 5
PCI: Setting latency timer of device 0000:00:1f.5 to 64
ALSA sound/pci/ac97/ac97_codec.c:2053: AC'97 0 analog subsections not ready
intel8x0_measure_ac97_clock: measured 56003 usecs
intel8x0: clocking to 49098
ALSA device list:
  #0: Intel 82801CA-ICH3 with CS4299 at 0x1c00, irq 5
TCP bic registered
NET: Registered protocol family 1
Using IPI Shortcut mode
ACPI: (supports S0 S3 S4 S5)
Time: tsc clocksource has been installed.
Time: acpi_pm clocksource has been installed.
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 172k freed
Adding 1330552k swap on /dev/hda2.  Priority:-1 extents:1 across:1330552k
EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
USB Universal Host Controller Interface driver v3.0
ACPI: PCI Interrupt 0000:00:1d.0[A] -> Link [LNKA] -> GSI 11 (level, low) -> IRQ 11
PCI: Setting latency timer of device 0000:00:1d.0 to 64
uhci_hcd 0000:00:1d.0: UHCI Host Controller
uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 1
uhci_hcd 0000:00:1d.0: irq 11, io base 0x00001800
usb usb1: new device found, idVendor=0000, idProduct=0000
usb usb1: new device strings: Mfr=3, Product=2, SerialNumber=1
usb usb1: Product: UHCI Host Controller
usb usb1: Manufacturer: Linux 2.6.18-rc2-mm1 uhci_hcd
usb usb1: SerialNumber: 0000:00:1d.0
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 9
ACPI: PCI Interrupt 0000:00:1d.1[B] -> Link [LNKD] -> GSI 9 (level, low) -> IRQ 9
PCI: Setting latency timer of device 0000:00:1d.1 to 64
uhci_hcd 0000:00:1d.1: UHCI Host Controller
uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 2
uhci_hcd 0000:00:1d.1: irq 9, io base 0x00001820
usb usb2: new device found, idVendor=0000, idProduct=0000
usb usb2: new device strings: Mfr=3, Product=2, SerialNumber=1
usb usb2: Product: UHCI Host Controller
usb usb2: Manufacturer: Linux 2.6.18-rc2-mm1 uhci_hcd
usb usb2: SerialNumber: 0000:00:1d.1
usb usb2: configuration #1 chosen from 1 choice
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
ACPI: PCI Interrupt 0000:00:1d.2[C] -> Link [LNKC] -> GSI 9 (level, low) -> IRQ 9
PCI: Setting latency timer of device 0000:00:1d.2 to 64
uhci_hcd 0000:00:1d.2: UHCI Host Controller
uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 3
uhci_hcd 0000:00:1d.2: irq 9, io base 0x00001840
usb usb3: new device found, idVendor=0000, idProduct=0000
usb usb3: new device strings: Mfr=3, Product=2, SerialNumber=1
usb usb3: Product: UHCI Host Controller
usb usb3: Manufacturer: Linux 2.6.18-rc2-mm1 uhci_hcd
usb usb3: SerialNumber: 0000:00:1d.2
usb usb3: configuration #1 chosen from 1 choice
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
e100: eth0: e100_watchdog: link up, 100Mbps, full-duplex
-- 
>From this, Udinaas surmised, various lessons could be drawn, should one
be inclined to draw lessons from multiple acts of stupidity.
	Steven Erikson - Midnight Tides
Debian (Unstable) GNU/Linux 2.6.18-rc4-mm3 4423 bogomips load 0.19

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: 2.6.18-rc6-mm1
  2006-09-08 19:23 ` 2.6.18-rc6-mm1 Michal Piotrowski
@ 2006-09-08 19:43   ` Andrew Morton
  2006-09-08 20:01     ` 2.6.18-rc6-mm1 Michal Piotrowski
  0 siblings, 1 reply; 114+ messages in thread
From: Andrew Morton @ 2006-09-08 19:43 UTC (permalink / raw)
  To: Michal Piotrowski; +Cc: linux-kernel, Ingo Molnar

On Fri, 08 Sep 2006 21:23:10 +0200
Michal Piotrowski <michal.k.k.piotrowski@gmail.com> wrote:

> Hi,
> 
> Andrew Morton wrote:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc6/2.6.18-rc6-mm1/
> > 
> > - autofs4 mounting of NFS is still sick.
> 
> BUG: unable to handle kernel paging request at virtual address fdb52df8
>  printing eip:
>  c013894c
> *pde = 37c85067
> *pte = 00000000
> Oops: 0000 [#1]
> 4K_STACKS PREEMPT SMP
> last sysfs file: /devices/platform/i2c-9191/9191-0290/temp2_input
> Modules linked in: ipv6 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 proces
> sor fan container evdev snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_se
> q_device sk98lin snd_pcm_oss snd_mixer_oss snd_pcm skge snd_timer snd soundcore snd_page_alloc ide_cd i2c_i801 iTCO_wdt inte
> l_agp cdrom agpgart rtc unix
> CPU:    0
> EIP:    0060:[<c013894c>]    Not tainted VLI
> EFLAGS: 00210212   (2.6.18-rc6-mm1 #115)
> EIP is at __module_text_address+0xf/0x5c
> eax: fdb54000   ebx: fdb67c04   ecx: f7c10000   edx: fdb52d00
> esi: 000000fa   edi: f7c10f9c   ebp: 00000005   esp: f7c10e68
> ds: 007b   es: 007b   ss: 0068
> Process udevd (pid: 20250, ti=f7c10000 task=f7c21000 task.ti=f7c10000)
> Stack: f7c10000 c5f36030 c012fb6c f7c10000 c014f61b c0341710 000284d0 00000010
>        f7c21000 00000002 f7c10000 00200202 f57ce3c0 f52a8bfc f57ce3c0 f76a6ca4
>       f4a3c800 c01575e4 f52a8bfc f7d31ec0 f76a6ca4 80010000 c015894c f76a6ca4
> Call Trace:
> [<c012fb6c>] __kernel_text_address+0x18/0x23
> [<c014f61b>] __alloc_pages+0x301/0x313
> [<c01575e4>] __pte_alloc+0xf/0x78
> [<c015894c>] copy_page_range+0x139/0x3dd
> [<c011e67b>] copy_process+0xc1e/0x13cf
> [<c011f001>] do_fork+0xb6/0x1d2
> [<c017cdfa>] mntput_no_expire+0x11/0x81
> [<c010122e>] sys_clone+0x28/0x2d
> [<c0102fc6>] sysenter_past_esp+0x5f/0x85
> [<c0110033>] wakeup_pmode_return+0x33/0x55
> =======================
> Code: 31 c0 5b 5e 5f 5d c3 83 01 01 83 51 04 00 8b 12 31 c0 81 fa 10 eb 33 c0 0f 45 c2 c3 5
> 6 53 89 c1 8b 15 10 eb 33 c0 83 ea 04 eb 20 <8b> b2 f8 00 00 00 8b 82 e8 00 00 00 39 c1 72 23 01 f0 39 c1 73
> Sep  8 20:23:34 euridica kernel: EIP: [<c013894c>] __module_text_address+0xf/0x5c SS:ESP 0068:f7c10e68

boggle.  Your modules list seems to have got trashed.

Presumably setting CONFIG_PAGE_OWNER=n will make that go away.

What were you doing when this happened?  That output is not present in
http://www.stardust.webpages.pl/files/mm/2.6.18-rc6-mm1/mm-dmesg

> config file -> http://www.stardust.webpages.pl/files/mm/2.6.18-rc6-mm1/mm-config
> Unfortunately, this kernel was build without debugging symbols. I'll try to reproduce this oops with CONFIG_DEBUG_*=y.
> 
> Ingo, can you take a look at this?
> 
> BUG: warning at /usr/src/linux-mm/kernel/lockdep.c:2359/check_flags()
>  [<c01041ca>] dump_trace+0x63/0x1ca
>  [<c0104343>] show_trace_log_lvl+0x12/0x25
>  [<c01049a3>] show_trace+0xd/0x10
>  [<c0104a68>] dump_stack+0x16/0x18
>  [<c0138553>] check_flags+0x92/0x220
>  [<c013b033>] lock_acquire+0x3a/0x88
>  [<c0136d32>] down_write+0x28/0x43
>  [<c0164a9b>] sys_brk+0x20/0xd6
>  [<c0103166>] sysenter_past_esp+0x5f/0x99
> DWARF2 unwinder stuck at sysenter_past_esp+0x5f/0x99
> 
> Leftover inexact backtrace:
> 
>  =======================
> irq event stamp: 603424
> hardirqs last  enabled at (603423): [<c0103238>] restore_nocheck+0x12/0x15
> hardirqs last disabled at (603424): [<c0103173>] sysenter_past_esp+0x6c/0x99
> softirqs last  enabled at (603376): [<c0126a61>] __do_softirq+0xe4/0xea
> softirqs last disabled at (603371): [<c0105b3b>] do_softirq+0x6d/0x11f
> 

That's

	DEBUG_LOCKS_WARN_ON(!current->hardirqs_enabled);

and as far as I can see there was no preceding oops.

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: 2.6.18-rc6-mm1
  2006-09-08 19:30 ` 2.6.18-rc6-mm1 thunder7
@ 2006-09-08 19:44   ` Andrew Morton
  2006-09-09  9:04     ` 2.6.18-rc6-mm1 thunder7
  0 siblings, 1 reply; 114+ messages in thread
From: Andrew Morton @ 2006-09-08 19:44 UTC (permalink / raw)
  To: Jurriaan; +Cc: linux-kernel

On Fri, 8 Sep 2006 21:30:41 +0200
thunder7@xs4all.nl wrote:

> From: Andrew Morton <akpm@osdl.org>
> Date: Fri, Sep 08, 2006 at 01:13:17AM -0700
> > 
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc6/2.6.18-rc6-mm1/
> > 
> This throws an oops on my IBM Thinkpad T23 notebook. Some parts scroll
> off the screen, but the visible stack trace goes like this:
> 
> savagefb_probe_i2c_connector
> savagefb_probe
> pci_match_device
> ....
> EIP: fb_ddc_read ....
> 
> .config and dmesg attached. 2.6.18-rc2-mm1 works just fine here.

We'd really need to see that trace, please.  netconsole is worth setting
up, if you have another machine on the LAN.

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: 2.6.18-rc6-mm1
  2006-09-08 19:43   ` 2.6.18-rc6-mm1 Andrew Morton
@ 2006-09-08 20:01     ` Michal Piotrowski
  0 siblings, 0 replies; 114+ messages in thread
From: Michal Piotrowski @ 2006-09-08 20:01 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel, Ingo Molnar

On 08/09/06, Andrew Morton <akpm@osdl.org> wrote:
> On Fri, 08 Sep 2006 21:23:10 +0200
> Michal Piotrowski <michal.k.k.piotrowski@gmail.com> wrote:
>
> > Hi,
> >
> > Andrew Morton wrote:
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc6/2.6.18-rc6-mm1/
> > >
> > > - autofs4 mounting of NFS is still sick.
> >
> > BUG: unable to handle kernel paging request at virtual address fdb52df8
> >  printing eip:
> >  c013894c
> > *pde = 37c85067
> > *pte = 00000000
> > Oops: 0000 [#1]
> > 4K_STACKS PREEMPT SMP
> > last sysfs file: /devices/platform/i2c-9191/9191-0290/temp2_input
> > Modules linked in: ipv6 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 proces
> > sor fan container evdev snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_se
> > q_device sk98lin snd_pcm_oss snd_mixer_oss snd_pcm skge snd_timer snd soundcore snd_page_alloc ide_cd i2c_i801 iTCO_wdt inte
> > l_agp cdrom agpgart rtc unix
> > CPU:    0
> > EIP:    0060:[<c013894c>]    Not tainted VLI
> > EFLAGS: 00210212   (2.6.18-rc6-mm1 #115)
> > EIP is at __module_text_address+0xf/0x5c
> > eax: fdb54000   ebx: fdb67c04   ecx: f7c10000   edx: fdb52d00
> > esi: 000000fa   edi: f7c10f9c   ebp: 00000005   esp: f7c10e68
> > ds: 007b   es: 007b   ss: 0068
> > Process udevd (pid: 20250, ti=f7c10000 task=f7c21000 task.ti=f7c10000)
> > Stack: f7c10000 c5f36030 c012fb6c f7c10000 c014f61b c0341710 000284d0 00000010
> >        f7c21000 00000002 f7c10000 00200202 f57ce3c0 f52a8bfc f57ce3c0 f76a6ca4
> >       f4a3c800 c01575e4 f52a8bfc f7d31ec0 f76a6ca4 80010000 c015894c f76a6ca4
> > Call Trace:
> > [<c012fb6c>] __kernel_text_address+0x18/0x23
> > [<c014f61b>] __alloc_pages+0x301/0x313
> > [<c01575e4>] __pte_alloc+0xf/0x78
> > [<c015894c>] copy_page_range+0x139/0x3dd
> > [<c011e67b>] copy_process+0xc1e/0x13cf
> > [<c011f001>] do_fork+0xb6/0x1d2
> > [<c017cdfa>] mntput_no_expire+0x11/0x81
> > [<c010122e>] sys_clone+0x28/0x2d
> > [<c0102fc6>] sysenter_past_esp+0x5f/0x85
> > [<c0110033>] wakeup_pmode_return+0x33/0x55
> > =======================
> > Code: 31 c0 5b 5e 5f 5d c3 83 01 01 83 51 04 00 8b 12 31 c0 81 fa 10 eb 33 c0 0f 45 c2 c3 5
> > 6 53 89 c1 8b 15 10 eb 33 c0 83 ea 04 eb 20 <8b> b2 f8 00 00 00 8b 82 e8 00 00 00 39 c1 72 23 01 f0 39 c1 73
> > Sep  8 20:23:34 euridica kernel: EIP: [<c013894c>] __module_text_address+0xf/0x5c SS:ESP 0068:f7c10e68
>
> boggle.  Your modules list seems to have got trashed.
>
> Presumably setting CONFIG_PAGE_OWNER=n will make that go away.
>
> What were you doing when this happened?

It appeared during reboot.

>  That output is not present in
> http://www.stardust.webpages.pl/files/mm/2.6.18-rc6-mm1/mm-dmesg

This dmesg log is from second bug.

>
> > config file -> http://www.stardust.webpages.pl/files/mm/2.6.18-rc6-mm1/mm-config
> > Unfortunately, this kernel was build without debugging symbols. I'll try to reproduce this oops with CONFIG_DEBUG_*=y.
> >

Regards,
Michal

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

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: [linux-usb-devel] 2.6.18-rc6-mm1
  2006-09-08 14:26 ` 2.6.18-rc6-mm1 Rafael J. Wysocki
@ 2006-09-08 20:44   ` Alan Stern
  2006-09-08 22:57     ` Rafael J. Wysocki
  0 siblings, 1 reply; 114+ messages in thread
From: Alan Stern @ 2006-09-08 20:44 UTC (permalink / raw)
  To: Rafael J. Wysocki; +Cc: Andrew Morton, linux-kernel, USB development list

On Fri, 8 Sep 2006, Andrew Morton wrote:

> Alan, is this likely to be due to your USB PM changes?

It's possible.  Most of those changes are innocuous.  They add routines
that don't get used until a later patch.  However one of them might be
responsible.


On Fri, 8 Sep 2006, Rafael J. Wysocki wrote:

> On Friday, 8 September 2006 10:13, Andrew Morton wrote:
> > 
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc6/2.6.18-rc6-mm1/
> 
> ohci_hcd doesn't work after a resume from disk on HPC nx6325, worked on
> 2.6.18-rc5-mm1.
> 
> It helps if I rmmod and modprobe it after the resume.

This patch affects OHCI.  You can try reverting it, to see if that makes 
any difference.  It probably should have been left out of -mm, since it 
interacts pretty strongly with some later USB PM patches that did get left 
out.

	gregkh-usb-usbcore-remove-usb_suspend_root_hub.patch

> Here's the relevant part of the dmesg output:
> 
> usb usb1: resuming
>  usbdev1.1_ep00: PM: resume from 0, parent usb1 still 1
> hub 1-0:1.0: PM: resume from 0, parent usb1 still 1
> hub 1-0:1.0: resuming
>  usbdev1.1: PM: resume from 0, parent usb1 still 1

If reverting that patch doesn't help, please post the relevant dmesg log 
after setting CONFIG_USB_DEBUG.

Alan Stern


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: [linux-usb-devel] 2.6.18-rc6-mm1
  2006-09-08 20:44   ` [linux-usb-devel] 2.6.18-rc6-mm1 Alan Stern
@ 2006-09-08 22:57     ` Rafael J. Wysocki
  2006-09-11 22:08       ` Rafael J. Wysocki
  2006-09-13 12:07       ` [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem Rafael J. Wysocki
  0 siblings, 2 replies; 114+ messages in thread
From: Rafael J. Wysocki @ 2006-09-08 22:57 UTC (permalink / raw)
  To: Alan Stern; +Cc: Andrew Morton, linux-kernel, USB development list

On Friday, 8 September 2006 22:44, Alan Stern wrote:
> On Fri, 8 Sep 2006, Andrew Morton wrote:
> 
> > Alan, is this likely to be due to your USB PM changes?
> 
> It's possible.  Most of those changes are innocuous.  They add routines
> that don't get used until a later patch.  However one of them might be
> responsible.

Well, after recompiling the kernel for several times (because of a different
problem) I'm no longer able to reproduce the problem.

Sorry for the noise.

Greetings,
Rafael


-- 
You never change things by fighting the existing reality.
		R. Buckminster Fuller

^ permalink raw reply	[flat|nested] 114+ messages in thread

* lockdep warning in check_flags()
  2006-09-08  8:13 2.6.18-rc6-mm1 Andrew Morton
                   ` (7 preceding siblings ...)
  2006-09-08 19:30 ` 2.6.18-rc6-mm1 thunder7
@ 2006-09-09  8:35 ` Frederik Deweerdt
  2006-09-11  5:43   ` Ingo Molnar
       [not found] ` <4503DC64.9070007@free.fr>
  2006-09-11 21:19 ` 2.6.18-rc6-mm1 Mark Haverkamp
  10 siblings, 1 reply; 114+ messages in thread
From: Frederik Deweerdt @ 2006-09-09  8:35 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel, mingo, arjanv

On Fri, Sep 08, 2006 at 01:13:17AM -0700, Andrew Morton wrote:
> 
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc6/2.6.18-rc6-mm1/
> 
Lockdep issues the following warning:

[   16.835268] Freeing unused kernel memory: 260k freed
[   16.842715] Write protecting the kernel read-only data: 432k
[   17.796518] BUG: warning at kernel/lockdep.c:2359/check_flags()
[   17.804117]  [<c0104436>] dump_trace+0x1f3/0x22a
[   17.811514]  [<c0104493>] show_trace_log_lvl+0x26/0x3c
[   17.818984]  [<c0104b58>] show_trace+0x1b/0x1d
[   17.826397]  [<c0104c43>] dump_stack+0x24/0x26
[   17.833856]  [<c013775e>] check_flags+0x1e4/0x2b1
[   17.841400]  [<c013a9e2>] lock_acquire+0x21/0x7a
[   17.848977]  [<c0135a50>] down_write+0x50/0x69
[   17.856557]  [<c01640d4>] sys_brk+0x23/0xe7
[   17.864105]  [<c01031f6>] sysenter_past_esp+0x5f/0x99
[   17.871556]  [<b7faf410>] 0xb7faf410
[   17.878831]  =======================
[   17.885839] irq event stamp: 8318
[   17.892746] hardirqs last  enabled at (8317): [<c01032c8>] restore_nocheck+0x12/0x15
[   17.906778] hardirqs last disabled at (8318): [<c0103203>] sysenter_past_esp+0x6c/0x99
[   17.921481] softirqs last  enabled at (7128): [<c0123cd1>] __do_softirq+0xe9/0xfa
[   17.936962] softirqs last disabled at (7121): [<c0123d3e>] do_softirq+0x5c/0x60

I've replaced the DEBUG_LOCKS_WARN_ON by a BUG, and it appears that the
user space program calling sys_brk is hotplug.
This is 100% reproducible, it happens at (nearly) the same time, at each
boot.
The lspci, .config and dmesg are available at
http://fdeweerdt.free.fr/lockdep_warning
I'm going to try to bisect sysenter_past_esp by instering some
TRACE_IRQS_ON between the beginning of the routine and the actual syscall
to see when the irq enabling is missed.


Thanks,
Frederik

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: 2.6.18-rc6-mm1
  2006-09-08 19:44   ` 2.6.18-rc6-mm1 Andrew Morton
@ 2006-09-09  9:04     ` thunder7
  2006-09-09 15:31       ` 2.6.18-rc6-mm1 Andrew Morton
  0 siblings, 1 reply; 114+ messages in thread
From: thunder7 @ 2006-09-09  9:04 UTC (permalink / raw)
  To: Andrew Morton; +Cc: Jurriaan, linux-kernel

From: Andrew Morton <akpm@osdl.org>
Date: Fri, Sep 08, 2006 at 12:44:11PM -0700
> On Fri, 8 Sep 2006 21:30:41 +0200
> thunder7@xs4all.nl wrote:
> 
> > From: Andrew Morton <akpm@osdl.org>
> > Date: Fri, Sep 08, 2006 at 01:13:17AM -0700
> > > 
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc6/2.6.18-rc6-mm1/
> > > 
> > This throws an oops on my IBM Thinkpad T23 notebook. Some parts scroll
> > off the screen, but the visible stack trace goes like this:
> > 
> We'd really need to see that trace, please.  netconsole is worth setting
> up, if you have another machine on the LAN.
> 
Well, I've learned that built-in framebuffers initialize _before_ the
network stack is up, so that didn't help. Rebuilding savagefb as a
module gave me:

hub 3-0:1.0: 2 ports detected
savagefb: mapped io at f8980000
savagefb: probed videoram:  16384k
savagefb: Detected current MCLK value of 71591 kHz
savagefb: 1024x768 TFT LCD panel detected and active
savagefb: Limiting video mode to 1024x768
savagefb: mapped framebuffer at f8a80000, pbase == e8000000
BUG: unable to handle kernel NULL pointer dereference at virtual address
00000000
 printing eip:
 f8831013
 *pde = 00000000
 Oops: 0000 [#1]
 4K_STACKS PREEMPT 
 last sysfs file: /devices/system/cpu/cpu0/cpufreq/scaling_governor
 Modules linked in: savagefb fb_ddc cfbimgblt uhci_hcd usbcore
 CPU:    0
 EIP:    0060:[<f8831013>]    Not tainted VLI
 EFLAGS: 00010286   (2.6.18-rc6-mm1 #6) 
 EIP is at fb_ddc_read+0x13/0x1c4 [fb_ddc]
 eax: f7faf250   ebx: 00000000   ecx: f7faf244   edx: f7faf244
 esi: 00000000   edi: f7faf008   ebp: f7fbed98   esp: f7fbed68
 ds: 007b   es: 007b   ss: 0068
 Process modprobe (pid: 1776, ti=f7fbe000 task=f7fbdab0
 task.ti=f7fbe000)
 Stack: 00000001 f7faf244 00004988 01000000 f7faf000 f9a6d9e0 f7fbede8 00000000 
        f7faf244 f7faf208 f7faf000 f7faf008 f7fbedb0 f8846af9 f7faf250 f7faf208 
        f7faf000 f7faf008 f7fbede8 f884667c f7faf000 f7faf6b0 f7fbedd0 c01ebe91 
 Call Trace:
 [<c01039eb>] show_trace_log_lvl+0x15/0x28
 [<c0103a8a>] show_stack_log_lvl+0x8c/0x97
 [<c0103e48>] show_registers+0x188/0x21c
 [<c0104085>] die+0x1a9/0x283
 [<c0113bb5>] do_page_fault+0x3ed/0x4bf
 [<c03421df>] error_code+0x3f/0x44
 [<f8846af9>] savagefb_probe_i2c_connector+0x18/0x66 [savagefb]
 [<f884667c>] savagefb_probe+0x484/0x672 [savagefb]
 [<c01f6722>] pci_device_probe+0x3a/0x61
 [<c0269ecb>] really_probe+0x37/0xb0
 [<c0269fbc>] driver_probe_device+0x78/0x84
 [<c026a06a>] __driver_attach+0x38/0x60
 [<c026992a>] bus_for_each_dev+0x42/0x69
 [<c0269df7>] driver_attach+0x16/0x18
 [<c0269491>] bus_add_driver+0x66/0x179
 [<c026a2f7>] driver_register+0x77/0x7c
 [<c01f68bf>] __pci_register_driver+0x5e/0x7e
 [<f882d02e>] savagefb_init+0x2e/0x36 [savagefb]
 [<c0132158>] sys_init_module+0x1274/0x1443
 [<c0102dd8>] syscall_call+0x7/0xb
 =======================
 Code: <ff> 33 ff 53 08 6a 00 ff 33 ff 53 08 c7 45 d4 00 00 00 00 83 c4 10 6a 00 31 ff ff 33 ff 53 04 6a 
 EIP: [<f8831013>] fb_ddc_read+0x13/0x1c4 [fb_ddc] SS:ESP 0068:f7fbed68

Hope this helps,
Jurriaan
-- 
"Besides," she added with a shrug, "strategy and tactics are anathema
to the Apocalypse."
        Steven Erikson - Deadhouse Gates
Debian (Unstable) GNU/Linux 2.6.18-rc4-mm3 4423 bogomips load 0.31

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: [patch -mm] s390: fix save_stack_trace
  2006-09-08 12:16 ` [patch -mm] s390: fix save_stack_trace Heiko Carstens
@ 2006-09-09 13:36   ` Andi Kleen
  0 siblings, 0 replies; 114+ messages in thread
From: Andi Kleen @ 2006-09-09 13:36 UTC (permalink / raw)
  To: Heiko Carstens; +Cc: Andrew Morton, linux-kernel, Martin Schwidefsky

On Friday 08 September 2006 14:16, Heiko Carstens wrote:
> From: Heiko Carstens <heiko.carstens@de.ibm.com>
>
> x86_64-mm-stacktrace-cleanup.patch reverses the logic in s390's
> save_stack_trace incorrectly. Fix this.

I added the patch to the original patch thanks
-Andi

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: 2.6.18-rc6-mm1 - x86_64-mm-lockdep-dont-force-framepointer.patch
  2006-09-08 12:23 ` 2.6.18-rc6-mm1 - x86_64-mm-lockdep-dont-force-framepointer.patch Heiko Carstens
@ 2006-09-09 13:39   ` Andi Kleen
  2006-09-11  8:45     ` Martin Schwidefsky
  0 siblings, 1 reply; 114+ messages in thread
From: Andi Kleen @ 2006-09-09 13:39 UTC (permalink / raw)
  To: Heiko Carstens; +Cc: Andrew Morton, linux-kernel, Martin Schwidefsky

On Friday 08 September 2006 14:23, Heiko Carstens wrote:
> x86_64-mm-lockdep-dont-force-framepointer.patch does this:
> > Don't force frame pointers for lockdep
> >
> > Now that stacktrace supports dwarf2 don't force frame pointers for
> > lockdep anymore
> >
> > Cc: mingo@elte.hu
> > Signed-off-by: Andi Kleen <ak@suse.de>
> >
> > ---
> >  lib/Kconfig.debug |    1 -
> >  1 files changed, 1 deletion(-)
> >
> > Index: linux/lib/Kconfig.debug
> > ===================================================================
> > --- linux.orig/lib/Kconfig.debug
> > +++ linux/lib/Kconfig.debug
> > @@ -218,7 +218,6 @@ config LOCKDEP
> >         bool
> >         depends on DEBUG_KERNEL && TRACE_IRQFLAGS_SUPPORT &&
> > STACKTRACE_SUPPORT && LOCKDEP_SUPPORT select STACKTRACE
> > -       select FRAME_POINTER
>
> This patch affects all architecture. I'd like to keep the "select
> FRAME_POINTER" for s390, since we don't support dwarf2.

Perhaps you should port the unwinder then?  I know you use it 
in userland.

> So this patch should be dropped.

I changed it now to add a if !X86 so it should be ok now

-Andi




^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: 2.6.18-rc6-mm1
  2006-09-09  9:04     ` 2.6.18-rc6-mm1 thunder7
@ 2006-09-09 15:31       ` Andrew Morton
  2006-09-09 22:02         ` 2.6.18-rc6-mm1 Jean Delvare
  0 siblings, 1 reply; 114+ messages in thread
From: Andrew Morton @ 2006-09-09 15:31 UTC (permalink / raw)
  To: Jurriaan
  Cc: linux-kernel, linux-fbdev-devel, Antonino A. Daplas, Jean Delvare

On Sat, 9 Sep 2006 11:04:49 +0200
thunder7@xs4all.nl wrote:

> From: Andrew Morton <akpm@osdl.org>
> Date: Fri, Sep 08, 2006 at 12:44:11PM -0700
> > On Fri, 8 Sep 2006 21:30:41 +0200
> > thunder7@xs4all.nl wrote:
> > 
> > > From: Andrew Morton <akpm@osdl.org>
> > > Date: Fri, Sep 08, 2006 at 01:13:17AM -0700
> > > > 
> > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc6/2.6.18-rc6-mm1/
> > > > 
> > > This throws an oops on my IBM Thinkpad T23 notebook. Some parts scroll
> > > off the screen, but the visible stack trace goes like this:
> > > 
> > We'd really need to see that trace, please.  netconsole is worth setting
> > up, if you have another machine on the LAN.
> > 
> Well, I've learned that built-in framebuffers initialize _before_ the
> network stack is up, so that didn't help. Rebuilding savagefb as a
> module gave me:
> 
> hub 3-0:1.0: 2 ports detected
> savagefb: mapped io at f8980000
> savagefb: probed videoram:  16384k
> savagefb: Detected current MCLK value of 71591 kHz
> savagefb: 1024x768 TFT LCD panel detected and active
> savagefb: Limiting video mode to 1024x768
> savagefb: mapped framebuffer at f8a80000, pbase == e8000000
> BUG: unable to handle kernel NULL pointer dereference at virtual address
> 00000000
>  printing eip:
>  f8831013
>  *pde = 00000000
>  Oops: 0000 [#1]
>  4K_STACKS PREEMPT 
>  last sysfs file: /devices/system/cpu/cpu0/cpufreq/scaling_governor
>  Modules linked in: savagefb fb_ddc cfbimgblt uhci_hcd usbcore
>  CPU:    0
>  EIP:    0060:[<f8831013>]    Not tainted VLI
>  EFLAGS: 00010286   (2.6.18-rc6-mm1 #6) 
>  EIP is at fb_ddc_read+0x13/0x1c4 [fb_ddc]
>  eax: f7faf250   ebx: 00000000   ecx: f7faf244   edx: f7faf244
>  esi: 00000000   edi: f7faf008   ebp: f7fbed98   esp: f7fbed68
>  ds: 007b   es: 007b   ss: 0068
>  Process modprobe (pid: 1776, ti=f7fbe000 task=f7fbdab0
>  task.ti=f7fbe000)
>  Stack: 00000001 f7faf244 00004988 01000000 f7faf000 f9a6d9e0 f7fbede8 00000000 
>         f7faf244 f7faf208 f7faf000 f7faf008 f7fbedb0 f8846af9 f7faf250 f7faf208 
>         f7faf000 f7faf008 f7fbede8 f884667c f7faf000 f7faf6b0 f7fbedd0 c01ebe91 
>  Call Trace:
>  [<c01039eb>] show_trace_log_lvl+0x15/0x28
>  [<c0103a8a>] show_stack_log_lvl+0x8c/0x97
>  [<c0103e48>] show_registers+0x188/0x21c
>  [<c0104085>] die+0x1a9/0x283
>  [<c0113bb5>] do_page_fault+0x3ed/0x4bf
>  [<c03421df>] error_code+0x3f/0x44
>  [<f8846af9>] savagefb_probe_i2c_connector+0x18/0x66 [savagefb]
>  [<f884667c>] savagefb_probe+0x484/0x672 [savagefb]
>  [<c01f6722>] pci_device_probe+0x3a/0x61
>  [<c0269ecb>] really_probe+0x37/0xb0
>  [<c0269fbc>] driver_probe_device+0x78/0x84
>  [<c026a06a>] __driver_attach+0x38/0x60
>  [<c026992a>] bus_for_each_dev+0x42/0x69
>  [<c0269df7>] driver_attach+0x16/0x18
>  [<c0269491>] bus_add_driver+0x66/0x179
>  [<c026a2f7>] driver_register+0x77/0x7c
>  [<c01f68bf>] __pci_register_driver+0x5e/0x7e
>  [<f882d02e>] savagefb_init+0x2e/0x36 [savagefb]
>  [<c0132158>] sys_init_module+0x1274/0x1443
>  [<c0102dd8>] syscall_call+0x7/0xb
>  =======================
>  Code: <ff> 33 ff 53 08 6a 00 ff 33 ff 53 08 c7 45 d4 00 00 00 00 83 c4 10 6a 00 31 ff ff 33 ff 53 04 6a 
>  EIP: [<f8831013>] fb_ddc_read+0x13/0x1c4 [fb_ddc] SS:ESP 0068:f7fbed68
> 
> Hope this helps,

Does, thanks.  I guess adapter->algo_data is NULL.

savagefb-use-generic-ddc-reading.patch, perhaps...



^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: 2.6.18-rc6-mm1
  2006-09-09 15:31       ` 2.6.18-rc6-mm1 Andrew Morton
@ 2006-09-09 22:02         ` Jean Delvare
  2006-09-10  6:30           ` 2.6.18-rc6-mm1 thunder7
  0 siblings, 1 reply; 114+ messages in thread
From: Jean Delvare @ 2006-09-09 22:02 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Jurriaan, linux-kernel, linux-fbdev-devel, Antonino A. Daplas

Hi Andrew, Jurriaan, Antonino,

> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc6/2.6.18-rc6-mm1/
> >
> > This throws an oops on my IBM Thinkpad T23 notebook. Some parts scroll
> > off the screen, but the visible stack trace goes like this:
> > (...) 
> > hub 3-0:1.0: 2 ports detected
> > savagefb: mapped io at f8980000
> > savagefb: probed videoram:  16384k
> > savagefb: Detected current MCLK value of 71591 kHz
> > savagefb: 1024x768 TFT LCD panel detected and active
> > savagefb: Limiting video mode to 1024x768
> > savagefb: mapped framebuffer at f8a80000, pbase == e8000000
> > BUG: unable to handle kernel NULL pointer dereference at virtual address
> > 00000000
> >  printing eip:
> >  f8831013
> >  *pde = 00000000
> >  Oops: 0000 [#1]
> >  4K_STACKS PREEMPT 
> >  last sysfs file: /devices/system/cpu/cpu0/cpufreq/scaling_governor
> >  Modules linked in: savagefb fb_ddc cfbimgblt uhci_hcd usbcore
> >  CPU:    0
> >  EIP:    0060:[<f8831013>]    Not tainted VLI
> >  EFLAGS: 00010286   (2.6.18-rc6-mm1 #6) 
> >  EIP is at fb_ddc_read+0x13/0x1c4 [fb_ddc]
> >  eax: f7faf250   ebx: 00000000   ecx: f7faf244   edx: f7faf244
> >  esi: 00000000   edi: f7faf008   ebp: f7fbed98   esp: f7fbed68
> >  ds: 007b   es: 007b   ss: 0068
> >  Process modprobe (pid: 1776, ti=f7fbe000 task=f7fbdab0
> >  task.ti=f7fbe000)
> >  Stack: 00000001 f7faf244 00004988 01000000 f7faf000 f9a6d9e0 f7fbede8 00000000 
> >         f7faf244 f7faf208 f7faf000 f7faf008 f7fbedb0 f8846af9 f7faf250 f7faf208 
> >         f7faf000 f7faf008 f7fbede8 f884667c f7faf000 f7faf6b0 f7fbedd0 c01ebe91 
> >  Call Trace:
> >  [<c01039eb>] show_trace_log_lvl+0x15/0x28
> >  [<c0103a8a>] show_stack_log_lvl+0x8c/0x97
> >  [<c0103e48>] show_registers+0x188/0x21c
> >  [<c0104085>] die+0x1a9/0x283
> >  [<c0113bb5>] do_page_fault+0x3ed/0x4bf
> >  [<c03421df>] error_code+0x3f/0x44
> >  [<f8846af9>] savagefb_probe_i2c_connector+0x18/0x66 [savagefb]
> >  [<f884667c>] savagefb_probe+0x484/0x672 [savagefb]
> >  [<c01f6722>] pci_device_probe+0x3a/0x61
> >  [<c0269ecb>] really_probe+0x37/0xb0
> >  [<c0269fbc>] driver_probe_device+0x78/0x84
> >  [<c026a06a>] __driver_attach+0x38/0x60
> >  [<c026992a>] bus_for_each_dev+0x42/0x69
> >  [<c0269df7>] driver_attach+0x16/0x18
> >  [<c0269491>] bus_add_driver+0x66/0x179
> >  [<c026a2f7>] driver_register+0x77/0x7c
> >  [<c01f68bf>] __pci_register_driver+0x5e/0x7e
> >  [<f882d02e>] savagefb_init+0x2e/0x36 [savagefb]
> >  [<c0132158>] sys_init_module+0x1274/0x1443
> >  [<c0102dd8>] syscall_call+0x7/0xb
> >  =======================
> >  Code: <ff> 33 ff 53 08 6a 00 ff 33 ff 53 08 c7 45 d4 00 00 00 00 83 c4 10 6a 00 31 ff ff 33 ff 53 04 6a 
> >  EIP: [<f8831013>] fb_ddc_read+0x13/0x1c4 [fb_ddc] SS:ESP 0068:f7fbed68
> > 
> > Hope this helps,
> 
> Does, thanks.  I guess adapter->algo_data is NULL.
> 
> savagefb-use-generic-ddc-reading.patch, perhaps...

I indeed think this patch is causing the oops. The old code did call
savage_do_probe_i2c_edid even if no i2c bus had been created for the
board, and savage_do_probe_i2c_edid bailed out quickly in that case
("chan->par = NULL;" at the end of savage_setup_i2c_bus, and "if
(chan->par) {" at the beginning of savage_do_probe_i2c_edid.) The new
fb_ddc_read function has no such quick exit, it pretty much assumes
that an i2c bus was successfully created beforehand.

So my guess is that Jurriaan's graphics adapter is supported by the
savagefb driver, but the driver doesn't create an i2c bus for it
(either because the hardware doesn't have it, or we simply have no
support.) Jurriaan, please confirm that your adapter is not one of
Savage4, Savage2000, ProSavagePM, ProSavage8.

If my analysis is correct, the following patch should fix the problem.
It can probably be optimized/cleaned up, but I'll leave that to
Antonino. Jurriaan, can you please apply this patch on top of
2.6.18-rc6-mm1 and report success or failure?

* * * * *

Hot fix to savagefb-use-generic-ddc-reading.patch.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Cc: "Antonino A. Daplas" <adaplas@pol.net>
---
 drivers/video/savage/savagefb-i2c.c |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

--- linux-2.6.18-rc6-mm1.orig/drivers/video/savage/savagefb-i2c.c	2006-09-09 23:21:24.000000000 +0200
+++ linux-2.6.18-rc6-mm1/drivers/video/savage/savagefb-i2c.c	2006-09-09 23:52:56.000000000 +0200
@@ -218,7 +218,10 @@
 	struct savagefb_par *par = info->par;
 	u8 *edid;
 
-	edid = fb_ddc_read(&par->chan.adapter);
+	if (par->chan.par)
+		edid = fb_ddc_read(&par->chan.adapter);
+	else
+		edid = NULL;
 
 	if (!edid) {
 		/* try to get from firmware */


-- 
Jean Delvare

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: 2.6.18-rc6-mm1
  2006-09-09 22:02         ` 2.6.18-rc6-mm1 Jean Delvare
@ 2006-09-10  6:30           ` thunder7
  0 siblings, 0 replies; 114+ messages in thread
From: thunder7 @ 2006-09-10  6:30 UTC (permalink / raw)
  To: Jean Delvare
  Cc: Andrew Morton, Jurriaan, linux-kernel, linux-fbdev-devel,
	Antonino A. Daplas

From: Jean Delvare <khali@linux-fr.org>
Date: Sun, Sep 10, 2006 at 12:02:45AM +0200
> Hi Andrew, Jurriaan, Antonino,
> 
> So my guess is that Jurriaan's graphics adapter is supported by the
> savagefb driver, but the driver doesn't create an i2c bus for it
> (either because the hardware doesn't have it, or we simply have no
> support.) Jurriaan, please confirm that your adapter is not one of
> Savage4, Savage2000, ProSavagePM, ProSavage8.

lspci calls it 'S3 Inc. SuperSavage IX/C SDR (rev 05)' 

> 
> If my analysis is correct, the following patch should fix the problem.
> It can probably be optimized/cleaned up, but I'll leave that to
> Antonino. Jurriaan, can you please apply this patch on top of
> 2.6.18-rc6-mm1 and report success or failure?

This patch fixes my problems, rc6-mm1 boots without problems even with
the savagefb driver builtin.

Thanks,
Jurriaan
-- 
Genius untempered by ethics is a deadly commodity.
	Iain Irvine - A Shadow on the Glass
Debian (Unstable) GNU/Linux 2.6.18-rc4-mm3 4423 bogomips load 0.04

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: 2.6.18-rc6-mm1: GPF loop on early boot
       [not found] ` <4503DC64.9070007@free.fr>
@ 2006-09-10  8:32   ` Andi Kleen
  2006-09-10 10:29     ` Arjan van de Ven
  2006-09-10 11:57     ` Ingo Molnar
  0 siblings, 2 replies; 114+ messages in thread
From: Andi Kleen @ 2006-09-10  8:32 UTC (permalink / raw)
  To: Laurent Riffard, mingo, Arjan van de Ven
  Cc: Andrew Morton, Kernel development list, Jeremy Fitzhardinge

On Sunday 10 September 2006 11:35, Laurent Riffard wrote:
> Le 08.09.2006 10:13, Andrew Morton a écrit :
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc6/
> >2.6.18-rc6-mm1/
>
> Hello,
>
> This kernel won't boot here: it starts a GPFs loop on
> early boot. I attached a screenshot of the first GPF
> (pause_on_oops=120 helped).


It's lockdep's fault. This patch should fix it:

In general from my experience lockdep seems to be a dependency nightmare.
It uses far too much infrastructure far too early. Should we always disable
lockdep very early (before interrupts are turned on) instead? (early 
everything is single threaded and will never have problems with lock 
ordering)

-Andi
Hackish patch to fix lockdep with PDA current

lockdep can call current very early, so let it always use early_current
Signed-off-by: Andi Kleen <ak@suse.de>

Index: linux/include/asm-i386/current.h
===================================================================
--- linux.orig/include/asm-i386/current.h
+++ linux/include/asm-i386/current.h
@@ -6,6 +6,8 @@
 
 struct task_struct;
 
+#define ARCH_HAS_EARLY_CURRENT 1
+
 static __always_inline struct task_struct *early_current(void)
 {
 	return current_thread_info()->task;
Index: linux/kernel/lockdep.c
===================================================================
--- linux.orig/kernel/lockdep.c
+++ linux/kernel/lockdep.c
@@ -41,6 +41,10 @@
 
 #include "lockdep_internals.h"
 
+#ifndef ARCH_HAS_EARLY_CURRENT
+#define early_current()() current
+#endif
+
 /*
  * hash_lock: protects the lockdep hashes and class/list/hash allocators.
  *
@@ -127,21 +131,21 @@ static struct list_head chainhash_table[
 
 void lockdep_off(void)
 {
-	current->lockdep_recursion++;
+	early_current()->lockdep_recursion++;
 }
 
 EXPORT_SYMBOL(lockdep_off);
 
 void lockdep_on(void)
 {
-	current->lockdep_recursion--;
+	early_current()->lockdep_recursion--;
 }
 
 EXPORT_SYMBOL(lockdep_on);
 
 int lockdep_internal(void)
 {
-	return current->lockdep_recursion != 0;
+	return early_current()->lockdep_recursion != 0;
 }
 
 EXPORT_SYMBOL(lockdep_internal);
@@ -522,7 +526,7 @@ print_circular_bug_entry(struct lock_lis
 static noinline int
 print_circular_bug_header(struct lock_list *entry, unsigned int depth)
 {
-	struct task_struct *curr = current;
+	struct task_struct *curr = early_current();
 
 	__raw_spin_unlock(&hash_lock);
 	debug_locks_off();
@@ -547,7 +551,7 @@ print_circular_bug_header(struct lock_li
 
 static noinline int print_circular_bug_tail(void)
 {
-	struct task_struct *curr = current;
+	struct task_struct *curr = early_current();
 	struct lock_list this;
 
 	if (debug_locks_silent)
@@ -1302,10 +1306,10 @@ cache_hit:
 	list_add_tail_rcu(&chain->entry, hash_head);
 	debug_atomic_inc(&chain_lookup_misses);
 #ifdef CONFIG_TRACE_IRQFLAGS
-	if (current->hardirq_context)
+	if (early_current()->hardirq_context)
 		nr_hardirq_chains++;
 	else {
-		if (current->softirq_context)
+		if (early_current()->softirq_context)
 			nr_softirq_chains++;
 		else
 			nr_process_chains++;
@@ -1788,10 +1792,10 @@ void early_boot_irqs_on(void)
  */
 void trace_hardirqs_on(void)
 {
-	struct task_struct *curr = current;
+	struct task_struct *curr = early_current();
 	unsigned long ip;
 
-	if (unlikely(!debug_locks || current->lockdep_recursion))
+	if (unlikely(!debug_locks || early_current()->lockdep_recursion))
 		return;
 
 	if (DEBUG_LOCKS_WARN_ON(unlikely(!early_boot_irqs_enabled)))
@@ -1807,7 +1811,7 @@ void trace_hardirqs_on(void)
 
 	if (DEBUG_LOCKS_WARN_ON(!irqs_disabled()))
 		return;
-	if (DEBUG_LOCKS_WARN_ON(current->hardirq_context))
+	if (DEBUG_LOCKS_WARN_ON(early_current()->hardirq_context))
 		return;
 	/*
 	 * We are going to turn hardirqs on, so set the
@@ -1836,9 +1840,9 @@ EXPORT_SYMBOL(trace_hardirqs_on);
  */
 void trace_hardirqs_off(void)
 {
-	struct task_struct *curr = current;
+	struct task_struct *curr = early_current();
 
-	if (unlikely(!debug_locks || current->lockdep_recursion))
+	if (unlikely(!debug_locks || early_current()->lockdep_recursion))
 		return;
 
 	if (DEBUG_LOCKS_WARN_ON(!irqs_disabled()))
@@ -1863,7 +1867,7 @@ EXPORT_SYMBOL(trace_hardirqs_off);
  */
 void trace_softirqs_on(unsigned long ip)
 {
-	struct task_struct *curr = current;
+	struct task_struct *curr = early_current();
 
 	if (unlikely(!debug_locks))
 		return;
@@ -1897,7 +1901,7 @@ void trace_softirqs_on(unsigned long ip)
  */
 void trace_softirqs_off(unsigned long ip)
 {
-	struct task_struct *curr = current;
+	struct task_struct *curr = early_current();
 
 	if (unlikely(!debug_locks))
 		return;
@@ -1956,7 +1960,7 @@ static int __lock_acquire(struct lockdep
 			  int trylock, int read, int check, int hardirqs_off,
 			  unsigned long ip)
 {
-	struct task_struct *curr = current;
+	struct task_struct *curr = early_current();
 	struct lock_class *class = NULL;
 	struct held_lock *hlock;
 	unsigned int depth, id;
@@ -1996,7 +2000,7 @@ static int __lock_acquire(struct lockdep
 	}
 
 	/*
-	 * Add the lock to the list of currently held locks.
+	 * Add the lock to the list of early_current()ly held locks.
 	 * (we dont increase the depth just yet, up until the
 	 * dependency checks are done)
 	 */
@@ -2067,7 +2071,7 @@ out_calc_hash:
 	/*
 	 * Calculate the chain hash: it's the combined has of all the
 	 * lock keys along the dependency chain. We save the hash value
-	 * at every step so that we can get the current hash easily
+	 * at every step so that we can get the early_current() hash easily
 	 * after unlock. The chain hash is then used to cache dependency
 	 * results.
 	 *
@@ -2213,7 +2217,7 @@ static int check_unlock(struct task_stru
 }
 
 /*
- * Remove the lock to the list of currently held locks in a
+ * Remove the lock to the list of early_current()ly held locks in a
  * potentially non-nested (out of order) manner. This is a
  * relatively rare operation, as all the unlock APIs default
  * to nested mode (which uses lock_release()):
@@ -2227,7 +2231,7 @@ lock_release_non_nested(struct task_stru
 	int i;
 
 	/*
-	 * Check whether the lock exists in the current stack
+	 * Check whether the lock exists in the early_current() stack
 	 * of held locks:
 	 */
 	depth = curr->lockdep_depth;
@@ -2272,10 +2276,10 @@ found_it:
 }
 
 /*
- * Remove the lock to the list of currently held locks - this gets
+ * Remove the lock to the list of early_current()ly held locks - this gets
  * called on mutex_unlock()/spin_unlock*() (or on a failed
  * mutex_lock_interruptible()). This is done for unlocks that nest
- * perfectly. (i.e. the current top of the lock-stack is unlocked)
+ * perfectly. (i.e. the early_current() top of the lock-stack is unlocked)
  */
 static int lock_release_nested(struct task_struct *curr,
 			       struct lockdep_map *lock, unsigned long ip)
@@ -2311,15 +2315,15 @@ static int lock_release_nested(struct ta
 }
 
 /*
- * Remove the lock to the list of currently held locks - this gets
+ * Remove the lock to the list of early_current()ly held locks - this gets
  * called on mutex_unlock()/spin_unlock*() (or on a failed
  * mutex_lock_interruptible()). This is done for unlocks that nest
- * perfectly. (i.e. the current top of the lock-stack is unlocked)
+ * perfectly. (i.e. the early_current() top of the lock-stack is unlocked)
  */
 static void
 __lock_release(struct lockdep_map *lock, int nested, unsigned long ip)
 {
-	struct task_struct *curr = current;
+	struct task_struct *curr = early_current();
 
 	if (!check_unlock(curr, lock, ip))
 		return;
@@ -2345,9 +2349,9 @@ static void check_flags(unsigned long fl
 		return;
 
 	if (irqs_disabled_flags(flags))
-		DEBUG_LOCKS_WARN_ON(current->hardirqs_enabled);
+		DEBUG_LOCKS_WARN_ON(early_current()->hardirqs_enabled);
 	else
-		DEBUG_LOCKS_WARN_ON(!current->hardirqs_enabled);
+		DEBUG_LOCKS_WARN_ON(!early_current()->hardirqs_enabled);
 
 	/*
 	 * We dont accurately track softirq state in e.g.
@@ -2356,13 +2360,13 @@ static void check_flags(unsigned long fl
 	 */
 	if (!hardirq_count()) {
 		if (softirq_count())
-			DEBUG_LOCKS_WARN_ON(current->softirqs_enabled);
+			DEBUG_LOCKS_WARN_ON(early_current()->softirqs_enabled);
 		else
-			DEBUG_LOCKS_WARN_ON(!current->softirqs_enabled);
+			DEBUG_LOCKS_WARN_ON(!early_current()->softirqs_enabled);
 	}
 
 	if (!debug_locks)
-		print_irqtrace_events(current);
+		print_irqtrace_events(early_current());
 #endif
 }
 
@@ -2375,16 +2379,16 @@ void lock_acquire(struct lockdep_map *lo
 {
 	unsigned long flags;
 
-	if (unlikely(current->lockdep_recursion))
+	if (unlikely(early_current()->lockdep_recursion))
 		return;
 
 	raw_local_irq_save(flags);
 	check_flags(flags);
 
-	current->lockdep_recursion = 1;
+	early_current()->lockdep_recursion = 1;
 	__lock_acquire(lock, subclass, trylock, read, check,
 		       irqs_disabled_flags(flags), ip);
-	current->lockdep_recursion = 0;
+	early_current()->lockdep_recursion = 0;
 	raw_local_irq_restore(flags);
 }
 
@@ -2394,14 +2398,14 @@ void lock_release(struct lockdep_map *lo
 {
 	unsigned long flags;
 
-	if (unlikely(current->lockdep_recursion))
+	if (unlikely(early_current()->lockdep_recursion))
 		return;
 
 	raw_local_irq_save(flags);
 	check_flags(flags);
-	current->lockdep_recursion = 1;
+	early_current()->lockdep_recursion = 1;
 	__lock_release(lock, nested, ip);
-	current->lockdep_recursion = 0;
+	early_current()->lockdep_recursion = 0;
 	raw_local_irq_restore(flags);
 }
 
@@ -2417,10 +2421,10 @@ void lockdep_reset(void)
 	unsigned long flags;
 
 	raw_local_irq_save(flags);
-	current->curr_chain_key = 0;
-	current->lockdep_depth = 0;
-	current->lockdep_recursion = 0;
-	memset(current->held_locks, 0, MAX_LOCK_DEPTH*sizeof(struct held_lock));
+	early_current()->curr_chain_key = 0;
+	early_current()->lockdep_depth = 0;
+	early_current()->lockdep_recursion = 0;
+	memset(early_current()->held_locks, 0, MAX_LOCK_DEPTH*sizeof(struct 
held_lock));
 	nr_hardirq_chains = 0;
 	nr_softirq_chains = 0;
 	nr_process_chains = 0;
@@ -2606,7 +2610,7 @@ print_freed_lock_bug(struct task_struct 
 void debug_check_no_locks_freed(const void *mem_from, unsigned long mem_len)
 {
 	const void *mem_to = mem_from + mem_len, *lock_from, *lock_to;
-	struct task_struct *curr = current;
+	struct task_struct *curr = early_current();
 	struct held_lock *hlock;
 	unsigned long flags;
 	int i;

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: 2.6.18-rc6-mm1: GPF loop on early boot
  2006-09-10  8:32   ` 2.6.18-rc6-mm1: GPF loop on early boot Andi Kleen
@ 2006-09-10 10:29     ` Arjan van de Ven
  2006-09-10 11:57     ` Ingo Molnar
  1 sibling, 0 replies; 114+ messages in thread
From: Arjan van de Ven @ 2006-09-10 10:29 UTC (permalink / raw)
  To: Andi Kleen
  Cc: Laurent Riffard, mingo, Andrew Morton, Kernel development list,
	Jeremy Fitzhardinge

On Sun, 2006-09-10 at 10:32 +0200, Andi Kleen wrote:
> On Sunday 10 September 2006 11:35, Laurent Riffard wrote:
> > Le 08.09.2006 10:13, Andrew Morton a écrit :
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc6/
> > >2.6.18-rc6-mm1/
> >
> > Hello,
> >
> > This kernel won't boot here: it starts a GPFs loop on
> > early boot. I attached a screenshot of the first GPF
> > (pause_on_oops=120 helped).
> 
> 
> It's lockdep's fault. This patch should fix it:
> 
> In general from my experience lockdep seems to be a dependency nightmare.
> It uses far too much infrastructure far too early. Should we always disable
> lockdep very early (before interrupts are turned on) instead? (early 
> everything is single threaded and will never have problems with lock 
> ordering)

lockdep starts somewhere in the middle; I doubt it's the only thing that
assumes that current is valid at that point.
>  /*
> - * Remove the lock to the list of currently held locks in a
> + * Remove the lock to the list of early_current()ly held locks in a
>   * potentially non-nested (out of order) manner. This is a
>   * relatively rare operation, as all the unlock APIs default
>   * to nested mode (which uses lock_release()):
> @@ -2227,7 +2231,7 @@ lock_release_non_nested(struct task_stru
>  	int i;
>  
>  	/*
> -	 * Check whether the lock exists in the current stack
> +	 * Check whether the lock exists in the early_current() stack
>  	 * of held locks:
>  	 */

??



^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: 2.6.18-rc6-mm1: GPF loop on early boot
  2006-09-10 11:57     ` Ingo Molnar
@ 2006-09-10 11:34       ` Andi Kleen
  2006-09-10 13:26         ` Ingo Molnar
  2006-09-10 12:36       ` 2.6.18-rc6-mm1: GPF loop on early boot Laurent Riffard
  2006-09-10 13:11       ` Ingo Molnar
  2 siblings, 1 reply; 114+ messages in thread
From: Andi Kleen @ 2006-09-10 11:34 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Laurent Riffard, Arjan van de Ven, Andrew Morton,
	Kernel development list, Jeremy Fitzhardinge

On Sunday 10 September 2006 13:57, Ingo Molnar wrote:
> * Andi Kleen <ak@suse.de> wrote:
> > > This kernel won't boot here: it starts a GPFs loop on
> > > early boot. I attached a screenshot of the first GPF
> > > (pause_on_oops=120 helped).
> >
> > It's lockdep's fault. This patch should fix it:>
> Well, it's also x86_64's fault: why does it call into a generic C 
> function (x86_64_start_kernel()) without having a full CPU state up and
> running? i686 doesnt do it, never did.

Actually i686 does now (since Jeremy's patches). The patch was for i386.
x86_64 doesn't need it.

But enough blame game. The "fault" in my original mail wasn't completely
serious anyways ...

>
> We had frequent breakages due to this property of the x86_64 arch code
> (many more than this single incident with lockdep), tracing and all
> sorts of other instrumentation (including earlier versions of lockdep)
> was hit by it again and again.

Well, just getting the new unwinder to work in lockdep was a nightmare
too (most of the problems I had with that were on i386, not x86-64) 
Just look at the number of patches that were needed for it.

>
> Basically, non-atomic setup of basic architecture state _is_ going to be
> a nightmare, lockdep or not, especially if it uses common infrastructure
> like 'current', spin_lock() or even something as simple as C functions.
> (for example the stack-footprint tracer was once hit by this weakness of
> the x86_64 code)

I disagree with that.  The nightmare is putting stuff that needs so much
infrastructure into the most basic operations.

> > Hackish patch to fix lockdep with PDA current
>
> hm, this is ugly beyond words. 

Agreed it is :). But it was the quickest way to fix it.

> Do you have a config i could try which 
> exhibits this problem? I'm sure there is a better solution.

You need the latest x86_64 patch (or latest mm) and enable lockdep
on i386. Possibly with some more interdependencies, but I hope not.

I guess a cleaner way would to set the global variable that turns
the tracing off during boot and then enable it when it starts making
sense. Not 100% sure where that point is.

-Andi

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: 2.6.18-rc6-mm1: GPF loop on early boot
  2006-09-10  8:32   ` 2.6.18-rc6-mm1: GPF loop on early boot Andi Kleen
  2006-09-10 10:29     ` Arjan van de Ven
@ 2006-09-10 11:57     ` Ingo Molnar
  2006-09-10 11:34       ` Andi Kleen
                         ` (2 more replies)
  1 sibling, 3 replies; 114+ messages in thread
From: Ingo Molnar @ 2006-09-10 11:57 UTC (permalink / raw)
  To: Andi Kleen
  Cc: Laurent Riffard, Arjan van de Ven, Andrew Morton,
	Kernel development list, Jeremy Fitzhardinge


* Andi Kleen <ak@suse.de> wrote:

> > This kernel won't boot here: it starts a GPFs loop on
> > early boot. I attached a screenshot of the first GPF
> > (pause_on_oops=120 helped).
> 
> It's lockdep's fault. This patch should fix it:

Well, it's also x86_64's fault: why does it call into a generic C 
function (x86_64_start_kernel()) without having a full CPU state up and 
running? i686 doesnt do it, never did.

We had frequent breakages due to this property of the x86_64 arch code 
(many more than this single incident with lockdep), tracing and all 
sorts of other instrumentation (including earlier versions of lockdep) 
was hit by it again and again.

Basically, non-atomic setup of basic architecture state _is_ going to be 
a nightmare, lockdep or not, especially if it uses common infrastructure 
like 'current', spin_lock() or even something as simple as C functions. 
(for example the stack-footprint tracer was once hit by this weakness of 
the x86_64 code)

> Hackish patch to fix lockdep with PDA current

hm, this is ugly beyond words. Do you have a config i could try which 
exhibits this problem? I'm sure there is a better solution.

	Ingo

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: 2.6.18-rc6-mm1: GPF loop on early boot
  2006-09-10 11:57     ` Ingo Molnar
  2006-09-10 11:34       ` Andi Kleen
@ 2006-09-10 12:36       ` Laurent Riffard
  2006-09-10 13:07         ` Ingo Molnar
  2006-09-10 13:11       ` Ingo Molnar
  2 siblings, 1 reply; 114+ messages in thread
From: Laurent Riffard @ 2006-09-10 12:36 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Andi Kleen, Arjan van de Ven, Andrew Morton,
	Kernel development list, Jeremy Fitzhardinge

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

Le 10.09.2006 13:57, Ingo Molnar a écrit :
> * Andi Kleen <ak@suse.de> wrote:
> 
>>> This kernel won't boot here: it starts a GPFs loop on
>>> early boot. I attached a screenshot of the first GPF
>>> (pause_on_oops=120 helped).
>> It's lockdep's fault. This patch should fix it:
> 
> Well, it's also x86_64's fault: why does it call into a generic C 
> function (x86_64_start_kernel()) without having a full CPU state up and 
> running? i686 doesnt do it, never did.
> 
> We had frequent breakages due to this property of the x86_64 arch code 
> (many more than this single incident with lockdep), tracing and all 
> sorts of other instrumentation (including earlier versions of lockdep) 
> was hit by it again and again.
> 
> Basically, non-atomic setup of basic architecture state _is_ going to be 
> a nightmare, lockdep or not, especially if it uses common infrastructure 
> like 'current', spin_lock() or even something as simple as C functions. 
> (for example the stack-footprint tracer was once hit by this weakness of 
> the x86_64 code)
> 
>> Hackish patch to fix lockdep with PDA current
> 
> hm, this is ugly beyond words. Do you have a config i could try which 
> exhibits this problem? I'm sure there is a better solution.
> 
> 	Ingo

Andi's hackish patch helped, it runs fine now. I'll try any better patch too.

Ingo, I attached my .config to my first post. mmm... It did not reach LKML, so 
here is it again.

Thanks for your help.
-- 
laurent

[-- Attachment #2: config-2.6.18-rc6-mm1 --]
[-- Type: text/plain, Size: 48984 bytes --]

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.18-rc6-mm1
# Sun Sep 10 00:10:53 2006
#
CONFIG_X86_32=y
CONFIG_GENERIC_TIME=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_SEMAPHORE_SLEEPERS=y
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_DMI=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"

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

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

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

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

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

#
# Processor type and features
#
# CONFIG_SMP is not set
CONFIG_X86_PC=y
# CONFIG_X86_ELAN is not set
# CONFIG_X86_VOYAGER is not set
# CONFIG_X86_NUMAQ is not set
# CONFIG_X86_SUMMIT is not set
# CONFIG_X86_BIGSMP is not set
# CONFIG_X86_VISWS is not set
# CONFIG_X86_GENERICARCH is not set
# CONFIG_X86_ES7000 is not set
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMII is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUMM is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
CONFIG_MK7=y
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MEFFICEON is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MGEODEGX1 is not set
# CONFIG_MGEODE_LX is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_X86_GENERIC is not set
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_L1_CACHE_SHIFT=6
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_CMPXCHG64=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_USE_3DNOW=y
CONFIG_X86_TSC=y
CONFIG_HPET_TIMER=y
# CONFIG_PREEMPT_NONE is not set
CONFIG_PREEMPT_VOLUNTARY=y
# CONFIG_PREEMPT is not set
CONFIG_X86_UP_APIC=y
CONFIG_X86_UP_IOAPIC=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_MCE=y
CONFIG_X86_MCE_NONFATAL=m
CONFIG_X86_MCE_P4THERMAL=y
CONFIG_VM86=y
# CONFIG_TOSHIBA is not set
# CONFIG_I8K is not set
CONFIG_X86_REBOOTFIXUPS=y
# CONFIG_MICROCODE is not set
CONFIG_X86_MSR=m
# CONFIG_X86_CPUID is not set

#
# Firmware Drivers
#
CONFIG_EDD=y
# CONFIG_DELL_RBU is not set
# CONFIG_DCDBAS is not set
CONFIG_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set
CONFIG_VMSPLIT_3G=y
# CONFIG_VMSPLIT_3G_OPT is not set
# CONFIG_VMSPLIT_2G is not set
# CONFIG_VMSPLIT_1G is not set
CONFIG_PAGE_OFFSET=0xC0000000
CONFIG_ARCH_FLATMEM_ENABLE=y
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_SELECT_MEMORY_MODEL=y
CONFIG_ARCH_POPULATES_NODE_MAP=y
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y
# CONFIG_DISCONTIGMEM_MANUAL is not set
# CONFIG_SPARSEMEM_MANUAL is not set
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
CONFIG_SPARSEMEM_STATIC=y
CONFIG_SPLIT_PTLOCK_CPUS=4
# CONFIG_RESOURCES_64BIT is not set
CONFIG_ADAPTIVE_READAHEAD=y
# CONFIG_READAHEAD_ALLOW_OVERHEADS is not set
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
# CONFIG_EFI is not set
CONFIG_REGPARM=y
CONFIG_SECCOMP=y
# CONFIG_SECCOMP_DISABLE_TSC is not set
# CONFIG_VGA_NOPROBE is not set
# CONFIG_HZ_100 is not set
CONFIG_HZ_250=y
# CONFIG_HZ_1000 is not set
CONFIG_HZ=250
CONFIG_KEXEC=y
CONFIG_PHYSICAL_START=0x100000
# CONFIG_COMPAT_VDSO is not set

#
# Power management options (ACPI, APM)
#
CONFIG_PM=y
CONFIG_PM_LEGACY=y
CONFIG_PM_DEBUG=y
CONFIG_DISABLE_CONSOLE_SUSPEND=y
# CONFIG_PM_TRACE is not set
# CONFIG_PM_SYSFS_DEPRECATED is not set
CONFIG_SOFTWARE_SUSPEND=y
CONFIG_PM_STD_PARTITION="/dev/hdb6"

#
# ACPI (Advanced Configuration and Power Interface) Support
#
CONFIG_ACPI=y
CONFIG_ACPI_SLEEP=y
CONFIG_ACPI_SLEEP_PROC_FS=y
# CONFIG_ACPI_SLEEP_PROC_SLEEP is not set
# CONFIG_ACPI_AC is not set
# CONFIG_ACPI_BATTERY is not set
CONFIG_ACPI_BUTTON=y
# CONFIG_ACPI_VIDEO is not set
CONFIG_ACPI_HOTKEY=m
CONFIG_ACPI_FAN=y
# CONFIG_ACPI_DOCK is not set
# CONFIG_ACPI_BAY is not set
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_THERMAL=y
# CONFIG_ACPI_ASUS is not set
# CONFIG_ACPI_IBM is not set
# CONFIG_ACPI_TOSHIBA is not set
# CONFIG_ACPI_SONY is not set
CONFIG_ACPI_BLACKLIST_YEAR=0
CONFIG_ACPI_DEBUG=y
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_SYSTEM=y
CONFIG_X86_PM_TIMER=y
# CONFIG_ACPI_CONTAINER is not set
# CONFIG_ACPI_SBS is not set

#
# APM (Advanced Power Management) BIOS Support
#
# CONFIG_APM is not set

#
# CPU Frequency scaling
#
# CONFIG_CPU_FREQ is not set

#
# Bus options (PCI, PCMCIA, EISA, MCA, ISA)
#
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GOMMCONFIG is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_MMCONFIG=y
# CONFIG_PCIEPORTBUS is not set
# CONFIG_PCI_MSI is not set
# CONFIG_PCI_MULTITHREAD_PROBE is not set
# CONFIG_PCI_DEBUG is not set
CONFIG_ISA_DMA_API=y
CONFIG_ISA=y
# CONFIG_EISA is not set
# CONFIG_MCA is not set
# CONFIG_SCx200 is not set

#
# PCCARD (PCMCIA/CardBus) support
#
# CONFIG_PCCARD is not set

#
# PCI Hotplug Support
#
# CONFIG_HOTPLUG_PCI is not set

#
# Executable file formats
#
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_AOUT=m
CONFIG_BINFMT_MISC=m

#
# Networking
#
CONFIG_NET=y

#
# Networking options
#
# CONFIG_NETDEBUG is not set
CONFIG_PACKET=m
# CONFIG_PACKET_MMAP is not set
CONFIG_UNIX=y
CONFIG_XFRM=y
CONFIG_XFRM_USER=m
# CONFIG_XFRM_SUB_POLICY is not set
# CONFIG_NET_KEY is not set
CONFIG_INET=y
# CONFIG_IP_MULTICAST is not set
CONFIG_IP_ADVANCED_ROUTER=y
CONFIG_ASK_IP_FIB_HASH=y
# CONFIG_IP_FIB_TRIE is not set
CONFIG_IP_FIB_HASH=y
# CONFIG_IP_MULTIPLE_TABLES is not set
# CONFIG_IP_ROUTE_MULTIPATH is not set
CONFIG_IP_ROUTE_VERBOSE=y
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_ARPD is not set
CONFIG_SYN_COOKIES=y
CONFIG_INET_AH=m
CONFIG_INET_ESP=m
CONFIG_INET_IPCOMP=m
CONFIG_INET_XFRM_TUNNEL=m
CONFIG_INET_TUNNEL=m
# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
# CONFIG_INET_XFRM_MODE_TUNNEL is not set
CONFIG_INET_DIAG=m
CONFIG_INET_TCP_DIAG=m
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_BIC=y

#
# IP: Virtual Server Configuration
#
# CONFIG_IP_VS is not set
# CONFIG_IPV6 is not set
# CONFIG_INET6_XFRM_TUNNEL is not set
# CONFIG_INET6_TUNNEL is not set
# CONFIG_NETWORK_SECMARK is not set
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set

#
# Core Netfilter Configuration
#
CONFIG_NETFILTER_NETLINK=m
CONFIG_NETFILTER_NETLINK_QUEUE=m
CONFIG_NETFILTER_NETLINK_LOG=m
CONFIG_NETFILTER_XTABLES=m
CONFIG_NETFILTER_XT_TARGET_CLASSIFY=m
# CONFIG_NETFILTER_XT_TARGET_DSCP is not set
CONFIG_NETFILTER_XT_TARGET_MARK=m
CONFIG_NETFILTER_XT_TARGET_NFQUEUE=m
CONFIG_NETFILTER_XT_MATCH_COMMENT=m
# CONFIG_NETFILTER_XT_MATCH_CONNTRACK is not set
# CONFIG_NETFILTER_XT_MATCH_DCCP is not set
# CONFIG_NETFILTER_XT_MATCH_DSCP is not set
# CONFIG_NETFILTER_XT_MATCH_ESP is not set
# CONFIG_NETFILTER_XT_MATCH_HELPER is not set
# CONFIG_NETFILTER_XT_MATCH_LENGTH is not set
CONFIG_NETFILTER_XT_MATCH_LIMIT=m
CONFIG_NETFILTER_XT_MATCH_MAC=m
CONFIG_NETFILTER_XT_MATCH_MARK=m
CONFIG_NETFILTER_XT_MATCH_POLICY=m
# CONFIG_NETFILTER_XT_MATCH_MULTIPORT is not set
# CONFIG_NETFILTER_XT_MATCH_PKTTYPE is not set
# CONFIG_NETFILTER_XT_MATCH_QUOTA is not set
# CONFIG_NETFILTER_XT_MATCH_REALM is not set
CONFIG_NETFILTER_XT_MATCH_SCTP=m
CONFIG_NETFILTER_XT_MATCH_STATE=m
# CONFIG_NETFILTER_XT_MATCH_STATISTIC is not set
CONFIG_NETFILTER_XT_MATCH_STRING=m
CONFIG_NETFILTER_XT_MATCH_TCPMSS=m

#
# IP: Netfilter Configuration
#
CONFIG_IP_NF_CONNTRACK=m
# CONFIG_IP_NF_CT_ACCT is not set
# CONFIG_IP_NF_CONNTRACK_MARK is not set
# CONFIG_IP_NF_CONNTRACK_EVENTS is not set
# CONFIG_IP_NF_CONNTRACK_NETLINK is not set
# CONFIG_IP_NF_CT_PROTO_SCTP is not set
# CONFIG_IP_NF_FTP is not set
# CONFIG_IP_NF_IRC is not set
# CONFIG_IP_NF_NETBIOS_NS is not set
# CONFIG_IP_NF_TFTP is not set
# CONFIG_IP_NF_AMANDA is not set
# CONFIG_IP_NF_PPTP is not set
# CONFIG_IP_NF_H323 is not set
# CONFIG_IP_NF_SIP is not set
CONFIG_IP_NF_QUEUE=m
CONFIG_IP_NF_IPTABLES=m
CONFIG_IP_NF_MATCH_IPRANGE=m
CONFIG_IP_NF_MATCH_TOS=m
CONFIG_IP_NF_MATCH_RECENT=m
# CONFIG_IP_NF_MATCH_ECN is not set
# CONFIG_IP_NF_MATCH_AH is not set
# CONFIG_IP_NF_MATCH_TTL is not set
CONFIG_IP_NF_MATCH_OWNER=m
CONFIG_IP_NF_MATCH_ADDRTYPE=m
CONFIG_IP_NF_MATCH_HASHLIMIT=m
CONFIG_IP_NF_FILTER=m
CONFIG_IP_NF_TARGET_REJECT=m
CONFIG_IP_NF_TARGET_LOG=m
CONFIG_IP_NF_TARGET_ULOG=m
# CONFIG_IP_NF_TARGET_TCPMSS is not set
CONFIG_IP_NF_NAT=m
CONFIG_IP_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=m
CONFIG_IP_NF_TARGET_REDIRECT=m
CONFIG_IP_NF_TARGET_NETMAP=m
CONFIG_IP_NF_TARGET_SAME=m
CONFIG_IP_NF_NAT_SNMP_BASIC=m
CONFIG_IP_NF_MANGLE=m
CONFIG_IP_NF_TARGET_TOS=m
CONFIG_IP_NF_TARGET_ECN=m
CONFIG_IP_NF_TARGET_TTL=m
# CONFIG_IP_NF_RAW is not set
CONFIG_IP_NF_ARPTABLES=m
CONFIG_IP_NF_ARPFILTER=m
# CONFIG_IP_NF_ARP_MANGLE is not set

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

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

#
# TIPC Configuration (EXPERIMENTAL)
#
# CONFIG_TIPC is not set
CONFIG_ATM=m
CONFIG_ATM_CLIP=m
# CONFIG_ATM_CLIP_NO_ICMP is not set
# CONFIG_ATM_LANE is not set
CONFIG_ATM_BR2684=m
# CONFIG_ATM_BR2684_IPFILTER is not set
# CONFIG_BRIDGE is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_NET_DIVERT is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set

#
# QoS and/or fair queueing
#
CONFIG_NET_SCHED=y
CONFIG_NET_SCH_CLK_JIFFIES=y
# CONFIG_NET_SCH_CLK_GETTIMEOFDAY is not set
# CONFIG_NET_SCH_CLK_CPU is not set

#
# Queueing/Scheduling
#
CONFIG_NET_SCH_CBQ=m
CONFIG_NET_SCH_HTB=m
CONFIG_NET_SCH_HFSC=m
# CONFIG_NET_SCH_ATM is not set
CONFIG_NET_SCH_PRIO=m
CONFIG_NET_SCH_RED=m
CONFIG_NET_SCH_SFQ=m
CONFIG_NET_SCH_TEQL=m
CONFIG_NET_SCH_TBF=m
CONFIG_NET_SCH_GRED=m
CONFIG_NET_SCH_DSMARK=m
# CONFIG_NET_SCH_NETEM is not set
CONFIG_NET_SCH_INGRESS=m

#
# Classification
#
CONFIG_NET_CLS=y
CONFIG_NET_CLS_BASIC=m
CONFIG_NET_CLS_TCINDEX=m
CONFIG_NET_CLS_ROUTE4=m
CONFIG_NET_CLS_ROUTE=y
CONFIG_NET_CLS_FW=m
CONFIG_NET_CLS_U32=m
CONFIG_CLS_U32_PERF=y
CONFIG_CLS_U32_MARK=y
CONFIG_NET_CLS_RSVP=m
# CONFIG_NET_CLS_RSVP6 is not set
# CONFIG_NET_EMATCH is not set
# CONFIG_NET_CLS_ACT is not set
CONFIG_NET_CLS_POLICE=y
# CONFIG_NET_CLS_IND is not set
CONFIG_NET_ESTIMATOR=y

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_HAMRADIO is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
# CONFIG_IEEE80211 is not set
CONFIG_WIRELESS_EXT=y

#
# Device Drivers
#

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

#
# Connector - unified userspace <-> kernelspace linker
#
# CONFIG_CONNECTOR is not set

#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set

#
# Parallel port support
#
CONFIG_PARPORT=m
CONFIG_PARPORT_PC=m
# CONFIG_PARPORT_PC_FIFO is not set
# CONFIG_PARPORT_PC_SUPERIO is not set
# CONFIG_PARPORT_GSC is not set
# CONFIG_PARPORT_AX88796 is not set
CONFIG_PARPORT_1284=y

#
# Plug and Play support
#
# CONFIG_PNP is not set

#
# Block devices
#
CONFIG_BLK_DEV_FD=m
# CONFIG_BLK_DEV_XD is not set
# CONFIG_PARIDE is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=m
CONFIG_BLK_DEV_CRYPTOLOOP=m
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_SX8 is not set
CONFIG_BLK_DEV_UB=m
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=4096
CONFIG_BLK_DEV_RAM_BLOCKSIZE=1024
CONFIG_BLK_DEV_INITRD=y
CONFIG_CDROM_PKTCDVD=m
CONFIG_CDROM_PKTCDVD_BUFFERS=8
# CONFIG_CDROM_PKTCDVD_WCACHE is not set
# CONFIG_ATA_OVER_ETH is not set

#
# ATA/ATAPI/MFM/RLL support
#
CONFIG_IDE=y
CONFIG_IDE_MAX_HWIFS=2
CONFIG_BLK_DEV_IDE=y

#
# Please see Documentation/ide.txt for help/info on IDE drives
#
# CONFIG_BLK_DEV_IDE_SATA is not set
# CONFIG_BLK_DEV_HD_IDE is not set
CONFIG_BLK_DEV_IDEDISK=y
# CONFIG_IDEDISK_MULTI_MODE is not set
CONFIG_BLK_DEV_IDECD=m
# CONFIG_BLK_DEV_IDETAPE is not set
# CONFIG_BLK_DEV_IDEFLOPPY is not set
CONFIG_BLK_DEV_IDESCSI=m
# CONFIG_IDE_TASK_IOCTL is not set

#
# IDE chipset support/bugfixes
#
CONFIG_IDE_GENERIC=m
# CONFIG_BLK_DEV_CMD640 is not set
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
# CONFIG_BLK_DEV_OFFBOARD is not set
# CONFIG_BLK_DEV_GENERIC is not set
# CONFIG_BLK_DEV_OPTI621 is not set
# CONFIG_BLK_DEV_RZ1000 is not set
CONFIG_BLK_DEV_IDEDMA_PCI=y
# CONFIG_BLK_DEV_IDEDMA_FORCED is not set
CONFIG_IDEDMA_PCI_AUTO=y
# CONFIG_IDEDMA_ONLYDISK is not set
# CONFIG_BLK_DEV_AEC62XX is not set
# CONFIG_BLK_DEV_ALI15X3 is not set
# CONFIG_BLK_DEV_AMD74XX is not set
# CONFIG_BLK_DEV_ATIIXP is not set
# CONFIG_BLK_DEV_CMD64X is not set
# CONFIG_BLK_DEV_TRIFLEX is not set
# CONFIG_BLK_DEV_CY82C693 is not set
# CONFIG_BLK_DEV_CS5520 is not set
# CONFIG_BLK_DEV_CS5530 is not set
# CONFIG_BLK_DEV_CS5535 is not set
# CONFIG_BLK_DEV_HPT34X is not set
# CONFIG_BLK_DEV_HPT366 is not set
# CONFIG_BLK_DEV_JMICRON is not set
# CONFIG_BLK_DEV_SC1200 is not set
# CONFIG_BLK_DEV_PIIX is not set
# CONFIG_BLK_DEV_IT821X is not set
# CONFIG_BLK_DEV_NS87415 is not set
# CONFIG_BLK_DEV_PDC202XX_OLD is not set
# CONFIG_BLK_DEV_PDC202XX_NEW is not set
# CONFIG_BLK_DEV_SVWKS is not set
# CONFIG_BLK_DEV_SIIMAGE is not set
# CONFIG_BLK_DEV_SIS5513 is not set
# CONFIG_BLK_DEV_SLC90E66 is not set
# CONFIG_BLK_DEV_TRM290 is not set
CONFIG_BLK_DEV_VIA82CXXX=m
# CONFIG_IDE_ARM is not set
# CONFIG_IDE_CHIPSETS is not set
CONFIG_BLK_DEV_IDEDMA=y
# CONFIG_IDEDMA_IVB is not set
CONFIG_IDEDMA_AUTO=y
# CONFIG_BLK_DEV_HD is not set

#
# SCSI device support
#
# CONFIG_RAID_ATTRS is not set
CONFIG_SCSI=m
CONFIG_SCSI_NETLINK=y
# CONFIG_SCSI_TGT is not set
CONFIG_SCSI_PROC_FS=y

#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=m
CONFIG_CHR_DEV_ST=m
# CONFIG_CHR_DEV_OSST is not set
CONFIG_BLK_DEV_SR=m
CONFIG_BLK_DEV_SR_VENDOR=y
CONFIG_CHR_DEV_SG=m
# CONFIG_CHR_DEV_SCH is not set

#
# Some SCSI devices (e.g. CD jukebox) support multiple LUNs
#
CONFIG_SCSI_MULTI_LUN=y
CONFIG_SCSI_CONSTANTS=y
# CONFIG_SCSI_LOGGING is not set

#
# SCSI Transports
#
CONFIG_SCSI_SPI_ATTRS=m
CONFIG_SCSI_FC_ATTRS=m
# CONFIG_SCSI_ISCSI_ATTRS is not set
# CONFIG_SCSI_SAS_ATTRS is not set
# CONFIG_SCSI_SAS_LIBSAS is not set

#
# SCSI low-level drivers
#
# CONFIG_ISCSI_TCP is not set
# CONFIG_BLK_DEV_3W_XXXX_RAID is not set
# CONFIG_SCSI_3W_9XXX is not set
# CONFIG_SCSI_7000FASST is not set
# CONFIG_SCSI_ACARD is not set
# CONFIG_SCSI_AHA152X is not set
# CONFIG_SCSI_AHA1542 is not set
# CONFIG_SCSI_AACRAID is not set
# CONFIG_SCSI_AIC7XXX is not set
# CONFIG_SCSI_AIC7XXX_OLD is not set
# CONFIG_SCSI_AIC79XX is not set
# CONFIG_SCSI_AIC94XX is not set
# CONFIG_SCSI_DPT_I2O is not set
# CONFIG_SCSI_ADVANSYS is not set
# CONFIG_SCSI_IN2000 is not set
# CONFIG_SCSI_ARCMSR is not set
# CONFIG_MEGARAID_NEWGEN is not set
# CONFIG_MEGARAID_LEGACY is not set
# CONFIG_MEGARAID_SAS is not set
# CONFIG_SCSI_HPTIOP is not set
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_DTC3280 is not set
# CONFIG_SCSI_EATA is not set
# CONFIG_SCSI_FUTURE_DOMAIN is not set
# CONFIG_SCSI_GDTH is not set
# CONFIG_SCSI_GENERIC_NCR5380 is not set
# CONFIG_SCSI_GENERIC_NCR5380_MMIO is not set
# CONFIG_SCSI_IPS is not set
# CONFIG_SCSI_INITIO is not set
# CONFIG_SCSI_INIA100 is not set
# CONFIG_SCSI_PPA is not set
# CONFIG_SCSI_IMM is not set
# CONFIG_SCSI_NCR53C406A is not set
# CONFIG_SCSI_STEX is not set
# CONFIG_SCSI_SYM53C8XX_2 is not set
# CONFIG_SCSI_IPR is not set
# CONFIG_SCSI_PAS16 is not set
# CONFIG_SCSI_PSI240I is not set
# CONFIG_SCSI_QLOGIC_FAS is not set
# CONFIG_SCSI_QLOGIC_1280 is not set
# CONFIG_SCSI_QLA_FC is not set
# CONFIG_SCSI_LPFC is not set
# CONFIG_SCSI_SYM53C416 is not set
# CONFIG_SCSI_DC395x is not set
# CONFIG_SCSI_DC390T is not set
# CONFIG_SCSI_T128 is not set
# CONFIG_SCSI_U14_34F is not set
# CONFIG_SCSI_ULTRASTOR is not set
# CONFIG_SCSI_NSP32 is not set
# CONFIG_SCSI_DEBUG is not set
# CONFIG_SCSI_SRP is not set

#
# Serial ATA (prod) and Parallel ATA (experimental) drivers
#
CONFIG_ATA=m
# CONFIG_SATA_AHCI is not set
# CONFIG_SATA_SVW is not set
# CONFIG_ATA_PIIX is not set
# CONFIG_SATA_MV is not set
# CONFIG_SATA_NV is not set
# CONFIG_PDC_ADMA is not set
# CONFIG_SATA_QSTOR is not set
# CONFIG_SATA_PROMISE is not set
# CONFIG_SATA_SX4 is not set
# CONFIG_SATA_SIL is not set
# CONFIG_SATA_SIL24 is not set
# CONFIG_SATA_SIS is not set
# CONFIG_SATA_ULI is not set
# CONFIG_SATA_VIA is not set
# CONFIG_SATA_VITESSE is not set
# CONFIG_PATA_ALI is not set
# CONFIG_PATA_AMD is not set
# CONFIG_PATA_ARTOP is not set
# CONFIG_PATA_ATIIXP is not set
# CONFIG_PATA_CMD64X is not set
# CONFIG_PATA_CS5520 is not set
# CONFIG_PATA_CS5530 is not set
# CONFIG_PATA_CS5535 is not set
# CONFIG_PATA_CYPRESS is not set
# CONFIG_PATA_EFAR is not set
CONFIG_ATA_GENERIC=m
# CONFIG_PATA_HPT366 is not set
# CONFIG_PATA_HPT37X is not set
# CONFIG_PATA_HPT3X2N is not set
# CONFIG_PATA_HPT3X3 is not set
# CONFIG_PATA_IT8172 is not set
# CONFIG_PATA_IT821X is not set
# CONFIG_PATA_JMICRON is not set
# CONFIG_ATA_JMICRON is not set
# CONFIG_PATA_LEGACY is not set
# CONFIG_PATA_TRIFLEX is not set
# CONFIG_PATA_MPIIX is not set
# CONFIG_PATA_OLDPIIX is not set
# CONFIG_PATA_NETCELL is not set
# CONFIG_PATA_NS87410 is not set
# CONFIG_PATA_OPTI is not set
# CONFIG_PATA_OPTIDMA is not set
# CONFIG_PATA_PDC_OLD is not set
# CONFIG_PATA_QDI is not set
# CONFIG_PATA_RADISYS is not set
# CONFIG_PATA_RZ1000 is not set
# CONFIG_PATA_SC1200 is not set
# CONFIG_PATA_SERVERWORKS is not set
# CONFIG_PATA_PDC2027X is not set
# CONFIG_PATA_SIL680 is not set
# CONFIG_PATA_SIS is not set
CONFIG_PATA_VIA=m
# CONFIG_PATA_WINBOND is not set

#
# Old CD-ROM drivers (not SCSI, not IDE)
#
# CONFIG_CD_NO_IDESCSI is not set

#
# Multi-device support (RAID and LVM)
#
CONFIG_MD=y
CONFIG_BLK_DEV_MD=m
CONFIG_MD_LINEAR=m
CONFIG_MD_RAID0=m
CONFIG_MD_RAID1=m
CONFIG_MD_RAID10=m
CONFIG_MD_RAID456=m
CONFIG_MD_RAID5_RESHAPE=y
# CONFIG_MD_MULTIPATH is not set
# CONFIG_MD_FAULTY is not set
CONFIG_BLK_DEV_DM=m
CONFIG_DM_CRYPT=m
CONFIG_DM_SNAPSHOT=m
CONFIG_DM_MIRROR=m
# CONFIG_DM_ZERO is not set
# CONFIG_DM_MULTIPATH is not set

#
# Fusion MPT device support
#
# CONFIG_FUSION is not set
# CONFIG_FUSION_SPI is not set
# CONFIG_FUSION_FC is not set
# CONFIG_FUSION_SAS is not set

#
# IEEE 1394 (FireWire) support
#
CONFIG_IEEE1394=m

#
# Subsystem Options
#
# CONFIG_IEEE1394_VERBOSEDEBUG is not set
CONFIG_IEEE1394_OUI_DB=y
# CONFIG_IEEE1394_EXTRA_CONFIG_ROMS is not set
# CONFIG_IEEE1394_EXPORT_FULL_API is not set

#
# Device Drivers
#
# CONFIG_IEEE1394_PCILYNX is not set
CONFIG_IEEE1394_OHCI1394=m

#
# Protocol Drivers
#
CONFIG_IEEE1394_VIDEO1394=m
# CONFIG_IEEE1394_SBP2 is not set
# CONFIG_IEEE1394_ETH1394 is not set
CONFIG_IEEE1394_DV1394=m
CONFIG_IEEE1394_RAWIO=m

#
# I2O device support
#
# CONFIG_I2O is not set

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

#
# ARCnet devices
#
# CONFIG_ARCNET is not set

#
# PHY device support
#
# CONFIG_PHYLIB is not set

#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
CONFIG_MII=m
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
# CONFIG_CASSINI is not set
# CONFIG_NET_VENDOR_3COM is not set
# CONFIG_LANCE is not set
# CONFIG_NET_VENDOR_SMC is not set
# CONFIG_NET_VENDOR_RACAL is not set

#
# Tulip family network device support
#
# CONFIG_NET_TULIP is not set
# CONFIG_AT1700 is not set
# CONFIG_DEPCA is not set
# CONFIG_HP100 is not set
# CONFIG_NET_ISA is not set
CONFIG_NET_PCI=y
# CONFIG_PCNET32 is not set
# CONFIG_AMD8111_ETH is not set
# CONFIG_ADAPTEC_STARFIRE is not set
# CONFIG_AC3200 is not set
# CONFIG_APRICOT is not set
# CONFIG_B44 is not set
# CONFIG_FORCEDETH is not set
# CONFIG_CS89x0 is not set
# CONFIG_DGRS is not set
# CONFIG_EEPRO100 is not set
# CONFIG_E100 is not set
# CONFIG_FEALNX is not set
# CONFIG_NATSEMI is not set
CONFIG_NE2K_PCI=m
# CONFIG_8139CP is not set
# CONFIG_8139TOO is not set
# CONFIG_SIS900 is not set
# CONFIG_EPIC100 is not set
# CONFIG_SUNDANCE is not set
# CONFIG_TLAN is not set
# CONFIG_VIA_RHINE is not set
# CONFIG_NET_POCKET is not set

#
# Ethernet (1000 Mbit)
#
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
# CONFIG_E1000 is not set
# CONFIG_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
# CONFIG_R8169 is not set
# CONFIG_SIS190 is not set
# CONFIG_SKGE is not set
# CONFIG_SKY2 is not set
# CONFIG_SK98LIN is not set
# CONFIG_VIA_VELOCITY is not set
# CONFIG_TIGON3 is not set
# CONFIG_BNX2 is not set
# CONFIG_QLA3XXX is not set

#
# Ethernet (10000 Mbit)
#
# CONFIG_CHELSIO_T1 is not set
# CONFIG_IXGB is not set
# CONFIG_S2IO is not set
# CONFIG_MYRI10GE is not set

#
# Token Ring devices
#
# CONFIG_TR is not set

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

#
# Obsolete Wireless cards support (pre-802.11)
#
# CONFIG_STRIP is not set
# CONFIG_ARLAN is not set
# CONFIG_WAVELAN is not set

#
# Wireless 802.11b ISA/PCI cards support
#
# CONFIG_IPW2100 is not set
# CONFIG_IPW2200 is not set
# CONFIG_AIRO is not set
# CONFIG_HERMES is not set
# CONFIG_ATMEL is not set

#
# Prism GT/Duette 802.11(a/b/g) PCI/Cardbus support
#
# CONFIG_PRISM54 is not set
# CONFIG_USB_ZD1201 is not set
# CONFIG_HOSTAP is not set
# CONFIG_ACX is not set
CONFIG_NET_WIRELESS=y

#
# Wan interfaces
#
# CONFIG_WAN is not set

#
# ATM drivers
#
# CONFIG_ATM_DUMMY is not set
# CONFIG_ATM_TCP is not set
# CONFIG_ATM_LANAI is not set
# CONFIG_ATM_ENI is not set
# CONFIG_ATM_FIRESTREAM is not set
# CONFIG_ATM_ZATM is not set
# CONFIG_ATM_NICSTAR is not set
# CONFIG_ATM_IDT77252 is not set
# CONFIG_ATM_AMBASSADOR is not set
# CONFIG_ATM_HORIZON is not set
# CONFIG_ATM_IA is not set
# CONFIG_ATM_FORE200E_MAYBE is not set
# CONFIG_ATM_HE is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
# CONFIG_PLIP is not set
CONFIG_PPP=m
# CONFIG_PPP_MULTILINK is not set
CONFIG_PPP_FILTER=y
CONFIG_PPP_ASYNC=m
CONFIG_PPP_SYNC_TTY=m
CONFIG_PPP_DEFLATE=m
CONFIG_PPP_BSDCOMP=m
# CONFIG_PPP_MPPE is not set
CONFIG_PPPOE=m
CONFIG_PPPOATM=m
# CONFIG_SLIP is not set
CONFIG_SLHC=m
# CONFIG_NET_FC is not set
# CONFIG_SHAPER is not set
CONFIG_NETCONSOLE=y
CONFIG_NETPOLL=y
# CONFIG_NETPOLL_RX is not set
# CONFIG_NETPOLL_TRAP is not set
CONFIG_NET_POLL_CONTROLLER=y

#
# ISDN subsystem
#
# CONFIG_ISDN is not set

#
# Telephony Support
#
# CONFIG_PHONE is not set

#
# Input device support
#
CONFIG_INPUT=y
# CONFIG_INPUT_FF_MEMLESS is not set

#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_PSAUX=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
CONFIG_INPUT_JOYDEV=m
# CONFIG_INPUT_TSDEV is not set
# CONFIG_INPUT_EVDEV is not set
# CONFIG_INPUT_EVBUG is not set

#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_LKKBD is not set
# CONFIG_KEYBOARD_XTKBD is not set
# CONFIG_KEYBOARD_NEWTON is not set
# CONFIG_KEYBOARD_STOWAWAY is not set
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
# CONFIG_MOUSE_SERIAL is not set
# CONFIG_MOUSE_INPORT is not set
# CONFIG_MOUSE_LOGIBM is not set
# CONFIG_MOUSE_PC110PAD is not set
# CONFIG_MOUSE_VSXXXAA is not set
CONFIG_INPUT_JOYSTICK=y
CONFIG_JOYSTICK_ANALOG=m
# CONFIG_JOYSTICK_A3D is not set
# CONFIG_JOYSTICK_ADI is not set
# CONFIG_JOYSTICK_COBRA is not set
# CONFIG_JOYSTICK_GF2K is not set
# CONFIG_JOYSTICK_GRIP is not set
# CONFIG_JOYSTICK_GRIP_MP is not set
# CONFIG_JOYSTICK_GUILLEMOT is not set
# CONFIG_JOYSTICK_INTERACT is not set
# CONFIG_JOYSTICK_SIDEWINDER is not set
# CONFIG_JOYSTICK_TMDC is not set
# CONFIG_JOYSTICK_IFORCE is not set
# CONFIG_JOYSTICK_WARRIOR is not set
# CONFIG_JOYSTICK_MAGELLAN is not set
# CONFIG_JOYSTICK_SPACEORB is not set
# CONFIG_JOYSTICK_SPACEBALL is not set
# CONFIG_JOYSTICK_STINGER is not set
# CONFIG_JOYSTICK_TWIDJOY is not set
# CONFIG_JOYSTICK_DB9 is not set
# CONFIG_JOYSTICK_GAMECON is not set
# CONFIG_JOYSTICK_TURBOGRAFX is not set
# CONFIG_JOYSTICK_JOYDUMP is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
CONFIG_INPUT_MISC=y
CONFIG_INPUT_PCSPKR=m
# CONFIG_INPUT_WISTRON_BTNS is not set
# CONFIG_INPUT_UINPUT is not set

#
# Hardware I/O ports
#
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
# CONFIG_SERIO_SERPORT is not set
# CONFIG_SERIO_CT82C710 is not set
# CONFIG_SERIO_PARKBD is not set
# CONFIG_SERIO_PCIPS2 is not set
CONFIG_SERIO_LIBPS2=y
# CONFIG_SERIO_RAW is not set
CONFIG_GAMEPORT=m
# CONFIG_GAMEPORT_NS558 is not set
# CONFIG_GAMEPORT_L4 is not set
# CONFIG_GAMEPORT_EMU10K1 is not set
# CONFIG_GAMEPORT_FM801 is not set

#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
CONFIG_VT_HW_CONSOLE_BINDING=y
# CONFIG_SERIAL_NONSTANDARD is not set
# CONFIG_NOZOMI is not set

#
# Serial drivers
#
CONFIG_SERIAL_8250=m
# CONFIG_SERIAL_8250_PCI is not set
CONFIG_SERIAL_8250_NR_UARTS=4
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
# CONFIG_SERIAL_8250_EXTENDED is not set

#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=m
# CONFIG_SERIAL_JSM is not set
CONFIG_UNIX98_PTYS=y
# CONFIG_LEGACY_PTYS is not set
CONFIG_PRINTER=m
# CONFIG_LP_CONSOLE is not set
# CONFIG_PPDEV is not set
# CONFIG_TIPAR is not set

#
# IPMI
#
# CONFIG_IPMI_HANDLER is not set

#
# Watchdog Cards
#
# CONFIG_WATCHDOG is not set
# CONFIG_HW_RANDOM is not set
# CONFIG_NVRAM is not set
CONFIG_RTC=m
# CONFIG_GEN_RTC is not set
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
# CONFIG_SONYPI is not set

#
# Ftape, the floppy tape device driver
#
# CONFIG_FTAPE is not set
CONFIG_AGP=m
# CONFIG_AGP_ALI is not set
# CONFIG_AGP_ATI is not set
# CONFIG_AGP_AMD is not set
# CONFIG_AGP_AMD64 is not set
# CONFIG_AGP_INTEL is not set
# CONFIG_AGP_NVIDIA is not set
# CONFIG_AGP_SIS is not set
# CONFIG_AGP_SWORKS is not set
CONFIG_AGP_VIA=m
# CONFIG_AGP_EFFICEON is not set
CONFIG_DRM=m
# CONFIG_DRM_TDFX is not set
# CONFIG_DRM_R128 is not set
# CONFIG_DRM_RADEON is not set
# CONFIG_DRM_MGA is not set
# CONFIG_DRM_SIS is not set
# CONFIG_DRM_VIA is not set
# CONFIG_DRM_SAVAGE is not set
# CONFIG_MWAVE is not set
# CONFIG_PC8736x_GPIO is not set
# CONFIG_NSC_GPIO is not set
# CONFIG_CS5535_GPIO is not set
# CONFIG_RAW_DRIVER is not set
# CONFIG_HPET is not set
# CONFIG_HANGCHECK_TIMER is not set

#
# TPM devices
#
# CONFIG_TCG_TPM is not set
# CONFIG_TELCLOCK is not set

#
# I2C support
#
CONFIG_I2C=y
CONFIG_I2C_CHARDEV=m

#
# I2C Algorithms
#
CONFIG_I2C_ALGOBIT=m
CONFIG_I2C_ALGOPCF=m
CONFIG_I2C_ALGOPCA=m

#
# I2C Hardware Bus support
#
# CONFIG_I2C_ALI1535 is not set
# CONFIG_I2C_ALI1563 is not set
# CONFIG_I2C_ALI15X3 is not set
# CONFIG_I2C_AMD756 is not set
# CONFIG_I2C_AMD8111 is not set
# CONFIG_I2C_ELEKTOR is not set
# CONFIG_I2C_I801 is not set
# CONFIG_I2C_I810 is not set
# CONFIG_I2C_PIIX4 is not set
CONFIG_I2C_ISA=m
# CONFIG_I2C_NFORCE2 is not set
# CONFIG_I2C_OCORES is not set
# CONFIG_I2C_PARPORT is not set
# CONFIG_I2C_PARPORT_LIGHT is not set
# CONFIG_I2C_PROSAVAGE is not set
# CONFIG_I2C_SAVAGE4 is not set
# CONFIG_SCx200_ACB is not set
# CONFIG_I2C_SIS5595 is not set
# CONFIG_I2C_SIS630 is not set
# CONFIG_I2C_SIS96X is not set
# CONFIG_I2C_STUB is not set
CONFIG_I2C_VIA=m
CONFIG_I2C_VIAPRO=m
# CONFIG_I2C_VOODOO3 is not set
# CONFIG_I2C_PCA_ISA is not set

#
# Miscellaneous I2C Chip support
#
# CONFIG_SENSORS_DS1337 is not set
# CONFIG_SENSORS_DS1374 is not set
# CONFIG_SENSORS_EEPROM is not set
# CONFIG_SENSORS_PCF8574 is not set
# CONFIG_SENSORS_PCA9539 is not set
# CONFIG_SENSORS_PCF8591 is not set
# CONFIG_SENSORS_MAX6875 is not set
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
# CONFIG_I2C_DEBUG_CHIP is not set

#
# SPI support
#
# CONFIG_SPI is not set
# CONFIG_SPI_MASTER is not set

#
# Dallas's 1-wire bus
#

#
# Hardware Monitoring support
#
CONFIG_HWMON=y
CONFIG_HWMON_VID=m
# CONFIG_SENSORS_ABITUGURU is not set
# CONFIG_SENSORS_ADM1021 is not set
# CONFIG_SENSORS_ADM1025 is not set
# CONFIG_SENSORS_ADM1026 is not set
# CONFIG_SENSORS_ADM1031 is not set
# CONFIG_SENSORS_ADM9240 is not set
# CONFIG_SENSORS_K8TEMP is not set
# CONFIG_SENSORS_ASB100 is not set
# CONFIG_SENSORS_ATXP1 is not set
# CONFIG_SENSORS_DS1621 is not set
# CONFIG_SENSORS_F71805F is not set
# CONFIG_SENSORS_FSCHER is not set
# CONFIG_SENSORS_FSCPOS is not set
# CONFIG_SENSORS_GL518SM is not set
# CONFIG_SENSORS_GL520SM is not set
# CONFIG_SENSORS_IT87 is not set
# CONFIG_SENSORS_LM63 is not set
# CONFIG_SENSORS_LM75 is not set
# CONFIG_SENSORS_LM77 is not set
# CONFIG_SENSORS_LM78 is not set
CONFIG_SENSORS_LM80=m
# CONFIG_SENSORS_LM83 is not set
# CONFIG_SENSORS_LM85 is not set
# CONFIG_SENSORS_LM87 is not set
# CONFIG_SENSORS_LM90 is not set
# CONFIG_SENSORS_LM92 is not set
# CONFIG_SENSORS_MAX1619 is not set
# CONFIG_SENSORS_PC87360 is not set
# CONFIG_SENSORS_SIS5595 is not set
# CONFIG_SENSORS_SMSC47M1 is not set
# CONFIG_SENSORS_SMSC47M192 is not set
# CONFIG_SENSORS_SMSC47B397 is not set
CONFIG_SENSORS_VIA686A=m
# CONFIG_SENSORS_VT8231 is not set
CONFIG_SENSORS_W83781D=m
# CONFIG_SENSORS_W83791D is not set
# CONFIG_SENSORS_W83792D is not set
# CONFIG_SENSORS_W83L785TS is not set
# CONFIG_SENSORS_W83627HF is not set
# CONFIG_SENSORS_W83627EHF is not set
# CONFIG_SENSORS_HDAPS is not set
# CONFIG_HWMON_DEBUG_CHIP is not set

#
# Misc devices
#
# CONFIG_IBM_ASM is not set

#
# Multimedia devices
#
CONFIG_VIDEO_DEV=m
# CONFIG_VIDEO_V4L1 is not set
CONFIG_VIDEO_V4L1_COMPAT=y
CONFIG_VIDEO_V4L2=y

#
# Video Capture Adapters
#

#
# Video Capture Adapters
#
# CONFIG_VIDEO_ADV_DEBUG is not set
CONFIG_VIDEO_HELPER_CHIPS_AUTO=y
# CONFIG_VIDEO_VIVI is not set
# CONFIG_VIDEO_SAA5246A is not set
# CONFIG_VIDEO_SAA5249 is not set
# CONFIG_VIDEO_SAA7134 is not set
# CONFIG_VIDEO_HEXIUM_ORION is not set
# CONFIG_VIDEO_HEXIUM_GEMINI is not set
# CONFIG_VIDEO_CX88 is not set

#
# V4L USB devices
#

#
# Radio Adapters
#
# CONFIG_RADIO_CADET is not set
# CONFIG_RADIO_RTRACK is not set
# CONFIG_RADIO_RTRACK2 is not set
# CONFIG_RADIO_AZTECH is not set
# CONFIG_RADIO_GEMTEK is not set
# CONFIG_RADIO_GEMTEK_PCI is not set
# CONFIG_RADIO_MAXIRADIO is not set
# CONFIG_RADIO_MAESTRO is not set
# CONFIG_RADIO_SF16FMI is not set
# CONFIG_RADIO_SF16FMR2 is not set
# CONFIG_RADIO_TERRATEC is not set
# CONFIG_RADIO_TRUST is not set
# CONFIG_RADIO_TYPHOON is not set
# CONFIG_RADIO_ZOLTRIX is not set

#
# Digital Video Broadcasting Devices
#
# CONFIG_DVB is not set
# CONFIG_USB_DABUSB is not set

#
# Graphics support
#
CONFIG_FIRMWARE_EDID=y
CONFIG_FB=y
CONFIG_FB_DDC=m
CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y
# CONFIG_FB_MACMODES is not set
# CONFIG_FB_BACKLIGHT is not set
CONFIG_FB_MODE_HELPERS=y
# CONFIG_FB_TILEBLITTING is not set
# CONFIG_FB_CIRRUS is not set
# CONFIG_FB_PM2 is not set
# CONFIG_FB_CYBER2000 is not set
# CONFIG_FB_ARC is not set
# CONFIG_FB_ASILIANT is not set
# CONFIG_FB_IMSTT is not set
# CONFIG_FB_VGA16 is not set
CONFIG_FB_VESA=y
# CONFIG_FB_HGA is not set
# CONFIG_FB_S1D13XXX is not set
CONFIG_FB_NVIDIA=m
CONFIG_FB_NVIDIA_I2C=y
CONFIG_FB_RIVA=m
CONFIG_FB_RIVA_I2C=y
# CONFIG_FB_RIVA_DEBUG is not set
# CONFIG_FB_I810 is not set
# CONFIG_FB_INTEL is not set
# CONFIG_FB_MATROX is not set
# CONFIG_FB_RADEON is not set
# CONFIG_FB_ATY128 is not set
# CONFIG_FB_ATY is not set
# CONFIG_FB_SAVAGE is not set
# CONFIG_FB_SIS is not set
# CONFIG_FB_NEOMAGIC is not set
# CONFIG_FB_KYRO is not set
# CONFIG_FB_3DFX is not set
# CONFIG_FB_VOODOO1 is not set
# CONFIG_FB_CYBLA is not set
# CONFIG_FB_TRIDENT is not set
# CONFIG_FB_GEODE is not set
# CONFIG_FB_VIRTUAL is not set

#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
# CONFIG_VGACON_SOFT_SCROLLBACK is not set
CONFIG_VIDEO_SELECT=y
# CONFIG_MDA_CONSOLE is not set
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
# CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set
# CONFIG_FONTS is not set
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y

#
# Logo configuration
#
CONFIG_LOGO=y
CONFIG_LOGO_LINUX_MONO=y
CONFIG_LOGO_LINUX_VGA16=y
CONFIG_LOGO_LINUX_CLUT224=y
# CONFIG_BACKLIGHT_LCD_SUPPORT is not set

#
# Sound
#
CONFIG_SOUND=m

#
# Advanced Linux Sound Architecture
#
CONFIG_SND=m
CONFIG_SND_TIMER=m
CONFIG_SND_PCM=m
CONFIG_SND_RAWMIDI=m
CONFIG_SND_SEQUENCER=m
# CONFIG_SND_SEQ_DUMMY is not set
CONFIG_SND_OSSEMUL=y
CONFIG_SND_MIXER_OSS=m
CONFIG_SND_PCM_OSS=m
CONFIG_SND_PCM_OSS_PLUGINS=y
CONFIG_SND_SEQUENCER_OSS=y
CONFIG_SND_RTCTIMER=m
CONFIG_SND_SEQ_RTCTIMER_DEFAULT=y
CONFIG_SND_DYNAMIC_MINORS=y
# CONFIG_SND_SUPPORT_OLD_API is not set
# CONFIG_SND_VERBOSE_PROCFS is not set
# CONFIG_SND_VERBOSE_PRINTK is not set
# CONFIG_SND_DEBUG is not set

#
# Generic devices
#
CONFIG_SND_AC97_CODEC=m
CONFIG_SND_AC97_BUS=m
# CONFIG_SND_DUMMY is not set
# CONFIG_SND_VIRMIDI is not set
# CONFIG_SND_MTPAV is not set
# CONFIG_SND_MTS64 is not set
# CONFIG_SND_SERIAL_U16550 is not set
# CONFIG_SND_MPU401 is not set
# CONFIG_SND_AC97_POWER_SAVE is not set

#
# ISA devices
#
# CONFIG_SND_ADLIB is not set
# CONFIG_SND_AD1848 is not set
# CONFIG_SND_CMI8330 is not set
# CONFIG_SND_CS4231 is not set
# CONFIG_SND_CS4232 is not set
# CONFIG_SND_CS4236 is not set
# CONFIG_SND_ES1688 is not set
# CONFIG_SND_ES18XX is not set
# CONFIG_SND_GUSCLASSIC is not set
# CONFIG_SND_GUSEXTREME is not set
# CONFIG_SND_GUSMAX is not set
# CONFIG_SND_OPL3SA2 is not set
# CONFIG_SND_OPTI92X_AD1848 is not set
# CONFIG_SND_OPTI92X_CS4231 is not set
# CONFIG_SND_OPTI93X is not set
# CONFIG_SND_MIRO is not set
# CONFIG_SND_SB8 is not set
# CONFIG_SND_SB16 is not set
# CONFIG_SND_SBAWE is not set
# CONFIG_SND_SGALAXY is not set
# CONFIG_SND_SSCAPE is not set
# CONFIG_SND_WAVEFRONT is not set

#
# PCI devices
#
# CONFIG_SND_AD1889 is not set
# CONFIG_SND_ALS300 is not set
# CONFIG_SND_ALS4000 is not set
# CONFIG_SND_ALI5451 is not set
# CONFIG_SND_ATIIXP is not set
# CONFIG_SND_ATIIXP_MODEM is not set
# CONFIG_SND_AU8810 is not set
# CONFIG_SND_AU8820 is not set
# CONFIG_SND_AU8830 is not set
# CONFIG_SND_AZT3328 is not set
# CONFIG_SND_BT87X is not set
# CONFIG_SND_CA0106 is not set
# CONFIG_SND_CMIPCI is not set
# CONFIG_SND_CS4281 is not set
# CONFIG_SND_CS46XX is not set
# CONFIG_SND_CS5535AUDIO is not set
# CONFIG_SND_DARLA20 is not set
# CONFIG_SND_GINA20 is not set
# CONFIG_SND_LAYLA20 is not set
# CONFIG_SND_DARLA24 is not set
# CONFIG_SND_GINA24 is not set
# CONFIG_SND_LAYLA24 is not set
# CONFIG_SND_MONA is not set
# CONFIG_SND_MIA is not set
# CONFIG_SND_ECHO3G is not set
# CONFIG_SND_INDIGO is not set
# CONFIG_SND_INDIGOIO is not set
# CONFIG_SND_INDIGODJ is not set
# CONFIG_SND_EMU10K1 is not set
# CONFIG_SND_EMU10K1X is not set
# CONFIG_SND_ENS1370 is not set
CONFIG_SND_ENS1371=m
# CONFIG_SND_ES1938 is not set
# CONFIG_SND_ES1968 is not set
# CONFIG_SND_FM801 is not set
# CONFIG_SND_HDA_INTEL is not set
# CONFIG_SND_HDSP is not set
# CONFIG_SND_HDSPM is not set
# CONFIG_SND_ICE1712 is not set
# CONFIG_SND_ICE1724 is not set
# CONFIG_SND_INTEL8X0 is not set
# CONFIG_SND_INTEL8X0M is not set
# CONFIG_SND_KORG1212 is not set
# CONFIG_SND_MAESTRO3 is not set
# CONFIG_SND_MIXART is not set
# CONFIG_SND_NM256 is not set
# CONFIG_SND_PCXHR is not set
# CONFIG_SND_RIPTIDE is not set
# CONFIG_SND_RME32 is not set
# CONFIG_SND_RME96 is not set
# CONFIG_SND_RME9652 is not set
# CONFIG_SND_SONICVIBES is not set
# CONFIG_SND_TRIDENT is not set
# CONFIG_SND_VIA82XX is not set
# CONFIG_SND_VIA82XX_MODEM is not set
# CONFIG_SND_VX222 is not set
# CONFIG_SND_YMFPCI is not set

#
# USB devices
#
# CONFIG_SND_USB_AUDIO is not set
# CONFIG_SND_USB_USX2Y is not set

#
# Open Sound System
#
# CONFIG_SOUND_PRIME is not set

#
# USB support
#
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB_ARCH_HAS_EHCI=y
CONFIG_USB=m
# CONFIG_USB_DEBUG is not set

#
# Miscellaneous USB options
#
CONFIG_USB_DEVICEFS=y
CONFIG_USB_BANDWIDTH=y
CONFIG_USB_DYNAMIC_MINORS=y
CONFIG_USB_SUSPEND=y
CONFIG_USB_MULTITHREAD_PROBE=y
# CONFIG_USB_OTG is not set

#
# USB Host Controller Drivers
#
CONFIG_USB_EHCI_HCD=m
# CONFIG_USB_EHCI_SPLIT_ISO is not set
CONFIG_USB_EHCI_ROOT_HUB_TT=y
# CONFIG_USB_EHCI_TT_NEWSCHED is not set
# CONFIG_USB_ISP116X_HCD is not set
# CONFIG_USB_OHCI_HCD is not set
CONFIG_USB_UHCI_HCD=m
# CONFIG_USB_SL811_HCD is not set

#
# USB Device Class drivers
#
# CONFIG_USB_ACM is not set
CONFIG_USB_PRINTER=m

#
# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support'
#

#
# may also be needed; see USB_STORAGE Help for more information
#
CONFIG_USB_STORAGE=m
# CONFIG_USB_STORAGE_DEBUG is not set
# CONFIG_USB_STORAGE_DATAFAB is not set
# CONFIG_USB_STORAGE_FREECOM is not set
# CONFIG_USB_STORAGE_ISD200 is not set
# CONFIG_USB_STORAGE_DPCM is not set
# CONFIG_USB_STORAGE_USBAT is not set
# CONFIG_USB_STORAGE_SDDR09 is not set
# CONFIG_USB_STORAGE_SDDR55 is not set
# CONFIG_USB_STORAGE_JUMPSHOT is not set
# CONFIG_USB_STORAGE_ALAUDA is not set
# CONFIG_USB_STORAGE_KARMA is not set
# CONFIG_USB_LIBUSUAL is not set

#
# USB Input Devices
#
CONFIG_USB_HID=m
CONFIG_USB_HIDINPUT=y
# CONFIG_USB_HIDINPUT_POWERBOOK is not set
# CONFIG_HID_FF is not set
# CONFIG_USB_HIDDEV is not set

#
# USB HID Boot Protocol drivers
#
# CONFIG_USB_KBD is not set
# CONFIG_USB_MOUSE is not set
# CONFIG_USB_AIPTEK is not set
# CONFIG_USB_WACOM is not set
# CONFIG_USB_ACECAD is not set
# CONFIG_USB_KBTAB is not set
# CONFIG_USB_POWERMATE is not set
# CONFIG_USB_TOUCHSCREEN is not set
# CONFIG_USB_YEALINK is not set
# CONFIG_USB_XPAD is not set
# CONFIG_USB_ATI_REMOTE is not set
# CONFIG_USB_ATI_REMOTE2 is not set
# CONFIG_USB_KEYSPAN_REMOTE is not set
# CONFIG_USB_APPLETOUCH is not set
# CONFIG_USB_TRANCEVIBRATOR is not set

#
# USB Imaging devices
#
# CONFIG_USB_MDC800 is not set
# CONFIG_USB_MICROTEK is not set

#
# USB Network Adapters
#
# CONFIG_USB_CATC is not set
# CONFIG_USB_KAWETH is not set
# CONFIG_USB_PEGASUS is not set
# CONFIG_USB_RTL8150 is not set
# CONFIG_USB_USBNET is not set
# CONFIG_USB_MON is not set

#
# USB port drivers
#
# CONFIG_USB_USS720 is not set

#
# USB Serial Converter support
#
# CONFIG_USB_SERIAL is not set

#
# USB Miscellaneous drivers
#
# CONFIG_USB_EMI62 is not set
# CONFIG_USB_EMI26 is not set
# CONFIG_USB_ADUTUX is not set
# CONFIG_USB_AUERSWALD is not set
# CONFIG_USB_RIO500 is not set
# CONFIG_USB_LEGOTOWER is not set
# CONFIG_USB_LCD is not set
# CONFIG_USB_LED is not set
# CONFIG_USB_CYPRESS_CY7C63 is not set
# CONFIG_USB_CYTHERM is not set
# CONFIG_USB_PHIDGET is not set
# CONFIG_USB_IDMOUSE is not set
# CONFIG_USB_APPLEDISPLAY is not set
# CONFIG_USB_SISUSBVGA is not set
# CONFIG_USB_LD is not set
# CONFIG_USB_TEST is not set
# CONFIG_USB_GOTEMP is not set

#
# USB DSL modem support
#
CONFIG_USB_ATM=m
# CONFIG_USB_SPEEDTOUCH is not set
# CONFIG_USB_CXACRU is not set
CONFIG_USB_UEAGLEATM=m
# CONFIG_USB_XUSBATM is not set

#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set

#
# MMC/SD Card support
#
# CONFIG_MMC is not set

#
# LED devices
#
# CONFIG_NEW_LEDS is not set

#
# LED drivers
#

#
# LED Triggers
#

#
# InfiniBand support
#
# CONFIG_INFINIBAND is not set

#
# EDAC - error detection and reporting (RAS) (EXPERIMENTAL)
#
CONFIG_EDAC=m

#
# Reporting subsystems
#
# CONFIG_EDAC_DEBUG is not set
CONFIG_EDAC_MM_EDAC=m
CONFIG_EDAC_AMD76X=m
# CONFIG_EDAC_E7XXX is not set
# CONFIG_EDAC_E752X is not set
# CONFIG_EDAC_I82875P is not set
# CONFIG_EDAC_I82860 is not set
# CONFIG_EDAC_K8 is not set
# CONFIG_EDAC_R82600 is not set
CONFIG_EDAC_POLL=y

#
# Real Time Clock
#
# CONFIG_RTC_CLASS is not set

#
# DMA Engine support
#
CONFIG_DMA_ENGINE=y

#
# DMA Clients
#
CONFIG_NET_DMA=y

#
# DMA Devices
#
# CONFIG_INTEL_IOATDMA is not set

#
# Userspace I/O
#
# CONFIG_UIO is not set

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

#
# Caches
#
# CONFIG_FSCACHE is not set

#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=m
CONFIG_JOLIET=y
# CONFIG_ZISOFS is not set
CONFIG_UDF_FS=m
CONFIG_UDF_NLS=y

#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=m
CONFIG_MSDOS_FS=m
CONFIG_VFAT_FS=m
CONFIG_FAT_DEFAULT_CODEPAGE=850
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
# CONFIG_NTFS_FS is not set

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

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

#
# Network File Systems
#
CONFIG_NFS_FS=m
CONFIG_NFS_V3=y
# CONFIG_NFS_V3_ACL is not set
CONFIG_NFS_V4=y
# CONFIG_NFS_DIRECTIO is not set
CONFIG_NFSD=m
CONFIG_NFSD_V3=y
# CONFIG_NFSD_V3_ACL is not set
CONFIG_NFSD_V4=y
CONFIG_NFSD_TCP=y
CONFIG_LOCKD=m
CONFIG_LOCKD_V4=y
CONFIG_EXPORTFS=m
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=m
CONFIG_SUNRPC_GSS=m
CONFIG_RPCSEC_GSS_KRB5=m
# CONFIG_RPCSEC_GSS_SPKM3 is not set
CONFIG_SMB_FS=m
# CONFIG_SMB_NLS_DEFAULT is not set
CONFIG_CIFS=m
CONFIG_CIFS_STATS=y
# CONFIG_CIFS_STATS2 is not set
# CONFIG_CIFS_WEAK_PW_HASH is not set
CONFIG_CIFS_XATTR=y
CONFIG_CIFS_POSIX=y
# CONFIG_CIFS_DEBUG2 is not set
# CONFIG_CIFS_EXPERIMENTAL is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set
# CONFIG_9P_FS is not set

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

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

#
# Distributed Lock Manager
#

#
# Instrumentation Support
#
# CONFIG_PROFILING is not set
# CONFIG_KPROBES is not set

#
# Kernel hacking
#
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
# CONFIG_PRINTK_TIME is not set
CONFIG_ENABLE_MUST_CHECK=y
CONFIG_MAGIC_SYSRQ=y
CONFIG_UNUSED_SYMBOLS=y
CONFIG_DEBUG_KERNEL=y
CONFIG_DEBUG_SHIRQ=y
CONFIG_LOG_BUF_SHIFT=15
CONFIG_DETECT_SOFTLOCKUP=y
# CONFIG_SCHEDSTATS is not set
CONFIG_DEBUG_SLAB=y
CONFIG_DEBUG_SLAB_LEAK=y
CONFIG_DEBUG_RT_MUTEXES=y
CONFIG_DEBUG_PI_LIST=y
# CONFIG_RT_MUTEX_TESTER is not set
CONFIG_DEBUG_SPINLOCK=y
CONFIG_DEBUG_MUTEXES=y
CONFIG_DEBUG_RWSEMS=y
CONFIG_DEBUG_LOCK_ALLOC=y
CONFIG_PROVE_LOCKING=y
CONFIG_LOCKDEP=y
CONFIG_DEBUG_LOCKDEP=y
CONFIG_TRACE_IRQFLAGS=y
CONFIG_DEBUG_SPINLOCK_SLEEP=y
CONFIG_DEBUG_LOCKING_API_SELFTESTS=y
CONFIG_STACKTRACE=y
# CONFIG_DEBUG_KOBJECT is not set
CONFIG_DEBUG_BUGVERBOSE=y
# CONFIG_DEBUG_INFO is not set
# CONFIG_PAGE_OWNER is not set
CONFIG_DEBUG_FS=y
# CONFIG_DEBUG_VM is not set
# CONFIG_DEBUG_LIST is not set
CONFIG_FRAME_POINTER=y
CONFIG_UNWIND_INFO=y
# CONFIG_STACK_UNWIND is not set
# CONFIG_PROFILE_LIKELY is not set
CONFIG_FORCED_INLINING=y
# CONFIG_DEBUG_SYNCHRO_TEST is not set
# CONFIG_RCU_TORTURE_TEST is not set
CONFIG_EARLY_PRINTK=y
CONFIG_DEBUG_STACKOVERFLOW=y
CONFIG_DEBUG_STACK_USAGE=y

#
# Page alloc debug is incompatible with Software Suspend on i386
#
CONFIG_DEBUG_RODATA=y
# CONFIG_4KSTACKS is not set
CONFIG_X86_FIND_SMP_CONFIG=y
CONFIG_X86_MPPARSE=y
CONFIG_DOUBLEFAULT=y

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

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

#
# Hardware crypto devices
#
# CONFIG_CRYPTO_DEV_PADLOCK is not set
# CONFIG_CRYPTO_DEV_GEODE is not set

#
# Library routines
#
CONFIG_CRC_CCITT=m
# CONFIG_CRC16 is not set
CONFIG_CRC32=y
CONFIG_LIBCRC32C=m
CONFIG_ZLIB_INFLATE=m
CONFIG_ZLIB_DEFLATE=m
CONFIG_TEXTSEARCH=y
CONFIG_TEXTSEARCH_KMP=m
CONFIG_TEXTSEARCH_BM=m
CONFIG_TEXTSEARCH_FSM=m
CONFIG_PLIST=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_X86_BIOS_REBOOT=y
CONFIG_KTIME_SCALAR=y

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: 2.6.18-rc6-mm1: GPF loop on early boot
  2006-09-10 12:36       ` 2.6.18-rc6-mm1: GPF loop on early boot Laurent Riffard
@ 2006-09-10 13:07         ` Ingo Molnar
  0 siblings, 0 replies; 114+ messages in thread
From: Ingo Molnar @ 2006-09-10 13:07 UTC (permalink / raw)
  To: Laurent Riffard
  Cc: Andi Kleen, Arjan van de Ven, Andrew Morton,
	Kernel development list, Jeremy Fitzhardinge


* Laurent Riffard <laurent.riffard@free.fr> wrote:

> Ingo, I attached my .config to my first post. mmm... It did not reach 
> LKML, so here is it again.

unfortunately i cannot reproduce it - could you send the screenshots 
(privately)? Which version of gcc are you using?

	Ingo

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: 2.6.18-rc6-mm1: GPF loop on early boot
  2006-09-10 11:57     ` Ingo Molnar
  2006-09-10 11:34       ` Andi Kleen
  2006-09-10 12:36       ` 2.6.18-rc6-mm1: GPF loop on early boot Laurent Riffard
@ 2006-09-10 13:11       ` Ingo Molnar
  2 siblings, 0 replies; 114+ messages in thread
From: Ingo Molnar @ 2006-09-10 13:11 UTC (permalink / raw)
  To: Andi Kleen
  Cc: Laurent Riffard, Arjan van de Ven, Andrew Morton,
	Kernel development list, Jeremy Fitzhardinge


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

> > It's lockdep's fault. This patch should fix it:
> 
> Well, it's also x86_64's fault [...]

ok, i see it happens on i686 - i assumed it's x86_64 because of the 
reference to PDA. Investigating it ...

	Ingo

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: 2.6.18-rc6-mm1: GPF loop on early boot
  2006-09-10 11:34       ` Andi Kleen
@ 2006-09-10 13:26         ` Ingo Molnar
  2006-09-10 13:55           ` Andi Kleen
  2006-09-10 16:33           ` Andrew Morton
  0 siblings, 2 replies; 114+ messages in thread
From: Ingo Molnar @ 2006-09-10 13:26 UTC (permalink / raw)
  To: Andi Kleen
  Cc: Laurent Riffard, Arjan van de Ven, Andrew Morton,
	Kernel development list, Jeremy Fitzhardinge


* Andi Kleen <ak@suse.de> wrote:

> > Basically, non-atomic setup of basic architecture state _is_ going to be
> > a nightmare, lockdep or not, especially if it uses common infrastructure
> > like 'current', spin_lock() or even something as simple as C functions.
> > (for example the stack-footprint tracer was once hit by this weakness of
> > the x86_64 code)
> 
> I disagree with that.  The nightmare is putting stuff that needs so 
> much infrastructure into the most basic operations.

ugh, "having a working current" is "so much infrastructure" ?? Lockdep 
uses a very low amount of infrastructure, considering its complexity: it 
has its own allocator, uses raw spinlocks, raw irq flags ops, it 
basically implements its own infrastructure for everything. Being able 
to access a per-task data area (current) is a quite fundamental thing 
for kernel code.

the i686 PDA patches introduce tons of early_current() uses. While i 
like the new PDA code, its bootstrap (like x86_64's PDA bootstrap) is 
too fragile in my opinion, and it will regularly hit instrumenting 
patches.

Perhaps the early setup code (if we really want to do it all in C) 
should be moved into 32-bit early boot userspace code (like 
compressed/misc.c) and it will thus not depend on any kernel 
infrastructure.

	Ingo

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: 2.6.18-rc6-mm1: GPF loop on early boot
  2006-09-10 13:26         ` Ingo Molnar
@ 2006-09-10 13:55           ` Andi Kleen
  2006-09-10 14:02             ` Ingo Molnar
  2006-09-10 16:33           ` Andrew Morton
  1 sibling, 1 reply; 114+ messages in thread
From: Andi Kleen @ 2006-09-10 13:55 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Laurent Riffard, Arjan van de Ven, Andrew Morton,
	Kernel development list, Jeremy Fitzhardinge

On Sunday 10 September 2006 15:26, Ingo Molnar wrote:
> * Andi Kleen <ak@suse.de> wrote:
> > > Basically, non-atomic setup of basic architecture state _is_ going to
> > > be a nightmare, lockdep or not, especially if it uses common
> > > infrastructure like 'current', spin_lock() or even something as simple
> > > as C functions. (for example the stack-footprint tracer was once hit by
> > > this weakness of the x86_64 code)
> >
> > I disagree with that.  The nightmare is putting stuff that needs so
> > much infrastructure into the most basic operations.
>
> ugh, "having a working current" is "so much infrastructure" ??

Together with stacktrace the infrastructure needed is quite
considerable.

>
> the i686 PDA patches introduce tons of early_current() uses. While i
> like the new PDA code, its bootstrap (like x86_64's PDA bootstrap) is
> too fragile in my opinion, and it will regularly hit instrumenting
> patches.

Or the instrumentation patches just always need to check
some global variable. Maybe system_state could be extended or something.

>
> Perhaps the early setup code (if we really want to do it all in C)

Sorry but moving it into assembler would be just crazy.

> should be moved into 32-bit early boot userspace code (like
> compressed/misc.c) and it will thus not depend on any kernel
> infrastructure.

Ok I guess it would make sense to add a i386_start_kernel to i386 and
initialize the boot PDA there. I would also move early_cpu_init
into there because that also avoids quite some mess later.

-Andi

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: 2.6.18-rc6-mm1: GPF loop on early boot
  2006-09-10 13:55           ` Andi Kleen
@ 2006-09-10 14:02             ` Ingo Molnar
  0 siblings, 0 replies; 114+ messages in thread
From: Ingo Molnar @ 2006-09-10 14:02 UTC (permalink / raw)
  To: Andi Kleen
  Cc: Laurent Riffard, Arjan van de Ven, Andrew Morton,
	Kernel development list, Jeremy Fitzhardinge


* Andi Kleen <ak@suse.de> wrote:

> > ugh, "having a working current" is "so much infrastructure" ??
> 
> Together with stacktrace the infrastructure needed is quite 
> considerable.

Having the ability to produce a backtrace _anywhere within the kernel_ 
is a pretty fundamental thing too. So IMO the problems with stacktrace 
were the stack dumping code's weaknesses, independent of lockdep, and 
they would have triggered in one way or another as well. Not that i 
think that doing a dwarf unwinder is simple - and you certainly did a 
great job with it. Now with stacktrace we do have a pretty powerful 
infrastructure to do transparent execution tracing: for example the 
page-tracing code could be changed to use stacktrace.

> > the i686 PDA patches introduce tons of early_current() uses. While i
> > like the new PDA code, its bootstrap (like x86_64's PDA bootstrap) is
> > too fragile in my opinion, and it will regularly hit instrumenting
> > patches.
> 
> Or the instrumentation patches just always need to check some global 
> variable. Maybe system_state could be extended or something.

maybe, but i find that unrobust too. Example: i debugged many 
early-bootup hangs via the use of an early_printk() based function 
execution tracer (a feature of the latency tracing patchset) - the lack 
of working 'current' would hit that code too.

Yes, it can all be worked around, but the fundamental weakness IMO is 
that we dont have a working 'current' in all situations.

> > should be moved into 32-bit early boot userspace code (like
> > compressed/misc.c) and it will thus not depend on any kernel
> > infrastructure.
> 
> Ok I guess it would make sense to add a i386_start_kernel to i386 and 
> initialize the boot PDA there. I would also move early_cpu_init into 
> there because that also avoids quite some mess later.

yes. And move all of this _outside_ the normal kernel build process, so 
that whatever ad-hoc or less ad-hoc instrumentation is added (be that 
PROFILE_UNLIKELY, function tracing, 'get_current' based hacks, irqtrace, 
lockdep or whatever) it wont be included in that code. That gets rid of
most of the dependency and bootstrap problems. It's hard enough already
to debug early boot code.

	Ingo

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: 2.6.18-rc6-mm1: GPF loop on early boot
  2006-09-10 13:26         ` Ingo Molnar
  2006-09-10 13:55           ` Andi Kleen
@ 2006-09-10 16:33           ` Andrew Morton
  2006-09-10 23:03             ` Jeremy Fitzhardinge
  1 sibling, 1 reply; 114+ messages in thread
From: Andrew Morton @ 2006-09-10 16:33 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Andi Kleen, Laurent Riffard, Arjan van de Ven,
	Kernel development list, Jeremy Fitzhardinge

On Sun, 10 Sep 2006 15:26:14 +0200
Ingo Molnar <mingo@elte.hu> wrote:

> * Andi Kleen <ak@suse.de> wrote:
> 
> > > Basically, non-atomic setup of basic architecture state _is_ going to be
> > > a nightmare, lockdep or not, especially if it uses common infrastructure
> > > like 'current', spin_lock() or even something as simple as C functions.
> > > (for example the stack-footprint tracer was once hit by this weakness of
> > > the x86_64 code)
> > 
> > I disagree with that.  The nightmare is putting stuff that needs so 
> > much infrastructure into the most basic operations.
> 
> ugh, "having a working current" is "so much infrastructure" ?? Lockdep 
> uses a very low amount of infrastructure, considering its complexity: it 
> has its own allocator, uses raw spinlocks, raw irq flags ops, it 
> basically implements its own infrastructure for everything. Being able 
> to access a per-task data area (current) is a quite fundamental thing 
> for kernel code.

I must say that having an unreliable early-current is going to be quite a
pita for evermore.  Things like mcount-based tricks and
basic-block-profiling-based tricks, for example.

Is it really going to be too messy to fake up some statically-defined gdt
which points at init_task, install that before we call any C at all?

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: 2.6.18-rc6-mm1: GPF loop on early boot
  2006-09-10 16:33           ` Andrew Morton
@ 2006-09-10 23:03             ` Jeremy Fitzhardinge
  2006-09-11  5:10               ` Ingo Molnar
                                 ` (2 more replies)
  0 siblings, 3 replies; 114+ messages in thread
From: Jeremy Fitzhardinge @ 2006-09-10 23:03 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Ingo Molnar, Andi Kleen, Laurent Riffard, Arjan van de Ven,
	Kernel development list, Jeremy Fitzhardinge

Andrew Morton wrote:
> I must say that having an unreliable early-current is going to be quite a
> pita for evermore.  Things like mcount-based tricks and
> basic-block-profiling-based tricks, for example.
>
> Is it really going to be too messy to fake up some statically-defined gdt
> which points at init_task, install that before we call any C at all?

That's on my TODO list - make %gs set correctly before hitting C code, 
and get rid of all the early_* stuff.  I had already encountered a 
PDA-related oops with lockdep enabled, and addressed it.

It's pretty easy to solve in general for the boot CPU, but its a bit 
more tricky to handle for secondary CPUs.

Laurent, could you resend your original oops?  It doesn't seem to have 
appeared on lkml.

In the meantime, I'll work on a proper fix for this.

    J

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: 2.6.18-rc6-mm1: GPF loop on early boot
  2006-09-10 23:03             ` Jeremy Fitzhardinge
@ 2006-09-11  5:10               ` Ingo Molnar
  2006-09-11  7:31                 ` Jeremy Fitzhardinge
  2006-09-11  5:21               ` Laurent Riffard
  2006-09-11  5:25               ` [patch] i386-PDA, lockdep: fix %gs restore Ingo Molnar
  2 siblings, 1 reply; 114+ messages in thread
From: Ingo Molnar @ 2006-09-11  5:10 UTC (permalink / raw)
  To: Jeremy Fitzhardinge
  Cc: Andrew Morton, Andi Kleen, Laurent Riffard, Arjan van de Ven,
	Kernel development list, Jeremy Fitzhardinge

Jeremy,

another thing about i386-pda: why did you pick the %gs selector to store 
the PDA in? %fs would be a better choice because %gs is used by glibc so 
the saving/restoring of %fs would likely be near zero-cycles cost. 
(instead of the current 9 cycles for saving/restoring %gs)

	Ingo

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: 2.6.18-rc6-mm1: GPF loop on early boot
  2006-09-11  5:21               ` Laurent Riffard
@ 2006-09-11  5:18                 ` Ingo Molnar
  0 siblings, 0 replies; 114+ messages in thread
From: Ingo Molnar @ 2006-09-11  5:18 UTC (permalink / raw)
  To: Laurent Riffard
  Cc: Jeremy Fitzhardinge, Andrew Morton, Andi Kleen, Arjan van de Ven,
	Kernel development list, Jeremy Fitzhardinge


btw., i dont think it's the early-bootup behavior of lockdep that causes 
your oops. I think %gs somehow ended up being invalid upon pagefault 
entry, well after bootup. Not sure why. Andi's patch just papers over 
this i believe.

ah ... found it meanwhile: in the syscall exit path the PDA patches 
restore the userspace %gs too early, trace_hardirqs_on() is called 
_after_ the restoring of %gs. Will send a patch in a few minutes.

	Ingo

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: 2.6.18-rc6-mm1: GPF loop on early boot
  2006-09-10 23:03             ` Jeremy Fitzhardinge
  2006-09-11  5:10               ` Ingo Molnar
@ 2006-09-11  5:21               ` Laurent Riffard
  2006-09-11  5:18                 ` Ingo Molnar
  2006-09-11  5:25               ` [patch] i386-PDA, lockdep: fix %gs restore Ingo Molnar
  2 siblings, 1 reply; 114+ messages in thread
From: Laurent Riffard @ 2006-09-11  5:21 UTC (permalink / raw)
  To: Jeremy Fitzhardinge
  Cc: Andrew Morton, Ingo Molnar, Andi Kleen, Arjan van de Ven,
	Kernel development list, Jeremy Fitzhardinge


Le 11.09.2006 01:03, Jeremy Fitzhardinge a écrit :
> Andrew Morton wrote:
>> I must say that having an unreliable early-current is going to be quite a
>> pita for evermore.  Things like mcount-based tricks and
>> basic-block-profiling-based tricks, for example.
>>
>> Is it really going to be too messy to fake up some statically-defined gdt
>> which points at init_task, install that before we call any C at all?
> 
> That's on my TODO list - make %gs set correctly before hitting C code, 
> and get rid of all the early_* stuff.  I had already encountered a 
> PDA-related oops with lockdep enabled, and addressed it.
> 
> It's pretty easy to solve in general for the boot CPU, but its a bit 
> more tricky to handle for secondary CPUs.
> 
> Laurent, could you resend your original oops?  It doesn't seem to have 
> appeared on lkml.

I guess my original mail was too big. Sorry for that. 
Please go to http://laurent.riffard.free.fr/2.6.18-rc6-mm1/, 
you'll find the files I sent in my first post:

* DSC02674.jpg (96k): screenshot of first GPF  
* config-2.6.18-rc6-mm1 (48k)
* dmesg-2.6.18-rc6-mm1 (25k)
 
> In the meantime, I'll work on a proper fix for this.
> 
>    J

-- 
laurent

^ permalink raw reply	[flat|nested] 114+ messages in thread

* [patch] i386-PDA, lockdep: fix %gs restore
  2006-09-10 23:03             ` Jeremy Fitzhardinge
  2006-09-11  5:10               ` Ingo Molnar
  2006-09-11  5:21               ` Laurent Riffard
@ 2006-09-11  5:25               ` Ingo Molnar
  2006-09-11  5:41                 ` Andi Kleen
                                   ` (4 more replies)
  2 siblings, 5 replies; 114+ messages in thread
From: Ingo Molnar @ 2006-09-11  5:25 UTC (permalink / raw)
  To: Jeremy Fitzhardinge
  Cc: Andrew Morton, Andi Kleen, Laurent Riffard, Arjan van de Ven,
	Kernel development list, Jeremy Fitzhardinge


Jeremy,

could you back out Andi's patch and try the patch below, does it fix the 
crash too?

	Ingo

--------------->
Subject: [patch] i386-PDA, lockdep: fix %gs restore
From: Ingo Molnar <mingo@elte.hu>

in the syscall exit path the %gs selector has to be restored _after_ the
last kernel function has been called. If lockdep is enabled then this
kernel function is TRACE_IRQS_ON.

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

---
 arch/i386/kernel/entry.S |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

Index: linux/arch/i386/kernel/entry.S
===================================================================
--- linux.orig/arch/i386/kernel/entry.S
+++ linux/arch/i386/kernel/entry.S
@@ -326,11 +326,12 @@ sysenter_past_esp:
 	testw $_TIF_ALLWORK_MASK, %cx
 	jne syscall_exit_work
 /* if something modifies registers it must also disable sysexit */
-1:	mov  PT_GS(%esp), %gs
+1:
+	TRACE_IRQS_ON
+	mov  PT_GS(%esp), %gs
 	movl PT_EIP(%esp), %edx
 	movl PT_OLDESP(%esp), %ecx
 	xorl %ebp,%ebp
-	TRACE_IRQS_ON
 	ENABLE_INTERRUPTS_SYSEXIT
 	CFI_ENDPROC
 .pushsection .fixup,"ax";	\

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: [patch] i386-PDA, lockdep: fix %gs restore
  2006-09-11  5:25               ` [patch] i386-PDA, lockdep: fix %gs restore Ingo Molnar
@ 2006-09-11  5:41                 ` Andi Kleen
  2006-09-11  5:48                   ` Ingo Molnar
  2006-09-11  5:46                 ` Ingo Molnar
                                   ` (3 subsequent siblings)
  4 siblings, 1 reply; 114+ messages in thread
From: Andi Kleen @ 2006-09-11  5:41 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Jeremy Fitzhardinge, Andrew Morton, Laurent Riffard,
	Arjan van de Ven, Kernel development list, Jeremy Fitzhardinge

On Monday 11 September 2006 07:25, Ingo Molnar wrote:
> Jeremy,
>
> could you back out Andi's patch and try the patch below, does it fix the
> crash too?

iirc the crash was long before any system calls could be called
(except maybe kernel_thread/clone, but for that %gs doesn't change)

-Andi

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: lockdep warning in check_flags()
  2006-09-09  8:35 ` lockdep warning in check_flags() Frederik Deweerdt
@ 2006-09-11  5:43   ` Ingo Molnar
  2006-09-12 14:13     ` Frederik Deweerdt
  0 siblings, 1 reply; 114+ messages in thread
From: Ingo Molnar @ 2006-09-11  5:43 UTC (permalink / raw)
  To: Frederik Deweerdt; +Cc: Andrew Morton, linux-kernel, arjanv


* Frederik Deweerdt <deweerdt@free.fr> wrote:

> Lockdep issues the following warning:
> 
> [   16.835268] Freeing unused kernel memory: 260k freed
> [   16.842715] Write protecting the kernel read-only data: 432k
> [   17.796518] BUG: warning at kernel/lockdep.c:2359/check_flags()

this warning means that the "soft" and "hard" hardirqs-disabled state 
got out of sync: the irqtrace tracking code thinks that hardirqs are 
disabled, while in reality they are enabled. The thing to watch for are 
new "stii" instructions in entry.S (and other assembly code), without a 
matching TRACE_HARDIRQS_ON call. [Another, rarer possiblity is NMI code 
saving/restoring interrupts - do you have NMIs enabled? (are there any 
NMI counts in /proc/interrupts?)]

lockdep automatically generates a minimal trace of hardirqs-off 
state-setting:

> [   17.885839] irq event stamp: 8318
> [   17.892746] hardirqs last  enabled at (8317): [<c01032c8>] restore_nocheck+0x12/0x15
> [   17.906778] hardirqs last disabled at (8318): [<c0103203>] sysenter_past_esp+0x6c/0x99
> [   17.921481] softirqs last  enabled at (7128): [<c0123cd1>] __do_softirq+0xe9/0xfa
> [   17.936962] softirqs last disabled at (7121): [<c0123d3e>] do_softirq+0x5c/0x60

this means that the last registered 'hardirqs off' event was 
sysenter_past_esp, i.e. the normal sysenter syscall entry code - but 
nothing re-enabled hardirqs - which is weird, given that you ended up in 
sys_brk().

> I've replaced the DEBUG_LOCKS_WARN_ON by a BUG, and it appears that 
> the user space program calling sys_brk is hotplug.

(ok, i'll enhance the debug printout to include the process name and 
PID.)

	Ingo

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: [patch] i386-PDA, lockdep: fix %gs restore
  2006-09-11  5:25               ` [patch] i386-PDA, lockdep: fix %gs restore Ingo Molnar
  2006-09-11  5:41                 ` Andi Kleen
@ 2006-09-11  5:46                 ` Ingo Molnar
  2006-09-11 16:35                   ` Laurent Riffard
  2006-09-11  7:42                 ` Jeremy Fitzhardinge
                                   ` (2 subsequent siblings)
  4 siblings, 1 reply; 114+ messages in thread
From: Ingo Molnar @ 2006-09-11  5:46 UTC (permalink / raw)
  To: Laurent Riffard
  Cc: Andrew Morton, Andi Kleen, Laurent Riffard, Arjan van de Ven,
	Kernel development list, Jeremy Fitzhardinge


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

> Jeremy,

Laurent that is ...

> could you back out Andi's patch and try the patch below, does it fix the 
> crash too?

	Ingo

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: [patch] i386-PDA, lockdep: fix %gs restore
  2006-09-11  5:41                 ` Andi Kleen
@ 2006-09-11  5:48                   ` Ingo Molnar
  0 siblings, 0 replies; 114+ messages in thread
From: Ingo Molnar @ 2006-09-11  5:48 UTC (permalink / raw)
  To: Andi Kleen
  Cc: Jeremy Fitzhardinge, Andrew Morton, Laurent Riffard,
	Arjan van de Ven, Kernel development list, Jeremy Fitzhardinge


* Andi Kleen <ak@suse.de> wrote:

> On Monday 11 September 2006 07:25, Ingo Molnar wrote:
> > Jeremy,
> >
> > could you back out Andi's patch and try the patch below, does it fix the
> > crash too?
> 
> iirc the crash was long before any system calls could be called 
> (except maybe kernel_thread/clone, but for that %gs doesn't change)

the screenshot from Laurent:

   http://laurent.riffard.free.fr/2.6.18-rc6-mm1/

shows a much later crash, which crash is consistent with the bug fixed 
by my patch.

	Ingo

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: 2.6.18-rc6-mm1: GPF loop on early boot
  2006-09-11  7:31                 ` Jeremy Fitzhardinge
@ 2006-09-11  7:29                   ` Ingo Molnar
  2006-09-11  7:41                     ` Jeremy Fitzhardinge
  0 siblings, 1 reply; 114+ messages in thread
From: Ingo Molnar @ 2006-09-11  7:29 UTC (permalink / raw)
  To: Jeremy Fitzhardinge
  Cc: Andrew Morton, Andi Kleen, Laurent Riffard, Arjan van de Ven,
	Kernel development list, Jeremy Fitzhardinge


* Jeremy Fitzhardinge <jeremy@goop.org> wrote:

> Ingo Molnar wrote:
> >another thing about i386-pda: why did you pick the %gs selector to store 
> >the PDA in? %fs would be a better choice because %gs is used by glibc so 
> >the saving/restoring of %fs would likely be near zero-cycles cost. 
> >(instead of the current 9 cycles for saving/restoring %gs)
> 
> Why would saving/restoring %fs be quicker? [...]

because userspace does not use it normally, while with %gs we'd switch 
between glibc's descriptor [which must be shadowed by the CPU] and the 
kernel's descriptor [which must be shadowed by the CPU too] - hence 
causing a constant reloading of the shadow register.

	Ingo

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: 2.6.18-rc6-mm1: GPF loop on early boot
  2006-09-11  5:10               ` Ingo Molnar
@ 2006-09-11  7:31                 ` Jeremy Fitzhardinge
  2006-09-11  7:29                   ` Ingo Molnar
  0 siblings, 1 reply; 114+ messages in thread
From: Jeremy Fitzhardinge @ 2006-09-11  7:31 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Andrew Morton, Andi Kleen, Laurent Riffard, Arjan van de Ven,
	Kernel development list, Jeremy Fitzhardinge

Ingo Molnar wrote:
> another thing about i386-pda: why did you pick the %gs selector to store 
> the PDA in? %fs would be a better choice because %gs is used by glibc so 
> the saving/restoring of %fs would likely be near zero-cycles cost. 
> (instead of the current 9 cycles for saving/restoring %gs)
>   

Why would saving/restoring %fs be quicker?  The main reason I chose %gs 
was so that it didn't add anything to the context switch time (since %gs 
needed to be switched anyway), and it leaves open the possibility of 
using gcc's TLS support in the kernel (I have a working demonstration of 
this, but Rusty and I are still working out the module details).

    J

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: 2.6.18-rc6-mm1: GPF loop on early boot
  2006-09-11  7:41                     ` Jeremy Fitzhardinge
@ 2006-09-11  7:36                       ` Ingo Molnar
  2006-09-11  7:59                         ` Jeremy Fitzhardinge
  2006-09-11  7:38                       ` Ingo Molnar
  1 sibling, 1 reply; 114+ messages in thread
From: Ingo Molnar @ 2006-09-11  7:36 UTC (permalink / raw)
  To: Jeremy Fitzhardinge
  Cc: Andrew Morton, Andi Kleen, Laurent Riffard, Arjan van de Ven,
	Kernel development list, Jeremy Fitzhardinge


* Jeremy Fitzhardinge <jeremy@goop.org> wrote:

> Ingo Molnar wrote:
> >because userspace does not use it normally, while with %gs we'd switch 
> >between glibc's descriptor [which must be shadowed by the CPU] and the 
> >kernel's descriptor [which must be shadowed by the CPU too] - hence 
> >causing a constant reloading of the shadow register.
> >  
> 
> Well, that means the only operation which would be different would be 
> the pop %fs at the end, since only it would end up loading a null 
> selector.  All the other operations would presumably take just as 
> long.

yes - but loading a null selector is a special-case: you dont have to 
invalidate/reload the shadow, you just have to turn access off. This 
might or might not make a difference on modern CPUs (it makes a 
difference with older CPUs) - but it's worth a try nevertheless. You 
measured a 9 cycles degradation with the %gs method, we could recover 
some of that.

	Ingo

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: 2.6.18-rc6-mm1: GPF loop on early boot
  2006-09-11  7:41                     ` Jeremy Fitzhardinge
  2006-09-11  7:36                       ` Ingo Molnar
@ 2006-09-11  7:38                       ` Ingo Molnar
  2006-09-11  7:56                         ` Jeremy Fitzhardinge
  1 sibling, 1 reply; 114+ messages in thread
From: Ingo Molnar @ 2006-09-11  7:38 UTC (permalink / raw)
  To: Jeremy Fitzhardinge
  Cc: Andrew Morton, Andi Kleen, Laurent Riffard, Arjan van de Ven,
	Kernel development list, Jeremy Fitzhardinge


btw., what's the connection of %gs based PDA to Xen and 
paravirtualization in general - %esp based current is just as 
Xen-friendly, or am i wrong? I guess there must be some connection, 
given that you are working on this ;)

	Ingo

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: 2.6.18-rc6-mm1: GPF loop on early boot
  2006-09-11  7:29                   ` Ingo Molnar
@ 2006-09-11  7:41                     ` Jeremy Fitzhardinge
  2006-09-11  7:36                       ` Ingo Molnar
  2006-09-11  7:38                       ` Ingo Molnar
  0 siblings, 2 replies; 114+ messages in thread
From: Jeremy Fitzhardinge @ 2006-09-11  7:41 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Andrew Morton, Andi Kleen, Laurent Riffard, Arjan van de Ven,
	Kernel development list, Jeremy Fitzhardinge

Ingo Molnar wrote:
> because userspace does not use it normally, while with %gs we'd switch 
> between glibc's descriptor [which must be shadowed by the CPU] and the 
> kernel's descriptor [which must be shadowed by the CPU too] - hence 
> causing a constant reloading of the shadow register.
>   

Well, that means the only operation which would be different would be 
the pop %fs at the end, since only it would end up loading a null 
selector.  All the other operations would presumably take just as long.

    J

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: [patch] i386-PDA, lockdep: fix %gs restore
  2006-09-11  5:25               ` [patch] i386-PDA, lockdep: fix %gs restore Ingo Molnar
  2006-09-11  5:41                 ` Andi Kleen
  2006-09-11  5:46                 ` Ingo Molnar
@ 2006-09-11  7:42                 ` Jeremy Fitzhardinge
  2006-09-11 19:33                 ` Jeremy Fitzhardinge
  2006-09-11 20:20                 ` Andi Kleen
  4 siblings, 0 replies; 114+ messages in thread
From: Jeremy Fitzhardinge @ 2006-09-11  7:42 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Andrew Morton, Andi Kleen, Laurent Riffard, Arjan van de Ven,
	Kernel development list, Jeremy Fitzhardinge

Ingo Molnar wrote:
> could you back out Andi's patch and try the patch below, does it fix the 
> crash too?
>   
Looks sensible.

    J

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: 2.6.18-rc6-mm1: GPF loop on early boot
  2006-09-11  7:56                         ` Jeremy Fitzhardinge
@ 2006-09-11  7:55                           ` Ingo Molnar
  0 siblings, 0 replies; 114+ messages in thread
From: Ingo Molnar @ 2006-09-11  7:55 UTC (permalink / raw)
  To: Jeremy Fitzhardinge
  Cc: Andrew Morton, Andi Kleen, Laurent Riffard, Arjan van de Ven,
	Kernel development list, Jeremy Fitzhardinge


* Jeremy Fitzhardinge <jeremy@goop.org> wrote:

> Ingo Molnar wrote:
> >btw., what's the connection of %gs based PDA to Xen and 
> >paravirtualization in general - %esp based current is just as 
> >Xen-friendly, or am i wrong? I guess there must be some connection, 
> >given that you are working on this ;)
> >  
> 
> Yep.  The goal is to put the Xen VCPU structure into the PDA, so that it 
> can be easily accessed.  At present, masking events (ie, cli), is 
> something along the lines of
> 
>    xen_shared_info->vcpu[smp_processor_id()].mask = 1
> 
> which comes out to something like 20 bytes of code, and is probably too 
> awkward to inline.  If the vcpu is in the PDA, it would come out to:
> 
>    movb $1, %gs:xen_vcpu_mask
> 
> which has the added benefit of not needing a register.

take a look at lockdep: amongst other things it adds the TRACE_IRQFLAGS 
/ irqflags.h infrastructure, which could easily be modified to allow the 
easy replacement of cli/sti/pushf/popf. I wrote it with the side-goal of 
paravirtualization. I.e. instead of the DISABLE_INTERRUPT / 
ENABLE_INTERRUPT duplication you do in -mm currently please just enhance 
irqflags.h to cover the needs of paravirtualization too. (most of which 
should be the moving of cli/sti into the assembly callbacks)

into that the PDA would plug in a natural way: current->hardirqs_enabled 
is basically just an alias for 
!xen_shared_info->vcpu[smp_processor_id()].mask.

	Ingo

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: 2.6.18-rc6-mm1: GPF loop on early boot
  2006-09-11  7:38                       ` Ingo Molnar
@ 2006-09-11  7:56                         ` Jeremy Fitzhardinge
  2006-09-11  7:55                           ` Ingo Molnar
  0 siblings, 1 reply; 114+ messages in thread
From: Jeremy Fitzhardinge @ 2006-09-11  7:56 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Andrew Morton, Andi Kleen, Laurent Riffard, Arjan van de Ven,
	Kernel development list, Jeremy Fitzhardinge

Ingo Molnar wrote:
> btw., what's the connection of %gs based PDA to Xen and 
> paravirtualization in general - %esp based current is just as 
> Xen-friendly, or am i wrong? I guess there must be some connection, 
> given that you are working on this ;)
>   

Yep.  The goal is to put the Xen VCPU structure into the PDA, so that it 
can be easily accessed.  At present, masking events (ie, cli), is 
something along the lines of

    xen_shared_info->vcpu[smp_processor_id()].mask = 1

which comes out to something like 20 bytes of code, and is probably too 
awkward to inline.  If the vcpu is in the PDA, it would come out to:

    movb $1, %gs:xen_vcpu_mask

which has the added benefit of not needing a register.

Even without modifying Xen to allow us to place the VCPU structure, 
putting a VCPU pointer into the PDA helps a lot:

    mov %gs:xen_vcpu, %eax
    movb $1, mask(%eax)

    J

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: 2.6.18-rc6-mm1: GPF loop on early boot
  2006-09-11  7:36                       ` Ingo Molnar
@ 2006-09-11  7:59                         ` Jeremy Fitzhardinge
  2006-09-11  8:01                           ` Ingo Molnar
  0 siblings, 1 reply; 114+ messages in thread
From: Jeremy Fitzhardinge @ 2006-09-11  7:59 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Andrew Morton, Andi Kleen, Laurent Riffard, Arjan van de Ven,
	Kernel development list, Jeremy Fitzhardinge

Ingo Molnar wrote:
> yes - but loading a null selector is a special-case: you dont have to 
> invalidate/reload the shadow, you just have to turn access off. This 
> might or might not make a difference on modern CPUs (it makes a 
> difference with older CPUs) - but it's worth a try nevertheless. You 
> measured a 9 cycles degradation with the %gs method, we could recover 
> some of that.
>   

It's a worthwhile experiment.  The gain would be the NULL selector load, 
but the loss would be an additional segment reload on context switch and 
TLS ABI incompatibility (which is more difficult to quantify).

First step is to make sure the PDA is set up before hitting C code...

    J

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: 2.6.18-rc6-mm1: GPF loop on early boot
  2006-09-11  7:59                         ` Jeremy Fitzhardinge
@ 2006-09-11  8:01                           ` Ingo Molnar
  2006-09-11  8:13                             ` Jeremy Fitzhardinge
  0 siblings, 1 reply; 114+ messages in thread
From: Ingo Molnar @ 2006-09-11  8:01 UTC (permalink / raw)
  To: Jeremy Fitzhardinge
  Cc: Andrew Morton, Andi Kleen, Laurent Riffard, Arjan van de Ven,
	Kernel development list, Jeremy Fitzhardinge


* Jeremy Fitzhardinge <jeremy@goop.org> wrote:

> Ingo Molnar wrote:
> >yes - but loading a null selector is a special-case: you dont have to 
> >invalidate/reload the shadow, you just have to turn access off. This 
> >might or might not make a difference on modern CPUs (it makes a 
> >difference with older CPUs) - but it's worth a try nevertheless. You 
> >measured a 9 cycles degradation with the %gs method, we could recover 
> >some of that.
> >  
> 
> It's a worthwhile experiment.  The gain would be the NULL selector 
> load, but the loss would be an additional segment reload on context 
> switch and TLS ABI incompatibility (which is more difficult to 
> quantify).

the ratio between the number of syscalls vs. the number of context 
switches is 1-2 orders of magnitude. So a loss of 9 cycles in the 
syscall path is roughly equal to a loss of 90-900 cycles in switch_to() 
costs ...

the TLS ABI is just a gcc stupidity. Why did they pick the _second_ 
extra selector, instead of the first one ...? Anyway, perhaps this could 
be solved by extending gcc with a switch to also generate __thread code 
off %fs. Probably not worth the pain though ...

	Ingo

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: 2.6.18-rc6-mm1: GPF loop on early boot
  2006-09-11  8:01                           ` Ingo Molnar
@ 2006-09-11  8:13                             ` Jeremy Fitzhardinge
  0 siblings, 0 replies; 114+ messages in thread
From: Jeremy Fitzhardinge @ 2006-09-11  8:13 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Andrew Morton, Andi Kleen, Laurent Riffard, Arjan van de Ven,
	Kernel development list, Jeremy Fitzhardinge

Ingo Molnar wrote:
> the ratio between the number of syscalls vs. the number of context 
> switches is 1-2 orders of magnitude. So a loss of 9 cycles in the 
> syscall path is roughly equal to a loss of 90-900 cycles in switch_to() 
> costs ...
>   

I agree.

> the TLS ABI is just a gcc stupidity. Why did they pick the _second_ 
> extra selector, instead of the first one ...?

Well, it doesn't matter which they chose if its the same for user and 
kernel space. Why does x86-64 have swapgs rather than swapfs?

>  Anyway, perhaps this could 
> be solved by extending gcc with a switch to also generate __thread code 
> off %fs. Probably not worth the pain though ...

If there's gcc hacking to be done, it would be trying to get it make the 
TLS offsets from the PDA/TCB positive rather than negative...

    J

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: 2.6.18-rc6-mm1 - x86_64-mm-lockdep-dont-force-framepointer.patch
  2006-09-09 13:39   ` Andi Kleen
@ 2006-09-11  8:45     ` Martin Schwidefsky
  0 siblings, 0 replies; 114+ messages in thread
From: Martin Schwidefsky @ 2006-09-11  8:45 UTC (permalink / raw)
  To: Andi Kleen; +Cc: Heiko Carstens, Andrew Morton, linux-kernel

On Sat, 2006-09-09 at 15:39 +0200, Andi Kleen wrote:
> > This patch affects all architecture. I'd like to keep the "select
> > FRAME_POINTER" for s390, since we don't support dwarf2.
> 
> Perhaps you should port the unwinder then?  I know you use it 
> in userland.

I have thought about porting the porting the unwinder but it is quite
some effort. Especially the CFI unwind annotations in entry.S are hairy.

> > So this patch should be dropped.
> 
> I changed it now to add a if !X86 so it should be ok now

Thanks.

-- 
blue skies,
  Martin.

Martin Schwidefsky
Linux for zSeries Development & Services
IBM Deutschland Entwicklung GmbH

"Reality continues to ruin my life." - Calvin.



^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: [patch] i386-PDA, lockdep: fix %gs restore
  2006-09-11  5:46                 ` Ingo Molnar
@ 2006-09-11 16:35                   ` Laurent Riffard
  0 siblings, 0 replies; 114+ messages in thread
From: Laurent Riffard @ 2006-09-11 16:35 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Andrew Morton, Andi Kleen, Arjan van de Ven,
	Kernel development list, Jeremy Fitzhardinge


Le 11.09.2006 07:46, Ingo Molnar a écrit :
> * Ingo Molnar <mingo@elte.hu> wrote:
> 
>> Jeremy,
> 
> Laurent that is ...
> 
>> could you back out Andi's patch and try the patch below, does it fix the 
>> crash too?

Sorry for the late answer, I had to go to work ;-).

So 2.6.18-rc6-mm1 + hotfixes + Ingo's "i386-PDA, lockdep: fix %gs restore" 
does work well.

Thanks
-- 
laurent

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: [patch] i386-PDA, lockdep: fix %gs restore
  2006-09-11  5:25               ` [patch] i386-PDA, lockdep: fix %gs restore Ingo Molnar
                                   ` (2 preceding siblings ...)
  2006-09-11  7:42                 ` Jeremy Fitzhardinge
@ 2006-09-11 19:33                 ` Jeremy Fitzhardinge
  2006-09-11 21:25                   ` Jeremy Fitzhardinge
  2006-09-11 20:20                 ` Andi Kleen
  4 siblings, 1 reply; 114+ messages in thread
From: Jeremy Fitzhardinge @ 2006-09-11 19:33 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Andrew Morton, Andi Kleen, Laurent Riffard, Arjan van de Ven,
	Kernel development list, Jeremy Fitzhardinge

Ingo Molnar wrote:
> Subject: [patch] i386-PDA, lockdep: fix %gs restore
> From: Ingo Molnar <mingo@elte.hu>
>
> in the syscall exit path the %gs selector has to be restored _after_ the
> last kernel function has been called. If lockdep is enabled then this
> kernel function is TRACE_IRQS_ON.
>
> Signed-off-by: Ingo Molnar <mingo@elte.hu>
>   
Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com>

    J

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: [patch] i386-PDA, lockdep: fix %gs restore
  2006-09-11  5:25               ` [patch] i386-PDA, lockdep: fix %gs restore Ingo Molnar
                                   ` (3 preceding siblings ...)
  2006-09-11 19:33                 ` Jeremy Fitzhardinge
@ 2006-09-11 20:20                 ` Andi Kleen
  2006-09-11 21:37                   ` Jeremy Fitzhardinge
  4 siblings, 1 reply; 114+ messages in thread
From: Andi Kleen @ 2006-09-11 20:20 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Jeremy Fitzhardinge, Andrew Morton, Laurent Riffard,
	Arjan van de Ven, Kernel development list, Jeremy Fitzhardinge

On Monday 11 September 2006 07:25, Ingo Molnar wrote:
> Jeremy,
>
> could you back out Andi's patch and try the patch below, does it fix the
> crash too?

I folded it into the original patch now thanks

-Andi

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: [patch] i386-PDA, lockdep: fix %gs restore
  2006-09-11 21:37                   ` Jeremy Fitzhardinge
@ 2006-09-11 20:48                     ` Andi Kleen
  0 siblings, 0 replies; 114+ messages in thread
From: Andi Kleen @ 2006-09-11 20:48 UTC (permalink / raw)
  To: Jeremy Fitzhardinge
  Cc: Ingo Molnar, Andrew Morton, Laurent Riffard, Arjan van de Ven,
	Kernel development list, Jeremy Fitzhardinge

On Monday 11 September 2006 23:37, Jeremy Fitzhardinge wrote:
> Andi Kleen wrote:
> > On Monday 11 September 2006 07:25, Ingo Molnar wrote:
> >> Jeremy,
> >>
> >> could you back out Andi's patch and try the patch below, does it fix the
> >> crash too?
> >
> > I folded it into the original patch now thanks
>
> Ingo's patch was wrong.  Here's an update:

Fixed too thanks

-Andi

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: 2.6.18-rc6-mm1
  2006-09-08  8:13 2.6.18-rc6-mm1 Andrew Morton
                   ` (9 preceding siblings ...)
       [not found] ` <4503DC64.9070007@free.fr>
@ 2006-09-11 21:19 ` Mark Haverkamp
  2006-09-11 22:16   ` 2.6.18-rc6-mm1 Andrew Morton
  10 siblings, 1 reply; 114+ messages in thread
From: Mark Haverkamp @ 2006-09-11 21:19 UTC (permalink / raw)
  To: Andrew Morton, Trond Myklebust; +Cc: linux-kernel

On Fri, 2006-09-08 at 01:13 -0700, Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc6/2.6.18-rc6-mm1/
> 

compiling a kernel with allnoconfig produces the following error:

  CHK     include/linux/version.h
  CHK     include/linux/utsrelease.h
  CHK     include/linux/compile.h
  GEN     .version
  CHK     include/linux/compile.h
  UPD     include/linux/compile.h
  CC      init/version.o
  LD      init/built-in.o
  LD      .tmp_vmlinux1
mm/built-in.o: In function `writeback_congestion_end':
(.text+0x5d3b): undefined reference to `blk_congestion_end'
make: *** [.tmp_vmlinux1] Error 1

The problem is that the block layer isn't configured and this is where
the blk_congestion_end symbol comes from.

This comes from the git-nfs.patch.


-- 
Mark Haverkamp <markh@osdl.org>


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: [patch] i386-PDA, lockdep: fix %gs restore
  2006-09-11 19:33                 ` Jeremy Fitzhardinge
@ 2006-09-11 21:25                   ` Jeremy Fitzhardinge
  0 siblings, 0 replies; 114+ messages in thread
From: Jeremy Fitzhardinge @ 2006-09-11 21:25 UTC (permalink / raw)
  To: Jeremy Fitzhardinge
  Cc: Ingo Molnar, Andrew Morton, Andi Kleen, Laurent Riffard,
	Arjan van de Ven, Kernel development list, Jeremy Fitzhardinge

Jeremy Fitzhardinge wrote:
> Ingo Molnar wrote:
>> Subject: [patch] i386-PDA, lockdep: fix %gs restore
>> From: Ingo Molnar <mingo@elte.hu>
>>
>> in the syscall exit path the %gs selector has to be restored _after_ the
>> last kernel function has been called. If lockdep is enabled then this
>> kernel function is TRACE_IRQS_ON.
>>
>> Signed-off-by: Ingo Molnar <mingo@elte.hu>
>>   
> Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com>

Actually, this patch is wrong.  I'll post a fix shortly.

    J

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: [patch] i386-PDA, lockdep: fix %gs restore
  2006-09-11 20:20                 ` Andi Kleen
@ 2006-09-11 21:37                   ` Jeremy Fitzhardinge
  2006-09-11 20:48                     ` Andi Kleen
  0 siblings, 1 reply; 114+ messages in thread
From: Jeremy Fitzhardinge @ 2006-09-11 21:37 UTC (permalink / raw)
  To: Andi Kleen
  Cc: Ingo Molnar, Andrew Morton, Laurent Riffard, Arjan van de Ven,
	Kernel development list, Jeremy Fitzhardinge

Andi Kleen wrote:
> On Monday 11 September 2006 07:25, Ingo Molnar wrote:
>   
>> Jeremy,
>>
>> could you back out Andi's patch and try the patch below, does it fix the
>> crash too?
>>     
>
> I folded it into the original patch now thanks
>   

Ingo's patch was wrong.  Here's an update:

Subject: [patch] i386-PDA, lockdep: fix %gs restore
From: Ingo Molnar <mingo@elte.hu>

in the syscall exit path the %gs selector has to be restored _after_ the
last kernel function has been called. If lockdep is enabled then this
kernel function is TRACE_IRQS_ON.

[ Make sure the move to %gs retains its exception label - jeremy@xensource.com ]

Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com>

---
 arch/i386/kernel/entry.S |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff -r cead1b87fd17 arch/i386/kernel/entry.S
--- a/arch/i386/kernel/entry.S	Sun Sep 10 16:28:43 2006 -0700
+++ b/arch/i386/kernel/entry.S	Mon Sep 11 14:22:36 2006 -0700
@@ -326,11 +326,11 @@ 1:	movl (%ebp),%ebp
 	testw $_TIF_ALLWORK_MASK, %cx
 	jne syscall_exit_work
 /* if something modifies registers it must also disable sysexit */
-1:	mov  PT_GS(%esp), %gs
 	movl PT_EIP(%esp), %edx
 	movl PT_OLDESP(%esp), %ecx
+	TRACE_IRQS_ON
+1:	mov  PT_GS(%esp), %gs
 	xorl %ebp,%ebp
-	TRACE_IRQS_ON
 	ENABLE_INTERRUPTS_SYSEXIT
 	CFI_ENDPROC
 .pushsection .fixup,"ax";	\



^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: [linux-usb-devel] 2.6.18-rc6-mm1
  2006-09-08 22:57     ` Rafael J. Wysocki
@ 2006-09-11 22:08       ` Rafael J. Wysocki
  2006-09-12 14:28         ` Alan Stern
  2006-09-13 12:07       ` [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem Rafael J. Wysocki
  1 sibling, 1 reply; 114+ messages in thread
From: Rafael J. Wysocki @ 2006-09-11 22:08 UTC (permalink / raw)
  To: Alan Stern; +Cc: Andrew Morton, linux-kernel, USB development list

On Saturday, 9 September 2006 00:57, Rafael J. Wysocki wrote:
> On Friday, 8 September 2006 22:44, Alan Stern wrote:
> > On Fri, 8 Sep 2006, Andrew Morton wrote:
> > 
> > > Alan, is this likely to be due to your USB PM changes?
> > 
> > It's possible.  Most of those changes are innocuous.  They add routines
> > that don't get used until a later patch.  However one of them might be
> > responsible.
> 
> Well, after recompiling the kernel for several times (because of a different
> problem) I'm no longer able to reproduce the problem.

Now I have another symtom: during the _second_ suspend the suspending of
USB controllers fails with messages like this:

usb_hcd_pci_suspend(): ehci_pci_suspend+0x0/0xab [ehci_hcd]() returns -22
pci_device_suspend(): usb_hcd_pci_suspend+0x0/0x16d [usbcore]() returns -22
suspend_device(): pci_device_suspend+0x0/0x4b() returns -22
Could not suspend device 0000:00:13.2: error -22

Could you please tell me which patches might have caused this, in your opinion?

Rafael


-- 
You never change things by fighting the existing reality.
		R. Buckminster Fuller

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: 2.6.18-rc6-mm1
  2006-09-11 21:19 ` 2.6.18-rc6-mm1 Mark Haverkamp
@ 2006-09-11 22:16   ` Andrew Morton
  0 siblings, 0 replies; 114+ messages in thread
From: Andrew Morton @ 2006-09-11 22:16 UTC (permalink / raw)
  To: Mark Haverkamp; +Cc: Trond Myklebust, linux-kernel

On Mon, 11 Sep 2006 14:19:52 -0700
Mark Haverkamp <markh@osdl.org> wrote:

> On Fri, 2006-09-08 at 01:13 -0700, Andrew Morton wrote:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc6/2.6.18-rc6-mm1/
> > 
> 
> compiling a kernel with allnoconfig produces the following error:
> 
>   CHK     include/linux/version.h
>   CHK     include/linux/utsrelease.h
>   CHK     include/linux/compile.h
>   GEN     .version
>   CHK     include/linux/compile.h
>   UPD     include/linux/compile.h
>   CC      init/version.o
>   LD      init/built-in.o
>   LD      .tmp_vmlinux1
> mm/built-in.o: In function `writeback_congestion_end':
> (.text+0x5d3b): undefined reference to `blk_congestion_end'
> make: *** [.tmp_vmlinux1] Error 1
> 
> The problem is that the block layer isn't configured and this is where
> the blk_congestion_end symbol comes from.
> 
> This comes from the git-nfs.patch.
> 

Yup, CONFIG_BLOCK=n is bust, sorry.  It's relatively simple to fix but I've
basically thrown up my hands and decided that we can tidy this up once
everything hits mainline.  Or Jens or Trond (whoever merges second) will
fix it prior to merging.

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: lockdep warning in check_flags()
  2006-09-11  5:43   ` Ingo Molnar
@ 2006-09-12 14:13     ` Frederik Deweerdt
  2006-09-12 16:54       ` Ingo Molnar
  0 siblings, 1 reply; 114+ messages in thread
From: Frederik Deweerdt @ 2006-09-12 14:13 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: Andrew Morton, linux-kernel, arjanv

On Mon, Sep 11, 2006 at 07:43:35AM +0200, Ingo Molnar wrote:
> 
> * Frederik Deweerdt <deweerdt@free.fr> wrote:
> 
> > Lockdep issues the following warning:
> > 
> > [   16.835268] Freeing unused kernel memory: 260k freed
> > [   16.842715] Write protecting the kernel read-only data: 432k
> > [   17.796518] BUG: warning at kernel/lockdep.c:2359/check_flags()
> 
> this warning means that the "soft" and "hard" hardirqs-disabled state 
> got out of sync: the irqtrace tracking code thinks that hardirqs are 
> disabled, while in reality they are enabled. The thing to watch for are 
> new "stii" instructions in entry.S (and other assembly code), without a 
> matching TRACE_HARDIRQS_ON call. [Another, rarer possiblity is NMI code 
> saving/restoring interrupts - do you have NMIs enabled? (are there any 
> NMI counts in /proc/interrupts?)]
NMIs were disabled. But I've just booted -mm2 and the warning went away.
Could this be related to the recent pda changes?
FWIW, I did the bisection (inserting TRACE_HARDIRQS_ON between
sysenter_past_esp and the cli) and it gave the following result:
In entry.S:
310
311         pushl %eax
312         CFI_ADJUST_CFA_OFFSET 4
313         SAVE_ALL
314         GET_THREAD_INFO(%ebp)
315
If I put TRACE_HARDIRQS_ON at line 310, lockdep complains about having
interrupts enabled and being told to re-enable them. If I put
TRACE_HARDIRQS_ON at line 315, lockdep goes back to the original
message.

Regards,
Frederik
> 
> lockdep automatically generates a minimal trace of hardirqs-off 
> state-setting:
> 
> > [   17.885839] irq event stamp: 8318
> > [   17.892746] hardirqs last  enabled at (8317): [<c01032c8>] restore_nocheck+0x12/0x15
> > [   17.906778] hardirqs last disabled at (8318): [<c0103203>] sysenter_past_esp+0x6c/0x99
> > [   17.921481] softirqs last  enabled at (7128): [<c0123cd1>] __do_softirq+0xe9/0xfa
> > [   17.936962] softirqs last disabled at (7121): [<c0123d3e>] do_softirq+0x5c/0x60
> 
> this means that the last registered 'hardirqs off' event was 
> sysenter_past_esp, i.e. the normal sysenter syscall entry code - but 
> nothing re-enabled hardirqs - which is weird, given that you ended up in 
> sys_brk().
> 
> > I've replaced the DEBUG_LOCKS_WARN_ON by a BUG, and it appears that 
> > the user space program calling sys_brk is hotplug.
> 
> (ok, i'll enhance the debug printout to include the process name and 
> PID.)
> 
> 	Ingo
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: [linux-usb-devel] 2.6.18-rc6-mm1
  2006-09-11 22:08       ` Rafael J. Wysocki
@ 2006-09-12 14:28         ` Alan Stern
  2006-09-12 17:22           ` Mattia Dongili
  0 siblings, 1 reply; 114+ messages in thread
From: Alan Stern @ 2006-09-12 14:28 UTC (permalink / raw)
  To: Rafael J. Wysocki; +Cc: Andrew Morton, linux-kernel, USB development list

On Tue, 12 Sep 2006, Rafael J. Wysocki wrote:

> Now I have another symtom: during the _second_ suspend the suspending of
> USB controllers fails with messages like this:
> 
> usb_hcd_pci_suspend(): ehci_pci_suspend+0x0/0xab [ehci_hcd]() returns -22
> pci_device_suspend(): usb_hcd_pci_suspend+0x0/0x16d [usbcore]() returns -22
> suspend_device(): pci_device_suspend+0x0/0x4b() returns -22
> Could not suspend device 0000:00:13.2: error -22
> 
> Could you please tell me which patches might have caused this, in your opinion?

It's a little difficult to pin down the blame.  In one form or another
this problem probably existed all along, although it may not have been 
very obvious.

For those interested in the explanation:

The EHCI USB controller is represented in sysfs by two device structures.  
The higher one represents the controller's PCI interface (let's call it
the "PCI-controller") and the lower one represents the USB interface
(let's call it the "root hub").  Inside the resume() routine for the
PCI-controller, if the driver finds that power was lost during the suspend
-- as it would be for suspend-to-disk -- the driver reinitializes the root
hub but without telling usbcore it has done so.  If the root hub had
already been suspended at the time of the suspend-to-disk, then
resume-from-disk would skip calling its resume() method.  So as far as 
usbcore knows the root hub should still be suspended, but in fact it is 
awake.

Consequently during the second suspend-to-disk, usbcore does not pass the
suspend() call on to the root hub's driver.  Then the suspend() method for
the PCI-controller fails, because it sees that the child root hub is still
unsuspended.

I was just going to send in a patch to fix the problem.  I haven't had
much of a chance to try it out yet.  The patch is included below, so you
can test it right away and let me know if it works for you before I submit 
it.

Alan Stern


Index: usb-2.6/drivers/usb/core/hub.c
===================================================================
--- usb-2.6.orig/drivers/usb/core/hub.c
+++ usb-2.6/drivers/usb/core/hub.c
@@ -1066,6 +1066,12 @@ void usb_root_hub_lost_power(struct usb_
 	unsigned long flags;
 
 	dev_warn(&rhdev->dev, "root hub lost power or was reset\n");
+
+	/* Make sure no potential wakeup events get lost,
+	 * by forcing the root hub to be resumed.
+	 */
+	rhdev->dev.power.prev_state.event = PM_EVENT_ON;
+
 	spin_lock_irqsave(&device_state_lock, flags);
 	hub = hdev_to_hub(rhdev);
 	for (port1 = 1; port1 <= rhdev->maxchild; ++port1) {


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: lockdep warning in check_flags()
  2006-09-12 14:13     ` Frederik Deweerdt
@ 2006-09-12 16:54       ` Ingo Molnar
  2006-09-12 20:21         ` Frederik Deweerdt
  0 siblings, 1 reply; 114+ messages in thread
From: Ingo Molnar @ 2006-09-12 16:54 UTC (permalink / raw)
  To: Frederik Deweerdt; +Cc: Andrew Morton, linux-kernel, arjanv


* Frederik Deweerdt <deweerdt@free.fr> wrote:

> On Mon, Sep 11, 2006 at 07:43:35AM +0200, Ingo Molnar wrote:
> > 
> > * Frederik Deweerdt <deweerdt@free.fr> wrote:
> > 
> > > Lockdep issues the following warning:
> > > 
> > > [   16.835268] Freeing unused kernel memory: 260k freed
> > > [   16.842715] Write protecting the kernel read-only data: 432k
> > > [   17.796518] BUG: warning at kernel/lockdep.c:2359/check_flags()
> > 
> > this warning means that the "soft" and "hard" hardirqs-disabled state 
> > got out of sync: the irqtrace tracking code thinks that hardirqs are 
> > disabled, while in reality they are enabled. The thing to watch for are 
> > new "stii" instructions in entry.S (and other assembly code), without a 
> > matching TRACE_HARDIRQS_ON call. [Another, rarer possiblity is NMI code 
> > saving/restoring interrupts - do you have NMIs enabled? (are there any 
> > NMI counts in /proc/interrupts?)]
> NMIs were disabled. But I've just booted -mm2 and the warning went away.
> Could this be related to the recent pda changes?

yeah, it could be related to the fix below. Can you confirm that by 
applying this to your -mm1 tree the message goes away?

	Ingo

--------------->
Subject: [patch] i386-PDA, lockdep: fix %gs restore
From: Ingo Molnar <mingo@elte.hu>

in the syscall exit path the %gs selector has to be restored _after_ the
last kernel function has been called. If lockdep is enabled then this
kernel function is TRACE_IRQS_ON.

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

---
 arch/i386/kernel/entry.S |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

Index: linux/arch/i386/kernel/entry.S
===================================================================
--- linux.orig/arch/i386/kernel/entry.S
+++ linux/arch/i386/kernel/entry.S
@@ -326,11 +326,12 @@ sysenter_past_esp:
 	testw $_TIF_ALLWORK_MASK, %cx
 	jne syscall_exit_work
 /* if something modifies registers it must also disable sysexit */
-1:	mov  PT_GS(%esp), %gs
+1:
+	TRACE_IRQS_ON
+	mov  PT_GS(%esp), %gs
 	movl PT_EIP(%esp), %edx
 	movl PT_OLDESP(%esp), %ecx
 	xorl %ebp,%ebp
-	TRACE_IRQS_ON
 	ENABLE_INTERRUPTS_SYSEXIT
 	CFI_ENDPROC
 .pushsection .fixup,"ax";	\

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: [linux-usb-devel] 2.6.18-rc6-mm1
  2006-09-12 14:28         ` Alan Stern
@ 2006-09-12 17:22           ` Mattia Dongili
  2006-09-12 18:04             ` Mattia Dongili
  0 siblings, 1 reply; 114+ messages in thread
From: Mattia Dongili @ 2006-09-12 17:22 UTC (permalink / raw)
  To: Alan Stern
  Cc: Rafael J. Wysocki, Andrew Morton, linux-kernel, USB development list

On Tue, Sep 12, 2006 at 10:28:27AM -0400, Alan Stern wrote:
> On Tue, 12 Sep 2006, Rafael J. Wysocki wrote:
> 
> > Now I have another symtom: during the _second_ suspend the suspending of
> > USB controllers fails with messages like this:
> > 
> > usb_hcd_pci_suspend(): ehci_pci_suspend+0x0/0xab [ehci_hcd]() returns -22
> > pci_device_suspend(): usb_hcd_pci_suspend+0x0/0x16d [usbcore]() returns -22
> > suspend_device(): pci_device_suspend+0x0/0x4b() returns -22
> > Could not suspend device 0000:00:13.2: error -22
> > 
> > Could you please tell me which patches might have caused this, in your opinion?

oh great, I was going to report (almost) the same for S3:

[  224.436000] uhci_hcd 0000:00:1d.2: Root hub isn't suspended!
[  224.436000] usb_hcd_pci_suspend(): uhci_suspend+0x0/0xe0 [uhci_hcd]() returns -16
[  224.436000] pci_device_suspend(): usb_hcd_pci_suspend+0x0/0x1a0 [usbcore]() returns -16
[  224.436000] suspend_device(): pci_device_suspend+0x0/0x70() returns -16
[  224.436000] Could not suspend device 0000:00:1d.2: error -16

I'd also add that the 3rd attempt at suspending will simply hang with
powered down monitor but sysrq is still available.

> It's a little difficult to pin down the blame.  In one form or another
> this problem probably existed all along, although it may not have been 
> very obvious.
> 
> For those interested in the explanation:
> 
> The EHCI USB controller is represented in sysfs by two device structures.  
> The higher one represents the controller's PCI interface (let's call it
> the "PCI-controller") and the lower one represents the USB interface
> (let's call it the "root hub").  Inside the resume() routine for the
> PCI-controller, if the driver finds that power was lost during the suspend
> -- as it would be for suspend-to-disk -- the driver reinitializes the root
> hub but without telling usbcore it has done so.  If the root hub had
> already been suspended at the time of the suspend-to-disk, then
> resume-from-disk would skip calling its resume() method.  So as far as 
> usbcore knows the root hub should still be suspended, but in fact it is 
> awake.
> 
> Consequently during the second suspend-to-disk, usbcore does not pass the
> suspend() call on to the root hub's driver.  Then the suspend() method for
> the PCI-controller fails, because it sees that the child root hub is still
> unsuspended.

I assume this is still true for suspend-to-ram :)
Maybe this is related, I'd like to add also that with previous kernels
(all the 2.6.17*-mm serie until 2.6.18-rc5-mm1) after the first resume I
get those annoying "resets":

[73060.848000] usb 1-2: reset low speed USB device using uhci_hcd and address 3
[73128.332000] usb 1-2: reset low speed USB device using uhci_hcd and address 3
[73586.392000] usb 1-2: reset low speed USB device using uhci_hcd and address 3
[73944.592000] usb 1-2: reset low speed USB device using uhci_hcd and address 3

when the device is reset while typing the char being typed is repeated 4
times. Suspending and resuming again seems to fix that.
Oh, here it is:
Bus 002 Device 001: ID 0000:0000  
Bus 003 Device 003: ID 054c:0056 Sony Corp. 
Bus 003 Device 001: ID 0000:0000  
Bus 001 Device 003: ID 046d:c001 Logitech, Inc. N48/M-BB48 [FirstMouse Plus]
Bus 001 Device 001: ID 0000:0000  

> I was just going to send in a patch to fix the problem.  I haven't had
> much of a chance to try it out yet.  The patch is included below, so you
> can test it right away and let me know if it works for you before I submit 
> it.

going to reboot to test it, hold on.

-- 
mattia
:wq!

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: [linux-usb-devel] 2.6.18-rc6-mm1
  2006-09-12 17:22           ` Mattia Dongili
@ 2006-09-12 18:04             ` Mattia Dongili
  2006-09-12 20:10               ` Alan Stern
  0 siblings, 1 reply; 114+ messages in thread
From: Mattia Dongili @ 2006-09-12 18:04 UTC (permalink / raw)
  To: Alan Stern, Rafael J. Wysocki, Andrew Morton, linux-kernel,
	USB development list

On Tue, Sep 12, 2006 at 07:22:11PM +0200, Mattia Dongili wrote:
> On Tue, Sep 12, 2006 at 10:28:27AM -0400, Alan Stern wrote:
[...]
> > I was just going to send in a patch to fix the problem.  I haven't had
> > much of a chance to try it out yet.  The patch is included below, so you
> > can test it right away and let me know if it works for you before I submit 
> > it.
> 
> going to reboot to test it, hold on.

No luck here. I'll give -mm2 a run just to 

full dmesg
with patch applied[1]:
http://oioio.altervista.org/linux/dmesg-2.6.18-rc6-mm1-fail-S3-2

without it (it's almost identical :)):
http://oioio.altervista.org/linux/dmesg-2.6.18-rc6-mm1-fail-S3

.config:
http://oioio.altervista.org/linux/config-2.6.18-rc6-mm1-3

[1]: I didn't rebuild fully, just applied the patch and re-run make
bzImage modules

-- 
mattia
:wq!

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: [linux-usb-devel] 2.6.18-rc6-mm1
  2006-09-12 18:04             ` Mattia Dongili
@ 2006-09-12 20:10               ` Alan Stern
  2006-09-13 17:00                 ` Rafael J. Wysocki
  0 siblings, 1 reply; 114+ messages in thread
From: Alan Stern @ 2006-09-12 20:10 UTC (permalink / raw)
  To: Mattia Dongili
  Cc: Rafael J. Wysocki, Andrew Morton, linux-kernel, USB development list

On Tue, 12 Sep 2006, Mattia Dongili wrote:

> No luck here. I'll give -mm2 a run just to 
> 
> full dmesg
> with patch applied[1]:
> http://oioio.altervista.org/linux/dmesg-2.6.18-rc6-mm1-fail-S3-2
> 
> without it (it's almost identical :)):
> http://oioio.altervista.org/linux/dmesg-2.6.18-rc6-mm1-fail-S3
> 
> .config:
> http://oioio.altervista.org/linux/config-2.6.18-rc6-mm1-3
> 
> [1]: I didn't rebuild fully, just applied the patch and re-run make
> bzImage modules

I can't reproduce your results here with my configuration.  I used 
2.6.18-rc6-mm2 instead of -mm1 but I don't think that should matter.

(It's also a little awkward to try.  My system has the annoying habit of 
waking up from suspend-to-RAM with the screen non-functional.  No doubt a 
BIOS problem.)

Please try this again after setting CONFIG_USB_DEBUG.  It's hard to say 
anything definite without more debugging info.

Alan Stern


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: lockdep warning in check_flags()
  2006-09-12 16:54       ` Ingo Molnar
@ 2006-09-12 20:21         ` Frederik Deweerdt
  0 siblings, 0 replies; 114+ messages in thread
From: Frederik Deweerdt @ 2006-09-12 20:21 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: Andrew Morton, linux-kernel, arjanv

On Tue, Sep 12, 2006 at 06:54:48PM +0200, Ingo Molnar wrote:
> 
> * Frederik Deweerdt <deweerdt@free.fr> wrote:
> 
> > On Mon, Sep 11, 2006 at 07:43:35AM +0200, Ingo Molnar wrote:
> > > 
> > > * Frederik Deweerdt <deweerdt@free.fr> wrote:
> > > 
> > > > Lockdep issues the following warning:
> > > > 
> > > > [   16.835268] Freeing unused kernel memory: 260k freed
> > > > [   16.842715] Write protecting the kernel read-only data: 432k
> > > > [   17.796518] BUG: warning at kernel/lockdep.c:2359/check_flags()
> > > 
> > > this warning means that the "soft" and "hard" hardirqs-disabled state 
> > > got out of sync: the irqtrace tracking code thinks that hardirqs are 
> > > disabled, while in reality they are enabled. The thing to watch for are 
> > > new "stii" instructions in entry.S (and other assembly code), without a 
> > > matching TRACE_HARDIRQS_ON call. [Another, rarer possiblity is NMI code 
> > > saving/restoring interrupts - do you have NMIs enabled? (are there any 
> > > NMI counts in /proc/interrupts?)]
> > NMIs were disabled. But I've just booted -mm2 and the warning went away.
> > Could this be related to the recent pda changes?
> 
> yeah, it could be related to the fix below. Can you confirm that by 
> applying this to your -mm1 tree the message goes away?
> 
It does, thanks Ingo.
Frederik

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem
  2006-09-08 22:57     ` Rafael J. Wysocki
  2006-09-11 22:08       ` Rafael J. Wysocki
@ 2006-09-13 12:07       ` Rafael J. Wysocki
  2006-09-13 12:42         ` Rafael J. Wysocki
  1 sibling, 1 reply; 114+ messages in thread
From: Rafael J. Wysocki @ 2006-09-13 12:07 UTC (permalink / raw)
  To: Alan Stern; +Cc: Andrew Morton, linux-kernel, USB development list

On Saturday, 9 September 2006 00:57, Rafael J. Wysocki wrote:
> On Friday, 8 September 2006 22:44, Alan Stern wrote:
> > On Fri, 8 Sep 2006, Andrew Morton wrote:
> > 
> > > Alan, is this likely to be due to your USB PM changes?
> > 
> > It's possible.  Most of those changes are innocuous.  They add routines
> > that don't get used until a later patch.  However one of them might be
> > responsible.
> 
> Well, after recompiling the kernel for several times (because of a different
> problem) I'm no longer able to reproduce the problem.

I have retested it on 2.6.18-rc6-mm1 and the problem sometimes happens.
It's not readily reproducible, as I said before, and it apparently doesn't
happen with gregkh-usb-usbcore-remove-usb_suspend_root_hub.patch
reverted.

Greetings,
Rafael


-- 
You never change things by fighting the existing reality.
		R. Buckminster Fuller

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem
  2006-09-13 12:07       ` [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem Rafael J. Wysocki
@ 2006-09-13 12:42         ` Rafael J. Wysocki
  2006-09-13 18:38           ` Alan Stern
  0 siblings, 1 reply; 114+ messages in thread
From: Rafael J. Wysocki @ 2006-09-13 12:42 UTC (permalink / raw)
  To: Alan Stern; +Cc: Andrew Morton, linux-kernel, USB development list

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

On Wednesday, 13 September 2006 14:07, Rafael J. Wysocki wrote:
> On Saturday, 9 September 2006 00:57, Rafael J. Wysocki wrote:
> > On Friday, 8 September 2006 22:44, Alan Stern wrote:
> > > On Fri, 8 Sep 2006, Andrew Morton wrote:
> > > 
> > > > Alan, is this likely to be due to your USB PM changes?
> > > 
> > > It's possible.  Most of those changes are innocuous.  They add routines
> > > that don't get used until a later patch.  However one of them might be
> > > responsible.
> > 
> > Well, after recompiling the kernel for several times (because of a different
> > problem) I'm no longer able to reproduce the problem.
> 
> I have retested it on 2.6.18-rc6-mm1 and the problem sometimes happens.
> It's not readily reproducible, as I said before, and it apparently doesn't
> happen with gregkh-usb-usbcore-remove-usb_suspend_root_hub.patch
> reverted.

Well, I have reproduced it with gregkh-usb-usbcore-remove-usb_suspend_root_hub.patch
reverted too.

Attached is the output of dmesg from the failing case with USB_DEBUG set.
It covers two attempts to suspend to disk, the second one being unsuccessful,
with reloading the ohci_hcd module in between.  [This kernel also has your
other patch to prevent the second suspend from failing applied, but it doesn't
help.]

Greetings,
Rafael


-- 
You never change things by fighting the existing reality.
		R. Buckminster Fuller

[-- Attachment #2: dmesg.log.gz --]
[-- Type: application/x-gzip, Size: 17040 bytes --]

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: [linux-usb-devel] 2.6.18-rc6-mm1
  2006-09-12 20:10               ` Alan Stern
@ 2006-09-13 17:00                 ` Rafael J. Wysocki
  0 siblings, 0 replies; 114+ messages in thread
From: Rafael J. Wysocki @ 2006-09-13 17:00 UTC (permalink / raw)
  To: Alan Stern
  Cc: Mattia Dongili, Andrew Morton, linux-kernel, USB development list

On Tuesday, 12 September 2006 22:10, Alan Stern wrote:
> On Tue, 12 Sep 2006, Mattia Dongili wrote:
> 
> > No luck here. I'll give -mm2 a run just to 
> > 
> > full dmesg
> > with patch applied[1]:
> > http://oioio.altervista.org/linux/dmesg-2.6.18-rc6-mm1-fail-S3-2
> > 
> > without it (it's almost identical :)):
> > http://oioio.altervista.org/linux/dmesg-2.6.18-rc6-mm1-fail-S3
> > 
> > .config:
> > http://oioio.altervista.org/linux/config-2.6.18-rc6-mm1-3
> > 
> > [1]: I didn't rebuild fully, just applied the patch and re-run make
> > bzImage modules
> 
> I can't reproduce your results here with my configuration.  I used 
> 2.6.18-rc6-mm2 instead of -mm1 but I don't think that should matter.

On my box the issue (the second suspend of USB controllers in a row fails
100% of the time) went away after I had reverted the following patches
(I'm using 2.6.18-rc6-mm2 now):

fix-gregkh-usb-usbcore-add-autosuspend-autoresume-infrastructure.patch
gregkh-usb-usbcore-add-autosuspend-autoresume-infrastructure.patch
gregkh-usb-usbcore-non-hub-specific-uses-of-autosuspend.patch
gregkh-usb-usbcore-remove-usb_suspend_root_hub.patch

Greetings,
Rafael


-- 
You never change things by fighting the existing reality.
		R. Buckminster Fuller

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem
  2006-09-13 12:42         ` Rafael J. Wysocki
@ 2006-09-13 18:38           ` Alan Stern
  2006-09-13 20:00             ` Rafael J. Wysocki
  2006-09-13 20:38             ` Mattia Dongili
  0 siblings, 2 replies; 114+ messages in thread
From: Alan Stern @ 2006-09-13 18:38 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Mattia Dongili, Andrew Morton, Kernel development list,
	USB development list

On Wed, 13 Sep 2006, Rafael J. Wysocki wrote:

> Well, I have reproduced it with gregkh-usb-usbcore-remove-usb_suspend_root_hub.patch
> reverted too.
> 
> Attached is the output of dmesg from the failing case with USB_DEBUG set.
> It covers two attempts to suspend to disk, the second one being unsuccessful,
> with reloading the ohci_hcd module in between.  [This kernel also has your
> other patch to prevent the second suspend from failing applied, but it doesn't
> help.]

Okay.  Your problem, and probably Mattia's too, is something other than
what that recent patch addressed.  I can't tell from the dmesg log exactly
what went wrong, but I can tell you where to look.

In drivers/usb/core/driver.c, resume_device() is not succeeding.  That is, 
the lines near the end which do

	if (status == 0)
		udev->dev.power.power_state.event = PM_EVENT_ON;

aren't running during the first resume.  You can see this in the dmesg 
log; lines 1173-1175 say

	usb usb1: resuming
	 usbdev1.1_ep00: PM: resume from 0, parent usb1 still 1
	hub 1-0:1.0: PM: resume from 0, parent usb1 still 1

If power_state.event had gotten set to PM_EVENT_ON then the parent state 
would be 0, not 1.  This is the source of your problem.  During your 
second suspend attempt, usb1 didn't get handled correctly because its 
state was set wrong.  (I suspect the mishandling took place in usbcore 
rather than the PM core, but it doesn't matter.  The state should not have 
been wrong to begin with.)  Consequently its parent device 0000:00:13.2 
refused to freeze, which aborted the suspend attempt.

For the usb1 device, udriver->resume should point to the generic_resume() 
routine in drivers/usb/core/generic.c.  In fact, this should be true for 
every device that driver.c:resume_device() sees.  But generic_resume() 
simply calls usb_port_resume() in hub.c, and the log doesn't contain any 
of the USB debugging messages that usb_port_resume() would produce.  So I 
can't tell what happened.

The patch below will add some extra debugging information.  We need to
find out why the resume didn't succeed.  Oh -- and of course, you should
reinstate all those autosuspend patches.  Otherwise this patch won't 
apply!

Alan Stern



Index: mm/drivers/usb/core/driver.c
===================================================================
--- mm.orig/drivers/usb/core/driver.c
+++ mm/drivers/usb/core/driver.c
@@ -825,6 +825,7 @@ static int resume_device(struct usb_devi
 	struct usb_device_driver	*udriver;
 	int				status = 0;
 
+	dev_dbg(&udev->dev, "%s: state %d\n", __FUNCTION__, udev->state);
 	if (udev->state == USB_STATE_NOTATTACHED ||
 			udev->state != USB_STATE_SUSPENDED)
 		goto done;
@@ -839,7 +840,7 @@ static int resume_device(struct usb_devi
 	status = udriver->resume(udev);
 
 done:
-	// dev_dbg(&udev->dev, "%s: status %d\n", __FUNCTION__, status);
+	dev_dbg(&udev->dev, "%s: status %d\n", __FUNCTION__, status);
 	if (status == 0)
 		udev->dev.power.power_state.event = PM_EVENT_ON;
 	return status;


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem
  2006-09-13 18:38           ` Alan Stern
@ 2006-09-13 20:00             ` Rafael J. Wysocki
  2006-09-13 21:01               ` Alan Stern
  2006-09-13 20:38             ` Mattia Dongili
  1 sibling, 1 reply; 114+ messages in thread
From: Rafael J. Wysocki @ 2006-09-13 20:00 UTC (permalink / raw)
  To: Alan Stern
  Cc: Mattia Dongili, Andrew Morton, Kernel development list,
	USB development list

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

On Wednesday, 13 September 2006 20:38, Alan Stern wrote:
> On Wed, 13 Sep 2006, Rafael J. Wysocki wrote:
> 
> > Well, I have reproduced it with gregkh-usb-usbcore-remove-usb_suspend_root_hub.patch
> > reverted too.
> > 
> > Attached is the output of dmesg from the failing case with USB_DEBUG set.
> > It covers two attempts to suspend to disk, the second one being unsuccessful,
> > with reloading the ohci_hcd module in between.  [This kernel also has your
> > other patch to prevent the second suspend from failing applied, but it doesn't
> > help.]
> 
> Okay.  Your problem, and probably Mattia's too, is something other than
> what that recent patch addressed.  I can't tell from the dmesg log exactly
> what went wrong, but I can tell you where to look.
> 
> In drivers/usb/core/driver.c, resume_device() is not succeeding.  That is, 
> the lines near the end which do
> 
> 	if (status == 0)
> 		udev->dev.power.power_state.event = PM_EVENT_ON;
> 
> aren't running during the first resume.  You can see this in the dmesg 
> log; lines 1173-1175 say
> 
> 	usb usb1: resuming
> 	 usbdev1.1_ep00: PM: resume from 0, parent usb1 still 1
> 	hub 1-0:1.0: PM: resume from 0, parent usb1 still 1
> 
> If power_state.event had gotten set to PM_EVENT_ON then the parent state 
> would be 0, not 1.  This is the source of your problem.  During your 
> second suspend attempt, usb1 didn't get handled correctly because its 
> state was set wrong.  (I suspect the mishandling took place in usbcore 
> rather than the PM core, but it doesn't matter.  The state should not have 
> been wrong to begin with.)  Consequently its parent device 0000:00:13.2 
> refused to freeze, which aborted the suspend attempt.
> 
> For the usb1 device, udriver->resume should point to the generic_resume() 
> routine in drivers/usb/core/generic.c.  In fact, this should be true for 
> every device that driver.c:resume_device() sees.  But generic_resume() 
> simply calls usb_port_resume() in hub.c, and the log doesn't contain any 
> of the USB debugging messages that usb_port_resume() would produce.  So I 
> can't tell what happened.
> 
> The patch below will add some extra debugging information.  We need to
> find out why the resume didn't succeed.  Oh -- and of course, you should
> reinstate all those autosuspend patches.  Otherwise this patch won't 
> apply!

OK

Attached is a dmesg output from 2.6.18-rc6-mm2 with the patch applied.
It covers two consecutive attempts to suspend (the second one obviously
failed).

Greetings,
Rafael


-- 
You never change things by fighting the existing reality.
		R. Buckminster Fuller

[-- Attachment #2: dmesg-debug.log.gz --]
[-- Type: application/x-gzip, Size: 14809 bytes --]

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem
  2006-09-13 18:38           ` Alan Stern
  2006-09-13 20:00             ` Rafael J. Wysocki
@ 2006-09-13 20:38             ` Mattia Dongili
  2006-09-13 20:54               ` Alan Stern
  1 sibling, 1 reply; 114+ messages in thread
From: Mattia Dongili @ 2006-09-13 20:38 UTC (permalink / raw)
  To: Alan Stern
  Cc: Rafael J. Wysocki, Andrew Morton, Kernel development list,
	USB development list

On Wed, Sep 13, 2006 at 02:38:35PM -0400, Alan Stern wrote:
> On Wed, 13 Sep 2006, Rafael J. Wysocki wrote:
> 
> > Well, I have reproduced it with gregkh-usb-usbcore-remove-usb_suspend_root_hub.patch
> > reverted too.
> > 
> > Attached is the output of dmesg from the failing case with USB_DEBUG set.
> > It covers two attempts to suspend to disk, the second one being unsuccessful,
> > with reloading the ohci_hcd module in between.  [This kernel also has your
> > other patch to prevent the second suspend from failing applied, but it doesn't
> > help.]
> 
> Okay.  Your problem, and probably Mattia's too, is something other than
> what that recent patch addressed.  I can't tell from the dmesg log exactly
> what went wrong, but I can tell you where to look.
> 
> In drivers/usb/core/driver.c, resume_device() is not succeeding.  That is, 
> the lines near the end which do
> 
> 	if (status == 0)
> 		udev->dev.power.power_state.event = PM_EVENT_ON;
> 
> aren't running during the first resume.  You can see this in the dmesg 
> log; lines 1173-1175 say
> 
> 	usb usb1: resuming
> 	 usbdev1.1_ep00: PM: resume from 0, parent usb1 still 1
> 	hub 1-0:1.0: PM: resume from 0, parent usb1 still 1
> 
> If power_state.event had gotten set to PM_EVENT_ON then the parent state 
> would be 0, not 1.  This is the source of your problem.  During your 
> second suspend attempt, usb1 didn't get handled correctly because its 
> state was set wrong.  (I suspect the mishandling took place in usbcore 
> rather than the PM core, but it doesn't matter.  The state should not have 
> been wrong to begin with.)  Consequently its parent device 0000:00:13.2 
> refused to freeze, which aborted the suspend attempt.
> 
> For the usb1 device, udriver->resume should point to the generic_resume() 
> routine in drivers/usb/core/generic.c.  In fact, this should be true for 
> every device that driver.c:resume_device() sees.  But generic_resume() 
> simply calls usb_port_resume() in hub.c, and the log doesn't contain any 
> of the USB debugging messages that usb_port_resume() would produce.  So I 
> can't tell what happened.
> 
> The patch below will add some extra debugging information.  We need to
> find out why the resume didn't succeed.  Oh -- and of course, you should
> reinstate all those autosuspend patches.  Otherwise this patch won't 
> apply!

ok, with USB_DEBUG=y and this is with your first patch still applied
http://oioio.altervista.org/linux/dmesg-2.6.18-rc6-mm1-verbose-usb-try2

this is without it:
http://oioio.altervista.org/linux/dmesg-2.6.18-rc6-mm1-verbose-usb-try3

I hope I'm not mixing thing too much with Rafael :)

Thanks
-- 
mattia
:wq!

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem
  2006-09-13 20:38             ` Mattia Dongili
@ 2006-09-13 20:54               ` Alan Stern
  2006-09-14 20:19                 ` Mattia Dongili
  0 siblings, 1 reply; 114+ messages in thread
From: Alan Stern @ 2006-09-13 20:54 UTC (permalink / raw)
  To: Mattia Dongili
  Cc: Rafael J. Wysocki, Andrew Morton, Kernel development list,
	USB development list

On Wed, 13 Sep 2006, Mattia Dongili wrote:

> > The patch below will add some extra debugging information.  We need to
> > find out why the resume didn't succeed.  Oh -- and of course, you should
> > reinstate all those autosuspend patches.  Otherwise this patch won't 
> > apply!
> 
> ok, with USB_DEBUG=y and this is with your first patch still applied
> http://oioio.altervista.org/linux/dmesg-2.6.18-rc6-mm1-verbose-usb-try2
> 
> this is without it:
> http://oioio.altervista.org/linux/dmesg-2.6.18-rc6-mm1-verbose-usb-try3
> 
> I hope I'm not mixing thing too much with Rafael :)

No.  But this log doesn't include the debugging output in the patch from 
my previous message.

Alan Stern


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem
  2006-09-13 20:00             ` Rafael J. Wysocki
@ 2006-09-13 21:01               ` Alan Stern
  2006-09-13 21:32                 ` Rafael J. Wysocki
  0 siblings, 1 reply; 114+ messages in thread
From: Alan Stern @ 2006-09-13 21:01 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Mattia Dongili, Andrew Morton, Kernel development list,
	USB development list

On Wed, 13 Sep 2006, Rafael J. Wysocki wrote:

> > The patch below will add some extra debugging information.  We need to
> > find out why the resume didn't succeed.  Oh -- and of course, you should
> > reinstate all those autosuspend patches.  Otherwise this patch won't 
> > apply!
> 
> OK
> 
> Attached is a dmesg output from 2.6.18-rc6-mm2 with the patch applied.
> It covers two consecutive attempts to suspend (the second one obviously
> failed).

Hmm... The patch didn't yield any output.  Unlike Mattia's log, yours
doesn't include any lines saying "usb usb1: wakeup_rh" so I can't be sure
whether the patch code should have run or not.

Try this patch instead.  It looks for problems occurring a little earlier 
in the call chain.

Alan Stern


Index: mm/drivers/usb/core/hcd-pci.c
===================================================================
--- mm.orig/drivers/usb/core/hcd-pci.c
+++ mm/drivers/usb/core/hcd-pci.c
@@ -406,6 +406,8 @@ int usb_hcd_pci_resume (struct pci_dev *
 			usb_hc_died (hcd);
 		}
 	}
+	dev_dbg(&dev->dev, "Controller %p state after resume %d\n",
+			&dev->dev, dev->dev.power.power_state.event);
 
 	return retval;
 }
Index: mm/drivers/usb/core/driver.c
===================================================================
--- mm.orig/drivers/usb/core/driver.c
+++ mm/drivers/usb/core/driver.c
@@ -1060,6 +1060,8 @@ int usb_resume_both(struct usb_device *u
 	struct usb_interface	*intf;
 	struct usb_device	*parent = udev->parent;
 
+	dev_dbg(&udev->dev, "Device state before resume %d\n", udev->state);
+
 	cancel_delayed_work(&udev->autosuspend);
 	if (udev->state == USB_STATE_NOTATTACHED)
 		return -ENODEV;
@@ -1072,6 +1074,9 @@ int usb_resume_both(struct usb_device *u
 			status = usb_resume_both(parent);
 		} else {
 
+	dev_dbg(&udev->dev, "Parent %p PM state %d\n",
+	udev->dev.parent, udev->dev.parent->power.power_state.event);
+
 			/* We can't progagate beyond the USB subsystem,
 			 * so if a root hub's controller is suspended
 			 * then we're stuck. */
@@ -1094,7 +1099,7 @@ int usb_resume_both(struct usb_device *u
 		}
 	}
 
-	// dev_dbg(&udev->dev, "%s: status %d\n", __FUNCTION__, status);
+	dev_dbg(&udev->dev, "%s: status %d\n", __FUNCTION__, status);
 	return status;
 }
 


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem
  2006-09-13 21:01               ` Alan Stern
@ 2006-09-13 21:32                 ` Rafael J. Wysocki
  2006-09-13 21:55                   ` Alan Stern
  0 siblings, 1 reply; 114+ messages in thread
From: Rafael J. Wysocki @ 2006-09-13 21:32 UTC (permalink / raw)
  To: Alan Stern
  Cc: Mattia Dongili, Andrew Morton, Kernel development list,
	USB development list

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

On Wednesday, 13 September 2006 23:01, Alan Stern wrote:
> On Wed, 13 Sep 2006, Rafael J. Wysocki wrote:
> 
> > > The patch below will add some extra debugging information.  We need to
> > > find out why the resume didn't succeed.  Oh -- and of course, you should
> > > reinstate all those autosuspend patches.  Otherwise this patch won't 
> > > apply!
> > 
> > OK
> > 
> > Attached is a dmesg output from 2.6.18-rc6-mm2 with the patch applied.
> > It covers two consecutive attempts to suspend (the second one obviously
> > failed).
> 
> Hmm... The patch didn't yield any output.  Unlike Mattia's log, yours
> doesn't include any lines saying "usb usb1: wakeup_rh" so I can't be sure
> whether the patch code should have run or not.
> 
> Try this patch instead.  It looks for problems occurring a little earlier 
> in the call chain.

I've applied both patches at a time (I hope they don't conflict).

The dmesg output is attached.

Greetings,
Rafael


-- 
You never change things by fighting the existing reality.
		R. Buckminster Fuller

[-- Attachment #2: dmesg-debug-2.log.gz --]
[-- Type: application/x-gzip, Size: 14973 bytes --]

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem
  2006-09-13 21:32                 ` Rafael J. Wysocki
@ 2006-09-13 21:55                   ` Alan Stern
  2006-09-14 13:14                     ` Rafael J. Wysocki
  0 siblings, 1 reply; 114+ messages in thread
From: Alan Stern @ 2006-09-13 21:55 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Andrew Morton, Mattia Dongili, Kernel development list,
	USB development list

On Wed, 13 Sep 2006, Rafael J. Wysocki wrote:

> > Try this patch instead.  It looks for problems occurring a little earlier 
> > in the call chain.
> 
> I've applied both patches at a time (I hope they don't conflict).
> 
> The dmesg output is attached.

The dmesg output shows the root-hub device state is set wrong.

I have to leave now, so I can't give you another patch to try.  You can 
experiment as follows...

Look in drivers/usb/host/ehci-pci.c, at ehci_pci_resume().  The part of 
interest is everything following the "restart:" statement label.

Try adding some ehci_dbg() lines in there (copy the form of the line just
after restart:).  We want to follow the value of
hcd->self.root_hub->state.  Initially it should be equal to
USB_STATE_SUSPENDED (= 8), and it shouldn't change.  But somewhere it is
getting set to USB_STATE_CONFIGURED (= 7).  I don't know where, but almost 
certainly somewhere in this routine.  If you can find out where that 
happens, I'd appreciate it.

Alan Stern


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem
  2006-09-13 21:55                   ` Alan Stern
@ 2006-09-14 13:14                     ` Rafael J. Wysocki
  2006-09-14 14:08                       ` Rafael J. Wysocki
  0 siblings, 1 reply; 114+ messages in thread
From: Rafael J. Wysocki @ 2006-09-14 13:14 UTC (permalink / raw)
  To: Alan Stern
  Cc: Andrew Morton, Mattia Dongili, Kernel development list,
	USB development list

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

On Wednesday, 13 September 2006 23:55, Alan Stern wrote:
> On Wed, 13 Sep 2006, Rafael J. Wysocki wrote:
> 
> > > Try this patch instead.  It looks for problems occurring a little earlier 
> > > in the call chain.
> > 
> > I've applied both patches at a time (I hope they don't conflict).
> > 
> > The dmesg output is attached.
> 
> The dmesg output shows the root-hub device state is set wrong.
> 
> I have to leave now, so I can't give you another patch to try.  You can 
> experiment as follows...
> 
> Look in drivers/usb/host/ehci-pci.c, at ehci_pci_resume().  The part of 
> interest is everything following the "restart:" statement label.
> 
> Try adding some ehci_dbg() lines in there (copy the form of the line just
> after restart:).  We want to follow the value of
> hcd->self.root_hub->state.  Initially it should be equal to
> USB_STATE_SUSPENDED (= 8), and it shouldn't change.  But somewhere it is
> getting set to USB_STATE_CONFIGURED (= 7).  I don't know where, but almost 
> certainly somewhere in this routine.  If you can find out where that 
> happens, I'd appreciate it.

Done, but it shows hcd->self.root_hub->state is already 7 right after restart.

I've used the following patch to verify this:

---
 drivers/usb/host/ehci-pci.c |    8 ++++++++
 1 file changed, 8 insertions(+)

Index: linux-2.6.18-rc6-mm2/drivers/usb/host/ehci-pci.c
===================================================================
--- linux-2.6.18-rc6-mm2.orig/drivers/usb/host/ehci-pci.c
+++ linux-2.6.18-rc6-mm2/drivers/usb/host/ehci-pci.c
@@ -291,14 +291,19 @@ static int ehci_pci_resume(struct usb_hc
 
 restart:
 	ehci_dbg(ehci, "lost power, restarting\n");
+	ehci_dbg(ehci, "root hub state: %d\n", hcd->self.root_hub->state);
 	usb_root_hub_lost_power(hcd->self.root_hub);
+	ehci_dbg(ehci, "root hub state: %d\n", hcd->self.root_hub->state);
 
 	/* Else reset, to cope with power loss or flush-to-storage
 	 * style "resume" having let BIOS kick in during reboot.
 	 */
 	(void) ehci_halt(ehci);
+	ehci_dbg(ehci, "root hub state: %d\n", hcd->self.root_hub->state);
 	(void) ehci_reset(ehci);
+	ehci_dbg(ehci, "root hub state: %d\n", hcd->self.root_hub->state);
 	(void) ehci_pci_reinit(ehci, pdev);
+	ehci_dbg(ehci, "root hub state: %d\n", hcd->self.root_hub->state);
 
 	/* emptying the schedule aborts any urbs */
 	spin_lock_irq(&ehci->lock);
@@ -306,12 +311,15 @@ restart:
 		ehci->reclaim_ready = 1;
 	ehci_work(ehci, NULL);
 	spin_unlock_irq(&ehci->lock);
+	ehci_dbg(ehci, "root hub state: %d\n", hcd->self.root_hub->state);
 
 	/* restart; khubd will disconnect devices */
 	retval = ehci_run(hcd);
+	ehci_dbg(ehci, "root hub state: %d\n", hcd->self.root_hub->state);
 
 	/* here we "know" root ports should always stay powered */
 	ehci_port_power(ehci, 1);
+	ehci_dbg(ehci, "root hub state: %d\n", hcd->self.root_hub->state);
 
 	return retval;
 }

The output of dmesg is attached.

Greetings,
Rafael


-- 
You never change things by fighting the existing reality.
		R. Buckminster Fuller

[-- Attachment #2: dmesg-debug-3.log.gz --]
[-- Type: application/x-gzip, Size: 15082 bytes --]

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem
  2006-09-14 13:14                     ` Rafael J. Wysocki
@ 2006-09-14 14:08                       ` Rafael J. Wysocki
  2006-09-14 15:04                         ` Alan Stern
  0 siblings, 1 reply; 114+ messages in thread
From: Rafael J. Wysocki @ 2006-09-14 14:08 UTC (permalink / raw)
  To: Alan Stern
  Cc: Andrew Morton, Mattia Dongili, Kernel development list,
	USB development list

On Thursday, 14 September 2006 15:14, Rafael J. Wysocki wrote:
> On Wednesday, 13 September 2006 23:55, Alan Stern wrote:
> > On Wed, 13 Sep 2006, Rafael J. Wysocki wrote:
> > 
> > > > Try this patch instead.  It looks for problems occurring a little earlier 
> > > > in the call chain.
> > > 
> > > I've applied both patches at a time (I hope they don't conflict).
> > > 
> > > The dmesg output is attached.
> > 
> > The dmesg output shows the root-hub device state is set wrong.
> > 
> > I have to leave now, so I can't give you another patch to try.  You can 
> > experiment as follows...
> > 
> > Look in drivers/usb/host/ehci-pci.c, at ehci_pci_resume().  The part of 
> > interest is everything following the "restart:" statement label.
> > 
> > Try adding some ehci_dbg() lines in there (copy the form of the line just
> > after restart:).  We want to follow the value of
> > hcd->self.root_hub->state.  Initially it should be equal to
> > USB_STATE_SUSPENDED (= 8), and it shouldn't change.  But somewhere it is
> > getting set to USB_STATE_CONFIGURED (= 7).  I don't know where, but almost 
> > certainly somewhere in this routine.  If you can find out where that 
> > happens, I'd appreciate it.
> 
> Done, but it shows hcd->self.root_hub->state is already 7 right after restart.

BTW, all of the systems on which the problem shows up seem to be 64-bit.

If you can't reproduce it on a 32-bit system, some type casting may be wrong
somewhere.

Greetings,
Rafael


-- 
You never change things by fighting the existing reality.
		R. Buckminster Fuller

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem
  2006-09-14 14:08                       ` Rafael J. Wysocki
@ 2006-09-14 15:04                         ` Alan Stern
  2006-09-14 16:17                           ` Alan Stern
  2006-09-14 16:48                           ` Rafael J. Wysocki
  0 siblings, 2 replies; 114+ messages in thread
From: Alan Stern @ 2006-09-14 15:04 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Andrew Morton, Mattia Dongili, Robert Hancock,
	Kernel development list, USB development list

On Thu, 14 Sep 2006, Rafael J. Wysocki wrote:

> > > Try adding some ehci_dbg() lines in there (copy the form of the line just
> > > after restart:).  We want to follow the value of
> > > hcd->self.root_hub->state.  Initially it should be equal to
> > > USB_STATE_SUSPENDED (= 8), and it shouldn't change.  But somewhere it is
> > > getting set to USB_STATE_CONFIGURED (= 7).  I don't know where, but almost 
> > > certainly somewhere in this routine.  If you can find out where that 
> > > happens, I'd appreciate it.
> > 
> > Done, but it shows hcd->self.root_hub->state is already 7 right after restart.
> 
> BTW, all of the systems on which the problem shows up seem to be 64-bit.
> 
> If you can't reproduce it on a 32-bit system, some type casting may be wrong
> somewhere.

I realized last night what the problem must be.  It's extremely obvious in 
retrospect, but I happen to have a blind spot in this particular area.

All you guys must have CONFIG_USB_SUSPEND turned off.  Mattis certainly 
does; I checked his .config.  Now I hardly ever do any testing without 
CONFIG_USB_SUSPEND, since there's not much point working on power 
management code if your kernel isn't set up to actually suspend devices.
As a result I missed seeing the problems caused by the autosuspend 
changes.

Now of course, the autosuspend stuff has to work properly no matter what 
the kernel configuration is.  I'll go back and rebuild the drivers with 
USB_SUSPEND turned off and see what happens.  With any luck I'll have a 
fix ready in the near future.

Alan Stern


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem
  2006-09-14 15:04                         ` Alan Stern
@ 2006-09-14 16:17                           ` Alan Stern
  2006-09-14 17:08                             ` Rafael J. Wysocki
  2006-09-14 16:48                           ` Rafael J. Wysocki
  1 sibling, 1 reply; 114+ messages in thread
From: Alan Stern @ 2006-09-14 16:17 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Andrew Morton, Mattia Dongili, Robert Hancock,
	Kernel development list, USB development list

On Thu, 14 Sep 2006, Alan Stern wrote:

> Now of course, the autosuspend stuff has to work properly no matter what 
> the kernel configuration is.  I'll go back and rebuild the drivers with 
> USB_SUSPEND turned off and see what happens.  With any luck I'll have a 
> fix ready in the near future.

This should start fixing things, but I'm not certain it will solve the 
entire problem.  If it doesn't work, send another dmesg log.

Alan Stern



Index: mm/drivers/usb/core/driver.c
===================================================================
--- mm.orig/drivers/usb/core/driver.c
+++ mm/drivers/usb/core/driver.c
@@ -813,7 +813,7 @@ static int suspend_device(struct usb_dev
 	status = udriver->suspend(udev, msg);
 
 done:
-	// dev_dbg(&udev->dev, "%s: status %d\n", __FUNCTION__, status);
+	dev_dbg(&udev->dev, "%s: status %d\n", __FUNCTION__, status);
 	if (status == 0)
 		udev->dev.power.power_state.event = msg.event;
 	return status;
@@ -839,7 +839,7 @@ static int resume_device(struct usb_devi
 	status = udriver->resume(udev);
 
 done:
-	// dev_dbg(&udev->dev, "%s: status %d\n", __FUNCTION__, status);
+	dev_dbg(&udev->dev, "%s: status %d\n", __FUNCTION__, status);
 	if (status == 0)
 		udev->dev.power.power_state.event = PM_EVENT_ON;
 	return status;
@@ -876,7 +876,7 @@ static int suspend_interface(struct usb_
 	}
 
 done:
-	// dev_dbg(&intf->dev, "%s: status %d\n", __FUNCTION__, status);
+	dev_dbg(&intf->dev, "%s: status %d\n", __FUNCTION__, status);
 	if (status == 0)
 		intf->dev.power.power_state.event = msg.event;
 	return status;
@@ -917,7 +917,7 @@ static int resume_interface(struct usb_i
 	}
 
 done:
-	// dev_dbg(&intf->dev, "%s: status %d\n", __FUNCTION__, status);
+	dev_dbg(&intf->dev, "%s: status %d\n", __FUNCTION__, status);
 	if (status == 0)
 		intf->dev.power.power_state.event = PM_EVENT_ON;
 	return status;
@@ -1021,7 +1021,7 @@ int usb_suspend_both(struct usb_device *
 	} else if (parent)
 		usb_autosuspend_device(parent, 0);
 
-	// dev_dbg(&udev->dev, "%s: status %d\n", __FUNCTION__, status);
+	dev_dbg(&udev->dev, "%s: status %d\n", __FUNCTION__, status);
 	return status;
 }
 
@@ -1079,11 +1079,12 @@ int usb_resume_both(struct usb_device *u
 					PM_EVENT_ON)
 				status = -EHOSTUNREACH;
 		}
-		if (status == 0 && udev->state == USB_STATE_SUSPENDED)
+		if (status == 0)
 			status = resume_device(udev);
 		if (parent)
 			mutex_unlock(&parent->pm_mutex);
-	}
+	} else
+		status = resume_device(udev);
 
 	/* Now the parent won't suspend until we are finished */
 
@@ -1094,7 +1095,7 @@ int usb_resume_both(struct usb_device *u
 		}
 	}
 
-	// dev_dbg(&udev->dev, "%s: status %d\n", __FUNCTION__, status);
+	dev_dbg(&udev->dev, "%s: status %d\n", __FUNCTION__, status);
 	return status;
 }
 
Index: mm/drivers/usb/core/hub.c
===================================================================
--- mm.orig/drivers/usb/core/hub.c
+++ mm/drivers/usb/core/hub.c
@@ -1898,6 +1898,8 @@ static int hub_suspend(struct usb_interf
 		if (bus) {
 			int	status = hcd_bus_suspend (bus);
 
+	dev_dbg(&hdev->dev, "bus_suspend %d\n", status);
+
 			if (status != 0) {
 				dev_dbg(&hdev->dev, "'global' suspend %d\n",
 					status);
@@ -1923,6 +1925,9 @@ static int hub_resume(struct usb_interfa
 		struct usb_bus	*bus = hdev->bus;
 		if (bus) {
 			status = hcd_bus_resume (bus);
+
+	dev_dbg(&hdev->dev, "bus_resume %d\n", status);
+
 			if (status) {
 				dev_dbg(&intf->dev, "'global' resume %d\n",
 					status);


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem
  2006-09-14 15:04                         ` Alan Stern
  2006-09-14 16:17                           ` Alan Stern
@ 2006-09-14 16:48                           ` Rafael J. Wysocki
  1 sibling, 0 replies; 114+ messages in thread
From: Rafael J. Wysocki @ 2006-09-14 16:48 UTC (permalink / raw)
  To: Alan Stern
  Cc: Andrew Morton, Mattia Dongili, Robert Hancock,
	Kernel development list, USB development list

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

On Thursday, 14 September 2006 17:04, Alan Stern wrote:
> On Thu, 14 Sep 2006, Rafael J. Wysocki wrote:
> 
> > > > Try adding some ehci_dbg() lines in there (copy the form of the line just
> > > > after restart:).  We want to follow the value of
> > > > hcd->self.root_hub->state.  Initially it should be equal to
> > > > USB_STATE_SUSPENDED (= 8), and it shouldn't change.  But somewhere it is
> > > > getting set to USB_STATE_CONFIGURED (= 7).  I don't know where, but almost 
> > > > certainly somewhere in this routine.  If you can find out where that 
> > > > happens, I'd appreciate it.
> > > 
> > > Done, but it shows hcd->self.root_hub->state is already 7 right after restart.
> > 
> > BTW, all of the systems on which the problem shows up seem to be 64-bit.
> > 
> > If you can't reproduce it on a 32-bit system, some type casting may be wrong
> > somewhere.
> 
> I realized last night what the problem must be.  It's extremely obvious in 
> retrospect, but I happen to have a blind spot in this particular area.
> 
> All you guys must have CONFIG_USB_SUSPEND turned off.  Mattis certainly 
> does; I checked his .config.  Now I hardly ever do any testing without 
> CONFIG_USB_SUSPEND, since there's not much point working on power 
> management code if your kernel isn't set up to actually suspend devices.
> As a result I missed seeing the problems caused by the autosuspend 
> changes.

Well, on my box the USB suspend also doesn't work with USB_SUSPEND set,
but the reason is different:

sb usb2: 'global' suspend -16
hub 2-0:1.0: suspend error -16
suspend_device(): usb_suspend+0x0/0x5b [usbcore]() returns -16
Could not suspend device usb2: error -16

The .config and full dmesg output (with the three debug patches applied) are
attached.

Greetings,
Rafael


-- 
You never change things by fighting the existing reality.
		R. Buckminster Fuller

[-- Attachment #2: dmesg-usb-suspend.log.gz --]
[-- Type: application/x-gzip, Size: 15471 bytes --]

[-- Attachment #3: kernel-config.gz --]
[-- Type: application/x-gzip, Size: 12931 bytes --]

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem
  2006-09-14 16:17                           ` Alan Stern
@ 2006-09-14 17:08                             ` Rafael J. Wysocki
  2006-09-14 17:13                               ` Rafael J. Wysocki
  2006-09-14 17:22                               ` Alan Stern
  0 siblings, 2 replies; 114+ messages in thread
From: Rafael J. Wysocki @ 2006-09-14 17:08 UTC (permalink / raw)
  To: Alan Stern
  Cc: Andrew Morton, Mattia Dongili, Robert Hancock,
	Kernel development list, USB development list

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

On Thursday, 14 September 2006 18:17, Alan Stern wrote:
> On Thu, 14 Sep 2006, Alan Stern wrote:
> 
> > Now of course, the autosuspend stuff has to work properly no matter what 
> > the kernel configuration is.  I'll go back and rebuild the drivers with 
> > USB_SUSPEND turned off and see what happens.  With any luck I'll have a 
> > fix ready in the near future.
> 
> This should start fixing things, but I'm not certain it will solve the 
> entire problem.  If it doesn't work, send another dmesg log.

Now USB didn't work after the first resume (kernel configured with USB_SUSPEND
unset).

The dmesg output is attached.

Rafael


-- 
You never change things by fighting the existing reality.
		R. Buckminster Fuller

[-- Attachment #2: dmesg-with-fix.log.gz --]
[-- Type: application/x-gzip, Size: 14301 bytes --]

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem
  2006-09-14 17:08                             ` Rafael J. Wysocki
@ 2006-09-14 17:13                               ` Rafael J. Wysocki
  2006-09-14 17:24                                 ` Alan Stern
  2006-09-14 17:22                               ` Alan Stern
  1 sibling, 1 reply; 114+ messages in thread
From: Rafael J. Wysocki @ 2006-09-14 17:13 UTC (permalink / raw)
  To: Alan Stern
  Cc: Andrew Morton, Mattia Dongili, Robert Hancock,
	Kernel development list, USB development list

On Thursday, 14 September 2006 19:08, Rafael J. Wysocki wrote:
> On Thursday, 14 September 2006 18:17, Alan Stern wrote:
> > On Thu, 14 Sep 2006, Alan Stern wrote:
> > 
> > > Now of course, the autosuspend stuff has to work properly no matter what 
> > > the kernel configuration is.  I'll go back and rebuild the drivers with 
> > > USB_SUSPEND turned off and see what happens.  With any luck I'll have a 
> > > fix ready in the near future.
> > 
> > This should start fixing things, but I'm not certain it will solve the 
> > entire problem.  If it doesn't work, send another dmesg log.
> 
> Now USB didn't work after the first resume (kernel configured with USB_SUSPEND
> unset).

Okay, this is not reproducible, so I gather it was due to my other problem
with the USB resume (sigh).

Anyway, the second suspend/resume worked just fine, so the patch apparently
helps.

Thanks,
Rafael


-- 
You never change things by fighting the existing reality.
		R. Buckminster Fuller

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem
  2006-09-14 17:08                             ` Rafael J. Wysocki
  2006-09-14 17:13                               ` Rafael J. Wysocki
@ 2006-09-14 17:22                               ` Alan Stern
  2006-09-14 17:35                                 ` Rafael J. Wysocki
  1 sibling, 1 reply; 114+ messages in thread
From: Alan Stern @ 2006-09-14 17:22 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Andrew Morton, Mattia Dongili, Robert Hancock,
	Kernel development list, USB development list

On Thu, 14 Sep 2006, Rafael J. Wysocki wrote:

> Now USB didn't work after the first resume (kernel configured with USB_SUSPEND
> unset).
> 
> The dmesg output is attached.

This is getting too confusing.  :-(

Let's try a simpler test.  Leave USB_SUSPEND unset.

First rmmod ohci-hcd.  None of your full-speed USB devices will work, but 
that's okay.  Try the suspend-twice test and see what happens.

Second, rmmod ehci-hcd and modprobe ohci-hcd.  Again try the suspend-twice 
test.

Having only one USB host driver loaded at any time should simplify things.

Alan Stern


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem
  2006-09-14 17:13                               ` Rafael J. Wysocki
@ 2006-09-14 17:24                                 ` Alan Stern
  0 siblings, 0 replies; 114+ messages in thread
From: Alan Stern @ 2006-09-14 17:24 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Andrew Morton, Mattia Dongili, Robert Hancock,
	Kernel development list, USB development list

On Thu, 14 Sep 2006, Rafael J. Wysocki wrote:

> Okay, this is not reproducible, so I gather it was due to my other problem
> with the USB resume (sigh).
> 
> Anyway, the second suspend/resume worked just fine, so the patch apparently
> helps.

Doing the simpler tests, with only one USB host driver at a time, is still 
the best way to go.  Once they both work with USB_SUSPEND turned off, 
we'll try them with USB_SUSPEND turned on.

Alan Stern


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem
  2006-09-14 17:22                               ` Alan Stern
@ 2006-09-14 17:35                                 ` Rafael J. Wysocki
  2006-09-14 18:28                                   ` Alan Stern
  0 siblings, 1 reply; 114+ messages in thread
From: Rafael J. Wysocki @ 2006-09-14 17:35 UTC (permalink / raw)
  To: Alan Stern
  Cc: Andrew Morton, Mattia Dongili, Robert Hancock,
	Kernel development list, USB development list

On Thursday, 14 September 2006 19:22, Alan Stern wrote:
> On Thu, 14 Sep 2006, Rafael J. Wysocki wrote:
> 
> > Now USB didn't work after the first resume (kernel configured with USB_SUSPEND
> > unset).
> > 
> > The dmesg output is attached.
> 
> This is getting too confusing.  :-(

Sorry for the confusion.

> Let's try a simpler test.  Leave USB_SUSPEND unset.
> 
> First rmmod ohci-hcd.  None of your full-speed USB devices will work, but 
> that's okay.  Try the suspend-twice test and see what happens.
> 
> Second, rmmod ehci-hcd and modprobe ohci-hcd.  Again try the suspend-twice 
> test.

Done, works (with USB_SUSPEND unset).

Greetings,
Rafael


-- 
You never change things by fighting the existing reality.
		R. Buckminster Fuller

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem
  2006-09-14 17:35                                 ` Rafael J. Wysocki
@ 2006-09-14 18:28                                   ` Alan Stern
       [not found]                                     ` <200609142137.52066.rjw@sisk.pl>
  0 siblings, 1 reply; 114+ messages in thread
From: Alan Stern @ 2006-09-14 18:28 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Andrew Morton, Mattia Dongili, Robert Hancock,
	Kernel development list, USB development list

On Thu, 14 Sep 2006, Rafael J. Wysocki wrote:

> > Let's try a simpler test.  Leave USB_SUSPEND unset.
> > 
> > First rmmod ohci-hcd.  None of your full-speed USB devices will work, but 
> > that's okay.  Try the suspend-twice test and see what happens.
> > 
> > Second, rmmod ehci-hcd and modprobe ohci-hcd.  Again try the suspend-twice 
> > test.
> 
> Done, works (with USB_SUSPEND unset).

Okay, good.  Then for the next stage, repeat the same tests but with 
USB_SUSPEND set.

Alan Stern


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem
  2006-09-13 20:54               ` Alan Stern
@ 2006-09-14 20:19                 ` Mattia Dongili
  2006-09-14 20:25                   ` Alan Stern
  0 siblings, 1 reply; 114+ messages in thread
From: Mattia Dongili @ 2006-09-14 20:19 UTC (permalink / raw)
  To: Alan Stern
  Cc: Rafael J. Wysocki, Andrew Morton, Kernel development list,
	USB development list

On Wed, Sep 13, 2006 at 04:54:13PM -0400, Alan Stern wrote:
> On Wed, 13 Sep 2006, Mattia Dongili wrote:
> 
> > > The patch below will add some extra debugging information.  We need to
> > > find out why the resume didn't succeed.  Oh -- and of course, you should
> > > reinstate all those autosuspend patches.  Otherwise this patch won't 
> > > apply!
> > 
> > ok, with USB_DEBUG=y and this is with your first patch still applied
> > http://oioio.altervista.org/linux/dmesg-2.6.18-rc6-mm1-verbose-usb-try2
> > 
> > this is without it:
> > http://oioio.altervista.org/linux/dmesg-2.6.18-rc6-mm1-verbose-usb-try3
> > 
> > I hope I'm not mixing thing too much with Rafael :)
> 
> No.  But this log doesn't include the debugging output in the patch from 
> my previous message.

doh! I'm pretty sure the patch is applied...
$ patch -p1 --dry-run < ../add_usb_debug.patch
patching file drivers/usb/core/driver.c
Reversed (or previously applied) patch detected!  Assume -R? [n]

Will try again with USB_SUSPEND=y, tomorrow I'll try to find some time
to test all the other things you suggested  (if still necessary) :)
-- 
mattia
:wq!

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem
       [not found]                                     ` <200609142137.52066.rjw@sisk.pl>
@ 2006-09-14 20:21                                       ` Rafael J. Wysocki
  2006-09-14 20:55                                       ` Alan Stern
  1 sibling, 0 replies; 114+ messages in thread
From: Rafael J. Wysocki @ 2006-09-14 20:21 UTC (permalink / raw)
  To: Alan Stern
  Cc: Andrew Morton, Mattia Dongili, Robert Hancock,
	Kernel development list, USB development list

On Thursday, 14 September 2006 21:37, Rafael J. Wysocki wrote:
> On Thursday, 14 September 2006 20:28, Alan Stern wrote:
> > On Thu, 14 Sep 2006, Rafael J. Wysocki wrote:
> > 
> > > > Let's try a simpler test.  Leave USB_SUSPEND unset.
> > > > 
> > > > First rmmod ohci-hcd.  None of your full-speed USB devices will work, but 
> > > > that's okay.  Try the suspend-twice test and see what happens.
> > > > 
> > > > Second, rmmod ehci-hcd and modprobe ohci-hcd.  Again try the suspend-twice 
> > > > test.
> > > 
> > > Done, works (with USB_SUSPEND unset).
> > 
> > Okay, good.
> 
> Well, sorry.  This test has been passed, but after a reboot it refused to
> suspend just once giving the same messages that I've got from the kernel
> with USB_SUSPEND set (the relevant dmesg output is attached).

This only happens if _both_ ohci_hcd and ehci_hcd are loaded before the
suspend.
 
> > Then for the next stage, repeat the same tests but with  
> > USB_SUSPEND set.
> 
> Compiling.

The results are now the same with and without USB_SUSPEND set.  Namely,
if one hcd is loaded before a suspend (either ehci or ohci), it succeeds
(repeatable arbitrary number of times in a row).  However, if both hcds are
loaded before a suspend, it fails (100% of the time) and the messages are
like in the dmesg output attached to the previous message.

I've reproduced this behavior on another x86_64 box.

Greetings,
Rafael


-- 
You never change things by fighting the existing reality.
		R. Buckminster Fuller

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem
  2006-09-14 20:19                 ` Mattia Dongili
@ 2006-09-14 20:25                   ` Alan Stern
  2006-09-14 20:35                     ` Mattia Dongili
  2006-09-16 11:58                     ` Mattia Dongili
  0 siblings, 2 replies; 114+ messages in thread
From: Alan Stern @ 2006-09-14 20:25 UTC (permalink / raw)
  To: Mattia Dongili
  Cc: Rafael J. Wysocki, Andrew Morton, Kernel development list,
	USB development list

On Thu, 14 Sep 2006, Mattia Dongili wrote:

> > No.  But this log doesn't include the debugging output in the patch from 
> > my previous message.
> 
> doh! I'm pretty sure the patch is applied...
> $ patch -p1 --dry-run < ../add_usb_debug.patch
> patching file drivers/usb/core/driver.c
> Reversed (or previously applied) patch detected!  Assume -R? [n]

Actually I was wrong to think the patch wasn't in there just because it
didn't produce any output.

> Will try again with USB_SUSPEND=y, tomorrow I'll try to find some time
> to test all the other things you suggested  (if still necessary) :)

No, don't do that.  Keep USB_SUSPEND=n, and try only the most recent patch
I sent to Rafael:

http://marc.theaimsgroup.com/?l=linux-kernel&m=115825076000987&w=2

I know for certain that some of Rafael's problems are different from 
yours, because his involve ehci-hcd and ohci-hcd whereas you have only 
UHCI controllers.

Alan Stern


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem
  2006-09-14 20:25                   ` Alan Stern
@ 2006-09-14 20:35                     ` Mattia Dongili
  2006-09-16 11:58                     ` Mattia Dongili
  1 sibling, 0 replies; 114+ messages in thread
From: Mattia Dongili @ 2006-09-14 20:35 UTC (permalink / raw)
  To: Alan Stern
  Cc: Rafael J. Wysocki, Andrew Morton, Kernel development list,
	USB development list

On Thu, Sep 14, 2006 at 04:25:26PM -0400, Alan Stern wrote:
> On Thu, 14 Sep 2006, Mattia Dongili wrote:
[...]
> > Will try again with USB_SUSPEND=y, tomorrow I'll try to find some time
> > to test all the other things you suggested  (if still necessary) :)
> 
> No, don't do that.  Keep USB_SUSPEND=n, and try only the most recent patch

damn! (hitting ctrl-c) :)

> I sent to Rafael:
> 
> http://marc.theaimsgroup.com/?l=linux-kernel&m=115825076000987&w=2
> 
> I know for certain that some of Rafael's problems are different from 
> yours, because his involve ehci-hcd and ohci-hcd whereas you have only 
> UHCI controllers.

ok, will do. But please allow some time (can go back to you tomorrow) as
I'm in low-spare-time-mode...

-- 
mattia
:wq!

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem
       [not found]                                     ` <200609142137.52066.rjw@sisk.pl>
  2006-09-14 20:21                                       ` Rafael J. Wysocki
@ 2006-09-14 20:55                                       ` Alan Stern
  2006-09-14 21:47                                         ` Rafael J. Wysocki
  1 sibling, 1 reply; 114+ messages in thread
From: Alan Stern @ 2006-09-14 20:55 UTC (permalink / raw)
  To: Rafael J. Wysocki, David Brownell
  Cc: Andrew Morton, Mattia Dongili, Robert Hancock,
	Kernel development list, USB development list

On Thu, 14 Sep 2006, Rafael J. Wysocki wrote:

> Well, sorry.  This test has been passed, but after a reboot it refused to
> suspend just once giving the same messages that I've got from the kernel
> with USB_SUSPEND set (the relevant dmesg output is attached).
> 
> > Then for the next stage, repeat the same tests but with  
> > USB_SUSPEND set.

Okay, hang on, let's try to solve this first.

This actually is a completely different problem from what I've been
attacking up to now, and we definitely should resolve it.  It's purely a
question of the ohci-hcd driver, nothing (or very little) to do with
usbcore or ehci-hcd or uhci-hcd.

I'm asking David to chime in, because this is his code and his driver.

Here's an explanation of the problem.  Basically it boils down to the way 
ohci-hcd rolls its own root-hub autosuspend.  I'm referring to the call to 
ohci_bus_suspend() near the end of ohci-hub.c:ohci_hub_status_data().
Things go wrong because that call totally bypasses usbcore.  It's a 
layering violation.

The corresponding root-hub autoresume code, i.e., the call to
usb_hcd_resume_root_hub() in ohci-hcd.c:ohci_irq(), _does_ go through
usbcore.  It fails for two reasons.  First, resume_root_hub does its job
by queuing a call to usb_autoresume_device(), and when CONFIG_USB_SUSPEND
isn't set that routine is a no-op.  Second, since usbcore was never
notified when the root hub was suspended, the root hub's device state
isn't USB_STATE_SUSPENED and the interface is still marked as active -- so
even if usb_autoresume_device() did get called it wouldn't do anything.

As I see it, there are two ways to resolve the problem.  The easiest is to
rip out the autosuspend stuff from ohci-hcd entirely.  When my generic
autosuspend patches are accepted, the HCD-specific stuff won't be needed
so much.  This has the disadvantage that the root hub will never get
suspended if CONFIG_USB_SUSPEND isn't set.  On the other hand, this is how 
ehci_hcd works already.

The second way is to copy what I did in uhci-hcd.  There is a special
"root hub is stopped" mode which kicks in only when no ports are
connected.  It isn't a full-fledged suspend, in the sense that usbcore
isn't notified -- just like what happens in ohci-hcd.  The difference is,
since we know no devices are attached, the driver can go back to normal
operation while in interrupt context.  It doesn't have to sleep because no
attached devices means no TRSMRCY delay is needed and the controller's
hardware can be reset directly.  As a result, the corresponding
"auto-restart" code doesn't need to go through usbcore either and so
usb_autoresume_device() never enters the picture.

I don't know if this is feasible with OHCI.  For now, I'll include a patch 
that takes the first approach and disables the ohci-hcd autosuspend 
entirely.  I think it will solve your problem above.

Alan Stern


Index: mm/drivers/usb/host/ohci-hub.c
===================================================================
--- mm.orig/drivers/usb/host/ohci-hub.c
+++ mm/drivers/usb/host/ohci-hub.c
@@ -391,17 +391,6 @@ ohci_hub_status_data (struct usb_hcd *hc
 done:
 	spin_unlock_irqrestore (&ohci->lock, flags);
 
-#ifdef	CONFIG_PM
-	/* save power by autosuspending idle root hubs;
-	 * INTR_RD wakes us when there's work
-	 */
-	if (can_suspend && usb_trylock_device (hcd->self.root_hub) == 0) {
-		ohci_vdbg (ohci, "autosuspend\n");
-		(void) ohci_bus_suspend (hcd);
-		usb_unlock_device (hcd->self.root_hub);
-	}
-#endif
-
 	return changed ? length : 0;
 }
 


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem
  2006-09-14 20:55                                       ` Alan Stern
@ 2006-09-14 21:47                                         ` Rafael J. Wysocki
  2006-09-14 22:19                                           ` Alan Stern
  0 siblings, 1 reply; 114+ messages in thread
From: Rafael J. Wysocki @ 2006-09-14 21:47 UTC (permalink / raw)
  To: Alan Stern
  Cc: David Brownell, Andrew Morton, Mattia Dongili, Robert Hancock,
	Kernel development list, USB development list

On Thursday, 14 September 2006 22:55, Alan Stern wrote:
> On Thu, 14 Sep 2006, Rafael J. Wysocki wrote:
> 
> > Well, sorry.  This test has been passed, but after a reboot it refused to
> > suspend just once giving the same messages that I've got from the kernel
> > with USB_SUSPEND set (the relevant dmesg output is attached).
> > 
> > > Then for the next stage, repeat the same tests but with  
> > > USB_SUSPEND set.
> 
> Okay, hang on, let's try to solve this first.
> 
> This actually is a completely different problem from what I've been
> attacking up to now, and we definitely should resolve it.  It's purely a
> question of the ohci-hcd driver, nothing (or very little) to do with
> usbcore or ehci-hcd or uhci-hcd.
> 
> I'm asking David to chime in, because this is his code and his driver.
> 
> Here's an explanation of the problem.  Basically it boils down to the way 
> ohci-hcd rolls its own root-hub autosuspend.  I'm referring to the call to 
> ohci_bus_suspend() near the end of ohci-hub.c:ohci_hub_status_data().
> Things go wrong because that call totally bypasses usbcore.  It's a 
> layering violation.
> 
> The corresponding root-hub autoresume code, i.e., the call to
> usb_hcd_resume_root_hub() in ohci-hcd.c:ohci_irq(), _does_ go through
> usbcore.  It fails for two reasons.  First, resume_root_hub does its job
> by queuing a call to usb_autoresume_device(), and when CONFIG_USB_SUSPEND
> isn't set that routine is a no-op.  Second, since usbcore was never
> notified when the root hub was suspended, the root hub's device state
> isn't USB_STATE_SUSPENED and the interface is still marked as active -- so
> even if usb_autoresume_device() did get called it wouldn't do anything.
> 
> As I see it, there are two ways to resolve the problem.  The easiest is to
> rip out the autosuspend stuff from ohci-hcd entirely.  When my generic
> autosuspend patches are accepted, the HCD-specific stuff won't be needed
> so much.  This has the disadvantage that the root hub will never get
> suspended if CONFIG_USB_SUSPEND isn't set.  On the other hand, this is how 
> ehci_hcd works already.

This isn't a big deal as far as I'm concerned, but I think that dependancy
will have to be reflected by some Kconfig rules (eg. if CONFIG_USB_SUSPEND
gets selected automatically if CONFIG_PM is set).

> The second way is to copy what I did in uhci-hcd.  There is a special
> "root hub is stopped" mode which kicks in only when no ports are
> connected.  It isn't a full-fledged suspend, in the sense that usbcore
> isn't notified -- just like what happens in ohci-hcd.  The difference is,
> since we know no devices are attached, the driver can go back to normal
> operation while in interrupt context.  It doesn't have to sleep because no
> attached devices means no TRSMRCY delay is needed and the controller's
> hardware can be reset directly.  As a result, the corresponding
> "auto-restart" code doesn't need to go through usbcore either and so
> usb_autoresume_device() never enters the picture.
> 
> I don't know if this is feasible with OHCI.  For now, I'll include a patch 
> that takes the first approach and disables the ohci-hcd autosuspend 
> entirely.  I think it will solve your problem above.

Yes it does.

Now I'm able to suspend/resume several times in a row with both
ohci and ehci hcds loaded all the time.  Thanks a lot!

Greetings,
Rafael


-- 
You never change things by fighting the existing reality.
		R. Buckminster Fuller

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem
  2006-09-14 21:47                                         ` Rafael J. Wysocki
@ 2006-09-14 22:19                                           ` Alan Stern
  0 siblings, 0 replies; 114+ messages in thread
From: Alan Stern @ 2006-09-14 22:19 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: David Brownell, Andrew Morton, Mattia Dongili, Robert Hancock,
	Kernel development list, USB development list

On Thu, 14 Sep 2006, Rafael J. Wysocki wrote:

> > As I see it, there are two ways to resolve the problem.  The easiest is to
> > rip out the autosuspend stuff from ohci-hcd entirely.  When my generic
> > autosuspend patches are accepted, the HCD-specific stuff won't be needed
> > so much.  This has the disadvantage that the root hub will never get
> > suspended if CONFIG_USB_SUSPEND isn't set.  On the other hand, this is how 
> > ehci_hcd works already.
> 
> This isn't a big deal as far as I'm concerned, but I think that dependancy
> will have to be reflected by some Kconfig rules (eg. if CONFIG_USB_SUSPEND
> gets selected automatically if CONFIG_PM is set).

Ultimately the best thing will be for CONFIG_USB_SUSPEND simply to 
disappear.  That's the long-term goal.  It was never intended to be much 
more than a stop-gap setting, for use while the USB suspend/resume 
routines were under development and not entirely reliable.

> > I don't know if this is feasible with OHCI.  For now, I'll include a patch 
> > that takes the first approach and disables the ohci-hcd autosuspend 
> > entirely.  I think it will solve your problem above.
> 
> Yes it does.
> 
> Now I'm able to suspend/resume several times in a row with both
> ohci and ehci hcds loaded all the time.  Thanks a lot!

You're welcome.

I'll wait to hear Dave's comments before submitting this.

Alan Stern


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem
  2006-09-14 20:25                   ` Alan Stern
  2006-09-14 20:35                     ` Mattia Dongili
@ 2006-09-16 11:58                     ` Mattia Dongili
  2006-09-16 14:31                       ` Alan Stern
  1 sibling, 1 reply; 114+ messages in thread
From: Mattia Dongili @ 2006-09-16 11:58 UTC (permalink / raw)
  To: Alan Stern
  Cc: Rafael J. Wysocki, Andrew Morton, Kernel development list,
	USB development list

On Thu, Sep 14, 2006 at 04:25:26PM -0400, Alan Stern wrote:
> On Thu, 14 Sep 2006, Mattia Dongili wrote:
[...]
> > Will try again with USB_SUSPEND=y, tomorrow I'll try to find some time
> > to test all the other things you suggested  (if still necessary) :)
> 
> No, don't do that.  Keep USB_SUSPEND=n, and try only the most recent patch
> I sent to Rafael:
> 
> http://marc.theaimsgroup.com/?l=linux-kernel&m=115825076000987&w=2
> 
> I know for certain that some of Rafael's problems are different from 
> yours, because his involve ehci-hcd and ohci-hcd whereas you have only 
> UHCI controllers.

Yay! this patch fixes the issue. It already survived 3 susp/resume
cycles.
Log is here:
http://oioio.altervista.org/linux/dmesg-2.6.18-rc6-mm1-usb-susp

Do you want to see a test run with USB_SUSPEND=y? (well I'll try it out
anyway)

Thanks again
PS: sadly spamcop has my provider in its blacklists, linux-usb-devel
didn't receive any of my mails...
-- 
mattia
:wq!

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem
  2006-09-16 11:58                     ` Mattia Dongili
@ 2006-09-16 14:31                       ` Alan Stern
  0 siblings, 0 replies; 114+ messages in thread
From: Alan Stern @ 2006-09-16 14:31 UTC (permalink / raw)
  To: Mattia Dongili
  Cc: Rafael J. Wysocki, Andrew Morton, Kernel development list,
	USB development list

On Sat, 16 Sep 2006, Mattia Dongili wrote:

> Yay! this patch fixes the issue. It already survived 3 susp/resume
> cycles.
> Log is here:
> http://oioio.altervista.org/linux/dmesg-2.6.18-rc6-mm1-usb-susp
> 
> Do you want to see a test run with USB_SUSPEND=y? (well I'll try it out
> anyway)

Then so far it looks good...  I'll submit this patch early next week.

Alan Stern


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: 2.6.18-rc6-mm1
  2006-09-13  4:54   ` 2.6.18-rc6-mm1 Neil Brown
@ 2006-09-16 14:10     ` Magnus Määttä
  0 siblings, 0 replies; 114+ messages in thread
From: Magnus Määttä @ 2006-09-16 14:10 UTC (permalink / raw)
  To: Neil Brown; +Cc: Andrew Morton, linux-kernel

Hi,

Sorry for the late reply, been away a few days.

On Wednesday 13 September 2006 06:54, Neil Brown wrote:
> On Saturday September 9, akpm@osdl.org wrote:
> > On Sat, 9 Sep 2006 14:45:32 +0200
> > Magnus Määttä <novell@kiruna.se> wrote:
> > > [15164.017991] RPC request reserved 9136 but used 9268
> > > [15164.037431] RPC request reserved 9136 but used 9268
> > > [15164.052988] RPC request reserved 9136 but used 9268
> > > 
> 
> Don't know what is causing this yet....
> 
> > > Using defaults from ksymoops -t elf32-i386 -a i386
> > > EFLAGS: 00210212   (2.6.18-rc6-mm1 #1)
> > > eax: 00000000   ebx: e5299000   ecx: 00000000   edx: e8843620
> ..
> > >  [<c02784ba>] nfsd+0x18a/0x2b0
> > >  [<c0103fb7>] kernel_thread_helper+0x7/0x10
> > > Code: 89 45 e8 8b 52 28 83 c6 70 89 55 e4 8b 40 04 83 f8 17 0f 86 6d 
> > > 04 00 00 8b 5d 08 8b 83 9c 04 00 00 c7 83 a0 04 00 00 01 00 00 00 
> > > <8b> 00 89 04 24 e8 06 d4 ca ff c7 46 04 00 00 00 00 89 c1 89 43
> > > 
> > > 
> > > >>EIP; c04ad300 <svc_process+40/6a0>   <=====
> 
> But this is probably fixed by the following patch.
> Can you confirm?

Yes, the patch fixed it, thanks!


Regards,
Magnus

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: 2.6.18-rc6-mm1
  2006-09-09 18:27 ` 2.6.18-rc6-mm1 Andrew Morton
  2006-09-10  0:37   ` 2.6.18-rc6-mm1 Magnus Määttä
@ 2006-09-13  4:54   ` Neil Brown
  2006-09-16 14:10     ` 2.6.18-rc6-mm1 Magnus Määttä
  1 sibling, 1 reply; 114+ messages in thread
From: Neil Brown @ 2006-09-13  4:54 UTC (permalink / raw)
  To: Andrew Morton; +Cc: Magnus Määttä, linux-kernel

On Saturday September 9, akpm@osdl.org wrote:
> On Sat, 9 Sep 2006 14:45:32 +0200
> Magnus Määttä <novell@kiruna.se> wrote:
> > [15164.017991] RPC request reserved 9136 but used 9268
> > [15164.037431] RPC request reserved 9136 but used 9268
> > [15164.052988] RPC request reserved 9136 but used 9268
> > 

Don't know what is causing this yet....

> > Using defaults from ksymoops -t elf32-i386 -a i386
> > EFLAGS: 00210212   (2.6.18-rc6-mm1 #1)
> > eax: 00000000   ebx: e5299000   ecx: 00000000   edx: e8843620
..
> >  [<c02784ba>] nfsd+0x18a/0x2b0
> >  [<c0103fb7>] kernel_thread_helper+0x7/0x10
> > Code: 89 45 e8 8b 52 28 83 c6 70 89 55 e4 8b 40 04 83 f8 17 0f 86 6d 
> > 04 00 00 8b 5d 08 8b 83 9c 04 00 00 c7 83 a0 04 00 00 01 00 00 00 
> > <8b> 00 89 04 24 e8 06 d4 ca ff c7 46 04 00 00 00 00 89 c1 89 43
> > 
> > 
> > >>EIP; c04ad300 <svc_process+40/6a0>   <=====

But this is probably fixed by the following patch.
Can you confirm?


thanks,
NeilBrown

Signed-off-by: Neil Brown <neilb@suse.de>

### Diffstat output
 ./net/sunrpc/svcsock.c |    1 +
 1 file changed, 1 insertion(+)

diff .prev/net/sunrpc/svcsock.c ./net/sunrpc/svcsock.c
--- .prev/net/sunrpc/svcsock.c	2006-09-13 14:48:05.000000000 +1000
+++ ./net/sunrpc/svcsock.c	2006-09-13 14:48:14.000000000 +1000
@@ -1709,6 +1709,7 @@ static int svc_deferred_recv(struct svc_
 	rqstp->rq_prot        = dr->prot;
 	rqstp->rq_addr        = dr->addr;
 	rqstp->rq_daddr       = dr->daddr;
+	rqstp->rq_respages    = rqstp->rq_pages;
 	return dr->argslen<<2;
 }
 

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: 2.6.18-rc6-mm1
  2006-09-11 21:56 2.6.18-rc6-mm1 Chuck Ebbert
@ 2006-09-11 22:35 ` Andrew Morton
  0 siblings, 0 replies; 114+ messages in thread
From: Andrew Morton @ 2006-09-11 22:35 UTC (permalink / raw)
  To: Chuck Ebbert; +Cc: linux-kernel

On Mon, 11 Sep 2006 17:56:26 -0400
Chuck Ebbert <76306.1226@compuserve.com> wrote:

> In-Reply-To: <20060911102328.861a64b3.akpm@osdl.org>
> 
> On Mon, 11 Sep 2006 10:23:28 -0700, Andrew Morton wrote:
> 
> > wget ftp://ftp.kernel.org/pub/linux/kernel/v2.6/testing/linux-2.6.18-rc6.tar.bz2
> > wget ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc6/2.6.18-rc6-mm1/2.6.18-rc6-mm1-broken-out.tar.gz
> > box:/home/akpm> mkdir aa
> > box:/home/akpm> cd aa
> > box:/home/akpm/aa> tar xfj ../linux-2.6.18-rc6.tar.bz2 
> > box:/home/akpm/aa> cd linux-2.6.18-rc6 
> > box:/home/akpm/aa/linux-2.6.18-rc6> tar xfz ../../2.6.18-rc6-mm1-broken-out.tar.gz
> > box:/home/akpm/aa/linux-2.6.18-rc6> mv broken-out patches
> > box:/home/akpm/aa/linux-2.6.18-rc6> quilt push -a > /dev/null
> > box:/home/akpm/aa/linux-2.6.18-rc6> quilt applied | wc -l
> > 1835
> 
> I found the problem:
> 
> $ set | fgrep QUILT
> QUILT_DIFF_OPTS=-p
> QUILT_PATCH_OPTS=--fuzz=0
>                  ^^^^^^^^
> 
> Your patchset does have conflicts -- you're just ignoring them
> by accepting fuzz (and patch hunks can even end up being applied
> at the wrong place.)
> 

Sure.  The -mm queue always has large amount of fuzz.  Lots and lots.  I'll
occasionally go and rediff the fuzzy patches to clean things up, but that
involves pointlessly incrementing the local version number on 200-300
patches, which I prefer to avoid.

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: 2.6.18-rc6-mm1
@ 2006-09-11 21:56 Chuck Ebbert
  2006-09-11 22:35 ` 2.6.18-rc6-mm1 Andrew Morton
  0 siblings, 1 reply; 114+ messages in thread
From: Chuck Ebbert @ 2006-09-11 21:56 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel

In-Reply-To: <20060911102328.861a64b3.akpm@osdl.org>

On Mon, 11 Sep 2006 10:23:28 -0700, Andrew Morton wrote:

> wget ftp://ftp.kernel.org/pub/linux/kernel/v2.6/testing/linux-2.6.18-rc6.tar.bz2
> wget ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc6/2.6.18-rc6-mm1/2.6.18-rc6-mm1-broken-out.tar.gz
> box:/home/akpm> mkdir aa
> box:/home/akpm> cd aa
> box:/home/akpm/aa> tar xfj ../linux-2.6.18-rc6.tar.bz2 
> box:/home/akpm/aa> cd linux-2.6.18-rc6 
> box:/home/akpm/aa/linux-2.6.18-rc6> tar xfz ../../2.6.18-rc6-mm1-broken-out.tar.gz
> box:/home/akpm/aa/linux-2.6.18-rc6> mv broken-out patches
> box:/home/akpm/aa/linux-2.6.18-rc6> quilt push -a > /dev/null
> box:/home/akpm/aa/linux-2.6.18-rc6> quilt applied | wc -l
> 1835

I found the problem:

$ set | fgrep QUILT
QUILT_DIFF_OPTS=-p
QUILT_PATCH_OPTS=--fuzz=0
                 ^^^^^^^^

Your patchset does have conflicts -- you're just ignoring them
by accepting fuzz (and patch hunks can even end up being applied
at the wrong place.)

-- 
Chuck


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: 2.6.18-rc6-mm1
  2006-09-11 12:41 2.6.18-rc6-mm1 Chuck Ebbert
@ 2006-09-11 17:23 ` Andrew Morton
  0 siblings, 0 replies; 114+ messages in thread
From: Andrew Morton @ 2006-09-11 17:23 UTC (permalink / raw)
  To: Chuck Ebbert; +Cc: linux-kernel

On Mon, 11 Sep 2006 08:41:02 -0400
Chuck Ebbert <76306.1226@compuserve.com> wrote:

> In-Reply-To: <20060910221421.1aeac3c9.akpm@osdl.org>
> 
> On Sun, 10 Sep 2006 22:14:21 -0700, Andrew Morton wrote:
> 
> > > Patch gregkh-driver-pm-pci-and-ide-handle-pm_event_prethaw.patch does not apply (enforce with -f)
> >
> > It works for me - I expect your tree is out of sync.
> 
> Well something is out of sync but I don't think it's me.

Beats me, sorry.

wget ftp://ftp.kernel.org/pub/linux/kernel/v2.6/testing/linux-2.6.18-rc6.tar.bz2
wget ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc6/2.6.18-rc6-mm1/2.6.18-rc6-mm1-broken-out.tar.gz
box:/home/akpm> mkdir aa
box:/home/akpm> cd aa
box:/home/akpm/aa> tar xfj ../linux-2.6.18-rc6.tar.bz2 
box:/home/akpm/aa> cd linux-2.6.18-rc6 
box:/home/akpm/aa/linux-2.6.18-rc6> tar xfz ../../2.6.18-rc6-mm1-broken-out.tar.gz
box:/home/akpm/aa/linux-2.6.18-rc6> mv broken-out patches
box:/home/akpm/aa/linux-2.6.18-rc6> quilt push -a > /dev/null
box:/home/akpm/aa/linux-2.6.18-rc6> quilt applied | wc -l
1835

box:/home/akpm/aa/linux-2.6.18-rc6> quilt --version
0.45

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: 2.6.18-rc6-mm1
@ 2006-09-11 12:41 Chuck Ebbert
  2006-09-11 17:23 ` 2.6.18-rc6-mm1 Andrew Morton
  0 siblings, 1 reply; 114+ messages in thread
From: Chuck Ebbert @ 2006-09-11 12:41 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel

In-Reply-To: <20060910221421.1aeac3c9.akpm@osdl.org>

On Sun, 10 Sep 2006 22:14:21 -0700, Andrew Morton wrote:

> > Patch gregkh-driver-pm-pci-and-ide-handle-pm_event_prethaw.patch does not apply (enforce with -f)
>
> It works for me - I expect your tree is out of sync.

Well something is out of sync but I don't think it's me.

Starting over with GPG-verified downloads from kernel.org I get:

$ tar xjf /mnt/t/lib/linux/2.6.17/linux-2.6.17.tar.bz2
$ cd linux-2.6.17
$ bzcat /mnt/t/lib/linux/2.6.18/rc6/patch-2.6.18-rc6.bz2 | patch -p1 -s
$ tar xjf /mnt/t/lib/linux/2.6.18/rc6/mm1/2.6.18-rc6-mm1-broken-out.tar.bz2
$ mv broken-out patches
$ quilt push -a
[...]
Applying patch gregkh-driver-pm-pci-and-ide-handle-pm_event_prethaw.patch
patching file drivers/ide/ide.c
Hunk #2 FAILED at 1221.
1 out of 2 hunks FAILED -- rejects in file drivers/ide/ide.c
patching file drivers/pci/pci.c
Patch gregkh-driver-pm-pci-and-ide-handle-pm_event_prethaw.patch does not apply
(enforce with -f)

And like I said, you can even see that git-block.patch, earlier in the series,
creates this problem:

$ quilt applied | fgrep block
git-block.patch
git-block-hack.patch

This is the failing hunk.  The highlighted context line is wrong because
git-block.patch changed it:

--- gregkh-2.6.orig/drivers/ide/ide.c
+++ gregkh-2.6/drivers/ide/ide.c
@@ -1207,7 +1207,7 @@ int system_bus_clock (void)

 EXPORT_SYMBOL(system_bus_clock);

-static int generic_ide_suspend(struct device *dev, pm_message_t state)
+static int generic_ide_suspend(struct device *dev, pm_message_t mesg)
 {
        ide_drive_t *drive = dev->driver_data;
        struct request rq;
@@ -1221,7 +1221,9 @@ static int generic_ide_suspend(struct de
        rq.special = &args;
        rq.end_io_data = &rqpm;                         <===================
        rqpm.pm_step = ide_pm_state_start_suspend;
-       rqpm.pm_state = state.event;
+       if (mesg.event == PM_EVENT_PRETHAW)
+               mesg.event = PM_EVENT_FREEZE;
+       rqpm.pm_state = mesg.event;

        return ide_do_drive_cmd(drive, &rq, ide_wait);
 }

And here is the piece of git-block.patch that changed it:

--- a/drivers/ide/ide.c
+++ b/drivers/ide/ide.c
@@ -1217,9 +1217,9 @@ static int generic_ide_suspend(struct de
        memset(&rq, 0, sizeof(rq));
        memset(&rqpm, 0, sizeof(rqpm));
        memset(&args, 0, sizeof(args));
-       rq.flags = REQ_PM_SUSPEND;
+       rq.cmd_type = REQ_TYPE_PM_SUSPEND;
        rq.special = &args;
-       rq.end_io_data = &rqpm;
+       rq.data = &rqpm;                                <===================
        rqpm.pm_step = ide_pm_state_start_suspend;
        rqpm.pm_state = state.event;

-- 
Chuck

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: 2.6.18-rc6-mm1
  2006-09-11  2:34 2.6.18-rc6-mm1 Chuck Ebbert
@ 2006-09-11  5:14 ` Andrew Morton
  0 siblings, 0 replies; 114+ messages in thread
From: Andrew Morton @ 2006-09-11  5:14 UTC (permalink / raw)
  To: Chuck Ebbert; +Cc: linux-kernel

On Sun, 10 Sep 2006 22:34:33 -0400
Chuck Ebbert <76306.1226@compuserve.com> wrote:

> On Fri, 8 Sep 2006 01:13:17 -0700, Andrew Morton wrote:
> 
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc6/2.6.18-rc6-mm1/
> 
> $ cd 2.6.18-rc6-mm1
> $ tar xjf 2.6.18-rc6-mm1-broken-out.tar.bz2
> $ mv broken-out patches
> $ quilt push -a
> ...
> Applying patch gregkh-driver-pm-pci-and-ide-handle-pm_event_prethaw.patch
> patching file drivers/ide/ide.c
> Hunk #2 FAILED at 1221.
> 1 out of 2 hunks FAILED -- rejects in file drivers/ide/ide.c
> patching file drivers/pci/pci.c
> Patch gregkh-driver-pm-pci-and-ide-handle-pm_event_prethaw.patch does not apply (enforce with -f)

It works for me - I expect your tree is out of sync.

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: 2.6.18-rc6-mm1
@ 2006-09-11  2:34 Chuck Ebbert
  2006-09-11  5:14 ` 2.6.18-rc6-mm1 Andrew Morton
  0 siblings, 1 reply; 114+ messages in thread
From: Chuck Ebbert @ 2006-09-11  2:34 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel

In-Reply-To: <20060908011317.6cb0495a.akpm@osdl.org>

On Fri, 8 Sep 2006 01:13:17 -0700, Andrew Morton wrote:

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

$ cd 2.6.18-rc6-mm1
$ tar xjf 2.6.18-rc6-mm1-broken-out.tar.bz2
$ mv broken-out patches
$ quilt push -a
...
Applying patch gregkh-driver-pm-pci-and-ide-handle-pm_event_prethaw.patch
patching file drivers/ide/ide.c
Hunk #2 FAILED at 1221.
1 out of 2 hunks FAILED -- rejects in file drivers/ide/ide.c
patching file drivers/pci/pci.c
Patch gregkh-driver-pm-pci-and-ide-handle-pm_event_prethaw.patch does not apply (enforce with -f)


git-block.patch (applied earlier) has this:

--- a/drivers/ide/ide.c
+++ b/drivers/ide/ide.c
@@ -1217,9 +1217,9 @@ static int generic_ide_suspend(struct de
        memset(&rq, 0, sizeof(rq));
        memset(&rqpm, 0, sizeof(rqpm));
        memset(&args, 0, sizeof(args));
-       rq.flags = REQ_PM_SUSPEND;
+       rq.cmd_type = REQ_TYPE_PM_SUSPEND;
        rq.special = &args;
-       rq.end_io_data = &rqpm;                       <=================
+       rq.data = &rqpm;                              <=================
        rqpm.pm_step = ide_pm_state_start_suspend;
        rqpm.pm_state = state.event;


which conflicts with this chunk in the failing patch:

@@ -1221,7 +1221,9 @@ static int generic_ide_suspend(struct de
        rq.special = &args;
        rq.end_io_data = &rqpm;                       <=================
        rqpm.pm_step = ide_pm_state_start_suspend;
-       rqpm.pm_state = state.event;
+       if (mesg.event == PM_EVENT_PRETHAW)
+               mesg.event = PM_EVENT_FREEZE;
+       rqpm.pm_state = mesg.event;

        return ide_do_drive_cmd(drive, &rq, ide_wait);
 }


I fixed that, but then...

Applying patch git-gfs2.patch
patching file CREDITS
patching file Documentation/filesystems/gfs2.txt
patching file MAINTAINERS
patching file fs/Kconfig
Hunk #1 succeeded at 325 (offset 2 lines).
Hunk #2 FAILED at 1933.
1 out of 2 hunks FAILED -- rejects in file fs/Kconfig

-- 
Chuck


^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: 2.6.18-rc6-mm1
  2006-09-10  5:35     ` 2.6.18-rc6-mm1 Andrew Morton
@ 2006-09-10 10:22       ` Magnus Määttä
  0 siblings, 0 replies; 114+ messages in thread
From: Magnus Määttä @ 2006-09-10 10:22 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel, Neil Brown

On Sunday 10 September 2006 07:35, Andrew Morton wrote:
> On Sun, 10 Sep 2006 02:37:51 +0200
> Magnus Määttä <novell@kiruna.se> wrote:
> 
> > > > EIP:    0060:[<c04ad300>]    Tainted: P      VLI
> > >
> > > What caused the taint?
> > 
> > I was pretty sure it was listed somewhere, but I guess it wasn't.
> > nvidia graphics module, I can try without it tomorrow if needed.
> > 
> 
> That would be appreciated thanks.
> 
> But first you'd need to ensure that it's a repeatable oops.  If
> it's not, the removing the nvidia driver won't tell us if the nvidia
> driver caused it.  (It almost certainly didn't).

Forgot to mention that I had this (well, I'm not 100% it was exactly the
same) oops with 2.6.18-rc5-mm1.

Here is the oops with an untainted kernel:

[  161.078154] BUG: unable to handle kernel NULL pointer dereference at virtual address 00000000
[  161.104908]  printing eip:
[  161.133157] c04ad300
[  161.158755] *pde = 00000000
[  161.186042] Oops: 0000 [#2]
[  161.212933] 4K_STACKS PREEMPT
[  161.240791] last sysfs file: /class/input/input1/name
[  161.274954] Modules linked in: snd_seq_midi snd_seq_oss ipaq usbserial eeprom snd_seq_dummy snd_pcm_oss snd_mixer_oss snd_emu10k1_synth snd_emux_synth snd_seq_virmidi snd_seq_midi_event snd_seq_midi_emul snd_seq snd_emu10k1 snd_rawmidi snd_ac97_codec snd_ac97_bus snd_pcm snd_seq_device snd_page_alloc snd_util_mem snd_hwdep psmouse
[  161.428307] CPU:    0
[  161.428308] EIP:    0060:[<c04ad300>]    Not tainted VLI
[  161.428310] EFLAGS: 00010216   (2.6.18-rc6-mm1 #1)
[  161.531660] EIP is at svc_process+0x40/0x6a0
[  161.566957] eax: 00000000   ebx: eaf8c000   ecx: 00000000   edx: ead74d40
[  161.610544] esi: eaf8c070   edi: ffff5225   ebp: eaf93fb0   esp: eaf93f70
[  161.654260] ds: 007b   es: 007b   ss: 0068
[  161.689932] Process nfsd (pid: 4655, ti=eaf93000 task=eaf9caa0 task.ti=eaf93000)
[  161.712308] Stack: 00000046 eeedefe0 00000001 eeedefc4 00000000 eaf93f9c c04eaa1b eeedefc4
[  161.762411]        00000001 ead74d40 eaf8c04c eaf93fb0 c012d70b 00000000 ffff5226 ffff5225
[  161.812643]        eaf93fe0 c02784ba eaf8c000 eaf93fc4 00000000 fffffeff ffffffff fffffef8
[  161.862772] Call Trace:
[  161.917732]  [<c01041bf>] show_trace_log_lvl+0x2f/0x50
[  161.956879]  [<c01042a7>] show_stack_log_lvl+0x97/0xc0
[  161.995482]  [<c0104532>] show_registers+0x1f2/0x2a0
[  162.033228]  [<c01047dd>] die+0x12d/0x240
[  162.067860]  [<c011735c>] do_page_fault+0x3ac/0x650
[  162.104983]  [<c04eaeef>] error_code+0x3f/0x44
[  162.140705]  [<c02784ba>] nfsd+0x18a/0x2b0
[  162.175232]  [<c0103fb7>] kernel_thread_helper+0x7/0x10
[  162.213210]  =======================
[  162.246050] Code: 89 45 e8 8b 52 28 83 c6 70 89 55 e4 8b 40 04 83 f8 17 0f 86 6d 04 00 00 8b 5d 08 8b 83 9c 04 00 00 c7 83 a0 04 00 00 01 00 00 00 <8b> 00 89 04 24 e8 06 d4 ca ff c7 46 04 00 00 00 00 89 c1 89 43
[  162.354045] EIP: [<c04ad300>] svc_process+0x40/0x6a0 SS:ESP 0068:eaf93f70


And oops #1 just in case it's not unrelated (and the BUG just after it):
[  105.928488] BUG: unable to handle kernel paging request at virtual address b79505a0
[  105.928503]  printing eip:
[  105.928506] c013d14c
[  105.928509] *pde = 2d268067
[  105.928511] *pte = 00000000
[  105.928518] Oops: 0000 [#1]
[  105.952628] 4K_STACKS PREEMPT
[  105.977498] last sysfs file: /class/input/input1/name
[  106.008548] Modules linked in: snd_seq_midi snd_seq_oss ipaq usbserial eeprom snd_seq_dummy snd_pcm_oss snd_mixer_oss snd_emu10k1_synth snd_emux_synth snd_seq_virmidi snd_seq_midi_event snd_seq_midi_emul snd_seq snd_emu10k1 snd_rawmidi snd_ac97_codec snd_ac97_bus snd_pcm snd_seq_device snd_page_alloc snd_util_mem snd_hwdep psmouse
[  106.150657] CPU:    0
[  106.150658] EIP:    0060:[<c013d14c>]    Not tainted VLI
[  106.150660] EFLAGS: 00010002   (2.6.18-rc6-mm1 #1)
[  106.241322] EIP is at trace_hardirqs_on+0x1c/0x150
[  106.273081] eax: 00000001   ebx: b794fba0   ecx: b794f2e0   edx: b7f61410
[  106.310907] esi: 00000008   edi: b7c08ff4   ebp: eee0dfa4   esp: eee0df8c
[  106.348781] ds: 007b   es: 007b   ss: 0068
[  106.378378] Process icecast (pid: 4446, ti=eee0d000 task=ee9d0050 task.ti=eee0d000)
[  106.401560] Stack: eee0df9c 00000046 00000000 00000000 00000000 00000008 00000000 c01033ba
[  106.445119]        b7f61410 b794f2e0 00000000 00000000 b794f3b0 00000000 00000008 b7c08ff4
[  106.489043]        b794f388 00000000 0000007b 0000007b 00000033 000000af b7f61410 00000073
[  106.533124] Call Trace:
[  106.576870]  [<c01041bf>] show_trace_log_lvl+0x2f/0x50
[  106.610486]  [<c01042a7>] show_stack_log_lvl+0x97/0xc0
[  106.643976]  [<c0104532>] show_registers+0x1f2/0x2a0
[  106.676895]  [<c01047dd>] die+0x12d/0x240
[  106.707110]  [<c011735c>] do_page_fault+0x3ac/0x650
[  106.740133]  [<c04eaeef>] error_code+0x3f/0x44
[  106.771908]  [<c01033ba>] sysenter_past_esp+0x93/0x99
[  106.805629]  =======================
[  106.834887] Code: c7 05 94 9a 8b c0 01 00 00 00 89 e5 c9 c3 90 55 89 e5 56 53 83 ec 10 a1 a0 29 63 c0 65 8b 1d 00 00 00 00 85 c0 0f 84 89 00 00 00 <8b> b3 00 0a 00 00 85 f6 75 7f 8b 0d 94 9a 8b c0 85 c9 0f 84 96

[  106.978502]  <3>BUG: sleeping function called from invalid context at kernel/rwsem.c:20
[  107.023854] in_atomic():0, irqs_disabled():1
[  107.058071]  [<c01041bf>] show_trace_log_lvl+0x2f/0x50
[  107.095140]  [<c0104207>] show_trace+0x27/0x30
[  107.129851]  [<c0104334>] dump_stack+0x24/0x30
[  107.164377]  [<c011d442>] __might_sleep+0xa2/0xc0
[  107.199995]  [<c013949e>] down_read+0x1e/0x60
[  107.234807]  [<c012e9b7>] blocking_notifier_call_chain+0x17/0x50
[  107.275150]  [<c0121881>] profile_task_exit+0x21/0x30
[  107.312713]  [<c012327b>] do_exit+0x1b/0x520
[  107.348071]  [<c01048e5>] die+0x235/0x240
[  107.382754]  [<c011735c>] do_page_fault+0x3ac/0x650
[  107.419931]  [<c04eaeef>] error_code+0x3f/0x44
[  107.455575]  [<c01033ba>] sysenter_past_esp+0x93/0x99
[  107.492825]  =======================

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: 2.6.18-rc6-mm1
  2006-09-10  0:37   ` 2.6.18-rc6-mm1 Magnus Määttä
@ 2006-09-10  5:35     ` Andrew Morton
  2006-09-10 10:22       ` 2.6.18-rc6-mm1 Magnus Määttä
  0 siblings, 1 reply; 114+ messages in thread
From: Andrew Morton @ 2006-09-10  5:35 UTC (permalink / raw)
  To: Magnus Määttä; +Cc: linux-kernel, Neil Brown

On Sun, 10 Sep 2006 02:37:51 +0200
Magnus Määttä <novell@kiruna.se> wrote:

> > > EIP:    0060:[<c04ad300>]    Tainted: P      VLI
> >
> > What caused the taint?
> 
> I was pretty sure it was listed somewhere, but I guess it wasn't.
> nvidia graphics module, I can try without it tomorrow if needed.
> 

That would be appreciated thanks.

But first you'd need to ensure that it's a repeatable oops.  If
it's not, the removing the nvidia driver won't tell us if the nvidia
driver caused it.  (It almost certainly didn't).

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: 2.6.18-rc6-mm1
  2006-09-09 18:27 ` 2.6.18-rc6-mm1 Andrew Morton
@ 2006-09-10  0:37   ` Magnus Määttä
  2006-09-10  5:35     ` 2.6.18-rc6-mm1 Andrew Morton
  2006-09-13  4:54   ` 2.6.18-rc6-mm1 Neil Brown
  1 sibling, 1 reply; 114+ messages in thread
From: Magnus Määttä @ 2006-09-10  0:37 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel, Neil Brown

Hi again!

On Saturday 09 September 2006 20:27, Andrew Morton wrote:
> On Sat, 9 Sep 2006 14:45:32 +0200
>
> Magnus Määttä <novell@kiruna.se> wrote:

> > I got this oops on my machine when I ran df on another one which
> > have mounted a few NFS shares from my machine. I got 5 more
> > pretty much identical ones within 10 seconds after the first one
> > (haven't seen any more after these though). Also, dmesg is filled
> > with, about a gazillion of these:
> > [15164.017991] RPC request reserved 9136 but used 9268
> > [15164.037431] RPC request reserved 9136 but used 9268
> > [15164.052988] RPC request reserved 9136 but used 9268
> >
> > Files are also getting corrupted when transfered from my machine,
> > but using my machine as client works fine.
>
> OK, so the NFS server isn't happy.
>
> > oops here:
> >
> > Error (regular_file): read_ksyms stat /proc/ksyms failed
>
> You don't need to run ksymoops at all in 2.6 - simply enable
> CONFIG_KALLSYMS and the kernel does the rest.

Oh, didn't know that!

> > No modules in ksyms, skipping objects
> > No ksyms, skipping lsmod
> > BUG: unable to handle kernel NULL pointer dereference at virtual
> > address 00000000
> > c04ad300
> > *pde = 00000000
> > Oops: 0000 [#1]
> > CPU:    0
> > EIP:    0060:[<c04ad300>]    Tainted: P      VLI
>
> What caused the taint?

I was pretty sure it was listed somewhere, but I guess it wasn't.
nvidia graphics module, I can try without it tomorrow if needed.

Ah, it was only listed in the original one:

[  218.012273] BUG: unable to handle kernel NULL pointer dereference at virtual address 00000000
[  218.012289]  printing eip:
[  218.012292] c04ad300
[  218.012294] *pde = 00000000
[  218.012302] Oops: 0000 [#1]
[  218.021009] 4K_STACKS PREEMPT
[  218.030577] last sysfs file: /class/input/input1/name
[  218.046224] Modules linked in: snd_seq_midi snd_seq_oss ipaq usbserial nvidia agpgart eeprom snd_seq_dummy snd_pcm_oss snd_mixer_oss snd_emu10k1_synth snd_emux_synth snd_seq_virmidi snd_seq_midi_event snd_seq_midi_emul snd_seq snd_emu10k1 snd_rawmidi snd_ac97_codec snd_ac97_bus snd_pcm snd_seq_device snd_page_alloc snd_util_mem snd_hwdep psmouse
[  218.142717] CPU:    0
[  218.142718] EIP:    0060:[<c04ad300>]    Tainted: P      VLI
[  218.142720] EFLAGS: 00210212   (2.6.18-rc6-mm1 #1)
[  218.182388] EIP is at svc_process+0x40/0x6a0
[  218.195608] eax: 00000000   ebx: e5299000   ecx: 00000000   edx: e8843620
[  218.216639] esi: e5299070   edi: ffff84de   ebp: e52a0fb0   esp: e52a0f70
[  218.237666] ds: 007b   es: 007b   ss: 0068
[  218.250352] Process nfsd (pid: 5040, ti=e52a0000 task=e52a5570 task.ti=e52a0000)
[  218.272754] Stack: 00200046 eb499aa0 00000001 eb499a84 00000000 e52a0f9c c04eaa1b eb499a84
[  218.299267]        00000001 e8843620 e529904c e52a0fb0 c012d70b 00000002 ffff84de ffff84de
[  218.325781]        e52a0fe0 c02784ba e5299000 e52a0fc4 00000000 fffffeff ffffffff fffffef8
[  218.352294] Call Trace:
[  218.360459]  [<c01041bf>] show_trace_log_lvl+0x2f/0x50
[  218.394276]  [<c01042a7>] show_stack_log_lvl+0x97/0xc0
[  218.428065]  [<c0104532>] show_registers+0x1f2/0x2a0
[  218.461416]  [<c01047dd>] die+0x12d/0x240
[  218.491904]  [<c011735c>] do_page_fault+0x3ac/0x650
[  218.525178]  [<c04eaeef>] error_code+0x3f/0x44
[  218.557331]  [<c02784ba>] nfsd+0x18a/0x2b0
[  218.588522]  [<c0103fb7>] kernel_thread_helper+0x7/0x10
[  218.623405]  =======================
[  218.653244] Code: 89 45 e8 8b 52 28 83 c6 70 89 55 e4 8b 40 04 83 f8 17 0f 86 6d 04 00 00 8b 5d 08 8b 83 9c 04 00 00 c7 83 a0 04 00 00 01 00 00 00 <8b> 00 89 04 24 e8 06 d4 ca ff c7 46 04 00 00 00 00 89 c1 89 43
[  218.755843] EIP: [<c04ad300>] svc_process+0x40/0x6a0 SS:ESP 0068:e52a0f70



Regards,
Magnus Määttä

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: 2.6.18-rc6-mm1
  2006-09-09 12:45 2.6.18-rc6-mm1 Magnus Määttä
@ 2006-09-09 18:27 ` Andrew Morton
  2006-09-10  0:37   ` 2.6.18-rc6-mm1 Magnus Määttä
  2006-09-13  4:54   ` 2.6.18-rc6-mm1 Neil Brown
  0 siblings, 2 replies; 114+ messages in thread
From: Andrew Morton @ 2006-09-09 18:27 UTC (permalink / raw)
  To: Magnus Määttä; +Cc: linux-kernel, Neil Brown

On Sat, 9 Sep 2006 14:45:32 +0200
Magnus Määttä <novell@kiruna.se> wrote:

> Hi Andrew,
> 
> Sorry, forgot to CC lkml when I sent the first one.
> 
> Andrew Morton wrote:
> > 
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc6/2.6.18-rc6-mm1/
> > 
> > - autofs4 mounting of NFS is still sick.
> 
> I got this oops on my machine when I ran df on another one which have 
> mounted a few NFS shares from my machine. I got 5 more pretty much 
> identical ones within 10 seconds after the first one (haven't seen 
> any more after these though). Also, dmesg is filled with, about a 
> gazillion of these:
> [15164.017991] RPC request reserved 9136 but used 9268
> [15164.037431] RPC request reserved 9136 but used 9268
> [15164.052988] RPC request reserved 9136 but used 9268
> 
> Files are also getting corrupted when transfered from my machine, but 
> using my machine as client works fine.

OK, so the NFS server isn't happy.

> oops here:
> 
> Error (regular_file): read_ksyms stat /proc/ksyms failed

You don't need to run ksymoops at all in 2.6 - simply enable
CONFIG_KALLSYMS and the kernel does the rest.

> No modules in ksyms, skipping objects
> No ksyms, skipping lsmod
> BUG: unable to handle kernel NULL pointer dereference at virtual 
> address 00000000
> c04ad300
> *pde = 00000000
> Oops: 0000 [#1]
> CPU:    0
> EIP:    0060:[<c04ad300>]    Tainted: P      VLI

What caused the taint?

> Using defaults from ksymoops -t elf32-i386 -a i386
> EFLAGS: 00210212   (2.6.18-rc6-mm1 #1)
> eax: 00000000   ebx: e5299000   ecx: 00000000   edx: e8843620
> esi: e5299070   edi: ffff84de   ebp: e52a0fb0   esp: e52a0f70
> ds: 007b   es: 007b   ss: 0068
> Stack: 00200046 eb499aa0 00000001 eb499a84 00000000 e52a0f9c c04eaa1b 
> eb499a84
>        00000001 e8843620 e529904c e52a0fb0 c012d70b 00000002 ffff84de 
> ffff84de
>        e52a0fe0 c02784ba e5299000 e52a0fc4 00000000 fffffeff ffffffff 
> fffffef8
> Call Trace:
>  [<c01041bf>] show_trace_log_lvl+0x2f/0x50
>  [<c01042a7>] show_stack_log_lvl+0x97/0xc0
>  [<c0104532>] show_registers+0x1f2/0x2a0
>  [<c01047dd>] die+0x12d/0x240
>  [<c011735c>] do_page_fault+0x3ac/0x650
>  [<c04eaeef>] error_code+0x3f/0x44
>  [<c02784ba>] nfsd+0x18a/0x2b0
>  [<c0103fb7>] kernel_thread_helper+0x7/0x10
> Code: 89 45 e8 8b 52 28 83 c6 70 89 55 e4 8b 40 04 83 f8 17 0f 86 6d 
> 04 00 00 8b 5d 08 8b 83 9c 04 00 00 c7 83 a0 04 00 00 01 00 00 00 
> <8b> 00 89 04 24 e8 06 d4 ca ff c7 46 04 00 00 00 00 89 c1 89 43
> 
> 
> >>EIP; c04ad300 <svc_process+40/6a0>   <=====
> 
> Trace; c01041bf <show_trace_log_lvl+2f/50>
> Trace; c01042a7 <show_stack_log_lvl+97/c0>
> Trace; c0104532 <show_registers+1f2/2a0>
> Trace; c01047dd <die+12d/240>
> Trace; c011735c <do_page_fault+3ac/650>
> Trace; c04eaeef <error_code+3f/44>
> Trace; c02784ba <nfsd+18a/2b0>
> Trace; c0103fb7 <kernel_thread_helper+7/10>
> 
> This architecture has variable length instructions, decoding before 
> eip
> is unreliable, take these instructions with a pinch of salt.
> 
> Code;  c04ad2d5 <svc_process+15/6a0>
> 00000000 <_EIP>:
> Code;  c04ad2d5 <svc_process+15/6a0>
>    0:   89 45 e8                  mov    %eax,0xffffffe8(%ebp)
> Code;  c04ad2d8 <svc_process+18/6a0>
>    3:   8b 52 28                  mov    0x28(%edx),%edx
> Code;  c04ad2db <svc_process+1b/6a0>
>    6:   83 c6 70                  add    $0x70,%esi
> Code;  c04ad2de <svc_process+1e/6a0>
>    9:   89 55 e4                  mov    %edx,0xffffffe4(%ebp)
> Code;  c04ad2e1 <svc_process+21/6a0>
>    c:   8b 40 04                  mov    0x4(%eax),%eax
> Code;  c04ad2e4 <svc_process+24/6a0>
>    f:   83 f8 17                  cmp    $0x17,%eax
> Code;  c04ad2e7 <svc_process+27/6a0>
>   12:   0f 86 6d 04 00 00         jbe    485 <_EIP+0x485>
> Code;  c04ad2ed <svc_process+2d/6a0>
>   18:   8b 5d 08                  mov    0x8(%ebp),%ebx
> Code;  c04ad2f0 <svc_process+30/6a0>
>   1b:   8b 83 9c 04 00 00         mov    0x49c(%ebx),%eax
> Code;  c04ad2f6 <svc_process+36/6a0>
>   21:   c7 83 a0 04 00 00 01      movl   $0x1,0x4a0(%ebx)
> Code;  c04ad2fd <svc_process+3d/6a0>
>   28:   00 00 00 
> 
> This decode from eip onwards should be reliable
> 
> Code;  c04ad300 <svc_process+40/6a0>
> 00000000 <_EIP>:
> Code;  c04ad300 <svc_process+40/6a0>   <=====
>    0:   8b 00                     mov    (%eax),%eax   <=====
> Code;  c04ad302 <svc_process+42/6a0>
>    2:   89 04 24                  mov    %eax,(%esp)
> Code;  c04ad305 <svc_process+45/6a0>
>    5:   e8 06 d4 ca ff            call   ffcad410 <_EIP+0xffcad410>
> Code;  c04ad30a <svc_process+4a/6a0>
>    a:   c7 46 04 00 00 00 00      movl   $0x0,0x4(%esi)
> Code;  c04ad311 <svc_process+51/6a0>
>   11:   89 c1                     mov    %eax,%ecx
> Code;  c04ad313 <svc_process+53/6a0>
>   13:   89                        .byte 0x89
> Code;  c04ad314 <svc_process+54/6a0>
>   14:   43                        inc    %ebx
> 
> EIP: [<c04ad300>] svc_process+0x40/0x6a0 SS:ESP 0068:e52a0f70
> Warning (Oops_read): Code line not seen, dumping what data is 
> available
> 
> 
> >>EIP; c04ad300 <svc_process+40/6a0>   <=====
> 
> 
> 2 warnings and 1 error issued.  Results may not be reliable.

^ permalink raw reply	[flat|nested] 114+ messages in thread

* Re: 2.6.18-rc6-mm1
@ 2006-09-09 12:45 Magnus Määttä
  2006-09-09 18:27 ` 2.6.18-rc6-mm1 Andrew Morton
  0 siblings, 1 reply; 114+ messages in thread
From: Magnus Määttä @ 2006-09-09 12:45 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel

Hi Andrew,

Sorry, forgot to CC lkml when I sent the first one.

Andrew Morton wrote:
> 
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc6/2.6.18-rc6-mm1/
> 
> - autofs4 mounting of NFS is still sick.

I got this oops on my machine when I ran df on another one which have 
mounted a few NFS shares from my machine. I got 5 more pretty much 
identical ones within 10 seconds after the first one (haven't seen 
any more after these though). Also, dmesg is filled with, about a 
gazillion of these:
[15164.017991] RPC request reserved 9136 but used 9268
[15164.037431] RPC request reserved 9136 but used 9268
[15164.052988] RPC request reserved 9136 but used 9268

Files are also getting corrupted when transfered from my machine, but 
using my machine as client works fine.

oops here:

Error (regular_file): read_ksyms stat /proc/ksyms failed
No modules in ksyms, skipping objects
No ksyms, skipping lsmod
BUG: unable to handle kernel NULL pointer dereference at virtual 
address 00000000
c04ad300
*pde = 00000000
Oops: 0000 [#1]
CPU:    0
EIP:    0060:[<c04ad300>]    Tainted: P      VLI
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00210212   (2.6.18-rc6-mm1 #1)
eax: 00000000   ebx: e5299000   ecx: 00000000   edx: e8843620
esi: e5299070   edi: ffff84de   ebp: e52a0fb0   esp: e52a0f70
ds: 007b   es: 007b   ss: 0068
Stack: 00200046 eb499aa0 00000001 eb499a84 00000000 e52a0f9c c04eaa1b 
eb499a84
       00000001 e8843620 e529904c e52a0fb0 c012d70b 00000002 ffff84de 
ffff84de
       e52a0fe0 c02784ba e5299000 e52a0fc4 00000000 fffffeff ffffffff 
fffffef8
Call Trace:
 [<c01041bf>] show_trace_log_lvl+0x2f/0x50
 [<c01042a7>] show_stack_log_lvl+0x97/0xc0
 [<c0104532>] show_registers+0x1f2/0x2a0
 [<c01047dd>] die+0x12d/0x240
 [<c011735c>] do_page_fault+0x3ac/0x650
 [<c04eaeef>] error_code+0x3f/0x44
 [<c02784ba>] nfsd+0x18a/0x2b0
 [<c0103fb7>] kernel_thread_helper+0x7/0x10
Code: 89 45 e8 8b 52 28 83 c6 70 89 55 e4 8b 40 04 83 f8 17 0f 86 6d 
04 00 00 8b 5d 08 8b 83 9c 04 00 00 c7 83 a0 04 00 00 01 00 00 00 
<8b> 00 89 04 24 e8 06 d4 ca ff c7 46 04 00 00 00 00 89 c1 89 43


>>EIP; c04ad300 <svc_process+40/6a0>   <=====

Trace; c01041bf <show_trace_log_lvl+2f/50>
Trace; c01042a7 <show_stack_log_lvl+97/c0>
Trace; c0104532 <show_registers+1f2/2a0>
Trace; c01047dd <die+12d/240>
Trace; c011735c <do_page_fault+3ac/650>
Trace; c04eaeef <error_code+3f/44>
Trace; c02784ba <nfsd+18a/2b0>
Trace; c0103fb7 <kernel_thread_helper+7/10>

This architecture has variable length instructions, decoding before 
eip
is unreliable, take these instructions with a pinch of salt.

Code;  c04ad2d5 <svc_process+15/6a0>
00000000 <_EIP>:
Code;  c04ad2d5 <svc_process+15/6a0>
   0:   89 45 e8                  mov    %eax,0xffffffe8(%ebp)
Code;  c04ad2d8 <svc_process+18/6a0>
   3:   8b 52 28                  mov    0x28(%edx),%edx
Code;  c04ad2db <svc_process+1b/6a0>
   6:   83 c6 70                  add    $0x70,%esi
Code;  c04ad2de <svc_process+1e/6a0>
   9:   89 55 e4                  mov    %edx,0xffffffe4(%ebp)
Code;  c04ad2e1 <svc_process+21/6a0>
   c:   8b 40 04                  mov    0x4(%eax),%eax
Code;  c04ad2e4 <svc_process+24/6a0>
   f:   83 f8 17                  cmp    $0x17,%eax
Code;  c04ad2e7 <svc_process+27/6a0>
  12:   0f 86 6d 04 00 00         jbe    485 <_EIP+0x485>
Code;  c04ad2ed <svc_process+2d/6a0>
  18:   8b 5d 08                  mov    0x8(%ebp),%ebx
Code;  c04ad2f0 <svc_process+30/6a0>
  1b:   8b 83 9c 04 00 00         mov    0x49c(%ebx),%eax
Code;  c04ad2f6 <svc_process+36/6a0>
  21:   c7 83 a0 04 00 00 01      movl   $0x1,0x4a0(%ebx)
Code;  c04ad2fd <svc_process+3d/6a0>
  28:   00 00 00 

This decode from eip onwards should be reliable

Code;  c04ad300 <svc_process+40/6a0>
00000000 <_EIP>:
Code;  c04ad300 <svc_process+40/6a0>   <=====
   0:   8b 00                     mov    (%eax),%eax   <=====
Code;  c04ad302 <svc_process+42/6a0>
   2:   89 04 24                  mov    %eax,(%esp)
Code;  c04ad305 <svc_process+45/6a0>
   5:   e8 06 d4 ca ff            call   ffcad410 <_EIP+0xffcad410>
Code;  c04ad30a <svc_process+4a/6a0>
   a:   c7 46 04 00 00 00 00      movl   $0x0,0x4(%esi)
Code;  c04ad311 <svc_process+51/6a0>
  11:   89 c1                     mov    %eax,%ecx
Code;  c04ad313 <svc_process+53/6a0>
  13:   89                        .byte 0x89
Code;  c04ad314 <svc_process+54/6a0>
  14:   43                        inc    %ebx

EIP: [<c04ad300>] svc_process+0x40/0x6a0 SS:ESP 0068:e52a0f70
Warning (Oops_read): Code line not seen, dumping what data is 
available


>>EIP; c04ad300 <svc_process+40/6a0>   <=====


2 warnings and 1 error issued.  Results may not be reliable.

^ permalink raw reply	[flat|nested] 114+ messages in thread

end of thread, other threads:[~2006-09-16 14:31 UTC | newest]

Thread overview: 114+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-09-08  8:13 2.6.18-rc6-mm1 Andrew Morton
2006-09-08 11:49 ` 2.6.18-rc6-mm1 Andy Whitcroft
2006-09-08 12:07 ` 2.6.18-rc6-mm1 Frederik Deweerdt
2006-09-08 12:16 ` [patch -mm] s390: fix save_stack_trace Heiko Carstens
2006-09-09 13:36   ` Andi Kleen
2006-09-08 12:23 ` 2.6.18-rc6-mm1 - x86_64-mm-lockdep-dont-force-framepointer.patch Heiko Carstens
2006-09-09 13:39   ` Andi Kleen
2006-09-11  8:45     ` Martin Schwidefsky
2006-09-08 14:26 ` 2.6.18-rc6-mm1 Rafael J. Wysocki
2006-09-08 20:44   ` [linux-usb-devel] 2.6.18-rc6-mm1 Alan Stern
2006-09-08 22:57     ` Rafael J. Wysocki
2006-09-11 22:08       ` Rafael J. Wysocki
2006-09-12 14:28         ` Alan Stern
2006-09-12 17:22           ` Mattia Dongili
2006-09-12 18:04             ` Mattia Dongili
2006-09-12 20:10               ` Alan Stern
2006-09-13 17:00                 ` Rafael J. Wysocki
2006-09-13 12:07       ` [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem Rafael J. Wysocki
2006-09-13 12:42         ` Rafael J. Wysocki
2006-09-13 18:38           ` Alan Stern
2006-09-13 20:00             ` Rafael J. Wysocki
2006-09-13 21:01               ` Alan Stern
2006-09-13 21:32                 ` Rafael J. Wysocki
2006-09-13 21:55                   ` Alan Stern
2006-09-14 13:14                     ` Rafael J. Wysocki
2006-09-14 14:08                       ` Rafael J. Wysocki
2006-09-14 15:04                         ` Alan Stern
2006-09-14 16:17                           ` Alan Stern
2006-09-14 17:08                             ` Rafael J. Wysocki
2006-09-14 17:13                               ` Rafael J. Wysocki
2006-09-14 17:24                                 ` Alan Stern
2006-09-14 17:22                               ` Alan Stern
2006-09-14 17:35                                 ` Rafael J. Wysocki
2006-09-14 18:28                                   ` Alan Stern
     [not found]                                     ` <200609142137.52066.rjw@sisk.pl>
2006-09-14 20:21                                       ` Rafael J. Wysocki
2006-09-14 20:55                                       ` Alan Stern
2006-09-14 21:47                                         ` Rafael J. Wysocki
2006-09-14 22:19                                           ` Alan Stern
2006-09-14 16:48                           ` Rafael J. Wysocki
2006-09-13 20:38             ` Mattia Dongili
2006-09-13 20:54               ` Alan Stern
2006-09-14 20:19                 ` Mattia Dongili
2006-09-14 20:25                   ` Alan Stern
2006-09-14 20:35                     ` Mattia Dongili
2006-09-16 11:58                     ` Mattia Dongili
2006-09-16 14:31                       ` Alan Stern
2006-09-08 17:43 ` 2.6.18-rc6-mm1 Stefan Richter
2006-09-08 18:04   ` 2.6.18-rc6-mm1 Andrew Morton
2006-09-08 18:36     ` 2.6.18-rc6-mm1 Stefan Richter
2006-09-08 19:23 ` 2.6.18-rc6-mm1 Michal Piotrowski
2006-09-08 19:43   ` 2.6.18-rc6-mm1 Andrew Morton
2006-09-08 20:01     ` 2.6.18-rc6-mm1 Michal Piotrowski
2006-09-08 19:30 ` 2.6.18-rc6-mm1 thunder7
2006-09-08 19:44   ` 2.6.18-rc6-mm1 Andrew Morton
2006-09-09  9:04     ` 2.6.18-rc6-mm1 thunder7
2006-09-09 15:31       ` 2.6.18-rc6-mm1 Andrew Morton
2006-09-09 22:02         ` 2.6.18-rc6-mm1 Jean Delvare
2006-09-10  6:30           ` 2.6.18-rc6-mm1 thunder7
2006-09-09  8:35 ` lockdep warning in check_flags() Frederik Deweerdt
2006-09-11  5:43   ` Ingo Molnar
2006-09-12 14:13     ` Frederik Deweerdt
2006-09-12 16:54       ` Ingo Molnar
2006-09-12 20:21         ` Frederik Deweerdt
     [not found] ` <4503DC64.9070007@free.fr>
2006-09-10  8:32   ` 2.6.18-rc6-mm1: GPF loop on early boot Andi Kleen
2006-09-10 10:29     ` Arjan van de Ven
2006-09-10 11:57     ` Ingo Molnar
2006-09-10 11:34       ` Andi Kleen
2006-09-10 13:26         ` Ingo Molnar
2006-09-10 13:55           ` Andi Kleen
2006-09-10 14:02             ` Ingo Molnar
2006-09-10 16:33           ` Andrew Morton
2006-09-10 23:03             ` Jeremy Fitzhardinge
2006-09-11  5:10               ` Ingo Molnar
2006-09-11  7:31                 ` Jeremy Fitzhardinge
2006-09-11  7:29                   ` Ingo Molnar
2006-09-11  7:41                     ` Jeremy Fitzhardinge
2006-09-11  7:36                       ` Ingo Molnar
2006-09-11  7:59                         ` Jeremy Fitzhardinge
2006-09-11  8:01                           ` Ingo Molnar
2006-09-11  8:13                             ` Jeremy Fitzhardinge
2006-09-11  7:38                       ` Ingo Molnar
2006-09-11  7:56                         ` Jeremy Fitzhardinge
2006-09-11  7:55                           ` Ingo Molnar
2006-09-11  5:21               ` Laurent Riffard
2006-09-11  5:18                 ` Ingo Molnar
2006-09-11  5:25               ` [patch] i386-PDA, lockdep: fix %gs restore Ingo Molnar
2006-09-11  5:41                 ` Andi Kleen
2006-09-11  5:48                   ` Ingo Molnar
2006-09-11  5:46                 ` Ingo Molnar
2006-09-11 16:35                   ` Laurent Riffard
2006-09-11  7:42                 ` Jeremy Fitzhardinge
2006-09-11 19:33                 ` Jeremy Fitzhardinge
2006-09-11 21:25                   ` Jeremy Fitzhardinge
2006-09-11 20:20                 ` Andi Kleen
2006-09-11 21:37                   ` Jeremy Fitzhardinge
2006-09-11 20:48                     ` Andi Kleen
2006-09-10 12:36       ` 2.6.18-rc6-mm1: GPF loop on early boot Laurent Riffard
2006-09-10 13:07         ` Ingo Molnar
2006-09-10 13:11       ` Ingo Molnar
2006-09-11 21:19 ` 2.6.18-rc6-mm1 Mark Haverkamp
2006-09-11 22:16   ` 2.6.18-rc6-mm1 Andrew Morton
2006-09-09 12:45 2.6.18-rc6-mm1 Magnus Määttä
2006-09-09 18:27 ` 2.6.18-rc6-mm1 Andrew Morton
2006-09-10  0:37   ` 2.6.18-rc6-mm1 Magnus Määttä
2006-09-10  5:35     ` 2.6.18-rc6-mm1 Andrew Morton
2006-09-10 10:22       ` 2.6.18-rc6-mm1 Magnus Määttä
2006-09-13  4:54   ` 2.6.18-rc6-mm1 Neil Brown
2006-09-16 14:10     ` 2.6.18-rc6-mm1 Magnus Määttä
2006-09-11  2:34 2.6.18-rc6-mm1 Chuck Ebbert
2006-09-11  5:14 ` 2.6.18-rc6-mm1 Andrew Morton
2006-09-11 12:41 2.6.18-rc6-mm1 Chuck Ebbert
2006-09-11 17:23 ` 2.6.18-rc6-mm1 Andrew Morton
2006-09-11 21:56 2.6.18-rc6-mm1 Chuck Ebbert
2006-09-11 22:35 ` 2.6.18-rc6-mm1 Andrew Morton

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).