Discussion:
2.6.23-rc6-mm1
Andrew Morton
2007-09-18 08:18:41 UTC
Permalink
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc6/2.6.23-rc6-mm1/

2.6.23-rc6-mm1 is a 29MB diff against 2.6.23-rc6.

It took me over two solid days to get this lot compiling and booting on a few
boxes. This required around ninety fixup patches and patch droppings. There
are several bugs in here which I know of (details below) and presumably many
more which I don't know of. I have to say that this just isn't working any
more.

- The Vaio hangs when quitting X due to x86_64-mm-cpa-clflush.patch, but
I didn't drop that patch because the iommu patch series depends on it.

- The Vaio also hangs during resume-from-RAM, due to git-acpi.patch

- And it hangs during suspend-to-RAM, due to git-acpi.patch

- Huge churn in networking. Many wireless drivers will be busted, and b44.c
has been disabled altogether. If you need b44, then good luck working out
what was done to it.

- Added Peter's writeback balancing changes. Might help people who are
seeing large latency during heavy writeback.

- Major changes in the basically-unmaintained IPC code. Needs careful
testing and reviewing.

- Matthias fixed the mm-to-git importer, so the below-referenced git tree
should hopefully be working again.

- Pleeeeeze do try to cc the appropriate developer(s) and mailing lists
when reporting problems, thanks.


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 tag v2.6.16-rc2-mm1
git-checkout -b local-v2.6.16-rc2-mm1 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 ***@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.

- When reporting bugs in this kernel via email, please also rewrite the
email Subject: in some manner to reflect the nature of the bug. Some
developers filter by Subject: when looking for messages to read.

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



Changes since 2.6.23-rc4-mm1:


origin.patch
git-acpi.patch
git-alsa.patch
git-arm.patch
git-audit-master.patch
git-avr32.patch
git-cifs.patch
git-cpufreq.patch
git-powerpc.patch
git-drm.patch
git-dvb.patch
git-hwmon.patch
git-gfs2-nmw.patch
git-hid.patch
git-ieee1394.patch
git-infiniband.patch
git-input.patch
git-jfs.patch
git-jg-misc.patch
git-kbuild.patch
git-kvm.patch
git-libata-all.patch
git-md-accel.patch
git-mips.patch
git-mmc.patch
git-mtd.patch
git-ubi.patch
git-net.patch
git-tehuti.patch
git-backlight.patch
git-nfs.patch
git-nfsd.patch
git-ocfs2.patch
git-r8169.patch
git-selinux.patch
git-s390.patch
git-sh.patch
git-scsi-misc.patch
git-block.patch
git-unionfs.patch
git-v9fs.patch
git-watchdog.patch
git-wireless.patch
git-ipwireless_cs.patch
git-newsetup.patch
git-xfs.patch
git-cryptodev.patch
git-kgdb.patch

git trees

-quote-fix-infinite-loop.patch
-spi_mpc83xx-hang-fix.patch
-drivers-edac-fix-printk-level-down-to-debug-from-emerg.patch
-drivers-edac-fix-e752x-correct-return-code.patch
-bcm1480-serial-build-fix.patch
-pnp-remove-smcf010-quirk.patch
-update-gitignore.patch
-md-fix-some-bugs-with-growing-raid5-raid6-arrays.patch
-mntput-called-before-dput-in-afs.patch
-fix-dac960-driver-on-machines-which-dont-support-64-bit-dma.patch
-documentation-00-index-notice-ecryptfstxt-moved.patch
-x86_64-add-parenthesis-to-irq-vector-macros.patch
-h8-300-fix-misnamed-config_blkdev_reserve_address-kconfig-variable.patch
-alsa-cs5535audio-correctly-set-dma-substream.patch
-alsa-cs5535audio-fix-prd-register-save-restore-power-management-race.patch
-alsa-cs5535audio-update-pci-device-handling-in-suspend-resume.patch
-alsa-cs5535audio-fix-acc_bm_cmd-register-handling.patch
-alsa-cs5535audio-drop-unused-bus-master-stuff.patch
-arm-extern-inline-static-inline.patch
-arm-cleanup-struct-irqaction-initializers.patch
-fix-gregkh-driver-driver-core-change-add_uevent_var-to-use-a-struct.patch
-ivtv-fbc-bugfix.patch
-hwmon-coretemp-remove-bogus-__cpuinitdata-etc-cleanup.patch
-pci-x-pci-express-read-control-interfaces-mthca.patch
-applesmc-switch-to-using-input-polldev.patch
-ams-switch-to-using-input-polldev.patch
-10-dots-braille-keyboards.patch
-de-dosify-iforce-protocoltxt.patch
-ide-mpc8xx-only-build-mpc8xx-on-arch_ppc.patch
-ide-ide-fix-pci-refcounting.patch
-ide-pdc202xx_new-fix-pci-refcounting.patch
-ide-hpt366-fix-pci-clock-detection-for-hpt374-take-4.patch
-ide-ide-add-ide_dev_is_sata-helper-take-2.patch
-ide-hpt366-ultradma-filter-for-sata-cards-take-2.patch
-ide-pdc202xx_new-pll-detection-fix.patch
-tty-add-the-new-ioctls-and-definitionto-the-mips.patch
-mips-qemu-network-work-again.patch
-drivers-mtd-mtdbdic-is-no-longer-an-own-module.patch
-ocfs2-warning-fix.patch
-gregkh-pci-pci-aer-fix-warnings-when-pcieaer-n.patch
-gregkh-pci-pci-remove-devinit-from-pci_read_bridge_bases.patch
-gregkh-pci-pci-remove-__devinit-from-pcibios_get_irq_routing_table.patch
-gregkh-pci-pci-unhide-smbus-on-compaq-deskpro-ep-401963-001-motherboard.patch
-gregkh-pci-pci-disable-decode-of-io-memory-during-bar-sizing.patch
-gregkh-pci-pci-piggy-bus.patch
-use-menuconfig-objects-fusion.patch
-drivers-message-fusion-mptctlc-mostly-kmalloc-memset-conversion-to-kzalloc.patch
-mpt-fusion-fix-two-potential-mem-leaks.patch
-message-fusion-remove-redundant-memset.patch
-hptiop-use-pci-vendor-symbol.patch
-drivers-scsi-advansysc-ld-error-re-2623-rc3-mm1.patch
-hptiop-add-new-firmware-interface-and-more-pci-device-ids.patch
-git-unionfs-build-fix.patch
-gregkh-usb-usb-oti6858-remove-broken-ioctl-code-in-mm-tree-and-also-the-broken-fixes.patch
-gregkh-usb-usb-iphone-charge.patch
-git-wireless-printk-fixes.patch
-x86_64-mm-cflags-probe.patch
-x86_64-mm-less-stack-alignment.patch
-x86_64-mm-vdso-install-unstripped-copies-on-disk.patch
-x86_64-mm-vdso-do-something-more-with-unstripped-copies-on-disk.patch
-x86_64-mm-fix-leak-of-__-kernel-from-top-level-directory-in-makefile.patch
-x86_64-get-boot_cpu_id-as-early-for-k8_scan_nodes.patch
-x86_64-family-10h-and-11h-to-k8topology.patch
-x86_64-get-mp_bus_to_node-as-early-v3.patch
-x86_64-get-mp_bus_to_node-as-early-v3-update.patch
-x86_64-use-bus-conf-in-nb-conf-fun1-to-get-bus-range-on-node.patch
-try-parent-numa_node-at-first-before-using-default.patch
-net-use-numa_node-in-net_devcice-dev-instead-of-parent.patch
-i386-optimize-memset-of-6-and-8-bytes.patch
-intel_cacheinfo-misc-section-annotation-fixes-fix.patch
-git-xfs-build-fix.patch
-serio-fix-modpost-warning.patch
-nfs-fix-oops-re-sysctls-and-v4-support.patch
-pcmcia-cistpl-use-get_unaligned-in-cis-parsing.patch
-atl1-disable-broken-64-bit-dma.patch
-therm_throtc-fix-section-mismatch.patch
-paravirt-fix-preemptible-lazy-mode-bug.patch
-uml-use-64-bits-for-block-size-on-x86_64.patch

Merged into mainline or a subsystem tree

+fix-dac960-driver-on-machines-which-dont-support-64-bit-dma-fix.patch
+uml-use-correct-type-in-blkgetsize-ioctl.patch
+atyfb-force-29mhz-xtal-on-g3-powerbooks.patch
+fix-failure-to-resume-from-initrds.patch
+fix-uts-corruption-during-cloneclone_newuts.patch
+rtc-ds1742c-should-use-resource_size_t-for-base-address.patch
+rtc-rtc-ds1553c-should-use-resource_size_t-for-base.patch
+mspec-handle-shrinking-virtual-memory-areas.patch
+mspec-handle-shrinking-virtual-memory-areas-3.patch
+pci-fix-unterminated-pci_device_id-lists.patch
+pci-fix-unterminated-pci_device_id-lists-fix.patch
+xen-dont-bother-trying-to-set-cr4.patch
+intelfb-fix-bug-in-dpll-disable.patch
+intel-agp-fix-i830-mask-variable-that-changed-with-g33-support.patch
+dir_index-error-out-instead-of-bug-on-corrupt-dx-dirs.patch
+nfs-fix-oops-re-sysctls-and-v4-support.patch
+disable-sys_timerfd-for-2623.patch

2.6.23 queue

+ext34-ensure-do_split-leaves-enough-free-space-in-both-blocks.patch
+kernel-userc-use-list_for_each_entry-instead-of-list_for_each.patch
+convert-uid-hash-to-hlist.patch
+fix-user-namespace-exiting-oops.patch
+fix-numa-memory-policy-reference-counting.patch

2.6.23 maybe-queue

+git-acpi-fixup.patch

Fix rejects in git-acpi.patch

+alsa-procfs-fix.patch
+git-alsa-sc6000-build-fix.patch
+generic-ac97-mixer-modem-oss-use-list_for_each_entry.patch
+ess-maestro-1-2-2e-sound-card-use-list_for_each_entry.patch
+routines-for-effect-processor-fx8010-use-list_for_each_entry.patch

alsa fixes

+arm-unbalanced-parenthesis-fix.patch

arm fix

-git-powerpc-fixup.patch

Unneeded

+powerpc-proper-defconfig-for-crosscompiles.patch
+powerpc-proper-defconfig-for-crosscompiles-fix.patch

powerpc fixes

-gregkh-driver-block-device.patch
-revert-gregkh-driver-block-device.patch

Dropped

+gregkh-driver-driver-core-add-config_uevent_helper_path.patch
+gregkh-driver-driver-core-remove-subsys_set_kset.patch
+gregkh-driver-driver-core-remove-kset_set_kset_s.patch
+gregkh-driver-driver-core-remove-subsys_put.patch
+gregkh-driver-driver-core-remove-subsys_get.patch
+gregkh-driver-driver-core-remove-put_bus.patch
+gregkh-driver-driver-core-remove-get_bus.patch
+gregkh-driver-kobjects-fix-up-improper-use-of-the-kobject-name-field.patch
+gregkh-driver-cdev-remove-unneeded-setting-of-cdev-names.patch
+gregkh-driver-drivers-clean-up-direct-setting-of-the-name-of-a-kset.patch
+gregkh-driver-kobject-remove-the-static-array-for-the-name.patch
+gregkh-driver-driver-core-make-platform_deviceid-an-int.patch
+gregkh-driver-sysfs-spit-a-warning-to-users-when-they-try-to-create-a-duplicate-sysfs-file.patch

driver tree updates

+fix-gregkh-driver-sysfs-spit-a-warning-to-users-when-they-try-to-create-a-duplicate-sysfs-file.patch
+fix-gregkh-driver-kobject-remove-the-static-array-for-the-name.patch
+fix-2--gregkh-driver-drivers-clean-up-direct-setting-of-the-name-of-a-kset.patch
+fix-gregkh-driver-drivers-clean-up-direct-setting-of-the-name-of-a-kset.patch
+drivers-char-nozomic-__devexit_p-usage-build-fix.patch

Fix it

+git-dvb-build-fix.patch

Fix git-dvb

+oops-in-pwc-v4l-driver.patch

v4l fix

+jdelvare-i2c-i2c-pcf8574-no-init.patch
+jdelvare-i2c-i2c-document-i2c_msg.patch

I2C tree updates

+i2c-i801-documentation-patch-for-intel-tolapai.patch
+i2c-i801-smbus-patch-for-intel-tolapai.patch
+i2c-i801-smbus-patch-for-intel-tolapai-fix.patch
+bfin_twi-remove-useless-twi_lock-mutex.patch

i2c stuff

+applesmc-for-mac-pro-2-x-quad-core.patch

hwmon driver update (needs work)

+ia64-tree-wide-misc-__cpuinitdata-init-exit-fix.patch

Fix ia64-tree-wide-misc-__cpuinitdata-init-exit.patch

+ia64-perfmon-remove-exit_pfm_fs.patch

ia64 fix

+git-input-fixup.patch

Fix git-input.patch

-pass-g-to-assembler-under-config_debug_info.patch
-pass-g-to-assembler-under-config_debug_info-fix.patch

These broek

+git-jg-misc-fix.patch

Fix git-jg-isc

+git-kbuild-fixup.patch

Fix git-kbuild.patch

+tristate-choices-with-mixed-tristate-and-boolean.patch

kbuild tweak

+drivers-ata-pata_ixp4xx_cfc-ioremap-return-code-check.patch
+ahci-raid-mode-sata-patch-for-intel-tolapai.patch
+ata-increase-allowed-config-flags.patch
+ata_piix-replace-spaces-with-tabs.patch

ata things

+ide-ide-pci-use-pci-dev-revision.patch
+ide-ide-use-io-ops-directly-part-2-take-2.patch
+ide-aec62xx-remove-init-setup.patch
+ide-cmd64x-remove-init-setup.patch
+ide-hpt366-remove-init-setup.patch
+ide-pdc202xx_new-remove-init-setup.patch
+ide-pdc202xx_old-remove-init-setup.patch
+ide-scc_pata-remove-init-setup.patch
+ide-serverworks-remove-init-setup.patch
+ide-ide-remove-init-setup-from-ide-pci-device-t.patch
+ide-aec62xx-no-need-to-disable-udma-in-init-hwif-method-for-atp850uf.patch
+ide-pdc202xx_new-add-declare-pdcnew-dev-macro.patch
+ide-pdc202xx_old-add-declare-pdc2026x-dev-macro.patch
+ide-piix-add-declare-ich-dev-macro.patch
+ide-ide-add-ide-hflag-error-stops-fifo.patch
+ide-ide-add-ide-hflag-serialize.patch
+ide-ide-add-ide-hflag-legacy-irqs.patch
+ide-alim15x3-always-tune-pio.patch
+ide-cs5520-always-tune-pio.patch
+ide-cy82c693-always-tune-pio.patch
+ide-opti621-always-tune-pio.patch
+ide-triflex-always-tune-pio.patch
+ide-ide-set-drive-autotune-in-ide-pci-setup-ports.patch
+ide-cmd64x-always-set-hwif-chipset-for-cmd646.patch
+ide-ide-fix-disabled-ports-reporting-for-pci-controllers.patch
+ide-rz1000-set-serialized-flag-only-if-mate-interface-exists.patch
+ide-serverworks-remove-dead-code-from-svwks-set-dma-mode.patch
+ide-ide-add-hwif-register-devices-helper.patch
+ide-ide-remove-unused-next-field-from-ide-pci-device-t.patch
+ide-ide-add-chipset-field-to-ide-pci-device-t.patch
+ide-ide-add-ide-hflag-force-legacy-irqs.patch
+ide-ide-add-ide-hflag-rqsize-256.patch
+ide-ide-add-ide-hflag-io-32bit-unmask-irqs-host-flags.patch

IDE tree updates

+git-mips-fixup.patch

Fix git-mips.patch

+mips-add-gpio-support-to-the-bcm947xx-platform-update.patch

Fix mips-add-gpio-support-to-the-bcm947xx-platform.patch

+mmc-fix-gregkh-driver-driver-core-change-add_uevent_var-to-use-a-struct.patch

Fix mmc tree for driver tree changes

-nommu-present-backing-device-capabilities-for-mtd.patch
-nommu-add-support-for-direct-mapping-through-mtdconcat.patch
-mtd-add-module-license-to-mtdbdi.patch

Dropped

+blackfin-on-chip-nand-flash-controller-driver.patch

MTD driver

-git-netdev-all.patch
-e1000e-build-fix.patch
+git-net.patch
+git-net-fixup.patch
+git-net-fix-2.patch
+nit-net-skge-build-fix.patch
-sundance-phy-address-form-0-only-for-device-id-0x0200.patch
+net-atm-lecc-printk-warning-fix.patch
+document-the-fact-that-smsc-ircc2-will-not-use-pnp-by-default.patch
+net-myri10ge-force-select-inet_lro.patch
+net-use-numa_node-in-net_devcice-dev-instead-of-parent.patch
+git-net-af_iucv-fixes.patch
+git-net-sgiseeq-fix.patch
+git-net-fix-ibmveth.patch
-uli526x-add-suspend-and-resume-routines.patch
-add-3c59x-maintainer.patch
-3c59x-check-return-of-pci_enable_device.patch
-ioc3-program-uart-predividers.patch
-sky2-fe-chip-support.patch
-sky2-use-debugfs-rename.patch
-sky2-document-gphy_ctrl-bits.patch
-sky2-dont-restrict-config-space-access.patch
-sky2-advanced-error-reporting.patch
-sky2-use-pci_config-access-functions.patch
-sky2-use-net_device-internal-stats.patch
-ktime_sub_ns-analog-of-ktime_add_ns.patch
-sky2-hardware-receive-timestamp-counter.patch
+skge-remove-broken-and-unused-phy_m_pc_mdi_xmode-macro.patch
+fix-a-potential-null-pointer-dereference-in-uli526x_interrupt.patch
+sb1250-macc-de-typedef-de-volatile-de-etc.patch
+net_sb1250_mac-update-kconfig-entry.patch
+net_sb1250_mac-rename-to-sb1250_mac.patch
+ipg-add-ip1000a-driver-to-kernel-tree.patch
+git-net-broke-ipg-add-ip1000a-driver-to-kernel-tree.patch
+git-tehuti.patch
+git-tehuti-vs-git-net.patch
-git-net.patch
-git-net-fixup.patch
-net-atm-lecc-printk-warning-fix.patch
-e1000e-incorporate-napi_struct-changes-from-net-2624git.patch
+git-net-vs-git-wireless.patch
+git-net-vs-git-wireless-2.patch
+ath5k-panic-fix.patch
+git-net-vs-git-wireless-3.patch
+git-net-broke-git-wireless.patch
+iwl3945-is-bust.patch
+more-wireless-borkage.patch
+more-wireless-borkage-2.patch
+more-wireless-borkage-3.patch
+p54pci-terminate-pci-table.patch
+git-wireless-fix-99.patch
+git-wireless-b44-is-bust.patch

Networking churn. It is indescribable, so I won't.

+git-backlight-build-fix.patch
+git-backlight-dependency-fix.patch

Fix git-backlight.patch

+git-net-vs-git-nfs.patch
+git-nfs-make-nfs_wb_page_priority-static.patch

Fix git-nfs.patch

+git-nfsd-fixup.patch

Fix git-nfsd.patch

+pcmcia-cistpl-use-get_unaligned-in-cis-parsing.patch
+add-support-for-pcmcia-card-sierra-wireless-ac850.patch
+introduce-dma_mask_none-as-a-signal-for-unable-to-do.patch
+pcmcia-use-dma_mask_none-for-the-default-for-all.patch

pcmcia stuff

+wake-up-from-a-serial-port.patch

Wake up machine over the serial port

+gregkh-pci-pci-fix-boot-time-hang-on-g31-g33-pc.patch
+gregkh-pci-cpqphp-use-pci_class_revision-instead-of-pci_revision_id-for-read.patch
+gregkh-pci-pci-quirk-amd_8131_mmrbc-omit-reading-pci-revision-id.patch
+gregkh-pci-pci-quirk_vt82c586_acpi-omit-reading-pci-revision-id.patch
+gregkh-pci-pci-re-enable-onboard-sound-on-msi-k8t-neo2-fir.patch

PCI tree updates

+i386-compaq-evo-n800c-needs-pci-bus-renumbering.patch
+i386-compaq-evo-n800c-needs-pci-bus-renumbering-fix.patch

PCI things

+sched-use-show_regs-to-improve-__schedule_bug-output.patch

sched cleanup

+git-scsi-misc-fixup.patch
+git-scsi-misc-arcmsr-build-fix.patch

fix git-scsi-misc

+scsi-early-detection-of-medium-not-present-updated.patch
+scsi-use-notifier-chain-for-asynchronous-event.patch

scsi fixes

+git-block-fix-u14-34f.patch
+git-block-fix-qlogicpti-build.patch

Fix git-block.patch

+sparc-fix-build-due-to-termios-changes.patch

Now-unneeded sparc64 fix

+gregkh-usb-usb-remove-unneeded-pointer-intf-from-speedtch_upload_firmware.patch
+gregkh-usb-usb-fix-location-of-statement-label-in-dummy-hcd.patch
+gregkh-usb-usb-usb-storage-initialize-huawei-e220-properly.patch
+gregkh-usb-usb-elan-u132-host-controller-driver-convert-sw_lock-to-mutex.patch
+gregkh-usb-usb-fix-errornous-assumption-in-the-usb-serial-framework-revealed-by-iuu_phoenix.patch
+gregkh-usb-usb-sisusbvga-fix-bug-and-build-warnings.patch
+gregkh-usb-usb-amd5536-use-pdev-revision.patch
+gregkh-usb-usb-get-rid-of-annoying-endpoint-release-message.patch
+gregkh-usb-usb-move-decision-to-ignore-freeze-events.patch
+gregkh-usb-usb-break-apart-flush_endpoint-and-disable_endpoint.patch
+gregkh-usb-usb-flush-outstanding-urbs-when-suspending.patch
+gregkh-usb-usb-usb-serial-ch341c-make-4-functions-static.patch

USB tree updates

-9p-build-fix.patch
-9p-is-bust.patch
-9p-is-still-bust.patch

Unneeded

+x86_64-mm-defconfig-update.patch
+x86_64-mm-vdso-compat-install-unstripped-copies-on-disk.patch
+x86_64-mm-vdso-64bit-install-unstripped-copies-on-disk.patch
+x86_64-mm-implement-missing-x86_64-function-smp_call_function_mask.patch
+x86_64-mm-eliminate-result-signage-problem-in-asm-x86_64-bitops_h.patch
+x86_64-mm-add-parenthesis-to-irq-vector-macros.patch
+x86_64-mm-export-i386-smp_call_function_mask-to-modules.patch
+x86_64-mm-remove-duplicated-nsec-update.patch
+x86_64-mm-remove-stub-early_printk_c.patch
+x86_64-mm-honor-_page_pse-bit-on-page-walks.patch
+x86_64-mm-remove-some-dead-code.patch
+x86_64-mm-honor-notify_die-returning-notify_stop.patch
+x86_64-mm-optionally-show-last-exception-from-to-register-contents-v2.patch
+x86_64-mm-rename-_i-assembler-includes-to-_h.patch

x86 tree updates

+voyager-include-asm-smph-to-fix-compile-error.patch
+therm_throtc-fix-section-mismatch.patch
+optimize-x86-page-faults-like-all-other-achitectures-and-kill-notifier-cruft.patch
+optimize-x86-page-faults-like-all-other-achitectures-and-kill-notifier-cruft-fix.patch
+hpet-force-enable-on-vt8235-37-chipsets.patch
+x86_64-check-msr-to-get-mmconfig-for-amd-family-10h-opteron.patch
+x86_64-check-and-enable-mmconfig-for-amd-family-10h-opteron.patch
+x86_64-check-and-enable-mmconfig-for-amd-family-10h-opteron-fix.patch
+x86_64-set-cfg_size-for-amd-family-10h-in-case-mmconfig-is.patch
+x86_64-set-cfg_size-for-amd-family-10h-in-case-mmconfig-is-fix.patch
+i386-cpuid_count-fix-argument-signedness-warnings.patch
+voyager-dont-try-to-support-unprocessor-builds.patch
+i386-fix-section-mismatch-warning-in-intelc.patch
+x86-misc-constifications.patch
+x86-constify-wd_ops.patch
+x86-multi-byte-single-instruction-nops.patch

x86 stuff

-hpet-force-enable-on-vt8235-37-chipsets.patch
-hpet-force-enable-on-vt8235-37-chipsets-fix.patch

Dropped

+convert-cpu_sibling_map-to-be-a-per-cpu-variable.patch
+convert-cpu_sibling_map-to-a-per_cpu-data-array-ia64.patch
+convert-cpu_sibling_map-to-a-per_cpu-data-array-ppc64.patch
+convert-cpu_sibling_map-to-a-per_cpu-data-array-ppc64-fix.patch
+convert-cpu_sibling_map-to-a-per_cpu-data-array-sparc64.patch

per-cpuification

+scsi-use-lock-per-host-instead-of-per-device-for-shared-queue-tag-host.patch
+x86_64-nx-bit-handling-in-change_page_attr.patch
+driver-core-fix-deprectated-sysfs-structure-for-nested-class-devices.patch

Maybe-2.6.23 patches

+use-vm_read-write-exec-to-set-vm_page_prot.patch
+prevent-kswapd-from-freeing-excessive-amounts-of-lowmem.patch
+mem-policy-add-mpol_f_mems_allowed-get_mempolicy-flag.patch
+update-n_high_memory-node-state-for-memory-hotadd.patch
+update-n_high_memory-node-state-for-memory-hotadd-fix.patch
+fix-panic-of-cpu-online-with-memory-less-node.patch
+slub-do-not-use-page-mapping-fix.patch
+add-node-states-sysfs-class-attributes-v5.patch
+nfs-remove-congestion_end.patch
+lib-percpu_counter_add.patch
+lib-percpu_counter_sub.patch
+lib-percpu_counter-variable-batch.patch
+lib-make-percpu_counter_add-take-s64.patch
+lib-percpu_counter_set.patch
+lib-percpu_counter_sum_positive.patch
+lib-percpu_count_sum.patch
+lib-percpu_counter_init-error-handling.patch
+lib-percpu_counter_init_irq.patch
+mm-bdi-init-hooks.patch
+mm-scalable-bdi-statistics-counters.patch
+mm-count-reclaimable-pages-per-bdi.patch
+mm-count-writeback-pages-per-bdi.patch
+mm-expose-bdi-statistics-in-sysfs.patch
+lib-floating-proportions.patch
+mm-per-device-dirty-threshold.patch
+mm-per-device-dirty-threshold-warning-fix.patch
+mm-dirty-balancing-for-tasks.patch
+mm-dirty-balancing-for-tasks-warning-fix.patch
+debug-sysfs-files-for-the-current-ratio-size-total.patch
+slub-simplify-irq-off-handling.patch
+slab-api-remove-useless-ctor-parameter-and-reorder-parameters.patch
+slab-api-remove-useless-ctor-parameter-and-reorder-parameters-fix.patch
+slab-api-remove-useless-ctor-parameter-and-reorder-parameters-fix-2.patch
+slab-api-remove-useless-ctor-parameter-and-reorder-parameters-vs-unionfs.patch

MM updates

+alpha-convert-to-generic-sys_ptrace.patch

alpha fix

+hibernation-check-if-acpi-is-enabled-during-restore-in-the-right-place.patch
+hibernation-enter-platform-hibernation-state-in-a-consistent-way-rev-4.patch
+hibernation-enter-platform-hibernation-state-in-a-consistent-way-rev-4-fix.patch

PM updates

+m32r-serial-remove-m32r_sio_share_irqs.patch

m32r cleanup

+uml-remove-unneeded-void-cast.patch
+uml-remove-unused-file.patch
+uml-more-idiomatic-parameter-parsing.patch

UML updates

+i-oat-add-support-for-msi-and-msi-x-fix.patch

Fix i-oat-add-support-for-msi-and-msi-x.patch

+softlockup-improve-debug-output-fix.patch

Fix softlockup-improve-debug-output.patch

-add-all-thread-stats-for-taskstats_cmd_attr_tgid.patch

Dropped

+ufs-fix-sun-state-fix-mount-check-in-ufs_fill_super.patch

Fix ufs-fix-sun-state.patch

+i386-and-x86_64-randomize-brk.patch
+i386-and-x86_64-randomize-brk-fix.patch

brk randomisation

+add-vmcore-cleanup-the-coding-style-according-to-andrews-comments.patch
+add-vmcore-add-nodemask_ts-size-and-nr_free_pagess-value-to-vmcoreinfo_data.patch
+add-vmcore-use-the-existing-ia64_tpa-instead-of-asm-code.patch
+add-vmcore-add-a-prefix-vmcoreinfo_-to-the-vmcoreinfo-macros.patch

Fix add-vmcoreinfo.patch

+send-quota-messages-via-netlink-fix.patch
+send-quota-messages-via-netlink-fix-fix.patch

Fix send-quota-messages-via-netlink.patch

+add-a-rounddown_pow_of_two-routine-to-log2hpatch-fix.patch

Fix add-a-rounddown_pow_of_two-routine-to-log2h.patch

+handle-recursive-calls-to-bust_spinlocks.patch
+store-__setup_str_-in-a-more-compact-way.patch
+constify-string-array-kparam-tracking-structures.patch
+avoid-negative-and-full-width-shifts-in-radix-treec.patch
+futex_compat-simplify-pointer-magic.patch
+futex_compat-update-to-match-native-version.patch
+add-config_vt_unicode.patch
+update-checkpatchpl-to-version-010.patch
+pvrusb2-hdw-terminate-usb-device-id-table-differently.patch
+i2o-fix-defined-but-not-used-build-warnings.patch
+i2o-fix-defined-but-not-used-build-warnings-fix.patch
+ipc-namespace-remove-config-ipc-ns-fix.patch
+spelling-fix-weired-weird.patch
+mutex-documentation-is-unclear-about-software-interrupts-tasklets-and-timers.patch
+dcache-trivial-comment-fix.patch
+procfs-detect-duplicate-names.patch
+procfs-detect-duplicate-names-fix.patch
+procfs-detect-duplicate-names-fix-fix-2.patch
+remove-dma_cache_wbackinvwback_inv-functions.patch
+maintainers-linux-omap-list-is-subscribers-only.patch
+try-to-reap-reiserfs-pages-left-around-by-invalidatepage.patch
+keys-make-request_key-and-co-fundamentally-asynchronous.patch
+keys-make-request_key-and-co-fundamentally-asynchronous-vs-git-mmc.patch
+make-the-pr_-family-of-macros-in-kernelh-complete.patch
+doc-about-email-clients-for-linux-patches.patch
+jbd-slab-cleanups.patch
+reiserfs-fix-kernel-panic-on-corrupted-directory.patch
+lib-iomapcbad_io_access-print-0x-hex-prefix.patch
+lk201-remove-obsolete-driver.patch

Misc

+ext2-reservations-fix-for-percpu_counter-changes.patch

Update ext2-reservations.patch

+ecryptfs-use-generic_file_splice_read.patch

ecryptfs update

+rtc-make-rtc-ds1553-driver-hotplug-aware-take-3.patch
+rtc-make-rtc-ds1742-driver-hotplug-aware-take-2.patch
+rtc-pcf8583-check-for-i2c-adapter-functionality.patch

rtc updates

+uvesafb-the-driver-core-dont-access-vga-registers-directly-when-running-on-non-x86.patch
+s3c2410fb-byte-ordering-fixes.patch
+intel-fb-support-for-interlaced-video-modes.patch
+fbdev-find-mode-with-the-highest-safest-refresh-rate-in-fb_find_mode.patch
+nvidiafb-add-boot-option-to-reverse-i2c-port-assignment.patch
+fbdev-support-for-byte-reversed-framebuffer-formats.patch
+ps3-fix-black-and-white-stripes.patch
+ps3fb-fix-spurious-mode-change-failures.patch
+fbdev-update-documentation-fb-00-index.patch
+tdfxfb-replace-busy-waiting-with-cpu_relax.patch
+pm2fb-replace-busy-waiting-with-cpu_relax.patch
+pm3fb-replace-busy-waiting-with-cpu_relax.patch
+tdfxfb-checkpatch-fixes.patch
+drivers-video-kconfig-fix-fb_pmagb_b-dependencies.patch
+export-font_vga_8x16.patch

fbdev updates

-drivers-video-geode-lxfb_corec-fix-lxfb_setup-warning-fix.patch

Folded into drivers-video-geode-lxfb_corec-fix-lxfb_setup-warning.patch

+bitmaph-remove-dead-artifacts.patch

RAID cleanup

+slab-api-remove-useless-ctor-parameter-and-reorder-parameters-vs-revoke.patch

Fix revoke for slab changes

+documentation-add-entries-to-filesystems-00-index-for-several-untracked-files.patch
+add-a-missing-00-index-file-for-documentation-vm.patch
+add-a-00-index-file-to-documentation-mips.patch
+add-a-00-index-file-to-documentation-sysctl.patch
+add-a-00-index-file-to-documentation-telephony.patch
+kernel-doc-fix-doc-blocks-and-html.patch
+documentation-delete-unreferenced-xterm-linuxxpm-file.patch
+express-relocatability-of-kernel-on-x86_64-in-documentation.patch
+express-relocatability-of-kernel-on-x86_64-in.patch
+express-new-elf32-mechanisms-in-documentation.patch
+add-reset_devices-to-the-recommended-parameters.patch

documentation

+sysctl-deprecate-sys_sysctl-in-a-user-space-visible-fashion-fix.patch

Fix sysctl-deprecate-sys_sysctl-in-a-user-space-visible-fashion.patch

+mxser-fix-compiler-warning-when-building-withoug-config_pci.patch
+mxser-fix-compiler-warning-when-building-withoug-config_pci-fix.patch

mxser updates

+task-containersv11-basic-task-container-framework-containers-fix-refcount-bug.patch

Fix task-containersv11-basic-task-container-framework-fix.patch

+task-containersv11-add-container_clone-interface-containers-fix-refcount-bug.patch

Fix task-containersv11-add-container_clone-interface.patch

+task-containersv11-add-procfs-interface-containers-bdi-init-hooks.patch

Fix task-containersv11-add-procfs-interface.patch

+task-containers-enable-containers-by-default-in-some-configs.patch

Containers Kconfig tweak

-kernel-userc-use-list_for_each_entry-instead-of-list_for_each.patch

Dropped (I think)

+memory-controller-memory-accounting-v7-fix.patch
+memory-controller-memory-accounting-v7-fix-swapoff-breakage-however.patch

Fix memory-controller-memory-accounting-v7.patch

+memory-controller-add-per-container-lru-and-reclaim-v7-fix-2.patch
+memory-controller-add-per-container-lru-and-reclaim-v7-cleanup.patch
+memory-controller-improve-user-interface.patch

Fix memory-controller-add-per-container-lru-and-reclaim-v7.patch some more

+memory-controller-add-switch-to-control-what-type-of-pages-to-limit-v7-cleanup.patch
+memory-controller-add-switch-to-control-what-type-of-pages-to-limit-v7-fix-2.patch

Fix memory-controller-add-switch-to-control-what-type-of-pages-to-limit-v7.patch

+memory-controller-make-charging-gfp-mask-aware.patch
+memory-controller-make-charging-gfp-mask-aware-fix.patch
+memory-controller-bug_on.patch

Memory controller fixes

+cyclades-avoid-label-defined-but-not-used-warning.patch

cyclades cleanup

+remove-asm-bitopsh-includes.patch
+forbid-asm-bitopsh-direct-inclusion.patch

cleanups

cyber2000fb-rename-bit-macro.patch
+cyber2000fb-checkpatch-fixes.patch

More fbdev things

+use-helpers-to-obtain-task-pid-in-printks-drm-fix.patch

Fix use-helpers-to-obtain-task-pid-in-printks.patch

+alpha-lock-bitops-fix.patch

Fix alpha-lock-bitops.patch

+powerpc-lock-bitops-fix.patch

Fix powerpc-lock-bitops.patch

-fs-cramfs-inodec-remove-error-variable.patch

Dropped

+ipc-store-ipcs-into-idrs.patch
+ipc-unify-the-syscalls-code.patch
+ipc-remove-the-ipc_get-routine.patch
+ipc-integrate-ipc_checkid-into-ipc_lock.patch
+ipc-integrate-ipc_checkid-into-ipc_lock-fix.patch
+storing-ipcs-into-idrs.patch
+ipc-introduce-the-ipcid_to_idx-macro.patch
+ipc-inline-ipc_buildid.patch

Major IPC cleanups

+remove-asm-bitopsh-includes-reiser4.patch
+git-nfsd-broke-reiser4.patch
+slab-api-remove-useless-ctor-parameter-and-reorder-parameters-vs-reiser4.patch

upbreak reiser4 for various things

+add-a-refcount-check-in-dput.patch

New debug check.



4641 commits in 1872 patch files

All patches:

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc6/2.6.23-rc6-mm1/patch-list
Andrew Morton
2007-09-18 08:24:24 UTC
Permalink
Post by Andrew Morton
- And it hangs during suspend-to-RAM, due to git-acpi.patch
Make that "suspend-to-disk".
Kamalesh Babulal
2007-09-18 09:13:48 UTC
Permalink
Post by Andrew Morton
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc6/2.6.23-rc6-mm1/
2.6.23-rc6-mm1 is a 29MB diff against 2.6.23-rc6.
<snip>

Hi Andrew,

The 2.6.23-rc6-mm1build fails at

CC drivers/pci/hotplug/rpadlpar_core.o
CC drivers/pci/hotplug/rpadlpar_sysfs.o
drivers/pci/hotplug/rpadlpar_sysfs.c:132: error: unknown field `name' specified in initializer
drivers/pci/hotplug/rpadlpar_sysfs.c: In function `dlpar_sysfs_init':
drivers/pci/hotplug/rpadlpar_sysfs.c:142: error: structure has no member named `name'
make[3]: *** [drivers/pci/hotplug/rpadlpar_sysfs.o] Error 1
make[2]: *** [drivers/pci/hotplug] Error 2
make[1]: *** [drivers/pci] Error 2
make: *** [drivers] Error 2
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
Andrew Morton
2007-09-18 09:27:39 UTC
Permalink
Post by Kamalesh Babulal
Post by Andrew Morton
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc6/2.6.23-rc6-mm1/
2.6.23-rc6-mm1 is a 29MB diff against 2.6.23-rc6.
<snip>
Hi Andrew,
The 2.6.23-rc6-mm1build fails at
CC drivers/pci/hotplug/rpadlpar_core.o
CC drivers/pci/hotplug/rpadlpar_sysfs.o
drivers/pci/hotplug/rpadlpar_sysfs.c:132: error: unknown field `name' specified in initializer
drivers/pci/hotplug/rpadlpar_sysfs.c:142: error: structure has no member named `name'
make[3]: *** [drivers/pci/hotplug/rpadlpar_sysfs.o] Error 1
make[2]: *** [drivers/pci/hotplug] Error 2
make[1]: *** [drivers/pci] Error 2
make: *** [drivers] Error 2
Probably this:

--- a/drivers/pci/hotplug/rpadlpar_sysfs.c~a
+++ a/drivers/pci/hotplug/rpadlpar_sysfs.c
@@ -129,8 +129,7 @@ struct kobj_type ktype_dlpar_io = {
};

struct kset dlpar_io_kset = {
- .kobj = {.name = DLPAR_KOBJ_NAME,
- .ktype = &ktype_dlpar_io,
+ .kobj = {.ktype = &ktype_dlpar_io,
.parent = &pci_hotplug_slots_subsys.kobj},
.ktype = &ktype_dlpar_io,
};
_

But I'm fed up with fixing that patch. It's Greg's turn.
Satyam Sharma
2007-09-18 09:34:48 UTC
Permalink
Post by Andrew Morton
Post by Kamalesh Babulal
Post by Andrew Morton
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc6/2.6.23-rc6-mm1/
2.6.23-rc6-mm1 is a 29MB diff against 2.6.23-rc6.
<snip>
Hi Andrew,
The 2.6.23-rc6-mm1build fails at
CC drivers/pci/hotplug/rpadlpar_core.o
CC drivers/pci/hotplug/rpadlpar_sysfs.o
drivers/pci/hotplug/rpadlpar_sysfs.c:132: error: unknown field `name' specified in initializer
drivers/pci/hotplug/rpadlpar_sysfs.c:142: error: structure has no member named `name'
make[3]: *** [drivers/pci/hotplug/rpadlpar_sysfs.o] Error 1
make[2]: *** [drivers/pci/hotplug] Error 2
make[1]: *** [drivers/pci] Error 2
make: *** [drivers] Error 2
--- a/drivers/pci/hotplug/rpadlpar_sysfs.c~a
+++ a/drivers/pci/hotplug/rpadlpar_sysfs.c
@@ -129,8 +129,7 @@ struct kobj_type ktype_dlpar_io = {
};
struct kset dlpar_io_kset = {
- .kobj = {.name = DLPAR_KOBJ_NAME,
- .ktype = &ktype_dlpar_io,
+ .kobj = {.ktype = &ktype_dlpar_io,
.parent = &pci_hotplug_slots_subsys.kobj},
.ktype = &ktype_dlpar_io,
};
_
But I'm fed up with fixing that patch. It's Greg's turn.
But wait ... isn't that a statically-allocated kobject, which were
supposed to be "naughty" in the first place?
Greg KH
2007-09-18 19:17:40 UTC
Permalink
Post by Satyam Sharma
Post by Andrew Morton
Post by Kamalesh Babulal
Post by Andrew Morton
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc6/2.6.23-rc6-mm1/
2.6.23-rc6-mm1 is a 29MB diff against 2.6.23-rc6.
<snip>
Hi Andrew,
The 2.6.23-rc6-mm1build fails at
CC drivers/pci/hotplug/rpadlpar_core.o
CC drivers/pci/hotplug/rpadlpar_sysfs.o
drivers/pci/hotplug/rpadlpar_sysfs.c:132: error: unknown field `name' specified in initializer
drivers/pci/hotplug/rpadlpar_sysfs.c:142: error: structure has no member named `name'
make[3]: *** [drivers/pci/hotplug/rpadlpar_sysfs.o] Error 1
make[2]: *** [drivers/pci/hotplug] Error 2
make[1]: *** [drivers/pci] Error 2
make: *** [drivers] Error 2
--- a/drivers/pci/hotplug/rpadlpar_sysfs.c~a
+++ a/drivers/pci/hotplug/rpadlpar_sysfs.c
@@ -129,8 +129,7 @@ struct kobj_type ktype_dlpar_io = {
};
struct kset dlpar_io_kset = {
- .kobj = {.name = DLPAR_KOBJ_NAME,
- .ktype = &ktype_dlpar_io,
+ .kobj = {.ktype = &ktype_dlpar_io,
.parent = &pci_hotplug_slots_subsys.kobj},
.ktype = &ktype_dlpar_io,
};
_
But I'm fed up with fixing that patch. It's Greg's turn.
But wait ... isn't that a statically-allocated kobject, which were
supposed to be "naughty" in the first place?
Yes it is, if you want to dynamically create it, please do. But there's
a lot of these in the kernel and I didn't want to break _all_ of them at
once, it's a multiple-stage set of patches to get us there (this name
array change is just the first in the set of these steps...)

thanks,

greg k-h
Andy Whitcroft
2007-09-18 09:34:44 UTC
Permalink
Post by Kamalesh Babulal
Post by Andrew Morton
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc6/2.6.23-rc6-mm1/
2.6.23-rc6-mm1 is a 29MB diff against 2.6.23-rc6.
<snip>
Hi Andrew,
The 2.6.23-rc6-mm1build fails at
CC drivers/pci/hotplug/rpadlpar_core.o
CC drivers/pci/hotplug/rpadlpar_sysfs.o
drivers/pci/hotplug/rpadlpar_sysfs.c:132: error: unknown field `name'
specified in initializer
drivers/pci/hotplug/rpadlpar_sysfs.c:142: error: structure has no member named `name'
make[3]: *** [drivers/pci/hotplug/rpadlpar_sysfs.o] Error 1
make[2]: *** [drivers/pci/hotplug] Error 2
make[1]: *** [drivers/pci] Error 2
make: *** [drivers] Error 2
This seems to be occuring across a number of the powerpc systems we test
with. That driver is a power dynamic lpar IO partitioning driver.

Relevant Cc: added.

-apw
Benjamin Herrenschmidt
2007-09-18 10:02:51 UTC
Permalink
Post by Andy Whitcroft
Post by Kamalesh Babulal
Post by Andrew Morton
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc6/2.6.23-rc6-mm1/
2.6.23-rc6-mm1 is a 29MB diff against 2.6.23-rc6.
<snip>
Hi Andrew,
The 2.6.23-rc6-mm1build fails at
CC drivers/pci/hotplug/rpadlpar_core.o
CC drivers/pci/hotplug/rpadlpar_sysfs.o
drivers/pci/hotplug/rpadlpar_sysfs.c:132: error: unknown field `name'
specified in initializer
drivers/pci/hotplug/rpadlpar_sysfs.c:142: error: structure has no member named `name'
make[3]: *** [drivers/pci/hotplug/rpadlpar_sysfs.o] Error 1
make[2]: *** [drivers/pci/hotplug] Error 2
make[1]: *** [drivers/pci] Error 2
make: *** [drivers] Error 2
This seems to be occuring across a number of the powerpc systems we test
with. That driver is a power dynamic lpar IO partitioning driver.
Relevant Cc: added.
That's because somebody is breaking sysfs/kobject interfaces without
fixing all users :-) (Fair enough... it's just that we need to make sure
whoever takes care of that driver nowadays is aware of the breakage).

Ben.
Kamalesh Babulal
2007-09-18 12:07:58 UTC
Permalink
Post by Benjamin Herrenschmidt
Post by Andy Whitcroft
Post by Kamalesh Babulal
Post by Andrew Morton
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc6/2.6.23-rc6-mm1/
2.6.23-rc6-mm1 is a 29MB diff against 2.6.23-rc6.
<snip>
Hi Andrew,
The 2.6.23-rc6-mm1build fails at
CC drivers/pci/hotplug/rpadlpar_core.o
CC drivers/pci/hotplug/rpadlpar_sysfs.o
drivers/pci/hotplug/rpadlpar_sysfs.c:132: error: unknown field `name'
specified in initializer
drivers/pci/hotplug/rpadlpar_sysfs.c:142: error: structure has no member named `name'
make[3]: *** [drivers/pci/hotplug/rpadlpar_sysfs.o] Error 1
make[2]: *** [drivers/pci/hotplug] Error 2
make[1]: *** [drivers/pci] Error 2
make: *** [drivers] Error 2
This seems to be occuring across a number of the powerpc systems we test
with. That driver is a power dynamic lpar IO partitioning driver.
Relevant Cc: added.
That's because somebody is breaking sysfs/kobject interfaces without
fixing all users :-) (Fair enough... it's just that we need to make sure
whoever takes care of that driver nowadays is aware of the breakage).
Ben.
Hi Andrew,

Using the kobject_set_name function to set the kobject k_name.

Signed-off-by: Kamalesh Babulal <***@linux.vnet.ibm.com>
---
--- linux-2.6.23-rc6/drivers/pci/hotplug/rpadlpar_sysfs.c
2007-09-18 14:56:05.000000000 +0530
+++ linux-2.6.23-rc6/drivers/pci/hotplug/~rpadlpar_sysfs.c
2007-09-18 16:51:55.000000000 +0530
@@ -129,17 +129,17 @@ struct kobj_type ktype_dlpar_io = {
};

struct kset dlpar_io_kset = {
- .kobj = {.name = DLPAR_KOBJ_NAME,
- .ktype = &ktype_dlpar_io,
- .parent = &pci_hotplug_slots_subsys.kobj},
+ .kobj = {.ktype = &ktype_dlpar_io,
+ .parent = &pci_hotplug_slots_subsys.kobj},
.ktype = &ktype_dlpar_io,
};

int dlpar_sysfs_init(void)
{
+ kobject_set_name(&dlpar_io_kset.kobj, DLPAR_KOBJ_NAME);
if (kset_register(&dlpar_io_kset)) {
printk(KERN_ERR "rpadlpar_io: cannot register kset for
%s\n",
- dlpar_io_kset.kobj.name);
+ dlpar_io_kset.kobj.k_name);
return -EINVAL;
}
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
Andrew Morton
2007-09-18 16:53:23 UTC
Permalink
Post by Kamalesh Babulal
Post by Benjamin Herrenschmidt
Post by Andy Whitcroft
Post by Kamalesh Babulal
Post by Andrew Morton
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc6/2.6.23-rc6-mm1/
2.6.23-rc6-mm1 is a 29MB diff against 2.6.23-rc6.
<snip>
Hi Andrew,
The 2.6.23-rc6-mm1build fails at
CC drivers/pci/hotplug/rpadlpar_core.o
CC drivers/pci/hotplug/rpadlpar_sysfs.o
drivers/pci/hotplug/rpadlpar_sysfs.c:132: error: unknown field `name'
specified in initializer
drivers/pci/hotplug/rpadlpar_sysfs.c:142: error: structure has no member
named `name'
make[3]: *** [drivers/pci/hotplug/rpadlpar_sysfs.o] Error 1
make[2]: *** [drivers/pci/hotplug] Error 2
make[1]: *** [drivers/pci] Error 2
make: *** [drivers] Error 2
This seems to be occuring across a number of the powerpc systems we test
with. That driver is a power dynamic lpar IO partitioning driver.
Relevant Cc: added.
That's because somebody is breaking sysfs/kobject interfaces without
fixing all users :-) (Fair enough... it's just that we need to make sure
whoever takes care of that driver nowadays is aware of the breakage).
Ben.
Hi Andrew,
Using the kobject_set_name function to set the kobject k_name.
---
--- linux-2.6.23-rc6/drivers/pci/hotplug/rpadlpar_sysfs.c
2007-09-18 14:56:05.000000000 +0530
+++ linux-2.6.23-rc6/drivers/pci/hotplug/~rpadlpar_sysfs.c
2007-09-18 16:51:55.000000000 +0530
@@ -129,17 +129,17 @@ struct kobj_type ktype_dlpar_io = {
};
struct kset dlpar_io_kset = {
- .kobj = {.name = DLPAR_KOBJ_NAME,
- .ktype = &ktype_dlpar_io,
- .parent = &pci_hotplug_slots_subsys.kobj},
+ .kobj = {.ktype = &ktype_dlpar_io,
+ .parent = &pci_hotplug_slots_subsys.kobj},
.ktype = &ktype_dlpar_io,
};
int dlpar_sysfs_init(void)
{
+ kobject_set_name(&dlpar_io_kset.kobj, DLPAR_KOBJ_NAME);
if (kset_register(&dlpar_io_kset)) {
printk(KERN_ERR "rpadlpar_io: cannot register kset for
%s\n",
- dlpar_io_kset.kobj.name);
+ dlpar_io_kset.kobj.k_name);
return -EINVAL;
}
Thanks.

Your email client replaces tabs with spaces, and is performing wordwrapping.
Greg KH
2007-09-18 19:16:30 UTC
Permalink
Post by Kamalesh Babulal
Post by Benjamin Herrenschmidt
Post by Andy Whitcroft
Post by Kamalesh Babulal
Post by Andrew Morton
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc6/2.6.23-rc6-mm1/
2.6.23-rc6-mm1 is a 29MB diff against 2.6.23-rc6.
<snip>
Hi Andrew,
The 2.6.23-rc6-mm1build fails at
CC drivers/pci/hotplug/rpadlpar_core.o
CC drivers/pci/hotplug/rpadlpar_sysfs.o
drivers/pci/hotplug/rpadlpar_sysfs.c:132: error: unknown field `name'
specified in initializer
drivers/pci/hotplug/rpadlpar_sysfs.c:142: error: structure has no member named `name'
make[3]: *** [drivers/pci/hotplug/rpadlpar_sysfs.o] Error 1
make[2]: *** [drivers/pci/hotplug] Error 2
make[1]: *** [drivers/pci] Error 2
make: *** [drivers] Error 2
This seems to be occuring across a number of the powerpc systems we test
with. That driver is a power dynamic lpar IO partitioning driver.
Relevant Cc: added.
That's because somebody is breaking sysfs/kobject interfaces without
fixing all users :-) (Fair enough... it's just that we need to make sure
whoever takes care of that driver nowadays is aware of the breakage).
Ben.
Hi Andrew,
Using the kobject_set_name function to set the kobject k_name.
Close, you should also use the kobject_name() function when referencing
it.

I'll fix this up in the patch, thanks.

Oh, and sorry for breaking this, I could only test all of the modules
build on x86 due to traveling while creating this patch. I need to set
up some cross-compilers on my laptop to fix this issue :(

thanks,

greg k-h
Benjamin Herrenschmidt
2007-09-18 21:35:32 UTC
Permalink
Post by Greg KH
Oh, and sorry for breaking this, I could only test all of the modules
build on x86 due to traveling while creating this patch. I need to set
up some cross-compilers on my laptop to fix this issue :(
Yuck :-) Oh well, I hope you have a _FAST_ laptop :-)

Cheers,
Ben.
V***@vt.edu
2007-09-18 15:07:23 UTC
Permalink
Post by Andrew Morton
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc6/2.6.23-rc6-mm1/
+gregkh-driver-driver-core-add-config_uevent_helper_path.patch
So I do a 'make silentoldconfig', and I get:

*
* Generic Driver Options
*
path to uevent helper (UEVENT_HELPER_PATH) [/sbin/hotplug] (NEW)

(Hey wow - the patch has a 'help' section, but no '?' listed because it's not a
bool or tristate. You can apparently get help during 'make menuconfig' but not
'make *oldconfig'. That rocks. ;)

Yeeh. Hah. I don't *have* a /sbin/hotplug on this udev-based Fedora box. But
wait, reading the patch says that's usually during early boot. Now to figure
out what /sbin/nash does with its onboard 'hotplug' command... ;)

(In other words, this *really* needs some better help documentation, to explain
who needs this, and who doesn't need it, and what happens if you select it
and you shouldn't have, and what happens if you leave it out when you should
have set it....)
Sam Ravnborg
2007-09-18 15:50:46 UTC
Permalink
Post by V***@vt.edu
Post by Andrew Morton
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc6/2.6.23-rc6-mm1/
+gregkh-driver-driver-core-add-config_uevent_helper_path.patch
*
* Generic Driver Options
*
path to uevent helper (UEVENT_HELPER_PATH) [/sbin/hotplug] (NEW)
(Hey wow - the patch has a 'help' section, but no '?' listed because it's not a
bool or tristate. You can apparently get help during 'make menuconfig' but not
'make *oldconfig'. That rocks. ;)
Please cc: relevant people next time you complain about kconfig.

Thanks,
Sam
Miles Lane
2007-09-18 15:27:23 UTC
Permalink
Selecting Help for "Subarchitecture Type" causes "make menuconfig" to
crash, and the bash display settings have to be reset.

Miles
Miles Lane
2007-09-18 15:39:54 UTC
Permalink
Post by Miles Lane
Selecting Help for "Subarchitecture Type" causes "make menuconfig" to
crash, and the bash display settings have to be reset.
There seem to be a lot of config option help screens that are crashing
"make menuconfig".
I poked around a little and found a couple more:
Under CPU Scaling Frequency, "'userspace' governer for userspace
frequency scaling" help causes a crash.
Under IO Schedulers, if you have:
<M> Anticipatory I/O scheduler
<M> Deadline I/O scheduler
<*> CFQ I/O scheduler
Default I/O scheduler (CFQ) --->
and then select "Default I/O Scheduler (CFQ)" and then select help,
you'll get a crash.
I got another crash when I selected help for "Symmetric
multi-processing support".

It seems likely that there are loads more.
Sam Ravnborg
2007-09-18 15:52:03 UTC
Permalink
Post by Miles Lane
Selecting Help for "Subarchitecture Type" causes "make menuconfig" to
crash, and the bash display settings have to be reset.
Please cc: relevant people next time.
I will take a look.

Thanks,
Sam
Sam Ravnborg
2007-09-18 19:17:41 UTC
Permalink
Hi Miles.
Post by Miles Lane
Selecting Help for "Subarchitecture Type" causes "make menuconfig" to
crash, and the bash display settings have to be reset.
Not reproduceable here.
But I noticed that we pass a null pointer to a vsprintf function which
in the cases you pointed out printed a (null) at my system.
Could you plase try if attached patch fix your system.

Thanks,
Sam

diff --git a/scripts/kconfig/mconf.c b/scripts/kconfig/mconf.c
index 2ee12a7..1935818 100644
--- a/scripts/kconfig/mconf.c
+++ b/scripts/kconfig/mconf.c
@@ -357,8 +357,9 @@ static void get_symbol_str(struct gstr *r, struct symbol *sym)
bool hit;
struct property *prop;

- str_printf(r, "Symbol: %s [=%s]\n", sym->name,
- sym_get_string_value(sym));
+ if (sym && sym->name)
+ str_printf(r, "Symbol: %s [=%s]\n", sym->name,
+ sym_get_string_value(sym));
for_all_prompts(sym, prop)
get_prompt_str(r, prop);
hit = false;
Miles Lane
2007-09-18 19:42:58 UTC
Permalink
Post by Sam Ravnborg
Hi Miles.
Post by Miles Lane
Selecting Help for "Subarchitecture Type" causes "make menuconfig" to
crash, and the bash display settings have to be reset.
Not reproduceable here.
But I noticed that we pass a null pointer to a vsprintf function which
in the cases you pointed out printed a (null) at my system.
Could you plase try if attached patch fix your system.
Sorry, it still crashes. I am running Ubuntu pre-6.10 (Gutsy -- the
development version of the distro). Maybe I should try "make
mrproper" first?

ncurses 5.6+20070716-1ubuntu1
bash 3.2-0ubuntu9
GNU Make 3.81
Sam Ravnborg
2007-09-18 20:26:54 UTC
Permalink
Post by Miles Lane
Post by Sam Ravnborg
Hi Miles.
Post by Miles Lane
Selecting Help for "Subarchitecture Type" causes "make menuconfig" to
crash, and the bash display settings have to be reset.
Not reproduceable here.
But I noticed that we pass a null pointer to a vsprintf function which
in the cases you pointed out printed a (null) at my system.
Could you plase try if attached patch fix your system.
Sorry, it still crashes. I am running Ubuntu pre-6.10 (Gutsy -- the
development version of the distro). Maybe I should try "make
mrproper" first?
make mrproper should not do any difference here.
I rather think you hit some ncurses bug.

If you could add '-g' to HOSTCFLAGS in top-level Makefile
and then do:
rm scripts/kconfig/mconf.o scripts/kconfig/mconf
make menuconfig

(to build mconf and to check that the error is still reproduceable).
And then run it in a debugger like this:
gdb scripts/kconfig/mconf
run arch/x86_64/Kconfig
^^^^^^ replace with your actual arch

Provoke the error and get a back-trace with 'bt'.

Thanks,
Sam
Gabriel C
2007-09-18 22:38:48 UTC
Permalink
Post by Sam Ravnborg
Post by Miles Lane
Post by Sam Ravnborg
Hi Miles.
Post by Miles Lane
Selecting Help for "Subarchitecture Type" causes "make menuconfig" to
crash, and the bash display settings have to be reset.
Not reproduceable here.
But I noticed that we pass a null pointer to a vsprintf function which
in the cases you pointed out printed a (null) at my system.
Could you plase try if attached patch fix your system.
Sorry, it still crashes. I am running Ubuntu pre-6.10 (Gutsy -- the
development version of the distro). Maybe I should try "make
mrproper" first?
make mrproper should not do any difference here.
I rather think you hit some ncurses bug.
If you could add '-g' to HOSTCFLAGS in top-level Makefile
rm scripts/kconfig/mconf.o scripts/kconfig/mconf
make menuconfig
(to build mconf and to check that the error is still reproduceable).
gdb scripts/kconfig/mconf
run arch/x86_64/Kconfig
^^^^^^ replace with your actual arch
Provoke the error and get a back-trace with 'bt'.
Hi Sam,

I can reproduce this bug on Frugalware Linux.

Here the bt:

Program received signal SIGSEGV, Segmentation fault.
0xb7dc4143 in strlen () from /lib/libc.so.6
(gdb) bt
#0 0xb7dc4143 in strlen () from /lib/libc.so.6
#1 0x0804fd60 in str_append (gs=0xbfe4f6e8, s=0x0) at scripts/kconfig/util.c:87
#2 0x0804e0cb in expr_print (e=0x8e22df8, fn=0x804fda0 <expr_print_gstr_helper>, data=0xbfe4f6e8, prevtoken=0) at scripts/kconfig/expr.c:1037
#3 0x0804e1e7 in expr_gstr_print (e=0x8e22df8, gs=0xbfe4f6e8) at scripts/kconfig/expr.c:1099
#4 0x0804a07e in get_symbol_str (r=0xbfe4f6e8, sym=0x8b54ee8) at scripts/kconfig/mconf.c:334
#5 0x0804a363 in show_help (menu=0x8b54f88) at scripts/kconfig/mconf.c:738
#6 0x0804acec in conf (menu=0x8b69480) at scripts/kconfig/mconf.c:781
#7 0x0804a971 in conf (menu=0x8063c40) at scripts/kconfig/mconf.c:703
#8 0x0804af8a in main (ac=Cannot access memory at address 0x0
) at scripts/kconfig/mconf.c:917


Looks somewhat strange -> Loading Image...

PS: Is without the patch you posted , I'll try with in a bit
Post by Sam Ravnborg
Thanks,
Sam
Gabriel
Gabriel C
2007-09-18 22:48:26 UTC
Permalink
Post by Gabriel C
Post by Sam Ravnborg
Post by Miles Lane
Post by Sam Ravnborg
Hi Miles.
Post by Miles Lane
Selecting Help for "Subarchitecture Type" causes "make menuconfig" to
crash, and the bash display settings have to be reset.
Not reproduceable here.
But I noticed that we pass a null pointer to a vsprintf function which
in the cases you pointed out printed a (null) at my system.
Could you plase try if attached patch fix your system.
Sorry, it still crashes. I am running Ubuntu pre-6.10 (Gutsy -- the
development version of the distro). Maybe I should try "make
mrproper" first?
make mrproper should not do any difference here.
I rather think you hit some ncurses bug.
If you could add '-g' to HOSTCFLAGS in top-level Makefile
rm scripts/kconfig/mconf.o scripts/kconfig/mconf
make menuconfig
(to build mconf and to check that the error is still reproduceable).
gdb scripts/kconfig/mconf
run arch/x86_64/Kconfig
^^^^^^ replace with your actual arch
Provoke the error and get a back-trace with 'bt'.
Hi Sam,
I can reproduce this bug on Frugalware Linux.
Program received signal SIGSEGV, Segmentation fault.
0xb7dc4143 in strlen () from /lib/libc.so.6
(gdb) bt
#0 0xb7dc4143 in strlen () from /lib/libc.so.6
#1 0x0804fd60 in str_append (gs=0xbfe4f6e8, s=0x0) at scripts/kconfig/util.c:87
#2 0x0804e0cb in expr_print (e=0x8e22df8, fn=0x804fda0 <expr_print_gstr_helper>, data=0xbfe4f6e8, prevtoken=0) at scripts/kconfig/expr.c:1037
#3 0x0804e1e7 in expr_gstr_print (e=0x8e22df8, gs=0xbfe4f6e8) at scripts/kconfig/expr.c:1099
#4 0x0804a07e in get_symbol_str (r=0xbfe4f6e8, sym=0x8b54ee8) at scripts/kconfig/mconf.c:334
#5 0x0804a363 in show_help (menu=0x8b54f88) at scripts/kconfig/mconf.c:738
#6 0x0804acec in conf (menu=0x8b69480) at scripts/kconfig/mconf.c:781
#7 0x0804a971 in conf (menu=0x8063c40) at scripts/kconfig/mconf.c:703
#8 0x0804af8a in main (ac=Cannot access memory at address 0x0
) at scripts/kconfig/mconf.c:917
Looks somewhat strange -> http://194.231.229.228/menuconfig.png
PS: Is without the patch you posted , I'll try with in a bit
The crash is still there but the (null)'s are all fixed by this patch.

Gabriel
Sam Ravnborg
2007-09-19 19:33:08 UTC
Permalink
Post by Gabriel C
Post by Gabriel C
Post by Sam Ravnborg
Post by Miles Lane
Post by Sam Ravnborg
Hi Miles.
Post by Miles Lane
Selecting Help for "Subarchitecture Type" causes "make menuconfig" to
crash, and the bash display settings have to be reset.
Not reproduceable here.
But I noticed that we pass a null pointer to a vsprintf function which
in the cases you pointed out printed a (null) at my system.
Could you plase try if attached patch fix your system.
Sorry, it still crashes. I am running Ubuntu pre-6.10 (Gutsy -- the
development version of the distro). Maybe I should try "make
mrproper" first?
make mrproper should not do any difference here.
I rather think you hit some ncurses bug.
If you could add '-g' to HOSTCFLAGS in top-level Makefile
rm scripts/kconfig/mconf.o scripts/kconfig/mconf
make menuconfig
(to build mconf and to check that the error is still reproduceable).
gdb scripts/kconfig/mconf
run arch/x86_64/Kconfig
^^^^^^ replace with your actual arch
Provoke the error and get a back-trace with 'bt'.
Hi Sam,
I can reproduce this bug on Frugalware Linux.
Program received signal SIGSEGV, Segmentation fault.
0xb7dc4143 in strlen () from /lib/libc.so.6
(gdb) bt
#0 0xb7dc4143 in strlen () from /lib/libc.so.6
#1 0x0804fd60 in str_append (gs=0xbfe4f6e8, s=0x0) at scripts/kconfig/util.c:87
#2 0x0804e0cb in expr_print (e=0x8e22df8, fn=0x804fda0 <expr_print_gstr_helper>, data=0xbfe4f6e8, prevtoken=0) at scripts/kconfig/expr.c:1037
#3 0x0804e1e7 in expr_gstr_print (e=0x8e22df8, gs=0xbfe4f6e8) at scripts/kconfig/expr.c:1099
#4 0x0804a07e in get_symbol_str (r=0xbfe4f6e8, sym=0x8b54ee8) at scripts/kconfig/mconf.c:334
#5 0x0804a363 in show_help (menu=0x8b54f88) at scripts/kconfig/mconf.c:738
#6 0x0804acec in conf (menu=0x8b69480) at scripts/kconfig/mconf.c:781
#7 0x0804a971 in conf (menu=0x8063c40) at scripts/kconfig/mconf.c:703
#8 0x0804af8a in main (ac=Cannot access memory at address 0x0
) at scripts/kconfig/mconf.c:917
Looks somewhat strange -> http://194.231.229.228/menuconfig.png
PS: Is without the patch you posted , I'll try with in a bit
The crash is still there but the (null)'s are all fixed by this patch.
Got it. We sometimes get a numm pointer when printing the expression (in expr.c).
I have queued following fix.

Thanks for reporting!

Sam

Patch is copy'n'pased due to temporary setup troubles after upgradign to Gutsy.
Will be at kbuil.git in a few minutes.
Post by Gabriel C
From 69d39ec036b4fca541efc3c9ee31ec65d6b95bd4 Mon Sep 17 00:00:00 2001
From: Sam Ravnborg <***@ravnborg.org>
Date: Wed, 19 Sep 2007 21:23:09 +0200
Subject: [PATCH] kconfig: fix segv fault in menuconfig

With specific configurations requesting help for certain
menu lines caused menuconfig to crash.
This was tracked down to a null pointer bug.
Thanks to "Miles Lane" <***@gmail.com> for inital reporting
and to Gabriel C <***@googlemail.com> for the backtrace
that helped me locating the bug.

Signed-off-by: Sam Ravnborg <***@ravnborg.org>
---
scripts/kconfig/mconf.c | 5 +++--
scripts/kconfig/util.c | 13 ++++++++-----
2 files changed, 11 insertions(+), 7 deletions(-)

diff --git a/scripts/kconfig/mconf.c b/scripts/kconfig/mconf.c
index 2ee12a7..1935818 100644
--- a/scripts/kconfig/mconf.c
+++ b/scripts/kconfig/mconf.c
@@ -357,8 +357,9 @@ static void get_symbol_str(struct gstr *r, struct symbol *sym)
bool hit;
struct property *prop;

- str_printf(r, "Symbol: %s [=%s]\n", sym->name,
- sym_get_string_value(sym));
+ if (sym && sym->name)
+ str_printf(r, "Symbol: %s [=%s]\n", sym->name,
+ sym_get_string_value(sym));
for_all_prompts(sym, prop)
get_prompt_str(r, prop);
hit = false;
diff --git a/scripts/kconfig/util.c b/scripts/kconfig/util.c
index e3f28b9..e1cad92 100644
--- a/scripts/kconfig/util.c
+++ b/scripts/kconfig/util.c
@@ -84,12 +84,15 @@ void str_free(struct gstr *gs)
/* Append to growable string */
void str_append(struct gstr *gs, const char *s)
{
- size_t l = strlen(gs->s) + strlen(s) + 1;
- if (l > gs->len) {
- gs->s = realloc(gs->s, l);
- gs->len = l;
+ size_t l;
+ if (s) {
+ l = strlen(gs->s) + strlen(s) + 1;
+ if (l > gs->len) {
+ gs->s = realloc(gs->s, l);
+ gs->len = l;
+ }
+ strcat(gs->s, s);
}
- strcat(gs->s, s);
}

/* Append printf formatted string to growable string */
Gabriel C
2007-09-19 20:36:49 UTC
Permalink
Post by Sam Ravnborg
Post by Gabriel C
Post by Gabriel C
Post by Sam Ravnborg
Post by Miles Lane
Post by Sam Ravnborg
Hi Miles.
Post by Miles Lane
Selecting Help for "Subarchitecture Type" causes "make menuconfig" to
crash, and the bash display settings have to be reset.
Not reproduceable here.
But I noticed that we pass a null pointer to a vsprintf function which
in the cases you pointed out printed a (null) at my system.
Could you plase try if attached patch fix your system.
Sorry, it still crashes. I am running Ubuntu pre-6.10 (Gutsy -- the
development version of the distro). Maybe I should try "make
mrproper" first?
make mrproper should not do any difference here.
I rather think you hit some ncurses bug.
If you could add '-g' to HOSTCFLAGS in top-level Makefile
rm scripts/kconfig/mconf.o scripts/kconfig/mconf
make menuconfig
(to build mconf and to check that the error is still reproduceable).
gdb scripts/kconfig/mconf
run arch/x86_64/Kconfig
^^^^^^ replace with your actual arch
Provoke the error and get a back-trace with 'bt'.
Hi Sam,
I can reproduce this bug on Frugalware Linux.
Program received signal SIGSEGV, Segmentation fault.
0xb7dc4143 in strlen () from /lib/libc.so.6
(gdb) bt
#0 0xb7dc4143 in strlen () from /lib/libc.so.6
#1 0x0804fd60 in str_append (gs=0xbfe4f6e8, s=0x0) at scripts/kconfig/util.c:87
#2 0x0804e0cb in expr_print (e=0x8e22df8, fn=0x804fda0 <expr_print_gstr_helper>, data=0xbfe4f6e8, prevtoken=0) at scripts/kconfig/expr.c:1037
#3 0x0804e1e7 in expr_gstr_print (e=0x8e22df8, gs=0xbfe4f6e8) at scripts/kconfig/expr.c:1099
#4 0x0804a07e in get_symbol_str (r=0xbfe4f6e8, sym=0x8b54ee8) at scripts/kconfig/mconf.c:334
#5 0x0804a363 in show_help (menu=0x8b54f88) at scripts/kconfig/mconf.c:738
#6 0x0804acec in conf (menu=0x8b69480) at scripts/kconfig/mconf.c:781
#7 0x0804a971 in conf (menu=0x8063c40) at scripts/kconfig/mconf.c:703
#8 0x0804af8a in main (ac=Cannot access memory at address 0x0
) at scripts/kconfig/mconf.c:917
Looks somewhat strange -> http://194.231.229.228/menuconfig.png
PS: Is without the patch you posted , I'll try with in a bit
The crash is still there but the (null)'s are all fixed by this patch.
Got it. We sometimes get a numm pointer when printing the expression (in expr.c).
I have queued following fix.
Patch is fine , fixes the problem here.
Post by Sam Ravnborg
Thanks for reporting!
Sam
Patch is copy'n'pased due to temporary setup troubles after upgradign to Gutsy.
Will be at kbuil.git in a few minutes.
Post by Gabriel C
From 69d39ec036b4fca541efc3c9ee31ec65d6b95bd4 Mon Sep 17 00:00:00 2001
Date: Wed, 19 Sep 2007 21:23:09 +0200
Subject: [PATCH] kconfig: fix segv fault in menuconfig
With specific configurations requesting help for certain
menu lines caused menuconfig to crash.
This was tracked down to a null pointer bug.
that helped me locating the bug.
---
scripts/kconfig/mconf.c | 5 +++--
scripts/kconfig/util.c | 13 ++++++++-----
2 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/scripts/kconfig/mconf.c b/scripts/kconfig/mconf.c
index 2ee12a7..1935818 100644
--- a/scripts/kconfig/mconf.c
+++ b/scripts/kconfig/mconf.c
@@ -357,8 +357,9 @@ static void get_symbol_str(struct gstr *r, struct symbol *sym)
bool hit;
struct property *prop;
- str_printf(r, "Symbol: %s [=%s]\n", sym->name,
- sym_get_string_value(sym));
+ if (sym && sym->name)
+ str_printf(r, "Symbol: %s [=%s]\n", sym->name,
+ sym_get_string_value(sym));
for_all_prompts(sym, prop)
get_prompt_str(r, prop);
hit = false;
diff --git a/scripts/kconfig/util.c b/scripts/kconfig/util.c
index e3f28b9..e1cad92 100644
--- a/scripts/kconfig/util.c
+++ b/scripts/kconfig/util.c
@@ -84,12 +84,15 @@ void str_free(struct gstr *gs)
/* Append to growable string */
void str_append(struct gstr *gs, const char *s)
{
- size_t l = strlen(gs->s) + strlen(s) + 1;
- if (l > gs->len) {
- gs->s = realloc(gs->s, l);
- gs->len = l;
+ size_t l;
+ if (s) {
+ l = strlen(gs->s) + strlen(s) + 1;
+ if (l > gs->len) {
+ gs->s = realloc(gs->s, l);
+ gs->len = l;
+ }
+ strcat(gs->s, s);
}
- strcat(gs->s, s);
}
/* Append printf formatted string to growable string */
Sam Ravnborg
2007-09-19 20:43:11 UTC
Permalink
Post by Gabriel C
Post by Sam Ravnborg
Got it. We sometimes get a numm pointer when printing the expression (in expr.c).
I have queued following fix.
Patch is fine , fixes the problem here.
Thanks for testing.

Sam
Sam Ravnborg
2007-09-19 18:48:18 UTC
Permalink
Post by Gabriel C
Hi Sam,
I can reproduce this bug on Frugalware Linux.
Program received signal SIGSEGV, Segmentation fault.
0xb7dc4143 in strlen () from /lib/libc.so.6
(gdb) bt
#0 0xb7dc4143 in strlen () from /lib/libc.so.6
#1 0x0804fd60 in str_append (gs=0xbfe4f6e8, s=0x0) at scripts/kconfig/util.c:87
So the string is null and we call strlen(null) => boom.

Thanks - will post a fix in a few minutes.
Need to investigate a bit more why I do not see the crash even
though I updated to ubuntu gutsy to check it out?!?

Sam
Gabriel C
2007-09-18 15:43:35 UTC
Permalink
Hi,

I get modpost errors here :

...

ERROR: "dvb_dmx_init" [drivers/media/video/video-buf-dvb.ko] undefined!
ERROR: "dvb_unregister_adapter" [drivers/media/video/video-buf-dvb.ko] undefined!
ERROR: "dvb_register_frontend" [drivers/media/video/video-buf-dvb.ko] undefined!
ERROR: "dvb_unregister_frontend" [drivers/media/video/video-buf-dvb.ko] undefined!
ERROR: "dvb_net_release" [drivers/media/video/video-buf-dvb.ko] undefined!
ERROR: "dvb_frontend_detach" [drivers/media/video/video-buf-dvb.ko] undefined!
ERROR: "dvb_dmxdev_release" [drivers/media/video/video-buf-dvb.ko] undefined!
ERROR: "dvb_dmx_swfilter" [drivers/media/video/video-buf-dvb.ko] undefined!
ERROR: "dvb_net_init" [drivers/media/video/video-buf-dvb.ko] undefined!
ERROR: "dvb_dmx_release" [drivers/media/video/video-buf-dvb.ko] undefined!
ERROR: "dvb_register_adapter" [drivers/media/video/video-buf-dvb.ko] undefined!
ERROR: "dvb_dmxdev_init" [drivers/media/video/video-buf-dvb.ko] undefined!
ERROR: "mt2131_attach" [drivers/media/video/cx23885/cx23885.ko] undefined!
ERROR: "s5h1409_attach" [drivers/media/video/cx23885/cx23885.ko] undefined!
CC arch/i386/boot/mca.o
CC arch/i386/boot/memory.o
CC arch/i386/boot/pm.o
make[1]: *** [__modpost] Fehler 1
make: *** [modules] Fehler 2

...


config there : http://194.231.229.228/MM/2.6.23-rc6-mm1/config-modpost-errors


Regards,

Gabriel
Sam Ravnborg
2007-09-18 15:56:39 UTC
Permalink
Please cc: relevant people.
Post by Gabriel C
Hi,
...
ERROR: "dvb_dmx_init" [drivers/media/video/video-buf-dvb.ko] undefined!
ERROR: "dvb_unregister_adapter" [drivers/media/video/video-buf-dvb.ko] undefined!
ERROR: "dvb_register_frontend" [drivers/media/video/video-buf-dvb.ko] undefined!
ERROR: "dvb_unregister_frontend" [drivers/media/video/video-buf-dvb.ko] undefined!
ERROR: "dvb_net_release" [drivers/media/video/video-buf-dvb.ko] undefined!
ERROR: "dvb_frontend_detach" [drivers/media/video/video-buf-dvb.ko] undefined!
ERROR: "dvb_dmxdev_release" [drivers/media/video/video-buf-dvb.ko] undefined!
ERROR: "dvb_dmx_swfilter" [drivers/media/video/video-buf-dvb.ko] undefined!
ERROR: "dvb_net_init" [drivers/media/video/video-buf-dvb.ko] undefined!
ERROR: "dvb_dmx_release" [drivers/media/video/video-buf-dvb.ko] undefined!
ERROR: "dvb_register_adapter" [drivers/media/video/video-buf-dvb.ko] undefined!
ERROR: "dvb_dmxdev_init" [drivers/media/video/video-buf-dvb.ko] undefined!
dvb issue so dvb added.
Post by Gabriel C
ERROR: "mt2131_attach" [drivers/media/video/cx23885/cx23885.ko] undefined!
ERROR: "s5h1409_attach" [drivers/media/video/cx23885/cx23885.ko] undefined!
Was not sure who maintain this stuff..
It's not in the git-tree I had around.

Sam
Post by Gabriel C
CC arch/i386/boot/mca.o
CC arch/i386/boot/memory.o
CC arch/i386/boot/pm.o
make[1]: *** [__modpost] Fehler 1
make: *** [modules] Fehler 2
...
config there : http://194.231.229.228/MM/2.6.23-rc6-mm1/config-modpost-errors
Regards,
Gabriel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
m***@linuxtv.org
2007-09-18 16:37:16 UTC
Permalink
Post by Sam Ravnborg
Please cc: relevant people.
Post by Gabriel C
Hi,
...
ERROR: "dvb_dmx_init" [drivers/media/video/video-buf-dvb.ko] undefined!
ERROR: "dvb_unregister_adapter" [drivers/media/video/video-buf-dvb.ko] undefined!
ERROR: "dvb_register_frontend" [drivers/media/video/video-buf-dvb.ko] undefined!
ERROR: "dvb_unregister_frontend" [drivers/media/video/video-buf-dvb.ko] undefined!
ERROR: "dvb_net_release" [drivers/media/video/video-buf-dvb.ko] undefined!
ERROR: "dvb_frontend_detach" [drivers/media/video/video-buf-dvb.ko] undefined!
ERROR: "dvb_dmxdev_release" [drivers/media/video/video-buf-dvb.ko] undefined!
ERROR: "dvb_dmx_swfilter" [drivers/media/video/video-buf-dvb.ko] undefined!
ERROR: "dvb_net_init" [drivers/media/video/video-buf-dvb.ko] undefined!
ERROR: "dvb_dmx_release" [drivers/media/video/video-buf-dvb.ko] undefined!
ERROR: "dvb_register_adapter" [drivers/media/video/video-buf-dvb.ko] undefined!
ERROR: "dvb_dmxdev_init" [drivers/media/video/video-buf-dvb.ko] undefined!
dvb issue so dvb added.
Post by Gabriel C
ERROR: "mt2131_attach" [drivers/media/video/cx23885/cx23885.ko] undefined!
ERROR: "s5h1409_attach" [drivers/media/video/cx23885/cx23885.ko] undefined!
Was not sure who maintain this stuff..
It's not in the git-tree I had around.
Sam,

This stuff is in -mm only right now.

It was a dependency problem, where a new driver (cx23885) is missing the
dependency on DVB_CORE.

The fix is in this changeset:

http://linuxtv.org/hg/~mkrufky/build-fix/rev/67acaa106a99

Mauro,

Please pull from:

http://linuxtv.org/hg/~mkrufky/build-fix

for:

- VIDEO_CX23885 depends on DVB_CORE

Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

Regards,

Mike Krufky
Mauro Carvalho Chehab
2007-09-18 22:06:11 UTC
Permalink
Applied at my -git tree.

Cheers,
Mauro.
Post by Gabriel C
Post by Sam Ravnborg
Please cc: relevant people.
=20
Hi,
...
ERROR: "dvb_dmx_init" [drivers/media/video/video-buf-dvb.ko] undef=
ined!
Post by Gabriel C
Post by Sam Ravnborg
ERROR: "dvb_unregister_adapter" [drivers/media/video/video-buf-dvb=
=2Eko]
Post by Gabriel C
undefined!
Post by Sam Ravnborg
ERROR: "dvb_register_frontend" [drivers/media/video/video-buf-dvb.=
ko]
Post by Gabriel C
undefined!
Post by Sam Ravnborg
ERROR: "dvb_unregister_frontend" [drivers/media/video/video-buf-dv=
b.ko]
Post by Gabriel C
undefined!
Post by Sam Ravnborg
ERROR: "dvb_net_release" [drivers/media/video/video-buf-dvb.ko]
undefined!
Post by Sam Ravnborg
ERROR: "dvb_frontend_detach" [drivers/media/video/video-buf-dvb.ko=
]
Post by Gabriel C
undefined!
Post by Sam Ravnborg
ERROR: "dvb_dmxdev_release" [drivers/media/video/video-buf-dvb.ko]
undefined!
Post by Sam Ravnborg
ERROR: "dvb_dmx_swfilter" [drivers/media/video/video-buf-dvb.ko]
undefined!
Post by Sam Ravnborg
ERROR: "dvb_net_init" [drivers/media/video/video-buf-dvb.ko] undef=
ined!
Post by Gabriel C
Post by Sam Ravnborg
ERROR: "dvb_dmx_release" [drivers/media/video/video-buf-dvb.ko]
undefined!
Post by Sam Ravnborg
ERROR: "dvb_register_adapter" [drivers/media/video/video-buf-dvb.k=
o]
Post by Gabriel C
undefined!
Post by Sam Ravnborg
ERROR: "dvb_dmxdev_init" [drivers/media/video/video-buf-dvb.ko]
undefined!
Post by Sam Ravnborg
=20
dvb issue so dvb added.
=20
ERROR: "mt2131_attach" [drivers/media/video/cx23885/cx23885.ko]
undefined!
Post by Sam Ravnborg
ERROR: "s5h1409_attach" [drivers/media/video/cx23885/cx23885.ko]
undefined!
Post by Sam Ravnborg
=20
Was not sure who maintain this stuff..
It's not in the git-tree I had around.
=20
Sam,
=20
This stuff is in -mm only right now.
=20
It was a dependency problem, where a new driver (cx23885) is missing =
the=20
Post by Gabriel C
dependency on DVB_CORE.
=20
=20
http://linuxtv.org/hg/~mkrufky/build-fix/rev/67acaa106a99
=20
Mauro,
=20
=20
http://linuxtv.org/hg/~mkrufky/build-fix
=20
=20
- VIDEO_CX23885 depends on DVB_CORE
=20
Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
=20
Regards,
=20
Mike Krufky
Mel Gorman
2007-09-18 16:20:39 UTC
Permalink
Hi Andrew,

PPC64 failed to build with the driver drivers/net/ehea with the
following error

CC [M] drivers/net/ehea/ehea_main.o
drivers/net/ehea/ehea_main.c: In function `ehea_open':
drivers/net/ehea/ehea_main.c:2322: error: implicit declaration of function `port_napi_enable'
drivers/net/ehea/ehea_main.c: At top level:
drivers/net/ehea/ehea_main.c:2340: error: conflicting types for 'port_napi_enable'
drivers/net/ehea/ehea_main.c:2322: error: previous implicit declaration of 'port_napi_enable' was here
make[1]: *** [drivers/net/ehea/ehea_main.o] Error 1

It's buried in git-net.patch and I've cc'd a potential owner based simply
on the mention of EHEA in a leader. I've included a candidate fix for the
error. It seems to be a simple case of port_napi_enable being defined in
the wrong place.

Signed-off-by: Mel Gorman <***@csn.ul.ie>

---
ehea_main.c | 32 ++++++++++++++++----------------
1 file changed, 16 insertions(+), 16 deletions(-)

diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.23-rc6-mm1-005_fix-rpadlpar_sysfs/drivers/net/ehea/ehea_main.c linux-2.6.23-rc6-mm1-010_fix_ehea_main/drivers/net/ehea/ehea_main.c
--- linux-2.6.23-rc6-mm1-005_fix-rpadlpar_sysfs/drivers/net/ehea/ehea_main.c 2007-09-18 11:29:28.000000000 +0100
+++ linux-2.6.23-rc6-mm1-010_fix_ehea_main/drivers/net/ehea/ehea_main.c 2007-09-18 17:15:27.000000000 +0100
@@ -2307,6 +2307,22 @@ out:
return ret;
}

+static void port_napi_disable(struct ehea_port *port)
+{
+ int i;
+
+ for (i = 0; i < port->num_def_qps; i++)
+ napi_disable(&port->port_res[i].napi);
+}
+
+static void port_napi_enable(struct ehea_port *port)
+{
+ int i;
+
+ for (i = 0; i < port->num_def_qps; i++)
+ napi_enable(&port->port_res[i].napi);
+}
+
static int ehea_open(struct net_device *dev)
{
int ret;
@@ -2328,22 +2344,6 @@ static int ehea_open(struct net_device *
return ret;
}

-static void port_napi_disable(struct ehea_port *port)
-{
- int i;
-
- for (i = 0; i < port->num_def_qps; i++)
- napi_disable(&port->port_res[i].napi);
-}
-
-static void port_napi_enable(struct ehea_port *port)
-{
- int i;
-
- for (i = 0; i < port->num_def_qps; i++)
- napi_enable(&port->port_res[i].napi);
-}
-
static int ehea_down(struct net_device *dev)
{
int ret;
Mel Gorman
2007-09-18 16:41:26 UTC
Permalink
My apologies for the repost, this should have gone to netdev and Dave Miller
as well.
Post by Kamalesh Babulal
Hi Andrew,
PPC64 failed to build with the driver drivers/net/ehea with the
following error
CC [M] drivers/net/ehea/ehea_main.o
drivers/net/ehea/ehea_main.c:2322: error: implicit declaration of function `port_napi_enable'
drivers/net/ehea/ehea_main.c:2340: error: conflicting types for 'port_napi_enable'
drivers/net/ehea/ehea_main.c:2322: error: previous implicit declaration of 'port_napi_enable' was here
make[1]: *** [drivers/net/ehea/ehea_main.o] Error 1
It's buried in git-net.patch and I've cc'd a potential owner based simply
on the mention of EHEA in a leader. I've included a candidate fix for the
error. It seems to be a simple case of port_napi_enable being defined in
the wrong place.
---
ehea_main.c | 32 ++++++++++++++++----------------
1 file changed, 16 insertions(+), 16 deletions(-)
diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.23-rc6-mm1-005_fix-rpadlpar_sysfs/drivers/net/ehea/ehea_main.c linux-2.6.23-rc6-mm1-010_fix_ehea_main/drivers/net/ehea/ehea_main.c
--- linux-2.6.23-rc6-mm1-005_fix-rpadlpar_sysfs/drivers/net/ehea/ehea_main.c 2007-09-18 11:29:28.000000000 +0100
+++ linux-2.6.23-rc6-mm1-010_fix_ehea_main/drivers/net/ehea/ehea_main.c 2007-09-18 17:15:27.000000000 +0100
return ret;
}
+static void port_napi_disable(struct ehea_port *port)
+{
+ int i;
+
+ for (i = 0; i < port->num_def_qps; i++)
+ napi_disable(&port->port_res[i].napi);
+}
+
+static void port_napi_enable(struct ehea_port *port)
+{
+ int i;
+
+ for (i = 0; i < port->num_def_qps; i++)
+ napi_enable(&port->port_res[i].napi);
+}
+
static int ehea_open(struct net_device *dev)
{
int ret;
@@ -2328,22 +2344,6 @@ static int ehea_open(struct net_device *
return ret;
}
-static void port_napi_disable(struct ehea_port *port)
-{
- int i;
-
- for (i = 0; i < port->num_def_qps; i++)
- napi_disable(&port->port_res[i].napi);
-}
-
-static void port_napi_enable(struct ehea_port *port)
-{
- int i;
-
- for (i = 0; i < port->num_def_qps; i++)
- napi_enable(&port->port_res[i].napi);
-}
-
static int ehea_down(struct net_device *dev)
{
int ret;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
David Miller
2007-09-18 19:08:44 UTC
Permalink
From: ***@skynet.ie (Mel Gorman)
Date: Tue, 18 Sep 2007 17:20:39 +0100
Post by Kamalesh Babulal
Hi Andrew,
PPC64 failed to build with the driver drivers/net/ehea with the
following error
CC [M] drivers/net/ehea/ehea_main.o
drivers/net/ehea/ehea_main.c:2322: error: implicit declaration of function `port_napi_enable'
drivers/net/ehea/ehea_main.c:2340: error: conflicting types for 'port_napi_enable'
drivers/net/ehea/ehea_main.c:2322: error: previous implicit declaration of 'port_napi_enable' was here
make[1]: *** [drivers/net/ehea/ehea_main.o] Error 1
It's buried in git-net.patch and I've cc'd a potential owner based simply
on the mention of EHEA in a leader. I've included a candidate fix for the
error. It seems to be a simple case of port_napi_enable being defined in
the wrong place.
Thanks for this fix, I'll merge it into the net-2.6.24 tree.
Miles Lane
2007-09-18 17:20:19 UTC
Permalink
This post might be inappropriate. Click to display it.
Mel Gorman
2007-09-18 18:05:25 UTC
Permalink
Post by Miles Lane
LD .tmp_vmlinux1
ac.c:(.text+0x3eeec): undefined reference to `power_supply_unregister'
ac.c:(.text+0x3f10b): undefined reference to `power_supply_register'
make: *** [.tmp_vmlinux1] Error 1
Hi Miles,

The problem appears to be that ACPI_AC is compiled in but POWER_SUPPLY is
a module. You could workaround it by making them both modules but I believe
the root cause may be a dependency problem. I've included a patch below that
when you apply and run make oldconfig should allow you to build your kernel.

ACPI folks, is this a fix? If so, there may be other dependency issues that
allow a compiled-in feature to depend on a module.

Signed-off-by: Mel Gorman <***@csn.ul.ie>

---
Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.23-rc6-mm1-015_fix_ia64_kgdb/drivers/acpi/Kconfig linux-2.6.23-rc6-mm1-020_fix_acpi/drivers/acpi/Kconfig
--- linux-2.6.23-rc6-mm1-015_fix_ia64_kgdb/drivers/acpi/Kconfig 2007-09-11 03:50:29.000000000 +0100
+++ linux-2.6.23-rc6-mm1-020_fix_acpi/drivers/acpi/Kconfig 2007-09-18 19:03:32.000000000 +0100
@@ -88,7 +88,7 @@ config ACPI_PROC_EVENT

config ACPI_AC
tristate "AC Adapter"
- depends on X86
+ depends on X86 && POWER_SUPPLY
default y
help
This driver adds support for the AC Adapter object, which indicates
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Randy Dunlap
2007-09-18 17:18:39 UTC
Permalink
Post by Andrew Morton
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc6/2.6.23-rc6-mm1/
2.6.23-rc6-mm1 is a 29MB diff against 2.6.23-rc6.
git-watchdog.patch
Still complains with:

drivers/watchdog/core/watchdog_dev.c:84: warning: format '%i' expects type 'int', but argument 5 has type 'size_t'

which Satyam posted a patch for:
http://lkml.org/lkml/2007/9/3/212
and Wim replied that he had applied it... ???
http://lkml.org/lkml/2007/9/4/145 (maybe to wrong tree/branch ?)

---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
Randy Dunlap
2007-09-18 17:41:44 UTC
Permalink
Post by Randy Dunlap
Post by Andrew Morton
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc6/2.6.23-rc6-mm1/
2.6.23-rc6-mm1 is a 29MB diff against 2.6.23-rc6.
git-watchdog.patch
drivers/watchdog/core/watchdog_dev.c:84: warning: format '%i' expects type 'int', but argument 5 has type 'size_t'
Please ignore. wrong directory :(


---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
Mel Gorman
2007-09-18 17:44:08 UTC
Permalink
Hi Andrew,

IA64 failed to build in kgdb with the messages

arch/ia64/kernel/kgdb.c: In function 'kgdb_arch_set_breakpoint':
arch/ia64/kernel/kgdb.c:555: warning: large integer implicitly truncated to unsigned type
arch/ia64/kernel/kgdb.c: At top level:
arch/ia64/kernel/kgdb.c:673: error: static declaration of 'kgdb_hwbreak_sstep' follows non-static declaration
include/asm/kgdb.h:33: error: previous declaration of 'kgdb_hwbreak_sstep' was here
make[1]: *** [arch/ia64/kernel/kgdb.o] Error 1
make: *** [arch/ia64/kernel] Error 2
make: *** Waiting for unfinished jobs....

It's buried in git-kgdb.patch and I've cc'd who might be the owner. A candidate
fix is below. The build error seems to be a simple case of a badly placed
static. The warning about large integer truncating does not have an obvious
fix and I didn't want to hide the warning with a real bug.

Signed-off-by: Mel Gorman <***@csn.ul.ie>

---
kgdb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.23-rc6-mm1-010_fix_ehea_main/arch/ia64/kernel/kgdb.c linux-2.6.23-rc6-mm1-015_fix_ia64_kgdb/arch/ia64/kernel/kgdb.c
--- linux-2.6.23-rc6-mm1-010_fix_ehea_main/arch/ia64/kernel/kgdb.c 2007-09-18 11:29:26.000000000 +0100
+++ linux-2.6.23-rc6-mm1-015_fix_ia64_kgdb/arch/ia64/kernel/kgdb.c 2007-09-18 17:33:36.000000000 +0100
@@ -670,7 +670,7 @@ void kgdb_roundup_cpus(unsigned long fla
smp_send_nmi_allbutself();
}

-static volatile int kgdb_hwbreak_sstep[NR_CPUS];
+volatile int kgdb_hwbreak_sstep[NR_CPUS];

static int kgdb_notify(struct notifier_block *self, unsigned long cmd,
void *ptr)
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
Mel Gorman
2007-09-19 16:29:32 UTC
Permalink
Post by Kamalesh Babulal
Hi Andrew,
IA64 failed to build in kgdb with the messages
ppc64 kgdb support is also broken but in a much more fundamental manner.
allmodconfig shows up

In file included from include/linux/kgdb.h:22,
from arch/powerpc/kernel/legacy_serial.c:15:
include/asm/kgdb.h:34: error: 'debugger' redeclared as different kind of symbol
include/asm/system.h:85: error: previous definition of 'debugger' was here
include/asm/kgdb.h:35: error: 'debugger_bpt' redeclared as different kind of symbol
include/asm/system.h:87: error: previous definition of 'debugger_bpt' was here
include/asm/kgdb.h:36: error: 'debugger_sstep' redeclared as different kind of symbol
include/asm/system.h:88: error: previous definition of 'debugger_sstep' was here
include/asm/kgdb.h:37: error: 'debugger_iabr_match' redeclared as different kind of symbol
include/asm/system.h:89: error: previous definition of 'debugger_iabr_match' was here
include/asm/kgdb.h:38: error: 'debugger_dabr_match' redeclared as different kind of symbol
include/asm/system.h:90: error: previous definition of 'debugger_dabr_match' was here
include/asm/kgdb.h:39: error: 'debugger_fault_handler' redeclared as different kind of symbol
include/asm/system.h:91: error: previous definition of 'debugger_fault_handler' was here
In file included from arch/powerpc/kernel/legacy_serial.c:15:
include/linux/kgdb.h:69: error: `BREAK_INSTR_SIZE' undeclared here (not in a function)
make[1]: *** [arch/powerpc/kernel/legacy_serial.o] Error 1
make: *** [arch/powerpc/kernel] Error 2

I cleared the redeclarations up and put in some defines but there is
much more fundamental breakage like

kernel/kgdb.c:122: error: `BUFMAX' undeclared here (not in a function)
kernel/kgdb.c:128: error: `NUMCRITREGBYTES' undeclared here (not in a function)
kernel/kgdb.c: In function `write_mem_msg':
kernel/kgdb.c:554: error: `CACHE_FLUSH_IS_SAFE' undeclared (first use in this function)
kernel/kgdb.c:554: error: (Each undeclared identifier is reported only once
kernel/kgdb.c:554: error: for each function it appears in.)
kernel/kgdb.c: In function `getthread':
kernel/kgdb.c:615: error: implicit declaration of function `kgdb_get_shadow_thread'
kernel/kgdb.c:616: warning: return makes pointer from integer without a cast
kernel/kgdb.c: In function `kgdb_activate_sw_breakpoints':
kernel/kgdb.c:719: error: `CACHE_FLUSH_IS_SAFE' undeclared (first use in this function)
kernel/kgdb.c: In function `kgdb_deactivate_sw_breakpoints':
kernel/kgdb.c:784: error: `CACHE_FLUSH_IS_SAFE' undeclared (first use in this function)
kernel/kgdb.c: In function `kgdb_handle_exception':
kernel/kgdb.c:956: error: implicit declaration of function `kgdb_skipexception'
kernel/kgdb.c:1036: error: implicit declaration of function `kgdb_disable_hw_debug'
kernel/kgdb.c:1072: error: implicit declaration of function `kgdb_post_master_code'
kernel/kgdb.c:1153: error: implicit declaration of function `kgdb_shadow_regs'
kernel/kgdb.c:1156: warning: assignment makes pointer from integer without a cast
kernel/kgdb.c:1333: error: implicit declaration of function `kgdb_shadowinfo'
kernel/kgdb.c: In function `breakpoint':
kernel/kgdb.c:1891: error: implicit declaration of function `BREAKPOINT'
kernel/kgdb.c: At top level:
kernel/kgdb.c:122: error: storage size of `remcom_in_buffer' isn't known
kernel/kgdb.c:123: error: storage size of `remcom_out_buffer' isn't known
kernel/kgdb.c:129: error: storage size of `kgdb_fault_jmp_regs' isn't known
kernel/kgdb.c:853: error: storage size of `gdbmsgbuf' isn't known
kernel/kgdb.c:122: warning: 'remcom_in_buffer' defined but not used
kernel/kgdb.c:123: warning: 'remcom_out_buffer' defined but not used
kernel/kgdb.c:853: warning: 'gdbmsgbuf' defined but not used
make[1]: *** [kernel/kgdb.o] Error 1
make: *** [kernel] Error 2

Even with the defines fixed up, I don't know what to do about
kgdb_skipexception() and friends because frankly I don't know what I'm
doing with kgdb. linuxppc-dev added to cc list this time in case they have
something useful.

The best I was able to come up with as a candidate fix was to disable
kgdb on ppc64 altogether. This is a cop-out, not a fix, sorry.

Signed-off-by: Mel Gorman <***@csn.ul.ie>
---
Kconfig.kgdb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.23-rc6-mm1-020_fix_acpi/lib/Kconfig.kgdb linux-2.6.23-rc6-mm1-025_fix_ppc64_kgdb/lib/Kconfig.kgdb
--- linux-2.6.23-rc6-mm1-020_fix_acpi/lib/Kconfig.kgdb 2007-09-18 11:29:30.000000000 +0100
+++ linux-2.6.23-rc6-mm1-025_fix_ppc64_kgdb/lib/Kconfig.kgdb 2007-09-19 15:54:23.000000000 +0100
@@ -14,7 +14,7 @@ config KGDB
bool "KGDB: kernel debugging with remote gdb"
select WANT_EXTRA_DEBUG_INFORMATION
select KGDB_ARCH_HAS_SHADOW_INFO if X86_64
- depends on DEBUG_KERNEL && (ARM || X86 || MIPS || (SUPERH && !SUPERH64) || IA64 || PPC)
+ depends on DEBUG_KERNEL && (ARM || X86 || MIPS || (SUPERH && !SUPERH64) || IA64)
help
If you say Y here, it will be possible to remotely debug the
kernel using gdb. Documentation of kernel debugger is available
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
V***@vt.edu
2007-09-18 19:32:57 UTC
Permalink
Post by Andrew Morton
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc6/2.6.23-rc6-mm1/
% uname -a
Linux turing-police.cc.vt.edu 2.6.23-rc6-mm1 #1 SMP PREEMPT Tue Sep 18 12:32:13 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux
% uptime
15:11:48 up 36 min, 1 user, load average: 0.05, 0.11, 0.09

Had a few issues, all self-inflicted (the biggie was 2 iptables modules that
needed fixing for the net namespace changes in git-net.patch - stuck an
&init_net in the right 2 places, a new #include line, and all was good).

I *did* have an odd issue with an out-of-tree GPL driver for a webcam.
(It's from http://mxhaard.free.fr/ if anybody cares).

The Makefile does this:

make -C /lib/modules/`uname -r`/build SUBDIRS=/home/valdis/src/gspcav1-20070508 CC=cc modules

and has this sort of stuff in it:

DEFINES += -DGSPCA_ENABLE_DEBUG
DEFINES += -DCONFIG_USB_GSPCA_MODULE=1 -DMODULE -D__KERNEL__
DEFINES += -DVID_HARDWARE_GSPCA=0xFF -DGSPCA_VERSION=\"$(VERSION)\"

In -rc4-mm1, $DEFINES got added to the compile command - in -rc6-mm1, I
had to namually add a 'CFLAGS += $(DEFINES)' or GSPCA_VERSION came up undefined.

The actual problematic code in the Makefile:

-- begin Makefile snippet
ifneq ($(KERNELRELEASE),) # We were called by kbuild
CFLAGS += $(DEFINES)
obj-m += gspca.o
gspca-objs := gspca_core.o decoder/gspcadecoder.o

else # We were called from command line

KERNEL_VERSION = `uname -r`
KERNELDIR := /lib/modules/$(KERNEL_VERSION)/build
PWD := $(shell pwd)
MODULE_INSTALLDIR = /lib/modules/$(KERNEL_VERSION)/kernel/drivers/usb/media/
MODULE_INSTALLDIR2 = /lib/modules/$(KERNEL_VERSION)/kernel/drivers/media/video/

default:
$(MAKE) -C $(KERNELDIR) SUBDIRS=$(PWD) CC=$(CC) modules

install:
mkdir -p $(MODULE_INSTALLDIR)
rm -f $(MODULE_INSTALLDIR)spca5xx.ko
rm -f $(MODULE_INSTALLDIR2)gspca.ko
install -c -m 0644 gspca.ko $(MODULE_INSTALLDIR)
/sbin/depmod -ae

uninstall:
rm -f $(MODULE_INSTALLDIR)gspca.ko
/sbin/depmod -aq

endif
--- end Makefile snippet

The Make definitely falls into the 'else' part (verified by adding an 'echo'
to the default: target). Adding the CFLAGS += to the else, or moving the line
above the if, makes it work.
Sam Ravnborg
2007-09-18 20:32:39 UTC
Permalink
Post by V***@vt.edu
Post by Andrew Morton
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc6/2.6.23-rc6-mm1/
% uname -a
Linux turing-police.cc.vt.edu 2.6.23-rc6-mm1 #1 SMP PREEMPT Tue Sep 18 12:32:13 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux
% uptime
15:11:48 up 36 min, 1 user, load average: 0.05, 0.11, 0.09
Had a few issues, all self-inflicted (the biggie was 2 iptables modules that
needed fixing for the net namespace changes in git-net.patch - stuck an
&init_net in the right 2 places, a new #include line, and all was good).
I *did* have an odd issue with an out-of-tree GPL driver for a webcam.
(It's from http://mxhaard.free.fr/ if anybody cares).
make -C /lib/modules/`uname -r`/build SUBDIRS=/home/valdis/src/gspcav1-20070508 CC=cc modules
DEFINES += -DGSPCA_ENABLE_DEBUG
DEFINES += -DCONFIG_USB_GSPCA_MODULE=1 -DMODULE -D__KERNEL__
DEFINES += -DVID_HARDWARE_GSPCA=0xFF -DGSPCA_VERSION=\"$(VERSION)\"
In -rc4-mm1, $DEFINES got added to the compile command - in -rc6-mm1, I
had to namually add a 'CFLAGS += $(DEFINES)' or GSPCA_VERSION came up undefined.
-- begin Makefile snippet
ifneq ($(KERNELRELEASE),) # We were called by kbuild
CFLAGS += $(DEFINES)
obj-m += gspca.o
gspca-objs := gspca_core.o decoder/gspcadecoder.o
So the external module were fiddeling with CFLAGS which is wrong.
Yes - it worked before by accident.
=====================================================================
--- 3.7 Compilation flags

EXTRA_CFLAGS, EXTRA_AFLAGS, EXTRA_LDFLAGS, EXTRA_ARFLAGS

All the EXTRA_ variables apply only to the kbuild makefile
where they are assigned. The EXTRA_ variables apply to all
commands executed in the kbuild makefile.

$(EXTRA_CFLAGS) specifies options for compiling C files with
$(CC).

Example:
# drivers/sound/emu10k1/Makefile
EXTRA_CFLAGS += -I$(obj)
ifdef DEBUG
EXTRA_CFLAGS += -DEMU10K1_DEBUG
endif


This variable is necessary because the top Makefile owns the
variable $(KBUILD_CFLAGS) and uses it for compilation flags for the
entire tree.
=====================================================================

Nowhere are the use of CFLAGS documented.
The use of EXTRA_CFLAGS has been working as far back as I remember so
there is no backward compatibility issues to my best knowledge.

Pelase ask the author of the module to either fix it or even better
submit the driver for inclusion because then we will find it during
the review pahse.

But anyway - thanks for reporting an issue related to an external module.

Sam
V***@vt.edu
2007-09-18 22:03:28 UTC
Permalink
Post by Sam Ravnborg
So the external module were fiddeling with CFLAGS which is wrong.
Yes - it worked before by accident.
OK, I can deal with that diagnosis. ;)
Post by Sam Ravnborg
Pelase ask the author of the module to either fix it or even better
submit the driver for inclusion because then we will find it during
the review pahse.
I'll take it up with the author, and see what happens...
Post by Sam Ravnborg
But anyway - thanks for reporting an issue related to an external module.
I had a few issues with some other modules, but they're evil binaries so
I'm taking those up directly with the companies involved.. ;)
Sam Ravnborg
2007-09-19 07:34:02 UTC
Permalink
Post by V***@vt.edu
Post by Sam Ravnborg
So the external module were fiddeling with CFLAGS which is wrong.
Yes - it worked before by accident.
OK, I can deal with that diagnosis. ;)
Post by Sam Ravnborg
Pelase ask the author of the module to either fix it or even better
submit the driver for inclusion because then we will find it during
the review pahse.
I'll take it up with the author, and see what happens...
Post by Sam Ravnborg
But anyway - thanks for reporting an issue related to an external module.
I had a few issues with some other modules, but they're evil binaries so
I'm taking those up directly with the companies involved.. ;)
How annoying is this - and is this the CFLAGS thing again?
We could introduce some workaraound so we continue to respect
the CFLAGS settings in a Makefile for a while.
But at the end of the day we should convince the external module people
to follow the Kbuild docs. So it will then be temporary.

Opinion?

Sam
V***@vt.edu
2007-09-19 15:53:23 UTC
Permalink
Post by Sam Ravnborg
Post by V***@vt.edu
I had a few issues with some other modules, but they're evil binaries so
I'm taking those up directly with the companies involved.. ;)
How annoying is this - and is this the CFLAGS thing again?
The other issues were VMWare and the removal of EXPORT_SYMBOL(set_dumpable),
and NVidia graphics driver not playing nice with x86_64-mm-cpa-clflush.patch
(these actually broke back around -rc[34]-mm1, so it's not a new issue). I
just had to spend 5 minutes re-checking that my workarounds did/didn't need
refreshing. Like I said, their problems (and mine), not lkml's.
Post by Sam Ravnborg
We could introduce some workaraound so we continue to respect
the CFLAGS settings in a Makefile for a while.
But at the end of the day we should convince the external module people
to follow the Kbuild docs. So it will then be temporary.
I already sent the author a patch for the broken Makefile. I don't think an
in-tree workaround is the right thing here. I've vote for an entry in the
"What's new in 2.6.2X" document when the kbuild changes go mainline, since
fixing it to use EXTRA_CFLAGS worked perfectly. External module maintainers
have (presumably) already read stable-API-nonsense, and should be used to
fixing code for new releases, so a 1 or 2 line Makefile tweak shouldn't be a
hardship.
Sam Ravnborg
2007-09-19 17:39:12 UTC
Permalink
Post by V***@vt.edu
Post by Sam Ravnborg
Post by V***@vt.edu
I had a few issues with some other modules, but they're evil binaries so
I'm taking those up directly with the companies involved.. ;)
How annoying is this - and is this the CFLAGS thing again?
The other issues were VMWare and the removal of EXPORT_SYMBOL(set_dumpable),
and NVidia graphics driver not playing nice with x86_64-mm-cpa-clflush.patch
(these actually broke back around -rc[34]-mm1, so it's not a new issue). I
just had to spend 5 minutes re-checking that my workarounds did/didn't need
refreshing. Like I said, their problems (and mine), not lkml's.
Post by Sam Ravnborg
We could introduce some workaraound so we continue to respect
the CFLAGS settings in a Makefile for a while.
But at the end of the day we should convince the external module people
to follow the Kbuild docs. So it will then be temporary.
I already sent the author a patch for the broken Makefile. I don't think an
in-tree workaround is the right thing here. I've vote for an entry in the
"What's new in 2.6.2X" document when the kbuild changes go mainline, since
fixing it to use EXTRA_CFLAGS worked perfectly.
Very good suggestion. I will try to make it happen when this hit mainline.
Thanks!
Post by V***@vt.edu
External module maintainers
have (presumably) already read stable-API-nonsense, and should be used to
fixing code for new releases, so a 1 or 2 line Makefile tweak shouldn't be a
hardship.
No but then on the other hand I do not want to make life too dificult for
the (non-binary) external modules.
I will keep an eye out for additional CFLAGS mis-use and if I get no more than
a few report I will no do the backward compatibility thing.

Sam
Rafael J. Wysocki
2007-09-18 20:21:53 UTC
Permalink
Post by Andrew Morton
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc6/2.6.23-rc6-mm1/
2.6.23-rc6-mm1 is a 29MB diff against 2.6.23-rc6.
It took me over two solid days to get this lot compiling and booting on a few
boxes. This required around ninety fixup patches and patch droppings. There
are several bugs in here which I know of (details below) and presumably many
more which I don't know of. I have to say that this just isn't working any
more.
- The Vaio hangs when quitting X due to x86_64-mm-cpa-clflush.patch, but
I didn't drop that patch because the iommu patch series depends on it.
- The Vaio also hangs during resume-from-RAM, due to git-acpi.patch
- And it hangs during suspend-to-RAM, due to git-acpi.patch
On my HP nx6325 it only boots with "noacpitimer nohpet" on the command line,
but then it works. Suspend-to-RAM and hibernation work too. :-)

Since 2.6.23-rc4-mm1 only booted with nohpet because of

x86_64-convert-to-clockevents.patch

I guess that the boot problems with this one result from the same patch.

Greetings,
Rafael
Rafael J. Wysocki
2007-09-18 20:54:54 UTC
Permalink
Post by Rafael J. Wysocki
Post by Andrew Morton
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc6/2.6.23-rc6-mm1/
2.6.23-rc6-mm1 is a 29MB diff against 2.6.23-rc6.
It took me over two solid days to get this lot compiling and booting on a few
boxes. This required around ninety fixup patches and patch droppings. There
are several bugs in here which I know of (details below) and presumably many
more which I don't know of. I have to say that this just isn't working any
more.
- The Vaio hangs when quitting X due to x86_64-mm-cpa-clflush.patch, but
I didn't drop that patch because the iommu patch series depends on it.
- The Vaio also hangs during resume-from-RAM, due to git-acpi.patch
- And it hangs during suspend-to-RAM, due to git-acpi.patch
Sorry, I was wrong.
Post by Rafael J. Wysocki
On my HP nx6325 it only boots with "noacpitimer nohpet" on the command line,
but then it works.
It _sometimes_ boots with "noacpitimer nohpet" and that's if I press the power
button for a couple of times during boot (before any messages appear on the
console).
Post by Rafael J. Wysocki
Suspend-to-RAM and hibernation work too. :-)
No, they don't (I must have booted -rc6 instead of it by mistake, sigh).
Post by Rafael J. Wysocki
Since 2.6.23-rc4-mm1 only booted with nohpet because of
x86_64-convert-to-clockevents.patch
I guess that the boot problems with this one result from the same patch.
Not sure any more ...

I'll try to compile it with NO_HZ and HIGH_RES_TIMERS unset.

Greetings,
Rafael
Rafael J. Wysocki
2007-09-18 21:37:12 UTC
Permalink
Post by Rafael J. Wysocki
Post by Rafael J. Wysocki
Post by Andrew Morton
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc6/2.6.23-rc6-mm1/
2.6.23-rc6-mm1 is a 29MB diff against 2.6.23-rc6.
It took me over two solid days to get this lot compiling and booting on a few
boxes. This required around ninety fixup patches and patch droppings. There
are several bugs in here which I know of (details below) and presumably many
more which I don't know of. I have to say that this just isn't working any
more.
- The Vaio hangs when quitting X due to x86_64-mm-cpa-clflush.patch, but
I didn't drop that patch because the iommu patch series depends on it.
- The Vaio also hangs during resume-from-RAM, due to git-acpi.patch
- And it hangs during suspend-to-RAM, due to git-acpi.patch
Sorry, I was wrong.
Post by Rafael J. Wysocki
On my HP nx6325 it only boots with "noacpitimer nohpet" on the command line,
but then it works.
It _sometimes_ boots with "noacpitimer nohpet" and that's if I press the power
button for a couple of times during boot (before any messages appear on the
console).
Post by Rafael J. Wysocki
Suspend-to-RAM and hibernation work too. :-)
No, they don't (I must have booted -rc6 instead of it by mistake, sigh).
Post by Rafael J. Wysocki
Since 2.6.23-rc4-mm1 only booted with nohpet because of
x86_64-convert-to-clockevents.patch
I guess that the boot problems with this one result from the same patch.
Not sure any more ...
I'll try to compile it with NO_HZ and HIGH_RES_TIMERS unset.
OK, in that configuration it's much better.

It boots with nohpet alone and suspend/hibernation seem to work (still,
it didn't want to boot right after hibernation, but booted after I'd switched
it off/on manually).

Unfortunately, I get this in dmesg:

ALSA /home/rafael/src/mm/linux-2.6.23-rc6-mm1/sound/pci/hda/hda_intel.c:1758: hda-intel: ioremap error

and (obviously) the sound card doesn't work.

Additionally, I've got a couple of these:

WARNING: at /home/rafael/src/mm/linux-2.6.23-rc6-mm1/drivers/usb/core/driver.c:1
217 usb_autopm_do_device()

Call Trace:
[<ffffffff8813885e>] :usbcore:usb_autopm_do_device+0x60/0xe9
[<ffffffff88138910>] :usbcore:usb_autosuspend_device+0xc/0xe
[<ffffffff88131aa8>] :usbcore:usb_disconnect+0x15f/0x18c
[<ffffffff88133305>] :usbcore:hub_thread+0x691/0x10a1
[<ffffffff8024a077>] autoremove_wake_function+0x0/0x38
[<ffffffff88132c74>] :usbcore:hub_thread+0x0/0x10a1
[<ffffffff80249f50>] kthread+0x49/0x79
[<ffffffff8020ce98>] child_rip+0xa/0x12
[<ffffffff80249f07>] kthread+0x0/0x79
[<ffffffff8020ce8e>] child_rip+0x0/0x12

Greetings,
Rafael

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Thomas Gleixner
2007-09-19 07:06:00 UTC
Permalink
Post by Rafael J. Wysocki
Post by Rafael J. Wysocki
Post by Rafael J. Wysocki
Post by Andrew Morton
- The Vaio also hangs during resume-from-RAM, due to git-acpi.patch
- And it hangs during suspend-to-RAM, due to git-acpi.patch
Sorry, I was wrong.
Post by Rafael J. Wysocki
On my HP nx6325 it only boots with "noacpitimer nohpet" on the command line,
but then it works.
It _sometimes_ boots with "noacpitimer nohpet" and that's if I press the power
button for a couple of times during boot (before any messages appear on the
console).
Post by Rafael J. Wysocki
Suspend-to-RAM and hibernation work too. :-)
No, they don't (I must have booted -rc6 instead of it by mistake, sigh).
Post by Rafael J. Wysocki
Since 2.6.23-rc4-mm1 only booted with nohpet because of
x86_64-convert-to-clockevents.patch
I guess that the boot problems with this one result from the same patch.
Not sure any more ...
I'll try to compile it with NO_HZ and HIGH_RES_TIMERS unset.
OK, in that configuration it's much better.
It boots with nohpet alone and suspend/hibernation seem to work (still,
it didn't want to boot right after hibernation, but booted after I'd switched
it off/on manually).
Can you please check, whether

http://tglx.de/projects/hrtimers/2.6.23-rc6/patch-2.6.23-rc6-hrt2.patch

works for you ?

tglx
Rafael J. Wysocki
2007-09-19 17:44:21 UTC
Permalink
Post by Thomas Gleixner
Post by Rafael J. Wysocki
Post by Rafael J. Wysocki
Post by Rafael J. Wysocki
Post by Andrew Morton
- The Vaio also hangs during resume-from-RAM, due to git-acpi.patch
- And it hangs during suspend-to-RAM, due to git-acpi.patch
Sorry, I was wrong.
Post by Rafael J. Wysocki
On my HP nx6325 it only boots with "noacpitimer nohpet" on the command line,
but then it works.
It _sometimes_ boots with "noacpitimer nohpet" and that's if I press the power
button for a couple of times during boot (before any messages appear on the
console).
Post by Rafael J. Wysocki
Suspend-to-RAM and hibernation work too. :-)
No, they don't (I must have booted -rc6 instead of it by mistake, sigh).
Post by Rafael J. Wysocki
Since 2.6.23-rc4-mm1 only booted with nohpet because of
x86_64-convert-to-clockevents.patch
I guess that the boot problems with this one result from the same patch.
Not sure any more ...
I'll try to compile it with NO_HZ and HIGH_RES_TIMERS unset.
OK, in that configuration it's much better.
It boots with nohpet alone and suspend/hibernation seem to work (still,
it didn't want to boot right after hibernation, but booted after I'd switched
it off/on manually).
Can you please check, whether
http://tglx.de/projects/hrtimers/2.6.23-rc6/patch-2.6.23-rc6-hrt2.patch
works for you ?
Nope. It's a total disaster. :-(

Doesn't boot at all, even with "noacpitimer nohpet", and that's with
NO_HZ and HIGH_RES_TIMERS unset.

If you have a bisectable patch series, I can try to identify the responsible
patch.

Greetings,
Rafael
Thomas Gleixner
2007-09-19 19:21:30 UTC
Permalink
Post by Rafael J. Wysocki
Post by Thomas Gleixner
Post by Rafael J. Wysocki
It boots with nohpet alone and suspend/hibernation seem to work (still,
it didn't want to boot right after hibernation, but booted after I'd switched
it off/on manually).
Can you please check, whether
http://tglx.de/projects/hrtimers/2.6.23-rc6/patch-2.6.23-rc6-hrt2.patch
works for you ?
Nope. It's a total disaster. :-(
True. I have instrumented it to the point where the broadcast device is
programmed, but no interrupt comes in for totally unknown reasons.
Post by Rafael J. Wysocki
Doesn't boot at all, even with "noacpitimer nohpet", and that's with
NO_HZ and HIGH_RES_TIMERS unset.
If you have a bisectable patch series, I can try to identify the responsible
patch.
http://tglx.de/projects/hrtimers/2.6.23-rc6/patch-2.6.23-rc6-hrt2.patches.tar.bz2

The first patches in the queue are the mainline fixups.

tglx



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Rafael J. Wysocki
2007-09-20 00:06:20 UTC
Permalink
Post by Thomas Gleixner
Post by Rafael J. Wysocki
Post by Thomas Gleixner
Post by Rafael J. Wysocki
It boots with nohpet alone and suspend/hibernation seem to work (still,
it didn't want to boot right after hibernation, but booted after I'd switched
it off/on manually).
Can you please check, whether
http://tglx.de/projects/hrtimers/2.6.23-rc6/patch-2.6.23-rc6-hrt2.patch
works for you ?
Nope. It's a total disaster. :-(
True. I have instrumented it to the point where the broadcast device is
programmed, but no interrupt comes in for totally unknown reasons.
Post by Rafael J. Wysocki
Doesn't boot at all, even with "noacpitimer nohpet", and that's with
NO_HZ and HIGH_RES_TIMERS unset.
If you have a bisectable patch series, I can try to identify the responsible
patch.
http://tglx.de/projects/hrtimers/2.6.23-rc6/patch-2.6.23-rc6-hrt2.patches.tar.bz2
The first patches in the queue are the mainline fixups.
It's x86_64-convert-to-clockevents.patch (ie. after applying it the box stops
to boot).

I haven't had the time to check if any special command line arguments help.
Will check tomorrow.

Greetings,
Rafael

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
linux-usb-***@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Thomas Gleixner
2007-09-20 06:18:48 UTC
Permalink
Post by Rafael J. Wysocki
Post by Thomas Gleixner
Post by Rafael J. Wysocki
Post by Thomas Gleixner
Post by Rafael J. Wysocki
It boots with nohpet alone and suspend/hibernation seem to work (still,
it didn't want to boot right after hibernation, but booted after I'd switched
it off/on manually).
Can you please check, whether
http://tglx.de/projects/hrtimers/2.6.23-rc6/patch-2.6.23-rc6-hrt2.patch
works for you ?
Nope. It's a total disaster. :-(
True. I have instrumented it to the point where the broadcast device is
programmed, but no interrupt comes in for totally unknown reasons.
Post by Rafael J. Wysocki
Doesn't boot at all, even with "noacpitimer nohpet", and that's with
NO_HZ and HIGH_RES_TIMERS unset.
If you have a bisectable patch series, I can try to identify the responsible
patch.
http://tglx.de/projects/hrtimers/2.6.23-rc6/patch-2.6.23-rc6-hrt2.patches.tar.bz2
The first patches in the queue are the mainline fixups.
It's x86_64-convert-to-clockevents.patch (ie. after applying it the box stops
to boot).
I haven't had the time to check if any special command line arguments help.
Will check tomorrow.
Can you please disable the patches, which I sent Linus wards:

timekeeping-access-rtc-outside-xtime-lock.patch
xtime-supsend-resume-fixup.patch
acpi-reevaluate-c-p-t-states.patch
clockevents-enforce-broadcast-on-resume.patch
clockevents-do-not-shutdown-broadcast-device-in-oneshot-mode.patch
clockevents-prevent-stale-tick-update-on-offline-cpu.patch

Without those patches you get the state of rc4-mm1. It would be
interesting to know which one interferes with the acpi stuff.

tglx
Mathieu Desnoyers
2007-09-18 20:54:03 UTC
Permalink
Hello,

I got the following error when building 2.6.23-rc6-mm1 on sparc:


/opt/crosstool/gcc-4.1.1-glibc-2.3.6/sparc-unknown-linux-gnu/bin/sparc-unknown-linux-gnu-gcc -Wp,-MD,drivers/serial/.serial_core.o.d -nostdinc -isystem /opt/crosstool/gcc-4.1.1-glibc-2.3.6/sparc-unknown-linux-gnu/lib/gcc/sparc-unknown-linux-gnu/4.1.1/include -D__KERNEL__ -Iinclude -Iinclude2 -I/home/compudj/git/linux-2.6-lttng/include -include include/linux/autoconf.h -I/home/compudj/git/linux-2.6-lttng/drivers/serial -Idrivers/serial -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Os -m32 -pipe -mno-fpu -fcall-used-g5 -fcall-used-g7 -fomit-frame-pointer -fno-stack-protector -Wdeclaration-after-statement -Wno-pointer-sign -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(serial_core)" -D"KBUILD_MODNAME=KBUILD_S
TR(serial_core)" -c -o drivers/serial/.tmp_serial_core.o /home/compudj/git/linux-2.6-lttng/drivers/serial/serial_core.c
/home/compudj/git/linux-2.6-lttng/drivers/serial/serial_core.c: In function 'uart_suspend_port':
/home/compudj/git/linux-2.6-lttng/drivers/serial/serial_core.c:1980: error: implicit declaration of function 'enable_irq_wake'
/home/compudj/git/linux-2.6-lttng/drivers/serial/serial_core.c: In function 'uart_resume_port':
/home/compudj/git/linux-2.6-lttng/drivers/serial/serial_core.c:2035: error: implicit declaration of function 'disable_irq_wake'
make[3]: *** [drivers/serial/serial_core.o] Error 1
make[2]: *** [drivers/serial] Error 2
make[1]: *** [drivers] Error 2
make: *** [_all] Error 2

config:

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.23-rc6-mm1
# Tue Sep 18 11:06:46 2007
#
CONFIG_MMU=y
CONFIG_HIGHMEM=y
CONFIG_ZONE_DMA=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_ARCH_NO_VIRT_TO_BUS=y
CONFIG_OF=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"

#
# General setup
#
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
# CONFIG_POSIX_MQUEUE is not set
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_TASKSTATS is not set
# CONFIG_USER_NS is not set
# CONFIG_AUDIT is not set
# CONFIG_IKCONFIG is not set
CONFIG_LOG_BUF_SHIFT=14
# CONFIG_CONTAINERS is not set
CONFIG_SYSFS_DEPRECATED=y
# CONFIG_RELAY is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SYSCTL=y
# CONFIG_EMBEDDED is not set
CONFIG_UID16=y
CONFIG_SYSCTL_SYSCALL=y
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_FUTEX=y
CONFIG_ANON_INODES=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_SLAB=y
# CONFIG_SLUB is not set
# CONFIG_SLOB is not set
CONFIG_PROC_PAGE_MONITOR=y
CONFIG_PROC_KPAGEMAP=y
CONFIG_RT_MUTEXES=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
# CONFIG_MODULE_UNLOAD is not set
CONFIG_MODVERSIONS=y
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y
CONFIG_BLOCK=y
# CONFIG_LBD is not set
# CONFIG_BLK_DEV_IO_TRACE is not set
# CONFIG_LSF is not set
# CONFIG_BLK_DEV_BSG 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"

#
# General machine setup
#
# CONFIG_SMP is not set
CONFIG_SPARC=y
CONFIG_SPARC32=y
CONFIG_SBUS=y
CONFIG_SBUSCHAR=y
CONFIG_SERIAL_CONSOLE=y
CONFIG_SUN_AUXIO=y
CONFIG_SUN_IO=y
CONFIG_RWSEM_GENERIC_SPINLOCK=y
CONFIG_GENERIC_FIND_NEXT_BIT=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
# CONFIG_ARCH_HAS_ILOG2_U32 is not set
# CONFIG_ARCH_HAS_ILOG2_U64 is not set
CONFIG_EMULATED_CMPXCHG=y
CONFIG_SUN_PM=y
# CONFIG_SUN4 is not set
# CONFIG_PCI is not set
# CONFIG_PCI_SYSCALL is not set
# CONFIG_ARCH_SUPPORTS_MSI is not set
CONFIG_NO_DMA=y
CONFIG_SUN_OPENPROMFS=m
# CONFIG_SPARC_LED is not set
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_AOUT=y
CONFIG_BINFMT_MISC=m
CONFIG_SUNOS_EMUL=y
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y
# CONFIG_DISCONTIGMEM_MANUAL is not set
# CONFIG_SPARSEMEM_MANUAL is not set
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
# CONFIG_SPARSEMEM_STATIC is not set
# CONFIG_SPARSEMEM_VMEMMAP_ENABLE is not set
CONFIG_SPLIT_PTLOCK_CPUS=4
# CONFIG_RESOURCES_64BIT is not set
CONFIG_ZONE_DMA_FLAG=1
CONFIG_BOUNCE=y

#
# Networking
#
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
# CONFIG_PACKET_MMAP is not set
CONFIG_UNIX=y
CONFIG_XFRM=y
# CONFIG_XFRM_USER is not set
# CONFIG_XFRM_SUB_POLICY is not set
# CONFIG_XFRM_MIGRATE is not set
# CONFIG_NET_KEY is not set
CONFIG_INET=y
# CONFIG_IP_MULTICAST is not set
# CONFIG_IP_ADVANCED_ROUTER is not set
CONFIG_IP_FIB_HASH=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 is not set
# 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=m
CONFIG_INET_XFRM_MODE_TRANSPORT=y
CONFIG_INET_XFRM_MODE_TUNNEL=y
CONFIG_INET_XFRM_MODE_BEET=y
CONFIG_INET_LRO=m
CONFIG_INET_DIAG=y
CONFIG_INET_TCP_DIAG=y
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_CUBIC=y
CONFIG_DEFAULT_TCP_CONG="cubic"
# CONFIG_TCP_MD5SIG is not set
CONFIG_IPV6=m
# CONFIG_IPV6_PRIVACY is not set
# CONFIG_IPV6_ROUTER_PREF is not set
# CONFIG_IPV6_OPTIMISTIC_DAD is not set
# CONFIG_INET6_AH is not set
# CONFIG_INET6_ESP is not set
# CONFIG_INET6_IPCOMP is not set
# CONFIG_IPV6_MIP6 is not set
# CONFIG_INET6_XFRM_TUNNEL is not set
# CONFIG_INET6_TUNNEL is not set
CONFIG_INET6_XFRM_MODE_TRANSPORT=m
CONFIG_INET6_XFRM_MODE_TUNNEL=m
CONFIG_INET6_XFRM_MODE_BEET=m
# CONFIG_INET6_XFRM_MODE_ROUTEOPTIMIZATION is not set
CONFIG_IPV6_SIT=m
# CONFIG_IPV6_TUNNEL is not set
# CONFIG_IPV6_MULTIPLE_TABLES is not set
# CONFIG_NETWORK_SECMARK is not set
# CONFIG_NETFILTER is not set
# CONFIG_IP_DCCP is not set
# CONFIG_IP_SCTP is not set
# CONFIG_TIPC is not set
# CONFIG_ATM is not set
# CONFIG_BRIDGE is not set
# CONFIG_VLAN_8021Q is not set
CONFIG_DECNET=m
# CONFIG_DECNET_ROUTER is not set
CONFIG_LLC=m
# CONFIG_LLC2 is not set
CONFIG_IPX=m
# CONFIG_IPX_INTERN is not set
CONFIG_ATALK=m
# CONFIG_DEV_APPLETALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB 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=m
# CONFIG_HAMRADIO is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
# CONFIG_AF_RXRPC is not set

#
# Wireless
#
# CONFIG_CFG80211 is not set
# CONFIG_WIRELESS_EXT is not set
# CONFIG_MAC80211 is not set
# CONFIG_IEEE80211 is not set
# CONFIG_RFKILL is not set
# CONFIG_NET_9P is not set

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
# CONFIG_FW_LOADER is not set
# CONFIG_SYS_HYPERVISOR is not set
# CONFIG_CONNECTOR is not set
# CONFIG_MTD is not set
CONFIG_OF_DEVICE=y
# CONFIG_PARPORT is not set
# CONFIG_BLK_DEV is not set
# CONFIG_MISC_DEVICES is not set
# CONFIG_IDE is not set

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

#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=y
CONFIG_CHR_DEV_ST=y
# CONFIG_CHR_DEV_OSST is not set
CONFIG_BLK_DEV_SR=y
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
# CONFIG_SCSI_SCAN_ASYNC is not set
CONFIG_SCSI_WAIT_SCAN=m

#
# SCSI Transports
#
# CONFIG_SCSI_SPI_ATTRS is not set
# CONFIG_SCSI_FC_ATTRS is not set
# CONFIG_SCSI_ISCSI_ATTRS is not set
# CONFIG_SCSI_SAS_LIBSAS is not set
# CONFIG_SCSI_SRP_ATTRS is not set
# CONFIG_SCSI_LOWLEVEL is not set
# CONFIG_ATA is not set
# CONFIG_MD is not set
CONFIG_NETDEVICES=y
# CONFIG_NETDEVICES_MULTIQUEUE is not set
CONFIG_DUMMY=m
CONFIG_BONDING=m
# CONFIG_MACVLAN is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set
# CONFIG_VETH is not set
# CONFIG_NET_ETHERNET is not set
CONFIG_NETDEV_1000=y
CONFIG_MYRI_SBUS=m
CONFIG_NETDEV_10000=y

#
# Wireless LAN
#
# CONFIG_WLAN_PRE80211 is not set
# CONFIG_WLAN_80211 is not set
# CONFIG_WAN is not set
CONFIG_PPP=m
# CONFIG_PPP_MULTILINK is not set
# CONFIG_PPP_FILTER is not set
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_PPPOL2TP is not set
CONFIG_SLIP=m
CONFIG_SLIP_COMPRESSED=y
CONFIG_SLHC=m
CONFIG_SLIP_SMART=y
# CONFIG_SLIP_MODE_SLIP6 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
# CONFIG_ISDN is not set
# CONFIG_PHONE is not set

#
# Input device support
#
CONFIG_INPUT=y
# CONFIG_INPUT_FF_MEMLESS is not set
# CONFIG_INPUT_POLLDEV 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 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_PS2_ALPS=y
CONFIG_MOUSE_PS2_LOGIPS2PP=y
CONFIG_MOUSE_PS2_SYNAPTICS=y
CONFIG_MOUSE_PS2_LIFEBOOK=y
CONFIG_MOUSE_PS2_TRACKPOINT=y
# CONFIG_MOUSE_PS2_TOUCHKIT is not set
# CONFIG_MOUSE_SERIAL is not set
# CONFIG_MOUSE_VSXXXAA is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TABLET 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_LIBPS2=y
# CONFIG_SERIO_RAW is not set
# CONFIG_GAMEPORT is not set

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

#
# Serial drivers
#

#
# Non-8250 serial port support
#
CONFIG_SERIAL_SUNCORE=y
# CONFIG_SERIAL_SUNZILOG is not set
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256
# CONFIG_IPMI_HANDLER is not set
CONFIG_HW_RANDOM=m
# CONFIG_R3964 is not set
# CONFIG_RAW_DRIVER is not set
# CONFIG_TCG_TPM is not set
# CONFIG_I2C is not set

#
# SPI support
#
# CONFIG_SPI is not set
# CONFIG_SPI_MASTER is not set
# CONFIG_W1 is not set
# CONFIG_POWER_SUPPLY is not set
CONFIG_HWMON=y
# CONFIG_HWMON_VID is not set
# CONFIG_SENSORS_ABITUGURU is not set
# CONFIG_SENSORS_ABITUGURU3 is not set
# CONFIG_SENSORS_F71805F is not set
# CONFIG_SENSORS_F71882FG is not set
# CONFIG_SENSORS_IT87 is not set
# CONFIG_SENSORS_PC87360 is not set
# CONFIG_SENSORS_PC87427 is not set
# CONFIG_SENSORS_SMSC47M1 is not set
# CONFIG_SENSORS_SMSC47B397 is not set
# CONFIG_SENSORS_VT1211 is not set
# CONFIG_SENSORS_W83627HF is not set
# CONFIG_SENSORS_W83627EHF is not set
# CONFIG_HWMON_DEBUG_CHIP is not set
# CONFIG_WATCHDOG is not set

#
# Sonics Silicon Backplane
#
CONFIG_SSB_POSSIBLE=y
# CONFIG_SSB is not set

#
# Multifunction device drivers
#
# CONFIG_MFD_SM501 is not set

#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set
# CONFIG_DVB_CORE is not set
CONFIG_DAB=y

#
# Graphics support
#
# CONFIG_BACKLIGHT_LCD_SUPPORT is not set

#
# Display device support
#
# CONFIG_DISPLAY_SUPPORT is not set
# CONFIG_VGASTATE is not set
CONFIG_VIDEO_OUTPUT_CONTROL=m
CONFIG_FB=y
CONFIG_FIRMWARE_EDID=y
# CONFIG_FB_DDC is not set
CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y
# CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set
# CONFIG_FB_SYS_FILLRECT is not set
# CONFIG_FB_SYS_COPYAREA is not set
# CONFIG_FB_SYS_IMAGEBLIT is not set
# CONFIG_FB_SYS_FOPS is not set
CONFIG_FB_DEFERRED_IO=y
# CONFIG_FB_SVGALIB is not set
# CONFIG_FB_MACMODES is not set
# CONFIG_FB_BACKLIGHT is not set
# CONFIG_FB_MODE_HELPERS is not set
# CONFIG_FB_TILEBLITTING is not set

#
# Frame buffer hardware drivers
#
CONFIG_FB_SBUS=y
# CONFIG_FB_BW2 is not set
# CONFIG_FB_CG3 is not set
# CONFIG_FB_CG6 is not set
CONFIG_FB_TCX=y
# CONFIG_FB_CG14 is not set
# CONFIG_FB_P9100 is not set
CONFIG_FB_LEO=y
# CONFIG_FB_IGA is not set
# CONFIG_FB_S1D13XXX is not set
# CONFIG_FB_VIRTUAL is not set

#
# Console display driver support
#
CONFIG_PROM_CONSOLE=y
CONFIG_DUMMY_CONSOLE=y
# CONFIG_FRAMEBUFFER_CONSOLE is not set
# CONFIG_LOGO is not set

#
# Sound
#
# CONFIG_SOUND is not set
CONFIG_HID_SUPPORT=y
CONFIG_HID=y
# CONFIG_HID_DEBUG is not set
# CONFIG_HIDRAW is not set
# CONFIG_USB_SUPPORT is not set
# CONFIG_MMC is not set
# CONFIG_NEW_LEDS is not set
# CONFIG_RTC_CLASS is not set

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

#
# Misc Linux/SPARC drivers
#
CONFIG_SUN_OPENPROMIO=m
CONFIG_SUN_MOSTEK_RTC=y
# CONFIG_SUN_BPP is not set
# CONFIG_SUN_VIDEOPIX is not set
# CONFIG_TADPOLE_TS102_UCTRL is not set
# CONFIG_SUN_JSFLASH is not set

#
# Unix98 PTY support
#
CONFIG_UNIX98_PTY_COUNT=256

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

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

#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=m
CONFIG_MSDOS_FS=m
CONFIG_VFAT_FS=m
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 is not set
CONFIG_PROC_SYSCTL=y
CONFIG_SYSFS=y
# CONFIG_TMPFS is not set
# CONFIG_HUGETLB_PAGE is not set
# CONFIG_CONFIGFS_FS is not set

#
# Layered filesystems
#
# CONFIG_UNION_FS is not set

#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
CONFIG_AFFS_FS=m
# 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=m
# CONFIG_CRAMFS is not set
# CONFIG_VXFS_FS is not set
CONFIG_HPFS_FS=m
# CONFIG_QNX4FS_FS is not set
CONFIG_SYSV_FS=m
CONFIG_UFS_FS=m
# CONFIG_UFS_FS_WRITE is not set
# CONFIG_UFS_DEBUG is not set

#
# Network File Systems
#
CONFIG_NFS_FS=y
# CONFIG_NFS_V3 is not set
# CONFIG_NFS_V4 is not set
# CONFIG_NFS_DIRECTIO is not set
CONFIG_NFSD=m
# CONFIG_NFSD_V3 is not set
CONFIG_NFSD_TCP=y
CONFIG_LOCKD=y
CONFIG_EXPORTFS=m
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=y
# CONFIG_SUNRPC_BIND34 is not set
# CONFIG_RPCSEC_GSS_KRB5 is not set
# CONFIG_RPCSEC_GSS_SPKM3 is not set
CONFIG_SMB_FS=m
# CONFIG_SMB_NLS_DEFAULT is not set
# CONFIG_CIFS is not set
# CONFIG_NCP_FS is not set
CONFIG_CODA_FS=m
# CONFIG_CODA_FS_OLD_API is not set
# CONFIG_AFS_FS is not set

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

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

#
# Distributed Lock Manager
#
# CONFIG_DLM is not set
CONFIG_INSTRUMENTATION=y
# CONFIG_PROFILING is not set
# CONFIG_MARKERS is not set

#
# Kernel hacking
#
# CONFIG_PRINTK_TIME is not set
CONFIG_ENABLE_MUST_CHECK=y
# CONFIG_MAGIC_SYSRQ is not set
# CONFIG_UNUSED_SYMBOLS is not set
# CONFIG_DEBUG_FS is not set
# CONFIG_HEADERS_CHECK is not set
# CONFIG_DEBUG_KERNEL is not set
CONFIG_DEBUG_BUGVERBOSE=y
# CONFIG_UNWIND_INFO is not set
# CONFIG_PROFILE_LIKELY is not set
# CONFIG_WANT_EXTRA_DEBUG_INFORMATION is not set
# CONFIG_KGDB_ATTACH_WAIT is not set

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

#
# Library routines
#
CONFIG_BITREVERSE=y
CONFIG_CRC_CCITT=m
# CONFIG_CRC16 is not set
# CONFIG_CRC_ITU_T is not set
CONFIG_CRC32=y
# CONFIG_CRC7 is not set
# CONFIG_LIBCRC32C is not set
CONFIG_ZLIB_INFLATE=m
CONFIG_ZLIB_DEFLATE=m
CONFIG_PLIST=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
--
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
-
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Andrew Morton
2007-09-18 21:05:08 UTC
Permalink
On Tue, 18 Sep 2007 16:54:03 -0400
Post by Mathieu Desnoyers
/opt/crosstool/gcc-4.1.1-glibc-2.3.6/sparc-unknown-linux-gnu/bin/sparc-unknown-linux-gnu-gcc -Wp,-MD,drivers/serial/.serial_core.o.d -nostdinc -isystem /opt/crosstool/gcc-4.1.1-glibc-2.3.6/sparc-unknown-linux-gnu/lib/gcc/sparc-unknown-linux-gnu/4.1.1/include -D__KERNEL__ -Iinclude -Iinclude2 -I/home/compudj/git/linux-2.6-lttng/include -include include/linux/autoconf.h -I/home/compudj/git/linux-2.6-lttng/drivers/serial -Idrivers/serial -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Os -m32 -pipe -mno-fpu -fcall-used-g5 -fcall-used-g7 -fomit-frame-pointer -fno-stack-protector -Wdeclaration-after-statement -Wno-pointer-sign -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(serial_core)" -D"KBUILD_MODNAME=KBUILD
_STR(serial_core)" -c -o drivers/serial/.tmp_serial_core.o /home/compudj/git/linux-2.6-lttng/drivers/serial/serial_core.c
Post by Mathieu Desnoyers
/home/compudj/git/linux-2.6-lttng/drivers/serial/serial_core.c:1980: error: implicit declaration of function 'enable_irq_wake'
/home/compudj/git/linux-2.6-lttng/drivers/serial/serial_core.c:2035: error: implicit declaration of function 'disable_irq_wake'
hm, I wonder why I didn't hit that.

enable_irq_wake() was added by wake-up-from-a-serial-port.patch

I note that git-input adds a call too, and might have a problem
with !CONFIG_GENERIC_HARDIRQS.

Not sure what the best fix is here. We could sprinkle ifdefs all
over the code, or just add the suitable empty stubs for enable_irq_wake(),
etc.
-
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Mariusz Kozlowski
2007-09-18 21:45:13 UTC
Permalink
Hello,

I wrote a simple script that finds all modules in /lib/modules/`uname -r`
and performs sth like 'modprobe $x; rmmod $x;' for every of them. The result is the
output below. This actually happens when rmmod'ing a module.

I narrowed it down to modules mmc_core and firewire_core. To reproduce that just
rmmod them.

PS. X doesn't work but that's another story.

Regards,

Mariusz

WARNING: at lib/kref.c:33 kref_get()
[<c0104a1c>] dump_trace+0x202/0x22b
[<c0104a5f>] show_trace_log_lvl+0x1a/0x30
[<c0105608>] show_trace+0x12/0x14
[<c010572c>] dump_stack+0x15/0x17
[<c024c567>] kref_get+0x40/0x42
[<c024b81e>] kobject_get+0x12/0x17
[<c02d5800>] bus_get+0x11/0x22
[<c02d5a89>] bus_remove_file+0xe/0x27
[<c02d5ab2>] remove_probe_files+0x10/0x1f
[<c02d5afc>] bus_unregister+0x3b/0x66
[<dee3c2bd>] sdio_unregister_bus+0xd/0xf [mmc_core]
[<dee3d66d>] mmc_exit+0xd/0x23 [mmc_core]
[<c013c9d6>] sys_delete_module+0x154/0x202
[<c010406a>] sysenter_past_esp+0x5f/0x99
[<ffffe410>] 0xffffe410
=======================
WARNING: at lib/kref.c:33 kref_get()
[<c0104a1c>] dump_trace+0x202/0x22b
[<c0104a5f>] show_trace_log_lvl+0x1a/0x30
[<c0105608>] show_trace+0x12/0x14
[<c010572c>] dump_stack+0x15/0x17
[<c024c567>] kref_get+0x40/0x42
[<c024b81e>] kobject_get+0x12/0x17
[<c02d5800>] bus_get+0x11/0x22
[<c02d5a89>] bus_remove_file+0xe/0x27
[<c02d5abe>] remove_probe_files+0x1c/0x1f
[<c02d5afc>] bus_unregister+0x3b/0x66
[<dee3c2bd>] sdio_unregister_bus+0xd/0xf [mmc_core]
[<dee3d66d>] mmc_exit+0xd/0x23 [mmc_core]
[<c013c9d6>] sys_delete_module+0x154/0x202
[<c010406a>] sysenter_past_esp+0x5f/0x99
[<ffffe410>] 0xffffe410
=======================
BUG: atomic counter underflow at:
[<c0104a1c>] dump_trace+0x202/0x22b
[<c0104a5f>] show_trace_log_lvl+0x1a/0x30
[<c0105608>] show_trace+0x12/0x14
[<c010572c>] dump_stack+0x15/0x17
[<c024c5b5>] kref_put+0x4c/0xa7
[<c024b74e>] kobject_put+0x14/0x16
[<c024b809>] unlink+0x3b/0x3e
[<c024b886>] kobject_del+0x16/0x19
[<c024b8a4>] kobject_unregister+0x1b/0x25
[<c024b8bd>] kset_unregister+0xf/0x11
[<c02d5b04>] bus_unregister+0x43/0x66
[<dee3c2bd>] sdio_unregister_bus+0xd/0xf [mmc_core]
[<dee3d66d>] mmc_exit+0xd/0x23 [mmc_core]
[<c013c9d6>] sys_delete_module+0x154/0x202
[<c010406a>] sysenter_past_esp+0x5f/0x99
[<ffffe410>] 0xffffe410
=======================
BUG: atomic counter underflow at:
[<c0104a1c>] dump_trace+0x202/0x22b
[<c0104a5f>] show_trace_log_lvl+0x1a/0x30
[<c0105608>] show_trace+0x12/0x14
[<c010572c>] dump_stack+0x15/0x17
[<c024c5b5>] kref_put+0x4c/0xa7
[<c024b74e>] kobject_put+0x14/0x16
[<c024b809>] unlink+0x3b/0x3e
[<c024b886>] kobject_del+0x16/0x19
[<c024b8a4>] kobject_unregister+0x1b/0x25
[<c024b8bd>] kset_unregister+0xf/0x11
[<c02d5b0f>] bus_unregister+0x4e/0x66
[<dee3c2bd>] sdio_unregister_bus+0xd/0xf [mmc_core]
[<dee3d66d>] mmc_exit+0xd/0x23 [mmc_core]
[<c013c9d6>] sys_delete_module+0x154/0x202
[<c010406a>] sysenter_past_esp+0x5f/0x99
[<ffffe410>] 0xffffe410
=======================
WARNING: at lib/kref.c:33 kref_get()
[<c0104a1c>] dump_trace+0x202/0x22b
[<c0104a5f>] show_trace_log_lvl+0x1a/0x30
[<c0105608>] show_trace+0x12/0x14
[<c010572c>] dump_stack+0x15/0x17
[<c024c567>] kref_get+0x40/0x42
[<c024b81e>] kobject_get+0x12/0x17
[<c02d5800>] bus_get+0x11/0x22
[<c02d5a89>] bus_remove_file+0xe/0x27
[<c02d5b1b>] bus_unregister+0x5a/0x66
[<dee3c2bd>] sdio_unregister_bus+0xd/0xf [mmc_core]
[<dee3d66d>] mmc_exit+0xd/0x23 [mmc_core]
[<c013c9d6>] sys_delete_module+0x154/0x202
[<c010406a>] sysenter_past_esp+0x5f/0x99
[<ffffe410>] 0xffffe410
=======================
BUG: atomic counter underflow at:
[<c0104a1c>] dump_trace+0x202/0x22b
[<c0104a5f>] show_trace_log_lvl+0x1a/0x30
[<c0105608>] show_trace+0x12/0x14
[<c010572c>] dump_stack+0x15/0x17
[<c024c5b5>] kref_put+0x4c/0xa7
[<c024b74e>] kobject_put+0x14/0x16
[<c024b809>] unlink+0x3b/0x3e
[<c024b886>] kobject_del+0x16/0x19
[<c024b8a4>] kobject_unregister+0x1b/0x25
[<c024b8bd>] kset_unregister+0xf/0x11
[<c024b8c7>] subsystem_unregister+0x8/0xa
[<c02d5b23>] bus_unregister+0x62/0x66
[<dee3c2bd>] sdio_unregister_bus+0xd/0xf [mmc_core]
[<dee3d66d>] mmc_exit+0xd/0x23 [mmc_core]
[<c013c9d6>] sys_delete_module+0x154/0x202
[<c010406a>] sysenter_past_esp+0x5f/0x99
[<ffffe410>] 0xffffe410
=======================
------------[ cut here ]------------
kernel BUG at mm/slab.c:592!
invalid opcode: 0000 [#1] PREEMPT
last sysfs file: /block/hdc/removable
Modules linked in: mmc_core pcmcia option usbserial firmware_class 8139too 8250_pci yenta_socket 8250 serial_core rsrc_nonstatic pcmcia_core
Sep 19 05:51:23 orion kernel:
Pid: 6048, comm: rmmod Not tainted (2.6.23-rc6-mm1 #1)
EIP: 0060:[<c015dabb>] EFLAGS: 00010046 CPU: 0
EIP is at kfree+0xad/0xc0
EAX: 00000400 EBX: c05caa48 ECX: 00000000 EDX: c1009e00
ESI: 00000000 EDI: c04f0815 EBP: c2a11e88 ESP: c2a11e78
DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
Process rmmod (pid: 6048, ti=c2a10000 task=c28f2030 task.ti=c2a10000)
last branch before last exception/interrupt
from c015da5c (kfree+0x4e/0xc0)
to c015dabb (kfree+0xad/0xc0)
Stack: 00000286 c05caa48 00000000 00000000 c2a11ea0 c024b7b5 00000000 c05caa4c
c024b7c1 c05caa20 c2a11ea8 c024b7cc c2a11ec8 c024c596 c1815800 c181e1c0
c2a11ed0 00000286 dee431b0 c05caa90 c2a11ed0 c024b74e c2a11ee8 c024b79d
Call Trace:
[<c024b7b5>] kobject_cleanup+0x65/0x71
[<c024b7cc>] kobject_release+0xb/0xd
[<c024c596>] kref_put+0x2d/0xa7
[<c024b74e>] kobject_put+0x14/0x16
[<c024b79d>] kobject_cleanup+0x4d/0x71
[<c024b7cc>] kobject_release+0xb/0xd
[<c024c596>] kref_put+0x2d/0xa7
[<c024b74e>] kobject_put+0x14/0x16
[<c024b8ab>] kobject_unregister+0x22/0x25
[<c024b8bd>] kset_unregister+0xf/0x11
[<c024b8c7>] subsystem_unregister+0x8/0xa
[<c02d5b23>] bus_unregister+0x62/0x66
[<dee3906f>] mmc_unregister_bus+0xd/0xf [mmc_core]
[<dee3d677>] mmc_exit+0x17/0x23 [mmc_core]
[<c013c9d6>] sys_delete_module+0x154/0x202
[<c010406a>] sysenter_past_esp+0x5f/0x99
[<ffffe410>] 0xffffe410
=======================
INFO: lockdep is turned off.
Code: ff ff 75 f0 9d 83 c4 04 5b 5e 5f 5d c3 ff 75 f0 9d e8 87 51 fd ff 83 c4 04 5b 5e 5f 5d c3 89 da 89 f0 e8 96 fe ff ff 8b 03 eb bf <0f> 0b eb fe 8b 52 0c eb 94 8b 52 0c 8b 0a e9 7c ff ff ff 55 89
EIP: [<c015dabb>] kfree+0xad/0xc0 SS:ESP 0068:c2a11e78
BUG: sleeping function called from invalid context at kernel/rwsem.c:20
in_atomic():0, irqs_disabled():1
INFO: lockdep is turned off.
irq event stamp: 2530
hardirqs last enabled at (2529): [<c015da91>] kfree+0x83/0xc0
hardirqs last disabled at (2530): [<c015da28>] kfree+0x1a/0xc0
softirqs last enabled at (2396): [<c011dc2f>] __do_softirq+0xa4/0xb2
softirqs last disabled at (2371): [<c011dc88>] do_softirq+0x4b/0x4d
[<c0104a1c>] dump_trace+0x202/0x22b
[<c0104a5f>] show_trace_log_lvl+0x1a/0x30
[<c0105608>] show_trace+0x12/0x14
[<c010572c>] dump_stack+0x15/0x17
[<c0114c6d>] __might_sleep+0xb7/0xc9
[<c012db84>] down_read+0x18/0x4b
[<c0140792>] acct_collect+0x3b/0x145
[<c011c0e6>] do_exit+0x12f/0x89a
[<c0105089>] do_trap+0x0/0xa9
[<c010510c>] do_trap+0x83/0xa9
[<c01053f1>] do_invalid_op+0x88/0x92
[<c0420b1a>] error_code+0x6a/0x70
[<c015dabb>] kfree+0xad/0xc0
[<c024b7b5>] kobject_cleanup+0x65/0x71
[<c024b7cc>] kobject_release+0xb/0xd
[<c024c596>] kref_put+0x2d/0xa7
[<c024b74e>] kobject_put+0x14/0x16
[<c024b79d>] kobject_cleanup+0x4d/0x71
[<c024b7cc>] kobject_release+0xb/0xd
[<c024c596>] kref_put+0x2d/0xa7
[<c024b74e>] kobject_put+0x14/0x16
[<c024b8ab>] kobject_unregister+0x22/0x25
[<c024b8bd>] kset_unregister+0xf/0x11
[<c024b8c7>] subsystem_unregister+0x8/0xa
[<c02d5b23>] bus_unregister+0x62/0x66
[<dee3906f>] mmc_unregister_bus+0xd/0xf [mmc_core]
[<dee3d677>] mmc_exit+0x17/0x23 [mmc_core]
[<c013c9d6>] sys_delete_module+0x154/0x202
[<c010406a>] sysenter_past_esp+0x5f/0x99
[<ffffe410>] 0xffffe410
=======================
modprobing: aes-i586
modprobing: twofish-i586
modprobing: anubis
modprobing: blowfish
modprobing: camellia
modprobing: cast5
modprobing: cast6
modprobing: cbc
modprobing: crc32c
modprobing: crypto_hash
modprobing: crypto_null
modprobing: deflate
modprobing: des
modprobing: fcrypt
modprobing: gf128mul
modprobing: hmac
modprobing: khazad
modprobing: lrw
modprobing: md4
modprobing: md5
modprobing: michael_mic
modprobing: pcbc
modprobing: serpent
modprobing: sha1
modprobing: sha256
modprobing: sha512
modprobing: tea
modprobing: tgr192
modprobing: twofish
modprobing: twofish_common
modprobing: wp512
modprobing: xcbc
modprobing: firmware_class
modprobing: sonypi
sonypi: Sony Programmable I/O Controller Driver v1.26.
sonypi: please try the sony-laptop module instead and report failures, see also http://www.linux.it/~malattia/wiki/index.php/Sony_drivers
sonypi: detected type2 model, verbose = 0, fnkeyinit = off, camera = off, compat = off, mask = 0xffffffff, useinput = on, acpi = on
sonypi: enabled at irq=11, port1=0x1080, port2=0x1084
sonypi: device allocated minor is 63
input: Sony Vaio Jogdial as /class/input/input7
input: Sony Vaio Keys as /class/input/input8
sonypi command failed at drivers/char/sonypi.c : sonypi_call1 (line 652)
sonypi command failed at drivers/char/sonypi.c : sonypi_call2 (line 663)
sonypi command failed at drivers/char/sonypi.c : sonypi_call2 (line 665)
sonypi command failed at drivers/char/sonypi.c : sonypi_call1 (line 652)
sonypi command failed at drivers/char/sonypi.c : sonypi_call2 (line 663)
sonypi command failed at drivers/char/sonypi.c : sonypi_call2 (line 665)
sonypi: removed.
modprobing: amd-rng
modprobing: geode-rng
modprobing: intel-rng
modprobing: rng-core
modprobing: via-rng
modprobing: geode-aes
modprobing: padlock-aes
padlock: VIA PadLock not detected.
modprobing: padlock-sha
padlock: VIA PadLock Hash Engine not detected.
modprobing: firewire-core
WARNING: at lib/kref.c:33 kref_get()
[<c0104a1c>] dump_trace+0x202/0x22b
[<c0104a5f>] show_trace_log_lvl+0x1a/0x30
[<c0105608>] show_trace+0x12/0x14
[<c010572c>] dump_stack+0x15/0x17
[<c024c567>] kref_get+0x40/0x42
[<c024b81e>] kobject_get+0x12/0x17
[<c024b97b>] kobject_init+0x43/0x82
[<c024b9c8>] kset_init+0xe/0x2e
[<c024be4f>] kset_register+0x15/0x38
[<c024be7a>] subsystem_register+0x8/0xa
[<c02d6008>] bus_register+0x65/0x209
[<ded6300d>] fw_core_init+0xd/0x99 [firewire_core]
[<c013aceb>] sys_init_module+0x125/0x1612
[<c010406a>] sysenter_past_esp+0x5f/0x99
[<ffffe410>] 0xffffe410
=======================
------------[ cut here ]------------
kernel BUG at mm/slab.c:592!
invalid opcode: 0000 [#2] PREEMPT
last sysfs file: /class/input/input7/modalias
Modules linked in: firewire_core crc_itu_t rng_core gf128mul crypto_hash zlib_deflate zlib_inflate libcrc32c mmc_core pcmcia option usbserial firmware_class 8139too 8250_pci yenta_socket 8250 serial_core rsrc_nonstatic pcmcia_core
Sep 19 05:51:48 orion kernel:
Pid: 6881, comm: rmmod Tainted: G D (2.6.23-rc6-mm1 #1)
EIP: 0060:[<c015dabb>] EFLAGS: 00010046 CPU: 0
EIP is at kfree+0xad/0xc0
EAX: 00000400 EBX: c05caa48 ECX: 00000000 EDX: c1009e00
ESI: 00000000 EDI: c04f0815 EBP: c2683e90 ESP: c2683e80
DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
Process rmmod (pid: 6881, ti=c2682000 task=c18d6030 task.ti=c2682000)
last branch before last exception/interrupt
from c015da5c (kfree+0x4e/0xc0)
to c015dabb (kfree+0xad/0xc0)
Stack: 00000286 c05caa48 00000000 00000000 c2683ea8 c024b7b5 00000000 c05caa4c
c024b7c1 c05caa20 c2683eb0 c024b7cc c2683ed0 c024c596 c1815800 c181e1c0
c2683ed8 00000286 dee09bd0 c05caa90 c2683ed8 c024b74e c2683ef0 c024b79d
Call Trace:
[<c024b7b5>] kobject_cleanup+0x65/0x71
[<c024b7cc>] kobject_release+0xb/0xd
[<c024c596>] kref_put+0x2d/0xa7
[<c024b74e>] kobject_put+0x14/0x16
[<c024b79d>] kobject_cleanup+0x4d/0x71
[<c024b7cc>] kobject_release+0xb/0xd
[<c024c596>] kref_put+0x2d/0xa7
[<c024b74e>] kobject_put+0x14/0x16
[<c024b8ab>] kobject_unregister+0x22/0x25
[<c024b8bd>] kset_unregister+0xf/0x11
[<c024b8c7>] subsystem_unregister+0x8/0xa
[<c02d5b23>] bus_unregister+0x62/0x66
[<dee0531c>] fw_core_cleanup+0x1c/0x1e [firewire_core]
[<c013c9d6>] sys_delete_module+0x154/0x202
[<c010406a>] sysenter_past_esp+0x5f/0x99
[<ffffe410>] 0xffffe410
=======================
INFO: lockdep is turned off.
Code: ff ff 75 f0 9d 83 c4 04 5b 5e 5f 5d c3 ff 75 f0 9d e8 87 51 fd ff 83 c4 04 5b 5e 5f 5d c3 89 da 89 f0 e8 96 fe ff ff 8b 03 eb bf <0f> 0b eb fe 8b 52 0c eb 94 8b 52 0c 8b 0a e9 7c ff ff ff 55 89
EIP: [<c015dabb>] kfree+0xad/0xc0 SS:ESP 0068:c2683e80
BUG: sleeping function called from invalid context at kernel/rwsem.c:20
in_atomic():0, irqs_disabled():1
INFO: lockdep is turned off.
irq event stamp: 0
hardirqs last enabled at (0): [<00000000>] 0x0
hardirqs last disabled at (0): [<c011743e>] copy_process+0x412/0x1395
softirqs last enabled at (0): [<c011745c>] copy_process+0x430/0x1395
softirqs last disabled at (0): [<00000000>] 0x0
[<c0104a1c>] dump_trace+0x202/0x22b
[<c0104a5f>] show_trace_log_lvl+0x1a/0x30
[<c0105608>] show_trace+0x12/0x14
[<c010572c>] dump_stack+0x15/0x17
[<c0114c6d>] __might_sleep+0xb7/0xc9
[<c012db84>] down_read+0x18/0x4b
[<c0140792>] acct_collect+0x3b/0x145
[<c011c0e6>] do_exit+0x12f/0x89a
[<c0105089>] do_trap+0x0/0xa9
[<c010510c>] do_trap+0x83/0xa9
[<c01053f1>] do_invalid_op+0x88/0x92
[<c0420b1a>] error_code+0x6a/0x70
[<c015dabb>] kfree+0xad/0xc0
[<c024b7b5>] kobject_cleanup+0x65/0x71
[<c024b7cc>] kobject_release+0xb/0xd
[<c024c596>] kref_put+0x2d/0xa7
[<c024b74e>] kobject_put+0x14/0x16
[<c024b79d>] kobject_cleanup+0x4d/0x71
[<c024b7cc>] kobject_release+0xb/0xd
[<c024c596>] kref_put+0x2d/0xa7
[<c024b74e>] kobject_put+0x14/0x16
[<c024b8ab>] kobject_unregister+0x22/0x25
[<c024b8bd>] kset_unregister+0xf/0x11
[<c024b8c7>] subsystem_unregister+0x8/0xa
[<c02d5b23>] bus_unregister+0x62/0x66
[<dee0531c>] fw_core_cleanup+0x1c/0x1e [firewire_core]
[<c013c9d6>] sys_delete_module+0x154/0x202
[<c010406a>] sysenter_past_esp+0x5f/0x99
[<ffffe410>] 0xffffe410
=======================
modprobing: mmc_block
BUG: sleeping function called from invalid context at mm/slab.c:3051
in_atomic():1, irqs_disabled():0
INFO: lockdep is turned off.
[<c0104a1c>] dump_trace+0x202/0x22b
[<c0104a5f>] show_trace_log_lvl+0x1a/0x30
[<c0105608>] show_trace+0x12/0x14
[<c010572c>] dump_stack+0x15/0x17
[<c0114c6d>] __might_sleep+0xb7/0xc9
[<c015e09a>] kmem_cache_alloc+0x78/0xac
[<c023623f>] do_shmat+0x195/0x377
[<c0107e8a>] sys_ipc+0x138/0x240
[<c010406a>] sysenter_past_esp+0x5f/0x99
[<ffffe410>] 0xffffe410
=======================
BUG: scheduling while atomic: X/6941/0x00000005
INFO: lockdep is turned off.
irq event stamp: 0
hardirqs last enabled at (0): [<00000000>] 0x0
hardirqs last disabled at (0): [<c011743e>] copy_process+0x412/0x1395
softirqs last enabled at (0): [<c011745c>] copy_process+0x430/0x1395
softirqs last disabled at (0): [<00000000>] 0x0
[<c0104a1c>] dump_trace+0x202/0x22b
[<c0104a5f>] show_trace_log_lvl+0x1a/0x30
[<c0105608>] show_trace+0x12/0x14
[<c010572c>] dump_stack+0x15/0x17
[<c01158b2>] __schedule_bug+0x6e/0x75
[<c041dbba>] __sched_text_start+0x2ca/0x3c0
[<c010418a>] work_resched+0x5/0x25
[<ffffe410>] 0xffffe410
=======================
note: X[6941] exited with preempt_count 7
BUG: scheduling while atomic: X/6941/0x10000008
INFO: lockdep is turned off.
[<c0104a1c>] dump_trace+0x202/0x22b
[<c0104a5f>] show_trace_log_lvl+0x1a/0x30
[<c0105608>] show_trace+0x12/0x14
[<c010572c>] dump_stack+0x15/0x17
[<c01158b2>] __schedule_bug+0x6e/0x75
[<c041dbba>] __sched_text_start+0x2ca/0x3c0
[<c01158da>] __cond_resched+0x21/0x3b
[<c041e30a>] cond_resched+0x2a/0x31
[<c0150469>] unmap_vmas+0x411/0x454
[<c0152d79>] exit_mmap+0x68/0xf6
[<c0116f62>] mmput+0x3f/0xdc
[<c011aaac>] exit_mm+0x75/0xd1
[<c011c101>] do_exit+0x14a/0x89a
[<c011c879>] do_group_exit+0x28/0x6e
[<c0123c61>] get_signal_to_deliver+0x298/0x45c
[<c01035cd>] do_notify_resume+0x89/0x758
[<c01041bd>] work_notifysig+0x13/0x1a
[<080c4b54>] 0x80c4b54
=======================
BUG: scheduling while atomic: X/6941/0x1000000a
INFO: lockdep is turned off.
[<c0104a1c>] dump_trace+0x202/0x22b
[<c0104a5f>] show_trace_log_lvl+0x1a/0x30
[<c0105608>] show_trace+0x12/0x14
[<c010572c>] dump_stack+0x15/0x17
[<c01158b2>] __schedule_bug+0x6e/0x75
[<c041dbba>] __sched_text_start+0x2ca/0x3c0
[<c01158da>] __cond_resched+0x21/0x3b
[<c041e30a>] cond_resched+0x2a/0x31
[<c011aee2>] put_files_struct+0xbb/0xd3
[<c011c142>] do_exit+0x18b/0x89a
[<c011c879>] do_group_exit+0x28/0x6e
[<c0123c61>] get_signal_to_deliver+0x298/0x45c
[<c01035cd>] do_notify_resume+0x89/0x758
[<c01041bd>] work_notifysig+0x13/0x1a
[<080c4b54>] 0x80c4b54
=======================
BUG: scheduling while atomic: X/6941/0x1000000a
INFO: lockdep is turned off.
[<c0104a1c>] dump_trace+0x202/0x22b
[<c0104a5f>] show_trace_log_lvl+0x1a/0x30
[<c0105608>] show_trace+0x12/0x14
[<c010572c>] dump_stack+0x15/0x17
[<c01158b2>] __schedule_bug+0x6e/0x75
[<c041dbba>] __sched_text_start+0x2ca/0x3c0
[<c01158da>] __cond_resched+0x21/0x3b
[<c041e30a>] cond_resched+0x2a/0x31
[<c011aee2>] put_files_struct+0xbb/0xd3
[<c011c142>] do_exit+0x18b/0x89a
[<c011c879>] do_group_exit+0x28/0x6e
[<c0123c61>] get_signal_to_deliver+0x298/0x45c
[<c01035cd>] do_notify_resume+0x89/0x758
[<c01041bd>] work_notifysig+0x13/0x1a
[<080c4b54>] 0x80c4b54
=======================
Cornelia Huck
2007-09-19 08:27:16 UTC
Permalink
On Tue, 18 Sep 2007 23:45:13 +0200,
Post by Mathieu Desnoyers
Hello,
I wrote a simple script that finds all modules in /lib/modules/`uname -r`
and performs sth like 'modprobe $x; rmmod $x;' for every of them. The result is the
output below. This actually happens when rmmod'ing a module.
I narrowed it down to modules mmc_core and firewire_core. To reproduce that just
rmmod them.
Hm, does that mean you can reproduce this when you modprobe/rmmod
either of them on a fresh boot? (There could be follow-on errors...)

Could you try with DEBUG_KOBJECT set?
Post by Mathieu Desnoyers
PS. X doesn't work but that's another story.
Regards,
Mariusz
WARNING: at lib/kref.c:33 kref_get()
[<c0104a1c>] dump_trace+0x202/0x22b
[<c0104a5f>] show_trace_log_lvl+0x1a/0x30
[<c0105608>] show_trace+0x12/0x14
[<c010572c>] dump_stack+0x15/0x17
[<c024c567>] kref_get+0x40/0x42
[<c024b81e>] kobject_get+0x12/0x17
[<c02d5800>] bus_get+0x11/0x22
[<c02d5a89>] bus_remove_file+0xe/0x27
[<c02d5ab2>] remove_probe_files+0x10/0x1f
[<c02d5afc>] bus_unregister+0x3b/0x66
[<dee3c2bd>] sdio_unregister_bus+0xd/0xf [mmc_core]
[<dee3d66d>] mmc_exit+0xd/0x23 [mmc_core]
[<c013c9d6>] sys_delete_module+0x154/0x202
[<c010406a>] sysenter_past_esp+0x5f/0x99
[<ffffe410>] 0xffffe410
=======================
Is this the first error message you see? This looks like the embedded
kset had its refcount decreased too much. (Or was the sdio bus never
registered? Don't see how this could happen if mmc_init was successful,
though.)

(The next errors seem to have the same cause.)
Post by Mathieu Desnoyers
modprobing: firewire-core
WARNING: at lib/kref.c:33 kref_get()
[<c0104a1c>] dump_trace+0x202/0x22b
[<c0104a5f>] show_trace_log_lvl+0x1a/0x30
[<c0105608>] show_trace+0x12/0x14
[<c010572c>] dump_stack+0x15/0x17
[<c024c567>] kref_get+0x40/0x42
[<c024b81e>] kobject_get+0x12/0x17
[<c024b97b>] kobject_init+0x43/0x82
[<c024b9c8>] kset_init+0xe/0x2e
[<c024be4f>] kset_register+0x15/0x38
[<c024be7a>] subsystem_register+0x8/0xa
[<c02d6008>] bus_register+0x65/0x209
[<ded6300d>] fw_core_init+0xd/0x99 [firewire_core]
[<c013aceb>] sys_init_module+0x125/0x1612
[<c010406a>] sysenter_past_esp+0x5f/0x99
[<ffffe410>] 0xffffe410
Strange. Can't see how this can happen except as a follow-on error.

(Next ones are follow-on errors from this one.)
Post by Mathieu Desnoyers
modprobing: mmc_block
(Following errors don't look like they could have anything to do with
the driver core.)
Mariusz Kozlowski
2007-09-19 16:43:54 UTC
Permalink
Hello,
Post by Cornelia Huck
Post by Mariusz Kozlowski
I wrote a simple script that finds all modules in /lib/modules/`uname -r`
and performs sth like 'modprobe $x; rmmod $x;' for every of them. The result is the
output below. This actually happens when rmmod'ing a module.
I narrowed it down to modules mmc_core and firewire_core. To reproduce that just
rmmod them.
Hm, does that mean you can reproduce this when you modprobe/rmmod
either of them on a fresh boot? (There could be follow-on errors...)
On fresh boot it happens with mmc_core. On the next fresh boot it didn't happen with
firewire_core. So you can be right that some of them are follow-on errors. Anyway to
trigger it just run these commands:

# logger -t "foobar" "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
# modprobe mmc_core
# rmmod mmc_core
# logger -t "foobar" "yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy"
Post by Cornelia Huck
Could you try with DEBUG_KOBJECT set?
Please find it attached below.

Regards,

Mariusz



xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
kobject mmc_core: registering. parent: <NULL>, set: module
kobject holders: registering. parent: mmc_core, set: <NULL>
kobject_uevent_env
kobject filter function caused the event to drop!
kobject_uevent_env
fill_kobj_path: path = '/module/mmc_core'
---- begin silly warning ----
This is a janitorial warning, not a kernel bug.
The kobject at, or inside 'mmc_bus_type'@(0xded0c1b0) is not dynamically allocated.
kobjects must be dynamically allocated, not static
---- end silly warning ----
kobject mmc: registering. parent: <NULL>, set: bus
kobject_uevent_env
fill_kobj_path: path = '/bus/mmc'
---- begin silly warning ----
This is a janitorial warning, not a kernel bug.
The kobject at, or inside 'mmc_bus_type'@(0xded0c290) is not dynamically allocated.
kobjects must be dynamically allocated, not static
---- end silly warning ----
kobject devices: registering. parent: mmc, set: <NULL>
kobject_uevent_env
kobject filter function caused the event to drop!
---- begin silly warning ----
This is a janitorial warning, not a kernel bug.
The kobject at, or inside 'mmc_bus_type'@(0xded0c220) is not dynamically allocated.
kobjects must be dynamically allocated, not static
---- end silly warning ----
kobject drivers: registering. parent: mmc, set: <NULL>
kobject_uevent_env
kobject filter function caused the event to drop!
---- begin silly warning ----
This is a janitorial warning, not a kernel bug.
The kobject at, or inside 'mmc_host_class'@(0xded0c4f8) is not dynamically allocated.
kobjects must be dynamically allocated, not static
---- end silly warning ----
---- begin silly warning ----
This is a janitorial warning, not a kernel bug.
The kobject at, or inside 'mmc_host_class'@(0xded0c470) is not dynamically allocated.
kobjects must be dynamically allocated, not static
---- end silly warning ----
kobject mmc_host: registering. parent: <NULL>, set: class
kobject_uevent_env
fill_kobj_path: path = '/class/mmc_host'
---- begin silly warning ----
This is a janitorial warning, not a kernel bug.
The kobject at, or inside 'sdio_bus_type'@(0xded0c790) is not dynamically allocated.
kobjects must be dynamically allocated, not static
---- end silly warning ----
kobject sdio: registering. parent: <NULL>, set: bus
kobject_uevent_env
fill_kobj_path: path = '/bus/sdio'
---- begin silly warning ----
This is a janitorial warning, not a kernel bug.
The kobject at, or inside 'sdio_bus_type'@(0xded0c870) is not dynamically allocated.
kobjects must be dynamically allocated, not static
---- end silly warning ----
kobject devices: registering. parent: sdio, set: <NULL>
kobject_uevent_env
kobject filter function caused the event to drop!
---- begin silly warning ----
This is a janitorial warning, not a kernel bug.
The kobject at, or inside 'sdio_bus_type'@(0xded0c800) is not dynamically allocated.
kobjects must be dynamically allocated, not static
---- end silly warning ----
kobject drivers: registering. parent: sdio, set: <NULL>
kobject_uevent_env
kobject filter function caused the event to drop!
kobject drivers: unregistering
kobject_uevent_env
kobject filter function caused the event to drop!
kobject drivers: cleaning up
kobject '<NULL>' does not have a release() function, if this is not a directory kobject, it is broken and must be fixed.
kobject devices: unregistering
kobject_uevent_env
kobject filter function caused the event to drop!
kobject devices: cleaning up
kobject '<NULL>' does not have a release() function, if this is not a directory kobject, it is broken and must be fixed.
kobject sdio: unregistering
kobject_uevent_env
fill_kobj_path: path = '/bus/sdio'
kobject sdio: cleaning up
kobject '<NULL>' does not have a release() function, if this is not a directory kobject, it is broken and must be fixed.
WARNING: at lib/kref.c:33 kref_get()
[<c0104a1c>] dump_trace+0x202/0x22b
[<c0104a5f>] show_trace_log_lvl+0x1a/0x30
[<c0105608>] show_trace+0x12/0x14
[<c010572c>] dump_stack+0x15/0x17
[<c024c6cf>] kref_get+0x40/0x42
[<c024b852>] kobject_get+0x12/0x17
[<c02d5970>] bus_get+0x11/0x22
[<c02d5bf9>] bus_remove_file+0xe/0x27
[<c02d5c22>] remove_probe_files+0x10/0x1f
[<c02d5c6c>] bus_unregister+0x3b/0x66
[<ded052bd>] sdio_unregister_bus+0xd/0xf [mmc_core]
[<ded0666d>] mmc_exit+0xd/0x23 [mmc_core]
[<c013c9d6>] sys_delete_module+0x154/0x202
[<c010406a>] sysenter_past_esp+0x5f/0x99
[<ffffe410>] 0xffffe410
=======================
kobject <NULL>: cleaning up
kobject '<NULL>' does not have a release() function, if this is not a directory kobject, it is broken and must be fixed.
WARNING: at lib/kref.c:33 kref_get()
[<c0104a1c>] dump_trace+0x202/0x22b
[<c0104a5f>] show_trace_log_lvl+0x1a/0x30
[<c0105608>] show_trace+0x12/0x14
[<c010572c>] dump_stack+0x15/0x17
[<c024c6cf>] kref_get+0x40/0x42
[<c024b852>] kobject_get+0x12/0x17
[<c02d5970>] bus_get+0x11/0x22
[<c02d5bf9>] bus_remove_file+0xe/0x27
[<c02d5c2e>] remove_probe_files+0x1c/0x1f
[<c02d5c6c>] bus_unregister+0x3b/0x66
[<ded052bd>] sdio_unregister_bus+0xd/0xf [mmc_core]
[<ded0666d>] mmc_exit+0xd/0x23 [mmc_core]
[<c013c9d6>] sys_delete_module+0x154/0x202
[<c010406a>] sysenter_past_esp+0x5f/0x99
[<ffffe410>] 0xffffe410
=======================
kobject <NULL>: cleaning up
kobject '<NULL>' does not have a release() function, if this is not a directory kobject, it is broken and must be fixed.
kobject <NULL>: unregistering
kobject_uevent_env
kobject filter function caused the event to drop!
BUG: atomic counter underflow at:
[<c0104a1c>] dump_trace+0x202/0x22b
[<c0104a5f>] show_trace_log_lvl+0x1a/0x30
[<c0105608>] show_trace+0x12/0x14
[<c010572c>] dump_stack+0x15/0x17
[<c024c71d>] kref_put+0x4c/0xaf
[<c024b74e>] kobject_put+0x14/0x16
[<c024b83d>] unlink+0x3b/0x3e
[<c024b8ba>] kobject_del+0x16/0x19
[<c024b8ef>] kobject_unregister+0x32/0x3f
[<c024b90b>] kset_unregister+0xf/0x11
[<c02d5c74>] bus_unregister+0x43/0x66
[<ded052bd>] sdio_unregister_bus+0xd/0xf [mmc_core]
[<ded0666d>] mmc_exit+0xd/0x23 [mmc_core]
[<c013c9d6>] sys_delete_module+0x154/0x202
[<c010406a>] sysenter_past_esp+0x5f/0x99
[<ffffe410>] 0xffffe410
=======================
kobject <NULL>: unregistering
kobject_uevent_env
kobject filter function caused the event to drop!
BUG: atomic counter underflow at:
[<c0104a1c>] dump_trace+0x202/0x22b
[<c0104a5f>] show_trace_log_lvl+0x1a/0x30
[<c0105608>] show_trace+0x12/0x14
[<c010572c>] dump_stack+0x15/0x17
[<c024c71d>] kref_put+0x4c/0xaf
[<c024b74e>] kobject_put+0x14/0x16
[<c024b83d>] unlink+0x3b/0x3e
[<c024b8ba>] kobject_del+0x16/0x19
[<c024b8ef>] kobject_unregister+0x32/0x3f
[<c024b90b>] kset_unregister+0xf/0x11
[<c02d5c7f>] bus_unregister+0x4e/0x66
[<ded052bd>] sdio_unregister_bus+0xd/0xf [mmc_core]
[<ded0666d>] mmc_exit+0xd/0x23 [mmc_core]
[<c013c9d6>] sys_delete_module+0x154/0x202
[<c010406a>] sysenter_past_esp+0x5f/0x99
[<ffffe410>] 0xffffe410
=======================
WARNING: at lib/kref.c:33 kref_get()
[<c0104a1c>] dump_trace+0x202/0x22b
[<c0104a5f>] show_trace_log_lvl+0x1a/0x30
[<c0105608>] show_trace+0x12/0x14
[<c010572c>] dump_stack+0x15/0x17
[<c024c6cf>] kref_get+0x40/0x42
[<c024b852>] kobject_get+0x12/0x17
[<c02d5970>] bus_get+0x11/0x22
[<c02d5bf9>] bus_remove_file+0xe/0x27
[<c02d5c8b>] bus_unregister+0x5a/0x66
[<ded052bd>] sdio_unregister_bus+0xd/0xf [mmc_core]
[<ded0666d>] mmc_exit+0xd/0x23 [mmc_core]
[<c013c9d6>] sys_delete_module+0x154/0x202
[<c010406a>] sysenter_past_esp+0x5f/0x99
[<ffffe410>] 0xffffe410
=======================
kobject <NULL>: cleaning up
kobject '<NULL>' does not have a release() function, if this is not a directory kobject, it is broken and must be fixed.
kobject <NULL>: unregistering
kobject_uevent_env
BUG: atomic counter underflow at:
[<c0104a1c>] dump_trace+0x202/0x22b
[<c0104a5f>] show_trace_log_lvl+0x1a/0x30
[<c0105608>] show_trace+0x12/0x14
[<c010572c>] dump_stack+0x15/0x17
[<c024c71d>] kref_put+0x4c/0xaf
[<c024b74e>] kobject_put+0x14/0x16
[<c024b83d>] unlink+0x3b/0x3e
[<c024b8ba>] kobject_del+0x16/0x19
[<c024b8ef>] kobject_unregister+0x32/0x3f
[<c024b90b>] kset_unregister+0xf/0x11
[<c024b915>] subsystem_unregister+0x8/0xa
[<c02d5c93>] bus_unregister+0x62/0x66
[<ded052bd>] sdio_unregister_bus+0xd/0xf [mmc_core]
[<ded0666d>] mmc_exit+0xd/0x23 [mmc_core]
[<c013c9d6>] sys_delete_module+0x154/0x202
[<c010406a>] sysenter_past_esp+0x5f/0x99
[<ffffe410>] 0xffffe410
=======================
kobject mmc_host: unregistering
kobject_uevent_env
fill_kobj_path: path = '/class/mmc_host'
kobject mmc_host: cleaning up
kobject drivers: unregistering
kobject_uevent_env
kobject filter function caused the event to drop!
kobject drivers: cleaning up
kobject '<NULL>' does not have a release() function, if this is not a directory kobject, it is broken and must be fixed.
kobject devices: unregistering
kobject_uevent_env
kobject filter function caused the event to drop!
kobject devices: cleaning up
kobject '<NULL>' does not have a release() function, if this is not a directory kobject, it is broken and must be fixed.
kobject mmc: unregistering
kobject_uevent_env
fill_kobj_path: path = '/bus/mmc'
kobject mmc: cleaning up
kobject '<NULL>' does not have a release() function, if this is not a directory kobject, it is broken and must be fixed.
kobject holders: unregistering
kobject_uevent_env
kobject filter function caused the event to drop!
kobject holders: cleaning up
kobject mmc_core: unregistering
kobject_uevent_env
fill_kobj_path: path = '/module/mmc_core'
kobject mmc_core: cleaning up
kobject '<NULL>' does not have a release() function, if this is not a directory kobject, it is broken and must be fixed.
yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy
Cornelia Huck
2007-09-19 18:02:05 UTC
Permalink
On Wed, 19 Sep 2007 18:43:54 +0200,
Post by Mariusz Kozlowski
On fresh boot it happens with mmc_core. On the next fresh boot it didn't happen with
firewire_core. So you can be right that some of them are follow-on errors.
OK, this seems to point to mmc_core then. (I couldn't reproduce it with
other modules registering a bus type like iucv either, so it doesn't
seem to be a generic type of bug...)
Post by Mariusz Kozlowski
Anyway to
# logger -t "foobar" "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
# modprobe mmc_core
# rmmod mmc_core
# logger -t "foobar" "yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy"
Unfortunately this would involve setting up a non-s390 test box, which
I currently don't have time to do :(
Post by Mariusz Kozlowski
Post by Cornelia Huck
Could you try with DEBUG_KOBJECT set?
Please find it attached below.
Thanks.
Post by Mariusz Kozlowski
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
kobject mmc_core: registering. parent: <NULL>, set: module
kobject holders: registering. parent: mmc_core, set: <NULL>
kobject_uevent_env
kobject filter function caused the event to drop!
kobject_uevent_env
fill_kobj_path: path = '/module/mmc_core'
---- begin silly warning ----
This is a janitorial warning, not a kernel bug.
kobjects must be dynamically allocated, not static
---- end silly warning ----
kobject mmc: registering. parent: <NULL>, set: bus
kobject_uevent_env
fill_kobj_path: path = '/bus/mmc'
---- begin silly warning ----
This is a janitorial warning, not a kernel bug.
kobjects must be dynamically allocated, not static
---- end silly warning ----
kobject devices: registering. parent: mmc, set: <NULL>
kobject_uevent_env
kobject filter function caused the event to drop!
---- begin silly warning ----
This is a janitorial warning, not a kernel bug.
kobjects must be dynamically allocated, not static
---- end silly warning ----
kobject drivers: registering. parent: mmc, set: <NULL>
kobject_uevent_env
kobject filter function caused the event to drop!
---- begin silly warning ----
This is a janitorial warning, not a kernel bug.
kobjects must be dynamically allocated, not static
---- end silly warning ----
---- begin silly warning ----
This is a janitorial warning, not a kernel bug.
kobjects must be dynamically allocated, not static
---- end silly warning ----
kobject mmc_host: registering. parent: <NULL>, set: class
kobject_uevent_env
fill_kobj_path: path = '/class/mmc_host'
---- begin silly warning ----
This is a janitorial warning, not a kernel bug.
kobjects must be dynamically allocated, not static
---- end silly warning ----
kobject sdio: registering. parent: <NULL>, set: bus
kobject_uevent_env
fill_kobj_path: path = '/bus/sdio'
---- begin silly warning ----
This is a janitorial warning, not a kernel bug.
kobjects must be dynamically allocated, not static
---- end silly warning ----
kobject devices: registering. parent: sdio, set: <NULL>
kobject_uevent_env
kobject filter function caused the event to drop!
---- begin silly warning ----
This is a janitorial warning, not a kernel bug.
kobjects must be dynamically allocated, not static
---- end silly warning ----
kobject drivers: registering. parent: sdio, set: <NULL>
kobject_uevent_env
kobject filter function caused the event to drop!
kobject drivers: unregistering
kobject_uevent_env
kobject filter function caused the event to drop!
kobject drivers: cleaning up
kobject '<NULL>' does not have a release() function, if this is not a directory kobject, it is broken and must be fixed.
<Unrelated side note: We should probably save the kobject's name for
printing this debug message, it looks a bit odd :)>
Post by Mariusz Kozlowski
kobject devices: unregistering
kobject_uevent_env
kobject filter function caused the event to drop!
kobject devices: cleaning up
kobject '<NULL>' does not have a release() function, if this is not a directory kobject, it is broken and must be fixed.
kobject sdio: unregistering
kobject_uevent_env
fill_kobj_path: path = '/bus/sdio'
kobject sdio: cleaning up
And now for some reason the reference count for the sdio bus has
already dropped to 0. Strange, since the addition/removal of stuff
below it looks symmetric, and it doesn't seem to do anything different
from other bus types.
Post by Mariusz Kozlowski
kobject '<NULL>' does not have a release() function, if this is not a directory kobject, it is broken and must be fixed.
WARNING: at lib/kref.c:33 kref_get()
[<c0104a1c>] dump_trace+0x202/0x22b
[<c0104a5f>] show_trace_log_lvl+0x1a/0x30
[<c0105608>] show_trace+0x12/0x14
[<c010572c>] dump_stack+0x15/0x17
[<c024c6cf>] kref_get+0x40/0x42
[<c024b852>] kobject_get+0x12/0x17
[<c02d5970>] bus_get+0x11/0x22
[<c02d5bf9>] bus_remove_file+0xe/0x27
[<c02d5c22>] remove_probe_files+0x10/0x1f
[<c02d5c6c>] bus_unregister+0x3b/0x66
[<ded052bd>] sdio_unregister_bus+0xd/0xf [mmc_core]
[<ded0666d>] mmc_exit+0xd/0x23 [mmc_core]
[<c013c9d6>] sys_delete_module+0x154/0x202
[<c010406a>] sysenter_past_esp+0x5f/0x99
[<ffffe410>] 0xffffe410
=======================
The bus_get()/bus_put() stuff will lead to repeated calls to the
release function in this error case, that explains the following
errors. (By the way, isn't the bus_get()/but_pus() pair in
bus_remove_file() superfluous? The caller should hold a reference
anyway.)

What completely confuses me here is that the devices/drivers ksets have
already been unregistered (see above), when remove_probe_files() should
have been called before that...
Post by Mariusz Kozlowski
kobject <NULL>: cleaning up
kobject '<NULL>' does not have a release() function, if this is not a directory kobject, it is broken and must be fixed.
WARNING: at lib/kref.c:33 kref_get()
[<c0104a1c>] dump_trace+0x202/0x22b
[<c0104a5f>] show_trace_log_lvl+0x1a/0x30
[<c0105608>] show_trace+0x12/0x14
[<c010572c>] dump_stack+0x15/0x17
[<c024c6cf>] kref_get+0x40/0x42
[<c024b852>] kobject_get+0x12/0x17
[<c02d5970>] bus_get+0x11/0x22
[<c02d5bf9>] bus_remove_file+0xe/0x27
[<c02d5c2e>] remove_probe_files+0x1c/0x1f
[<c02d5c6c>] bus_unregister+0x3b/0x66
[<ded052bd>] sdio_unregister_bus+0xd/0xf [mmc_core]
[<ded0666d>] mmc_exit+0xd/0x23 [mmc_core]
[<c013c9d6>] sys_delete_module+0x154/0x202
[<c010406a>] sysenter_past_esp+0x5f/0x99
[<ffffe410>] 0xffffe410
=======================
kobject <NULL>: cleaning up
kobject '<NULL>' does not have a release() function, if this is not a directory kobject, it is broken and must be fixed.
kobject <NULL>: unregistering
And here sdio is unregistered *again*. (The <NULL> indicates that this
is a kobject for which kobject_cleanup() has already been called.)
Post by Mariusz Kozlowski
kobject_uevent_env
kobject filter function caused the event to drop!
[<c0104a1c>] dump_trace+0x202/0x22b
[<c0104a5f>] show_trace_log_lvl+0x1a/0x30
[<c0105608>] show_trace+0x12/0x14
[<c010572c>] dump_stack+0x15/0x17
[<c024c71d>] kref_put+0x4c/0xaf
[<c024b74e>] kobject_put+0x14/0x16
[<c024b83d>] unlink+0x3b/0x3e
[<c024b8ba>] kobject_del+0x16/0x19
[<c024b8ef>] kobject_unregister+0x32/0x3f
[<c024b90b>] kset_unregister+0xf/0x11
[<c02d5c74>] bus_unregister+0x43/0x66
[<ded052bd>] sdio_unregister_bus+0xd/0xf [mmc_core]
[<ded0666d>] mmc_exit+0xd/0x23 [mmc_core]
[<c013c9d6>] sys_delete_module+0x154/0x202
[<c010406a>] sysenter_past_esp+0x5f/0x99
[<ffffe410>] 0xffffe410
=======================
kobject <NULL>: unregistering
kobject_uevent_env
kobject filter function caused the event to drop!
[<c0104a1c>] dump_trace+0x202/0x22b
[<c0104a5f>] show_trace_log_lvl+0x1a/0x30
[<c0105608>] show_trace+0x12/0x14
[<c010572c>] dump_stack+0x15/0x17
[<c024c71d>] kref_put+0x4c/0xaf
[<c024b74e>] kobject_put+0x14/0x16
[<c024b83d>] unlink+0x3b/0x3e
[<c024b8ba>] kobject_del+0x16/0x19
[<c024b8ef>] kobject_unregister+0x32/0x3f
[<c024b90b>] kset_unregister+0xf/0x11
[<c02d5c7f>] bus_unregister+0x4e/0x66
[<ded052bd>] sdio_unregister_bus+0xd/0xf [mmc_core]
[<ded0666d>] mmc_exit+0xd/0x23 [mmc_core]
[<c013c9d6>] sys_delete_module+0x154/0x202
[<c010406a>] sysenter_past_esp+0x5f/0x99
[<ffffe410>] 0xffffe410
=======================
WARNING: at lib/kref.c:33 kref_get()
[<c0104a1c>] dump_trace+0x202/0x22b
[<c0104a5f>] show_trace_log_lvl+0x1a/0x30
[<c0105608>] show_trace+0x12/0x14
[<c010572c>] dump_stack+0x15/0x17
[<c024c6cf>] kref_get+0x40/0x42
[<c024b852>] kobject_get+0x12/0x17
[<c02d5970>] bus_get+0x11/0x22
[<c02d5bf9>] bus_remove_file+0xe/0x27
[<c02d5c8b>] bus_unregister+0x5a/0x66
[<ded052bd>] sdio_unregister_bus+0xd/0xf [mmc_core]
[<ded0666d>] mmc_exit+0xd/0x23 [mmc_core]
[<c013c9d6>] sys_delete_module+0x154/0x202
[<c010406a>] sysenter_past_esp+0x5f/0x99
[<ffffe410>] 0xffffe410
=======================
kobject <NULL>: cleaning up
kobject '<NULL>' does not have a release() function, if this is not a directory kobject, it is broken and must be fixed.
kobject <NULL>: unregistering
kobject_uevent_env
[<c0104a1c>] dump_trace+0x202/0x22b
[<c0104a5f>] show_trace_log_lvl+0x1a/0x30
[<c0105608>] show_trace+0x12/0x14
[<c010572c>] dump_stack+0x15/0x17
[<c024c71d>] kref_put+0x4c/0xaf
[<c024b74e>] kobject_put+0x14/0x16
[<c024b83d>] unlink+0x3b/0x3e
[<c024b8ba>] kobject_del+0x16/0x19
[<c024b8ef>] kobject_unregister+0x32/0x3f
[<c024b90b>] kset_unregister+0xf/0x11
[<c024b915>] subsystem_unregister+0x8/0xa
[<c02d5c93>] bus_unregister+0x62/0x66
[<ded052bd>] sdio_unregister_bus+0xd/0xf [mmc_core]
[<ded0666d>] mmc_exit+0xd/0x23 [mmc_core]
[<c013c9d6>] sys_delete_module+0x154/0x202
[<c010406a>] sysenter_past_esp+0x5f/0x99
[<ffffe410>] 0xffffe410
=======================
kobject mmc_host: unregistering
kobject_uevent_env
fill_kobj_path: path = '/class/mmc_host'
kobject mmc_host: cleaning up
kobject drivers: unregistering
kobject_uevent_env
kobject filter function caused the event to drop!
kobject drivers: cleaning up
kobject '<NULL>' does not have a release() function, if this is not a directory kobject, it is broken and must be fixed.
kobject devices: unregistering
kobject_uevent_env
kobject filter function caused the event to drop!
kobject devices: cleaning up
kobject '<NULL>' does not have a release() function, if this is not a directory kobject, it is broken and must be fixed.
kobject mmc: unregistering
kobject_uevent_env
fill_kobj_path: path = '/bus/mmc'
kobject mmc: cleaning up
kobject '<NULL>' does not have a release() function, if this is not a directory kobject, it is broken and must be fixed.
kobject holders: unregistering
kobject_uevent_env
kobject filter function caused the event to drop!
kobject holders: cleaning up
kobject mmc_core: unregistering
kobject_uevent_env
fill_kobj_path: path = '/module/mmc_core'
kobject mmc_core: cleaning up
kobject '<NULL>' does not have a release() function, if this is not a directory kobject, it is broken and must be fixed.
yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy
-ECONFUSED. Perhaps DEBUG_DRIVER may help some more. Or /me getting
some sleep.
Cornelia Huck
2007-09-20 07:42:21 UTC
Permalink
On Wed, 19 Sep 2007 20:02:05 +0200,
Post by Cornelia Huck
Post by Mariusz Kozlowski
kobject drivers: cleaning up
kobject '<NULL>' does not have a release() function, if this is not a directory kobject, it is broken and must be fixed.
<Unrelated side note: We should probably save the kobject's name for
printing this debug message, it looks a bit odd :)>
kobject: Temporarily save k_name on cleanup for debug message.

Signed-off-by: Cornelia Huck <***@de.ibm.com>

---
lib/kobject.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)

--- linux-2.6.orig/lib/kobject.c
+++ linux-2.6/lib/kobject.c
@@ -498,9 +498,9 @@ void kobject_cleanup(struct kobject * ko
struct kobj_type * t = get_ktype(kobj);
struct kset * s = kobj->kset;
struct kobject * parent = kobj->parent;
+ const char *k_name = kobj->k_name;

pr_debug("kobject %s: cleaning up\n",kobject_name(kobj));
- kfree(kobj->k_name);
kobj->k_name = NULL;
if (t && t->release)
t->release(kobj);
@@ -508,8 +508,8 @@ void kobject_cleanup(struct kobject * ko
pr_debug("kobject '%s' does not have a release() function, "
"if this is not a directory kobject, it is broken "
"and must be fixed.\n",
- kobject_name(kobj));
-
+ k_name);
+ kfree(k_name);
if (s)
kset_put(s);
kobject_put(parent);
Cornelia Huck
2007-09-20 07:43:50 UTC
Permalink
On Wed, 19 Sep 2007 20:02:05 +0200,
Post by Cornelia Huck
Post by Mariusz Kozlowski
kobject drivers: cleaning up
kobject '<NULL>' does not have a release() function, if this is not a directory kobject, it is broken and must be fixed.
<Unrelated side note: We should probably save the kobject's name for
printing this debug message, it looks a bit odd :)>
kobject: Temporarily save k_name on cleanup for debug message.

Signed-off-by: Cornelia Huck <***@de.ibm.com>

---
lib/kobject.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)

--- linux-2.6.orig/lib/kobject.c
+++ linux-2.6/lib/kobject.c
@@ -498,9 +498,9 @@ void kobject_cleanup(struct kobject * ko
struct kobj_type * t = get_ktype(kobj);
struct kset * s = kobj->kset;
struct kobject * parent = kobj->parent;
+ const char *k_name = kobj->k_name;

pr_debug("kobject %s: cleaning up\n",kobject_name(kobj));
- kfree(kobj->k_name);
kobj->k_name = NULL;
if (t && t->release)
t->release(kobj);
@@ -508,8 +508,8 @@ void kobject_cleanup(struct kobject * ko
pr_debug("kobject '%s' does not have a release() function, "
"if this is not a directory kobject, it is broken "
"and must be fixed.\n",
- kobject_name(kobj));
-
+ k_name);
+ kfree(k_name);
if (s)
kset_put(s);
kobject_put(parent);
Andy Whitcroft
2007-09-19 09:28:48 UTC
Permalink
I am seeing this strange link error from a PowerMac G5 (powerpc):

[...]
KSYM .tmp_kallsyms2.S
AS .tmp_kallsyms2.o
LD vmlinux.o
ld: dynreloc miscount for fs/built-in.o, section .opd
ld: can not edit opd Bad value
make: *** [vmlinux.o] Error 1

Compiler version below.

***@elm3b19:~# gcc -v
Using built-in specs.
Target: powerpc-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.0 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-java-awt=gtk-default
--enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre
--enable-mpfr --disable-softfloat
--enable-targets=powerpc-linux,powerpc64-linux --with-cpu=default32
--disable-werror --enable-checking=release powerpc-linux-gnu
Thread model: posix
gcc version 4.0.3 (Ubuntu 4.0.3-1ubuntu5)

-apw
Segher Boessenkool
2007-09-19 16:36:29 UTC
Permalink
Post by Andy Whitcroft
[...]
KSYM .tmp_kallsyms2.S
AS .tmp_kallsyms2.o
LD vmlinux.o
ld: dynreloc miscount for fs/built-in.o, section .opd
ld: can not edit opd Bad value
make: *** [vmlinux.o] Error 1
Compiler version below.
It's an ld error, could you show us your ld version instead? And
please try with current mainline ld, too?


Segher



From ***@gmane.org Tue Mar 04 03:33:20 2003
Andy Whitcroft
2007-09-19 16:52:50 UTC
Permalink
Post by Segher Boessenkool
Post by Andy Whitcroft
[...]
KSYM .tmp_kallsyms2.S
AS .tmp_kallsyms2.o
LD vmlinux.o
ld: dynreloc miscount for fs/built-in.o, section .opd
ld: can not edit opd Bad value
make: *** [vmlinux.o] Error 1
Compiler version below.
It's an ld error, could you show us your ld version instead? And
please try with current mainline ld, too?
***@elm3b19:~# ld -v
GNU ld version 2.16.91 20060118 Debian GNU/Linux

Getting the compiler suite changed on here is going to be a lot
tricker. One of the reasons we keep it back there is those versions
are supposed to be supported and we want to test those combinations.

-apw
Sam Ravnborg
2007-09-19 17:44:03 UTC
Permalink
Post by Andy Whitcroft
[...]
KSYM .tmp_kallsyms2.S
AS .tmp_kallsyms2.o
LD vmlinux.o
ld: dynreloc miscount for fs/built-in.o, section .opd
ld: can not edit opd Bad value
make: *** [vmlinux.o] Error 1
We have had this issue before.
Try to see:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=045e72acf16054c4ed2760e9a8edb19a08053af1

Here it was caused by a weak declaration that was superflous.

I expect the workaround to be equally simple this time - or I hope so.

Sam
Andy Whitcroft
2007-09-19 09:36:14 UTC
Permalink
Seeing the following panic booting an old powerpc LPAR:

Unable to handle kernel paging request for data at address 0x00000000
Faulting instruction address: 0xc000000000047b48
cpu 0x0: Vector: 300 (Data Access) at [c0000000006a3750]
pc: c000000000047b48: .pSeries_log_error+0x364/0x420
lr: c000000000047acc: .pSeries_log_error+0x2e8/0x420
sp: c0000000006a39d0
msr: 8000000000001032
dar: 0
dsisr: 42000000
current = 0xc0000000005acab0
paca = 0xc0000000005ad700
pid = 0, comm = swapper
enter ? for help
[c0000000006a3af0] c000000000021164 .rtas_call+0x200/0x250
[c0000000006a3ba0] c000000000049d50 .early_enable_eeh+0x168/0x360
[c0000000006a3c70] c00000000002f674 .traverse_pci_devices+0x8c/0x138
[c0000000006a3d10] c000000000560ce8 .eeh_init+0x1a8/0x200
[c0000000006a3db0] c00000000055fb70 .pSeries_setup_arch+0x128/0x234
[c0000000006a3e40] c00000000054f830 .setup_arch+0x214/0x24c
[c0000000006a3ee0] c000000000546a38 .start_kernel+0xd4/0x3e4
[c0000000006a3f90] c00000000045adc4 .start_here_common+0x54/0x58
0:mon>

This machine is:

# cat /proc/cpuinfo
processor : 0
cpu : POWER4+ (gq)
clock : 1703.965296MHz
revision : 19.0

[...]
machine : CHRP IBM,7040-681

-apw
Jiri Slaby
2007-09-19 11:43:37 UTC
Permalink
Post by Andrew Morton
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc6/2.6.23-rc6-mm1/
2.6.23-rc6-mm1 is a 29MB diff against 2.6.23-rc6.
It took me over two solid days to get this lot compiling and booting on a few
boxes. This required around ninety fixup patches and patch droppings. There
are several bugs in here which I know of (details below) and presumably many
more which I don't know of. I have to say that this just isn't working any
more.
- The Vaio hangs when quitting X due to x86_64-mm-cpa-clflush.patch, but
I didn't drop that patch because the iommu patch series depends on it.
No matter whether slub/slab is selected someone gets a page and moves/adds its
.lru head to some list after being in the deffered_pages list yet -- this breaks
the deffered_pages list and loops forever in list_for_each (unless LIST_DEBUG is
selected, which produces a BUG).

Any ideas who could be the one pushing the page to some other list?

regards,
--
Jiri Slaby (***@gmail.com)
Faculty of Informatics, Masaryk University
Jiri Slaby
2007-09-19 11:53:47 UTC
Permalink
Post by Jiri Slaby
Post by Andrew Morton
- The Vaio hangs when quitting X due to x86_64-mm-cpa-clflush.patch, but
I didn't drop that patch because the iommu patch series depends on it.
No matter whether slub/slab is selected someone gets a page and moves/adds its
Oh, only adds, if it moves, it won't break the list. Going to check for
POISON1/2 in __list_add, will get results (if any) in few moments...

regards,
--
Jiri Slaby (***@gmail.com)
Faculty of Informatics, Masaryk University
Jiri Slaby
2007-09-19 14:59:04 UTC
Permalink
Post by Jiri Slaby
Post by Jiri Slaby
Post by Andrew Morton
- The Vaio hangs when quitting X due to x86_64-mm-cpa-clflush.patch, but
I didn't drop that patch because the iommu patch series depends on it.
No matter whether slub/slab is selected someone gets a page and moves/adds its
Oh, only adds, if it moves, it won't break the list. Going to check for
POISON1/2 in __list_add, will get results (if any) in few moments...
Huh, it took longer than I expect :). Changed this:
diff --git a/arch/x86_64/mm/pageattr.c b/arch/x86_64/mm/pageattr.c
index 836c218..cd8499c 100644
--- a/arch/x86_64/mm/pageattr.c
+++ b/arch/x86_64/mm/pageattr.c
@@ -112,7 +112,14 @@ static inline void save_page(struct page *fpage, int data)
return;
SetPageFlush(fpage);
}
+ printk("ADD (%s): E=%p, H=%p, H->N=%p, N->P=%p, N->N=%p; PREV0=%p, "
+ "NEXT0=%p, ",
+ current->comm, &fpage->lru,
+ &deferred_pages, deferred_pages.next,
+ deferred_pages.next->prev, deferred_pages.next->next,
+ fpage->lru.prev, fpage->lru.next);
list_add(&fpage->lru, &deferred_pages);
+ printk("PREV1=%p, NEXT1=%p\n", fpage->lru.prev, fpage->lru.next);
}

/*
@@ -274,6 +281,7 @@ void global_flush_tlb(void)
down_read(&init_mm.mmap_sem);
arg.full_flush = full_flush;
full_flush = 0;
+ printk("FLUSH\n");
list_replace_init(&deferred_pages, &arg.l);
up_read(&init_mm.mmap_sem);

diff --git a/include/linux/list.h b/include/linux/list.h
index f29fc9c..1add963 100644
--- a/include/linux/list.h
+++ b/include/linux/list.h
@@ -265,6 +265,8 @@ static inline void list_del_init(struct list_head *entry)
static inline void list_move(struct list_head *list, struct list_head *head)
{
__list_del(list->prev, list->next);
+ list->next = LIST_POISON1;
+ list->prev = LIST_POISON2;
list_add(list, head);
}

@@ -277,6 +279,8 @@ static inline void list_move_tail(struct list_head *list,
struct list_head *head)
{
__list_del(list->prev, list->next);
+ list->next = LIST_POISON1;
+ list->prev = LIST_POISON2;
list_add_tail(list, head);
}

diff --git a/lib/list_debug.c b/lib/list_debug.c
index 4350ba9..57573d5 100644
--- a/lib/list_debug.c
+++ b/lib/list_debug.c
@@ -15,15 +15,34 @@
* This is only for internal list manipulation where we know
* the prev/next entries already!
*/
-
+#include <linux/sched.h>
void __list_add(struct list_head *new,
struct list_head *prev,
struct list_head *next)
{
+ static unsigned int a, b;
+ unsigned long off;
+
+ if (unlikely(!a && current && current->comm[0] == 'X'))
+ a++;
+
+ if (unlikely(a && !b && (void *)new >= (void *)mem_map &&
+ (void *)new < (void *)(mem_map + 1048576) &&
+ (new->prev != LIST_POISON2 || new->next != LIST_POISON1) &&
+ (new->prev != NULL || new->next != NULL) &&
+ (new->prev != new || new->next != new))) {
+ off = ((void *)new - (void *)mem_map) % sizeof(struct page);
+ if (off == offsetof(struct page, lru)) {
+ printk(KERN_DEBUG "POISONS (%p): "
+ "%p, %p\n", new, new->prev, new->next);
+ dump_stack();
+ }
+ }
if (unlikely(next->prev != prev)) {
printk(KERN_ERR "list_add corruption. next->prev should be "
"prev (%p), but was %p. (next=%p).\n",
prev, next->prev, next);
+ b++;
BUG();
}
if (unlikely(prev->next != next)) {

---------8<---------8<---------8<---------8<---------8<---------8<----
and got this:
ADD (X): E=ffff81000115b9e0, H=ffffffff80673aa0, H->N=ffff8100011573e0,
N->P=ffffffff80673aa0, N->N=ffff81000115ba18; PREV0=0000000000200200,
NEXT0=0000000000100100, PREV1=ffffffff80673aa0, NEXT1=ffff8100011573e0
/----------------------------------------------------------\
this (^^^^) was output from unmap path, see (1) below
and here (vvvv) follows output from free_page path, see (2)
\----------------------------------------------------------/
POISONS (ffff81000115b9e0): ffffffff80673aa0, ffff8100011573e0

Call Trace:
[<ffffffff80328c06>] __list_add+0xf6/0x190
[<ffffffff80328cac>] list_add+0xc/0x10
[<ffffffff8026e46d>] free_hot_cold_page+0xfd/0x170
[<ffffffff8026e52b>] free_hot_page+0xb/0x10
[<ffffffff8026e555>] __free_pages+0x25/0x30
[<ffffffff8026e58b>] free_pages+0x2b/0x40
[<ffffffff8037cf16>] agp_generic_destroy_page+0x56/0x70
[<ffffffff8037d9d5>] agp_free_memory+0x65/0xd0
[<ffffffff8037c0e9>] agp_free_memory_wrap+0x39/0x60
[<ffffffff8037c79b>] agp_release+0xdb/0x1c0
[<ffffffff80291440>] __fput+0xc0/0x1b0
[<ffffffff802915b6>] fput+0x16/0x20
[<ffffffff8028e516>] filp_close+0x56/0x90
[<ffffffff8023a552>] put_files_struct+0xc2/0xd0
[<ffffffff8023ba55>] do_exit+0x1e5/0x990
[<ffffffff8023c237>] do_group_exit+0x37/0x90
[<ffffffff8023c2a2>] sys_exit_group+0x12/0x20
[<ffffffff8020bd0e>] system_call+0x7e/0x83

ADD (X): E=ffff81000115b9a8, H=ffffffff80673aa0, H->N=ffff81000115b9e0,
N->P=ffffffff8067ef50, N->N=ffff81000115ba18; PREV0=0000000000200200,
NEXT0=0000000000100100, <3>list_add corruption. next->prev should be prev
(ffffffff80673aa0), but was ffffffff8067ef50. (next=ffff81000115b9e0).
------------[ cut here ]------------
kernel BUG at /home/l/latest/xxx/lib/list_debug.c:46!
invalid opcode: 0000 [1] SMP
last sysfs file: /devices/pci0000:00/0000:00:02.0/enable
CPU 1
Modules linked in: ipv6 floppy sr_mod ehci_hcd cdrom rtc_cmos usbhid rtc_core
rtc_lib
Pid: 1603, comm: X Not tainted 2.6.23-rc6-mm1_64 #51
RIP: 0010:[<ffffffff80328c73>] [<ffffffff80328c73>] __list_add+0x163/0x190
RSP: 0018:ffff810004e31c38 EFLAGS: 00010202
RAX: 0000000000000079 RBX: ffff81000115b9a8 RCX: ffffffff80673f68
RDX: ffffffff80673f68 RSI: 0000000000000086 RDI: ffffffff80673f60
RBP: ffff810004e31c58 R08: 0000000000000000 R09: 0000000000000001
R10: 0000000000000001 R11: 0000000000000000 R12: ffffffff80673aa0
R13: ffff81000115b9e0 R14: 0000000000006350 R15: ffff810006211a80
FS: 0000000000000000(0000) GS:ffff810003016500(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000514cc0 CR3: 0000000000201000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process X (pid: 1603, threadinfo ffff810004e30000, task ffff810003b26bd0)
last branch before last exception/interrupt
from [<ffffffff80238a83>] printk+0xa3/0xb0
to [<ffffffff80328c6c>] __list_add+0x15c/0x190
Stack: ffffffff8067ef50 ffff81000115b9a8 ffff81000115b980 ffff8100011573b8
ffff810004e31c68 ffffffff80328cac ffff810004e31d08 ffffffff80225b28
ffff81000115ba18 0000000000200200 0000000000100100 ffffffff8067ee80
Call Trace:
[<ffffffff80328cac>] list_add+0xc/0x10
[<ffffffff80225b28>] __change_page_attr+0x478/0x4a0
[<ffffffff80225bf6>] change_page_attr_addr+0xa6/0x140
[<ffffffff80225cc3>] change_page_attr+0x33/0x40
[<ffffffff8037cf04>] agp_generic_destroy_page+0x44/0x70
[<ffffffff8037d9d5>] agp_free_memory+0x65/0xd0
[<ffffffff8037c0e9>] agp_free_memory_wrap+0x39/0x60
[<ffffffff8037c79b>] agp_release+0xdb/0x1c0
[<ffffffff80291440>] __fput+0xc0/0x1b0
[<ffffffff802915b6>] fput+0x16/0x20
[<ffffffff8028e516>] filp_close+0x56/0x90
[<ffffffff8023a552>] put_files_struct+0xc2/0xd0
[<ffffffff8023ba55>] do_exit+0x1e5/0x990
[<ffffffff8023c237>] do_group_exit+0x37/0x90
[<ffffffff8023c2a2>] sys_exit_group+0x12/0x20
[<ffffffff8020bd0e>] system_call+0x7e/0x83


Code: 0f 0b eb fe 80 ba e2 02 00 00 58 b8 01 00 00 00 0f 45 05 c6
RIP [<ffffffff80328c73>] __list_add+0x163/0x190
RSP <ffff810004e31c38>
Fixing recursive fault but reboot is needed!


---------8<---------8<---------8<---------8<---------8<---------8<----
That means
void agp_generic_destroy_page(void *addr)
{
struct page *page;

if (addr == NULL)
return;

page = virt_to_page(addr);
(1) unmap_page_from_agp(page);
put_page(page);
(2) free_page((unsigned long)addr);
atomic_dec(&agp_bridge->current_memory_agp);
}

(1) unmap_page_from_agp -> change_page_attr -> change_page_attr_addr ->
__change_page_attr -> save_page -> list_add(&fpage->lru, &deferred_pages);
(2) free_page -> free_pages -> __free_pages -> free_hot_page ->
free_hot_cold_page -> list_add(&page->lru, &pcp->list);

any ideas how to fix this?

regards,
--
Jiri Slaby (***@gmail.com)
Faculty of Informatics, Masaryk University
Andrew Morton
2007-09-19 19:10:17 UTC
Permalink
Post by Jiri Slaby
---------8<---------8<---------8<---------8<---------8<---------8<----
That means
void agp_generic_destroy_page(void *addr)
{
struct page *page;
if (addr == NULL)
return;
page = virt_to_page(addr);
(1) unmap_page_from_agp(page);
put_page(page);
(2) free_page((unsigned long)addr);
atomic_dec(&agp_bridge->current_memory_agp);
}
(1) unmap_page_from_agp -> change_page_attr -> change_page_attr_addr ->
__change_page_attr -> save_page -> list_add(&fpage->lru, &deferred_pages);
(2) free_page -> free_pages -> __free_pages -> free_hot_page ->
free_hot_cold_page -> list_add(&page->lru, &pcp->list);
that'll hurt.
Post by Jiri Slaby
any ideas how to fix this?
We should hold a single reference on the page for its membership in
deferred_pages.
Andi Kleen
2007-09-19 19:24:53 UTC
Permalink
Post by Andrew Morton
Post by Jiri Slaby
---------8<---------8<---------8<---------8<---------8<---------8<----
That means
void agp_generic_destroy_page(void *addr)
{
struct page *page;
if (addr == NULL)
return;
page = virt_to_page(addr);
(1) unmap_page_from_agp(page);
put_page(page);
(2) free_page((unsigned long)addr);
atomic_dec(&agp_bridge->current_memory_agp);
}
(1) unmap_page_from_agp -> change_page_attr -> change_page_attr_addr ->
__change_page_attr -> save_page -> list_add(&fpage->lru, &deferred_pages);
(2) free_page -> free_pages -> __free_pages -> free_hot_page ->
free_hot_cold_page -> list_add(&page->lru, &pcp->list);
that'll hurt.
Post by Jiri Slaby
any ideas how to fix this?
We should hold a single reference on the page for its membership in
deferred_pages.
The code is broken anyways. If you free pages without flushing
them first some other innocent user allocating them will end up
with possible uncached pages for some time.

Does this simple patch help?

-Andi


Flush uncached AGP pages before freeing

Signed-off-by: Andi Kleen <***@suse.de>

Index: linux/drivers/char/agp/generic.c
===================================================================
--- linux.orig/drivers/char/agp/generic.c
+++ linux/drivers/char/agp/generic.c
@@ -1185,6 +1185,7 @@ void agp_generic_destroy_page(void *addr

page = virt_to_page(addr);
unmap_page_from_agp(page);
+ flush_agp_mappings();
put_page(page);
free_page((unsigned long)addr);
atomic_dec(&agp_bridge->current_memory_agp);
Jiri Slaby
2007-09-19 19:46:41 UTC
Permalink
Post by Andi Kleen
Post by Andrew Morton
Post by Jiri Slaby
---------8<---------8<---------8<---------8<---------8<---------8<----
That means
void agp_generic_destroy_page(void *addr)
{
struct page *page;
if (addr == NULL)
return;
page = virt_to_page(addr);
(1) unmap_page_from_agp(page);
put_page(page);
(2) free_page((unsigned long)addr);
atomic_dec(&agp_bridge->current_memory_agp);
}
(1) unmap_page_from_agp -> change_page_attr -> change_page_attr_addr ->
__change_page_attr -> save_page -> list_add(&fpage->lru, &deferred_pages);
(2) free_page -> free_pages -> __free_pages -> free_hot_page ->
free_hot_cold_page -> list_add(&page->lru, &pcp->list);
that'll hurt.
Post by Jiri Slaby
any ideas how to fix this?
We should hold a single reference on the page for its membership in
deferred_pages.
The code is broken anyways. If you free pages without flushing
them first some other innocent user allocating them will end up
with possible uncached pages for some time.
Does this simple patch help?
Yeah. (But X doesn't run -- this is maybe the known issue in this release).
Post by Andi Kleen
Flush uncached AGP pages before freeing
Index: linux/drivers/char/agp/generic.c
===================================================================
--- linux.orig/drivers/char/agp/generic.c
+++ linux/drivers/char/agp/generic.c
@@ -1185,6 +1185,7 @@ void agp_generic_destroy_page(void *addr
page = virt_to_page(addr);
unmap_page_from_agp(page);
+ flush_agp_mappings();
put_page(page);
free_page((unsigned long)addr);
atomic_dec(&agp_bridge->current_memory_agp);
thanks,
--
Jiri Slaby (***@gmail.com)
Faculty of Informatics, Masaryk University
Andi Kleen
2007-09-19 19:54:25 UTC
Permalink
Post by Jiri Slaby
Yeah. (But X doesn't run -- this is maybe the known issue in this release).
What do you mean with not run?

-Andi
Jiri Slaby
2007-09-19 19:57:27 UTC
Permalink
Post by Andi Kleen
Post by Jiri Slaby
Yeah. (But X doesn't run -- this is maybe the known issue in this release).
What do you mean with not run?
(II) intel(0): Initializing HW Cursor
(II) intel(0): xf86BindGARTMemory: bind key 0 at 0x005ff000 (pgoffset 1535)
(WW) intel(0): xf86BindGARTMemory: binding of gart memory with key 0
at offset 0x5ff000 failed (Invalid argument)

Fatal server error:
Couldn't bind memory for front buffer

I thought I'd seen a thread about this issue, but I can't find it now. Is it
known or am I seeing ghosts yet, Andrew?

regards,
--
Jiri Slaby (***@gmail.com)
Faculty of Informatics, Masaryk University
Jiri Slaby
2007-09-19 20:01:59 UTC
Permalink
Post by Jiri Slaby
Post by Andi Kleen
Post by Jiri Slaby
Yeah. (But X doesn't run -- this is maybe the known issue in this release).
What do you mean with not run?
(II) intel(0): Initializing HW Cursor
(II) intel(0): xf86BindGARTMemory: bind key 0 at 0x005ff000 (pgoffset 1535)
(WW) intel(0): xf86BindGARTMemory: binding of gart memory with key 0
at offset 0x5ff000 failed (Invalid argument)
Couldn't bind memory for front buffer
Further info:
4690 write(0, "(II) intel(0): Initializing HW C"..., 38) = 38
4690 write(0, "(II) intel(0): xf86BindGARTMemor"..., 76) = 76
4690 ioctl(9, AGPIOC_BIND, 0x7fffbe1cb850) = -1 EINVAL (Invalid argument)
4690 write(0, "(WW) intel(0): xf86BindGARTMemor"..., 115) = 115
4690 write(2, "\nFatal server error:\n", 21) = 21
Post by Jiri Slaby
I thought I'd seen a thread about this issue, but I can't find it now. Is it
known or am I seeing ghosts yet, Andrew?
--
Jiri Slaby (***@gmail.com)
Faculty of Informatics, Masaryk University
Andrew Morton
2007-09-19 21:42:46 UTC
Permalink
On Wed, 19 Sep 2007 22:01:59 +0200
Post by Jiri Slaby
Post by Jiri Slaby
Post by Andi Kleen
Post by Jiri Slaby
Yeah. (But X doesn't run -- this is maybe the known issue in this release).
What do you mean with not run?
(II) intel(0): Initializing HW Cursor
(II) intel(0): xf86BindGARTMemory: bind key 0 at 0x005ff000 (pgoffset 1535)
(WW) intel(0): xf86BindGARTMemory: binding of gart memory with key 0
at offset 0x5ff000 failed (Invalid argument)
Couldn't bind memory for front buffer
4690 write(0, "(II) intel(0): Initializing HW C"..., 38) = 38
4690 write(0, "(II) intel(0): xf86BindGARTMemor"..., 76) = 76
4690 ioctl(9, AGPIOC_BIND, 0x7fffbe1cb850) = -1 EINVAL (Invalid argument)
4690 write(0, "(WW) intel(0): xf86BindGARTMemor"..., 115) = 115
4690 write(2, "\nFatal server error:\n", 21) = 21
This might be a Dave thing and not an Andi thing.

In my usual -mm-testing I only test X on the one machine (the Vaio,
natch). Check that it runs glxgears, check suspend/resume to mem and disk.
It has intel graphics and I'm not seeing any such problems.

Have you time to bisect it?
http://www.zip.com.au/~akpm/linux/patches/stuff/bisecting-mm-trees.txt
describes how.

As a quick test, perhaps build a tree with just
2.6.23-rc6+origin.patch+git-drm.patch? Fortunately git-agpgart.patch is
presently empty.
V***@vt.edu
2007-09-19 20:32:55 UTC
Permalink
Post by Jiri Slaby
Post by Andi Kleen
Post by Jiri Slaby
Yeah. (But X doesn't run -- this is maybe the known issue in this release)
.
Post by Jiri Slaby
Post by Andi Kleen
What do you mean with not run?
(II) intel(0): Initializing HW Cursor
(II) intel(0): xf86BindGARTMemory: bind key 0 at 0x005ff000 (pgoffset 1535)
(WW) intel(0): xf86BindGARTMemory: binding of gart memory with key 0
at offset 0x5ff000 failed (Invalid argument)
Couldn't bind memory for front buffer
I thought I'd seen a thread about this issue, but I can't find it now. Is it
known or am I seeing ghosts yet, Andrew?
That would probably have been me, saying that x86_64-mm-cpa-clflush.patch broke
the NVidia graphics driver in 23-rc3-mm1. Is it breaking *other* X drivers as
well?
Jiri Slaby
2007-09-19 20:47:41 UTC
Permalink
Post by V***@vt.edu
Post by Jiri Slaby
Post by Andi Kleen
Post by Jiri Slaby
Yeah. (But X doesn't run -- this is maybe the known issue in this release)
.
Post by Jiri Slaby
Post by Andi Kleen
What do you mean with not run?
(II) intel(0): Initializing HW Cursor
(II) intel(0): xf86BindGARTMemory: bind key 0 at 0x005ff000 (pgoffset 1535)
(WW) intel(0): xf86BindGARTMemory: binding of gart memory with key 0
at offset 0x5ff000 failed (Invalid argument)
Couldn't bind memory for front buffer
I thought I'd seen a thread about this issue, but I can't find it now. Is it
known or am I seeing ghosts yet, Andrew?
That would probably have been me, saying that x86_64-mm-cpa-clflush.patch broke
the NVidia graphics driver in 23-rc3-mm1. Is it breaking *other* X drivers as
well?
Yes, the issue is there from rc3-mm1, see (intel and radeon cards are affected
in my case):
http://lkml.org/lkml/2007/9/9/51

But now I'm talking about another issue -- a regression since rc4-mm1, where X
server is unable to bind agp memory (those x logs above). The clflush issue has
solved andi in
http://lkml.org/lkml/2007/9/19/334
recently

regards,
--
Jiri Slaby (***@gmail.com)
Faculty of Informatics, Masaryk University
Dave Airlie
2007-09-20 01:51:47 UTC
Permalink
Post by Jiri Slaby
Post by Andi Kleen
Post by Jiri Slaby
Yeah. (But X doesn't run -- this is maybe the known issue in this release).
What do you mean with not run?
(II) intel(0): Initializing HW Cursor
(II) intel(0): xf86BindGARTMemory: bind key 0 at 0x005ff000 (pgoffset 1535)
(WW) intel(0): xf86BindGARTMemory: binding of gart memory with key 0
at offset 0x5ff000 failed (Invalid argument)
Couldn't bind memory for front buffer
I thought I'd seen a thread about this issue, but I can't find it now. Is it
known or am I seeing ghosts yet, Andrew?
Can you send me a complete Xorg log file?

and lspci -vv?

my 945 works fine with my drm tree on top of Linus with clflush + my
agp fix I just sent out ..

Dave.
Jiri Slaby
2007-09-20 07:24:56 UTC
Permalink
Post by Dave Airlie
Post by Jiri Slaby
Post by Andi Kleen
Post by Jiri Slaby
Yeah. (But X doesn't run -- this is maybe the known issue in this release).
What do you mean with not run?
(II) intel(0): Initializing HW Cursor
(II) intel(0): xf86BindGARTMemory: bind key 0 at 0x005ff000 (pgoffset 1535)
(WW) intel(0): xf86BindGARTMemory: binding of gart memory with key 0
at offset 0x5ff000 failed (Invalid argument)
Couldn't bind memory for front buffer
I thought I'd seen a thread about this issue, but I can't find it now. Is it
known or am I seeing ghosts yet, Andrew?
Can you send me a complete Xorg log file?
Maybe you are rather interested in these dmesg lines:
Linux agpgart interface v0.102
agpgart: suspend/resume problematic: resume with 3D/DRI active may lockup X.Org
on some chipset/BIOS combos (see DEBUG_AGP_PM in intel-agp.c)
agpgart: Detected an Intel G33 Chipset.
agpgart: Detected 8192K stolen memory.
agpgart: AGP aperture is 256M @ 0xd0000000
[drm] Initialized drm 1.1.0 20060810
ACPI: PCI Interrupt 0000:00:02.0[A] -> GSI 16 (level, low) -> IRQ 16
[drm] Initialized i915 1.6.0 20060119 on minor 0
...
set status page addr 0x00033000
agpgart: pg_start == 0x000005ff,intel_private.gtt_entries == 0x00000800
agpgart: Trying to insert into local/stolen memory

So the problem is, that X passes too low start.

The X log:
http://www.fi.muni.cz/~xslaby/sklad/Xorg.0.log.old
Post by Dave Airlie
and lspci -vv?
# lspci -vvx
00:00.0 Host bridge: Intel Corporation DRAM Controller (rev 02)
Subsystem: Intel Corporation DRAM Controller
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort+ >SERR- <PERR-
Latency: 0
Capabilities: [e0] Vendor Specific Information
00: 86 80 c0 29 06 00 90 20 02 00 00 06 00 00 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 c0 29
30: 00 00 00 00 e0 00 00 00 00 00 00 00 00 00 00 00

00:02.0 VGA compatible controller: Intel Corporation Integrated Graphics
Controller (rev 02) (prog-if 00 [VGA])
Subsystem: Intel Corporation Integrated Graphics Controller
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin A routed to IRQ 16
Region 0: Memory at ffa80000 (32-bit, non-prefetchable) [size=512K]
Region 1: I/O ports at ec00 [size=8]
Region 2: Memory at d0000000 (32-bit, prefetchable) [size=256M]
Region 3: Memory at ff900000 (32-bit, non-prefetchable) [size=1M]
Capabilities: [90] Message Signalled Interrupts: Mask- 64bit- Queue=0/0
Enable-
Address: 00000000 Data: 0000
Capabilities: [d0] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00: 86 80 c2 29 07 00 90 00 02 00 00 03 00 00 00 00
10: 00 00 a8 ff 01 ec 00 00 08 00 00 d0 00 00 90 ff
20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 c2 29
30: 00 00 00 00 90 00 00 00 00 00 00 00 0a 01 00 00

00:03.0 Communication controller: Intel Corporation MEI Controller (rev 02)
Subsystem: Intel Corporation MEI Controller
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin A routed to IRQ 10
Region 0: Memory at ffa7bc00 (64-bit, non-prefetchable) [size=16]
Capabilities: [50] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [8c] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0
Enable-
Address: 0000000000000000 Data: 0000
00: 86 80 c4 29 06 00 10 00 02 00 80 07 00 00 80 00
10: 04 bc a7 ff 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 c4 29
30: 00 00 00 00 50 00 00 00 00 00 00 00 0a 01 00 00

00:03.2 IDE interface: Intel Corporation PT IDER Controller (rev 02) (prog-if 85
[Master SecO PriO])
Subsystem: Intel Corporation PT IDER Controller
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin C routed to IRQ 12
Region 0: I/O ports at e880 [size=8]
Region 1: I/O ports at e800 [size=4]
Region 2: I/O ports at e480 [size=8]
Region 3: I/O ports at e400 [size=4]
Region 4: I/O ports at e080 [size=16]
Capabilities: [c8] Power Management version 3
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [d0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0
Enable-
Address: 0000000000000000 Data: 0000
00: 86 80 c6 29 05 00 b0 00 02 85 01 01 00 00 00 00
10: 81 e8 00 00 01 e8 00 00 81 e4 00 00 01 e4 00 00
20: 81 e0 00 00 00 00 00 00 00 00 00 00 86 80 c6 29
30: 00 00 00 00 c8 00 00 00 00 00 00 00 0c 03 00 00

00:03.3 Serial controller: Intel Corporation Serial KT Controller (rev 02)
(prog-if 02 [16550])
Subsystem: Intel Corporation Serial KT Controller
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin B routed to IRQ 17
Region 0: I/O ports at e000 [size=8]
Region 1: Memory at ffa7a000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [c8] Power Management version 3
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [d0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0
Enable-
Address: 0000000000000000 Data: 0000
00: 86 80 c7 29 07 00 b0 00 02 02 00 07 00 00 00 00
10: 01 e0 00 00 00 a0 a7 ff 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 c7 29
30: 00 00 00 00 c8 00 00 00 00 00 00 00 05 02 00 00

00:19.0 Ethernet controller: Intel Corporation 82566DM-2 Gigabit Network
Connection (rev 02)
Subsystem: Intel Corporation Unknown device 0000
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin A routed to IRQ 318
Region 0: Memory at ffa40000 (32-bit, non-prefetchable) [size=128K]
Region 1: Memory at ffa79000 (32-bit, non-prefetchable) [size=4K]
Region 2: I/O ports at dc00 [size=32]
Capabilities: [c8] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=1 PME-
Capabilities: [d0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0
Enable+
Address: 00000000fee0300c Data: 4199
Capabilities: [e0] Vendor Specific Information
00: 86 80 bd 10 07 04 10 00 02 00 00 02 00 00 00 00
10: 00 00 a4 ff 00 90 a7 ff 01 dc 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 00 00
30: 00 00 00 00 c8 00 00 00 00 00 00 00 0f 01 00 00

00:1a.0 USB Controller: Intel Corporation USB UHCI Controller #4 (rev 02)
(prog-if 00 [UHCI])
Subsystem: Intel Corporation USB UHCI Controller #4
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin A routed to IRQ 16
Region 4: I/O ports at d880 [size=32]
Capabilities: [50] Vendor Specific Information
00: 86 80 37 29 05 00 90 02 02 00 03 0c 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 81 d8 00 00 00 00 00 00 00 00 00 00 86 80 37 29
30: 00 00 00 00 50 00 00 00 00 00 00 00 0a 01 00 00

00:1a.1 USB Controller: Intel Corporation USB UHCI Controller #5 (rev 02)
(prog-if 00 [UHCI])
Subsystem: Intel Corporation USB UHCI Controller #5
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin B routed to IRQ 21
Region 4: I/O ports at d800 [size=32]
Capabilities: [50] Vendor Specific Information
00: 86 80 38 29 05 00 90 02 02 00 03 0c 00 00 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 01 d8 00 00 00 00 00 00 00 00 00 00 86 80 38 29
30: 00 00 00 00 50 00 00 00 00 00 00 00 0e 02 00 00

00:1a.2 USB Controller: Intel Corporation USB UHCI Controller #6 (rev 02)
(prog-if 00 [UHCI])
Subsystem: Intel Corporation USB UHCI Controller #6
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin C routed to IRQ 18
Region 4: I/O ports at d480 [size=32]
Capabilities: [50] Vendor Specific Information
00: 86 80 39 29 05 00 90 02 02 00 03 0c 00 00 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 81 d4 00 00 00 00 00 00 00 00 00 00 86 80 39 29
30: 00 00 00 00 50 00 00 00 00 00 00 00 0c 03 00 00

00:1a.7 USB Controller: Intel Corporation USB2 EHCI Controller #2 (rev 02)
(prog-if 20 [EHCI])
Subsystem: Intel Corporation USB2 EHCI Controller #2
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin D routed to IRQ 19
Region 0: Memory at ffa7b400 (32-bit, non-prefetchable) [size=1K]
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA
PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [58] Debug port
Capabilities: [98] Vendor Specific Information
00: 86 80 3c 29 06 00 90 02 02 20 03 0c 00 00 00 00
10: 00 b4 a7 ff 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 3c 29
30: 00 00 00 00 50 00 00 00 00 00 00 00 03 04 00 00

00:1b.0 Audio device: Intel Corporation HD Audio Controller (rev 02)
Subsystem: Intel Corporation HD Audio Controller
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR-
Latency: 0, Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 22
Region 0: Memory at ffa70000 (64-bit, non-prefetchable) [size=16K]
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA
PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [60] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0
Enable-
Address: 0000000000000000 Data: 0000
Capabilities: [70] Express Unknown type IRQ 0
Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag-
Device: Latency L0s <64ns, L1 <1us
Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported-
Device: RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+
Device: MaxPayload 128 bytes, MaxReadReq 128 bytes
Link: Supported Speed unknown, Width x0, ASPM unknown, Port 0
Link: Latency L0s <64ns, L1 <1us
Link: ASPM Disabled CommClk- ExtSynch-
Link: Speed unknown, Width x0
Capabilities: [100] Virtual Channel
Capabilities: [130] Unknown (5)
00: 86 80 3e 29 06 00 10 00 02 00 03 04 08 00 00 00
10: 04 00 a7 ff 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 3e 29
30: 00 00 00 00 50 00 00 00 00 00 00 00 07 01 00 00

00:1d.0 USB Controller: Intel Corporation USB UHCI Controller #1 (rev 02)
(prog-if 00 [UHCI])
Subsystem: Intel Corporation USB UHCI Controller #1
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin A routed to IRQ 23
Region 4: I/O ports at d400 [size=32]
Capabilities: [50] Vendor Specific Information
00: 86 80 34 29 05 00 90 02 02 00 03 0c 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 01 d4 00 00 00 00 00 00 00 00 00 00 86 80 34 29
30: 00 00 00 00 50 00 00 00 00 00 00 00 0a 01 00 00

00:1d.1 USB Controller: Intel Corporation USB UHCI Controller #2 (rev 02)
(prog-if 00 [UHCI])
Subsystem: Intel Corporation USB UHCI Controller #2
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin B routed to IRQ 19
Region 4: I/O ports at d080 [size=32]
Capabilities: [50] Vendor Specific Information
00: 86 80 35 29 05 00 90 02 02 00 03 0c 00 00 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 81 d0 00 00 00 00 00 00 00 00 00 00 86 80 35 29
30: 00 00 00 00 50 00 00 00 00 00 00 00 03 02 00 00

00:1d.2 USB Controller: Intel Corporation USB UHCI Controller #3 (rev 02)
(prog-if 00 [UHCI])
Subsystem: Intel Corporation USB UHCI Controller #3
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin D routed to IRQ 16
Region 4: I/O ports at d000 [size=32]
Capabilities: [50] Vendor Specific Information
00: 86 80 36 29 05 00 90 02 02 00 03 0c 00 00 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 01 d0 00 00 00 00 00 00 00 00 00 00 86 80 36 29
30: 00 00 00 00 50 00 00 00 00 00 00 00 0a 04 00 00

00:1d.7 USB Controller: Intel Corporation USB2 EHCI Controller #1 (rev 02)
(prog-if 20 [EHCI])
Subsystem: Intel Corporation USB2 EHCI Controller #1
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin A routed to IRQ 23
Region 0: Memory at ffa7b000 (32-bit, non-prefetchable) [size=1K]
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA
PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [58] Debug port
Capabilities: [98] Vendor Specific Information
00: 86 80 3a 29 06 00 90 02 02 20 03 0c 00 00 00 00
10: 00 b0 a7 ff 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 3a 29
30: 00 00 00 00 50 00 00 00 00 00 00 00 0a 01 00 00

00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 92) (prog-if 01
[Subtractive decode])
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR+ FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR-
Latency: 0
Bus: primary=00, secondary=01, subordinate=01, sec-latency=32
Memory behind bridge: ff600000-ff6fffff
Secondary status: 66MHz- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort+ <SERR- <PERR-
BridgeCtl: Parity- SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
Capabilities: [50] Subsystem: Intel Corporation 82801 PCI Bridge
00: 86 80 4e 24 06 01 10 00 92 01 04 06 00 00 01 00
10: 00 00 00 00 00 00 00 00 00 01 01 20 f0 00 80 22
20: 60 ff 60 ff f1 ff 01 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 50 00 00 00 00 00 00 00 ff 00 02 00

00:1f.0 ISA bridge: Intel Corporation LPC Interface Controller (rev 02)
Subsystem: Intel Corporation LPC Interface Controller
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Capabilities: [e0] Vendor Specific Information
00: 86 80 10 29 07 00 10 02 02 00 01 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 10 29
30: 00 00 00 00 e0 00 00 00 00 00 00 00 00 00 00 00

00:1f.2 SATA controller: Intel Corporation 6 port SATA AHCI Controller (rev 02)
(prog-if 01 [AHCI 1.0])
Subsystem: Intel Corporation 6 port SATA AHCI Controller
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin B routed to IRQ 319
Region 0: I/O ports at cc00 [size=8]
Region 1: I/O ports at c880 [size=4]
Region 2: I/O ports at c800 [size=8]
Region 3: I/O ports at c480 [size=4]
Region 4: I/O ports at c400 [size=32]
Region 5: Memory at ffa78800 (32-bit, non-prefetchable) [size=2K]
Capabilities: [80] Message Signalled Interrupts: Mask- 64bit- Queue=0/4
Enable+
Address: fee0300c Data: 4169
Capabilities: [70] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot+,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [a8] #12 [0010]
Capabilities: [b0] Vendor Specific Information
00: 86 80 22 29 07 04 b0 02 02 01 06 01 00 00 00 00
10: 01 cc 00 00 81 c8 00 00 01 c8 00 00 81 c4 00 00
20: 01 c4 00 00 00 88 a7 ff 00 00 00 00 86 80 22 29
30: 00 00 00 00 80 00 00 00 00 00 00 00 03 02 00 00

00:1f.3 SMBus: Intel Corporation SMBus Controller (rev 02)
Subsystem: Intel Corporation SMBus Controller
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin C routed to IRQ 18
Region 0: Memory at ffa7b800 (64-bit, non-prefetchable) [size=256]
Region 4: I/O ports at 0400 [size=32]
00: 86 80 30 29 03 00 80 02 02 00 05 0c 00 00 00 00
10: 04 b8 a7 ff 00 00 00 00 00 00 00 00 00 00 00 00
20: 01 04 00 00 00 00 00 00 00 00 00 00 86 80 30 29
30: 00 00 00 00 00 00 00 00 00 00 00 00 03 03 00 00

00:1f.5 IDE interface: Intel Corporation 2 port SATA IDE Controller (rev 02)
(prog-if 85 [Master SecO PriO])
Subsystem: Intel Corporation 2 port SATA IDE Controller
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin B routed to IRQ 19
Region 0: I/O ports at c000 [size=8]
Region 1: I/O ports at bc00 [size=4]
Region 2: I/O ports at b880 [size=8]
Region 3: I/O ports at b800 [size=4]
Region 4: I/O ports at b480 [size=16]
Region 5: I/O ports at b400 [size=16]
Capabilities: [70] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [b0] Vendor Specific Information
00: 86 80 26 29 07 00 b0 02 02 85 01 01 00 00 00 00
10: 01 c0 00 00 01 bc 00 00 81 b8 00 00 01 b8 00 00
20: 81 b4 00 00 01 b4 00 00 00 00 00 00 86 80 26 29
30: 00 00 00 00 70 00 00 00 00 00 00 00 03 02 00 00

00:1f.6 Signal processing controller: Intel Corporation Thermal Subsystem (rev 02)
Subsystem: Intel Corporation Thermal Subsystem
Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR-
Interrupt: pin C routed to IRQ 12
Region 0: Memory at ffa6f000 (64-bit, non-prefetchable) [size=4K]
Capabilities: [50] Power Management version 3
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00: 86 80 32 29 02 00 10 00 02 00 80 11 00 00 00 00
10: 04 f0 a6 ff 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 32 29
30: 00 00 00 00 50 00 00 00 00 00 00 00 0c 03 00 00

01:00.0 Ethernet controller: Atheros Communications, Inc. AR5212 802.11abg NIC
(rev 01)
Subsystem: Wistron NeWeb Corp. CM9 Wireless a/b/g MiniPCI Adapter
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 64 (2500ns min, 7000ns max), Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 14
Region 0: Memory at ff6f0000 (32-bit, non-prefetchable) [size=64K]
Capabilities: [44] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=2 PME-
00: 8c 16 13 00 16 00 90 02 01 00 00 02 08 40 00 00
10: 00 00 6f ff 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 01 50 00 00 5f 18 12 10
30: 00 00 00 00 44 00 00 00 00 00 00 00 0e 01 0a 1c
Post by Dave Airlie
my 945 works fine with my drm tree on top of Linus with clflush + my
agp fix I just sent out ..
Should I try?

regards,
--
Jiri Slaby (***@gmail.com)
Faculty of Informatics, Masaryk University
Dave Airlie
2007-09-20 07:33:45 UTC
Permalink
Post by Jiri Slaby
Post by Dave Airlie
Post by Jiri Slaby
Couldn't bind memory for front buffer
I thought I'd seen a thread about this issue, but I can't find it now. Is it
known or am I seeing ghosts yet, Andrew?
Can you send me a complete Xorg log file?
Linux agpgart interface v0.102
agpgart: suspend/resume problematic: resume with 3D/DRI active may lockup X.Org
on some chipset/BIOS combos (see DEBUG_AGP_PM in intel-agp.c)
agpgart: Detected an Intel G33 Chipset.
agpgart: Detected 8192K stolen memory.
[drm] Initialized drm 1.1.0 20060810
ACPI: PCI Interrupt 0000:00:02.0[A] -> GSI 16 (level, low) -> IRQ 16
[drm] Initialized i915 1.6.0 20060119 on minor 0
...
set status page addr 0x00033000
agpgart: pg_start == 0x000005ff,intel_private.gtt_entries == 0x00000800
agpgart: Trying to insert into local/stolen memory
So the problem is, that X passes too low start.
http://www.fi.muni.cz/~xslaby/sklad/Xorg.0.log.old
I've cc'd Zhenyu who might be able to shed some light on this? can you
try 2.6.23-rc7 as maybe the G33 support still needs some work.. or
maybe I'm missing a patch in the drm..

Dave.
Dave Airlie
2007-09-20 00:18:54 UTC
Permalink
Post by Andi Kleen
Post by Andrew Morton
Post by Jiri Slaby
---------8<---------8<---------8<---------8<---------8<---------8<----
That means
void agp_generic_destroy_page(void *addr)
{
struct page *page;
if (addr == NULL)
return;
page = virt_to_page(addr);
(1) unmap_page_from_agp(page);
put_page(page);
(2) free_page((unsigned long)addr);
atomic_dec(&agp_bridge->current_memory_agp);
}
(1) unmap_page_from_agp -> change_page_attr -> change_page_attr_addr ->
__change_page_attr -> save_page -> list_add(&fpage->lru, &deferred_pages);
(2) free_page -> free_pages -> __free_pages -> free_hot_page ->
free_hot_cold_page -> list_add(&page->lru, &pcp->list);
that'll hurt.
Post by Jiri Slaby
any ideas how to fix this?
We should hold a single reference on the page for its membership in
deferred_pages.
The code is broken anyways. If you free pages without flushing
them first some other innocent user allocating them will end up
with possible uncached pages for some time.
Does this simple patch help?
-Andi
Flush uncached AGP pages before freeing
In theory this should be handled by the caller, so as to avoid the
overhead of continuous flushing however I can see a potential race
condition here if the pages are put back into the kernel before the
caller flushes the mappings..

Do we need some sort of two step approach here? as flushing after each
page would be a major overhead for dynamic agp stuff in the new memory
manager..

Dave.
Post by Andi Kleen
Index: linux/drivers/char/agp/generic.c
===================================================================
--- linux.orig/drivers/char/agp/generic.c
+++ linux/drivers/char/agp/generic.c
@@ -1185,6 +1185,7 @@ void agp_generic_destroy_page(void *addr
page = virt_to_page(addr);
unmap_page_from_agp(page);
+ flush_agp_mappings();
put_page(page);
free_page((unsigned long)addr);
atomic_dec(&agp_bridge->current_memory_agp);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Dave Airlie
2007-09-20 01:42:29 UTC
Permalink
Post by Andi Kleen
The code is broken anyways. If you free pages without flushing
them first some other innocent user allocating them will end up
with possible uncached pages for some time.
Does this simple patch help?
I've attached a more complicated patch that does a 2 stage effort to
unmapping and freeing pages. My kernel no longer hangs with this
patch...

Jiri can you confirm?

I'll look at the other issue separately..

Dave.
Andrew Morton
2007-09-20 02:24:39 UTC
Permalink
From 225696d75e7ec0bafbb47b935bd700e3fbeefbde Mon Sep 17 00:00:00 2001
Date: Thu, 20 Sep 2007 11:30:41 +1000
Subject: [PATCH] agp: fix race condition between unmapping and freeing pages
This fixes the hang-when-quitting-X on the Vaio.
Jiri Slaby
2007-09-20 07:19:51 UTC
Permalink
Post by Andrew Morton
From 225696d75e7ec0bafbb47b935bd700e3fbeefbde Mon Sep 17 00:00:00 2001
Date: Thu, 20 Sep 2007 11:30:41 +1000
Subject: [PATCH] agp: fix race condition between unmapping and freeing pages
This fixes the hang-when-quitting-X on the Vaio.
Checked.
Andy Whitcroft
2007-09-19 16:43:48 UTC
Permalink
Seems I have a case of a largish i386 NUMA (NUMA-Q) which has a mkfs
stuck in a 'D' wait:

=======================
mkfs.ext2 D c10220f4 0 6233 6222
c344fc80 00000082 00000286 c10220f4 c344fc90 002ed099 c2963340 c2b9f640
c142bce0 c2b9f640 c344fc90 002ed099 c344fcfc c344fcc0 c1219563 c1109bf2
c344fcc4 c186e4d4 c186e4d4 002ed099 c1022612 c2b9f640 c186e000 c104000c
Call Trace:
[<c10220f4>] lock_timer_base+0x19/0x35
[<c1219563>] schedule_timeout+0x70/0x8d
[<c1109bf2>] prop_fraction_single+0x37/0x5d
[<c1022612>] process_timeout+0x0/0x5
[<c104000c>] task_dirty_limit+0x3a/0xb5
[<c12194da>] io_schedule_timeout+0x1e/0x28
[<c10454b4>] congestion_wait+0x62/0x7a
[<c102b021>] autoremove_wake_function+0x0/0x33
[<c10402af>] get_dirty_limits+0x16a/0x172
[<c102b021>] autoremove_wake_function+0x0/0x33
[<c104040b>] balance_dirty_pages+0x154/0x1be
[<c103bda3>] generic_perform_write+0x168/0x18a
[<c103be38>] generic_file_buffered_write+0x73/0x107
[<c103c346>] __generic_file_aio_write_nolock+0x47a/0x4a5
[<c11b0fef>] do_sock_write+0x92/0x99
[<c11b1048>] sock_aio_write+0x52/0x5e
[<c103c3b9>] generic_file_aio_write_nolock+0x48/0x9b
[<c105d2d6>] do_sync_write+0xbf/0xfc
[<c102b021>] autoremove_wake_function+0x0/0x33
[<c1010311>] do_page_fault+0x2cc/0x739
[<c105d3a0>] vfs_write+0x8d/0x108
[<c105d4c3>] sys_write+0x41/0x67
[<c100260a>] syscall_call+0x7/0xb
=======================

This machine and others have run numerous test runs on this kernel and
this is the first time I've see a hang like this.

I wonder if this is the ultimate cause of the couple of mainline hangs
which were seen, but not diagnosed.

-apw
Hugh Dickins
2007-09-19 20:03:19 UTC
Permalink
Post by Andy Whitcroft
Seems I have a case of a largish i386 NUMA (NUMA-Q) which has a mkfs
=======================
mkfs.ext2 D c10220f4 0 6233 6222
[<c12194da>] io_schedule_timeout+0x1e/0x28
[<c10454b4>] congestion_wait+0x62/0x7a
[<c10402af>] get_dirty_limits+0x16a/0x172
[<c104040b>] balance_dirty_pages+0x154/0x1be
[<c103bda3>] generic_perform_write+0x168/0x18a
[<c103be38>] generic_file_buffered_write+0x73/0x107
[<c103c346>] __generic_file_aio_write_nolock+0x47a/0x4a5
[<c103c3b9>] generic_file_aio_write_nolock+0x48/0x9b
[<c105d2d6>] do_sync_write+0xbf/0xfc
[<c105d3a0>] vfs_write+0x8d/0x108
[<c105d4c3>] sys_write+0x41/0x67
[<c100260a>] syscall_call+0x7/0xb
=======================
[edited out some bogus lines from stale stack]
Post by Andy Whitcroft
This machine and others have run numerous test runs on this kernel and
this is the first time I've see a hang like this.
I've been seeing something like that on 4-way PPC64: in my case I've
shells hanging in D state trying to append to kernel build log on ext3
(the builds themselves going on elsewhere, in tmpfs): one of the shells
holding i_mutex and stuck doing congestion_waits from balance_dirty_pages.
Post by Andy Whitcroft
I wonder if this is the ultimate cause of the couple of mainline hangs
which were seen, but not diagnosed.
My *guess* is that this is peculiar to 2.6.23-rc6-mm1, and from Peter's
mm-per-device-dirty-threshold.patch. printks showed bdi_nr_reclaimable
0, bdi_nr_writeback 24, bdi_thresh 1 in balance_dirty_pages (though I've
not done enough to check if those really correlate with the hangs),
and I'm wondering if the bdi_stat_sum business is needed on the
!nr_reclaimable path.

So I'm running now with the patch below, good so far, but can't judge
until tomorrow whether it has actually addressed the problem seen.

Not-yet-Signed-off-by: Hugh Dickins <***@veritas.com>
---
mm/page-writeback.c | 53 +++++++++++++++++++-----------------------
1 file changed, 24 insertions(+), 29 deletions(-)

--- 2.6.23-rc6-mm1/mm/page-writeback.c 2007-09-18 12:28:25.000000000 +0100
+++ linux/mm/page-writeback.c 2007-09-19 20:00:46.000000000 +0100
@@ -379,7 +379,7 @@ static void balance_dirty_pages(struct a
bdi_nr_reclaimable = bdi_stat(bdi, BDI_RECLAIMABLE);
bdi_nr_writeback = bdi_stat(bdi, BDI_WRITEBACK);
if (bdi_nr_reclaimable + bdi_nr_writeback <= bdi_thresh)
- break;
+ break;

if (!bdi->dirty_exceeded)
bdi->dirty_exceeded = 1;
@@ -392,39 +392,34 @@ static void balance_dirty_pages(struct a
*/
if (bdi_nr_reclaimable) {
writeback_inodes(&wbc);
-
+ pages_written += write_chunk - wbc.nr_to_write;
get_dirty_limits(&background_thresh, &dirty_thresh,
&bdi_thresh, bdi);
+ }

- /*
- * In order to avoid the stacked BDI deadlock we need
- * to ensure we accurately count the 'dirty' pages when
- * the threshold is low.
- *
- * Otherwise it would be possible to get thresh+n pages
- * reported dirty, even though there are thresh-m pages
- * actually dirty; with m+n sitting in the percpu
- * deltas.
- */
- if (bdi_thresh < 2*bdi_stat_error(bdi)) {
- bdi_nr_reclaimable =
- bdi_stat_sum(bdi, BDI_RECLAIMABLE);
- bdi_nr_writeback =
- bdi_stat_sum(bdi, BDI_WRITEBACK);
- } else {
- bdi_nr_reclaimable =
- bdi_stat(bdi, BDI_RECLAIMABLE);
- bdi_nr_writeback =
- bdi_stat(bdi, BDI_WRITEBACK);
- }
+ /*
+ * In order to avoid the stacked BDI deadlock we need
+ * to ensure we accurately count the 'dirty' pages when
+ * the threshold is low.
+ *
+ * Otherwise it would be possible to get thresh+n pages
+ * reported dirty, even though there are thresh-m pages
+ * actually dirty; with m+n sitting in the percpu
+ * deltas.
+ */
+ if (bdi_thresh < 2*bdi_stat_error(bdi)) {
+ bdi_nr_reclaimable = bdi_stat_sum(bdi, BDI_RECLAIMABLE);
+ bdi_nr_writeback = bdi_stat_sum(bdi, BDI_WRITEBACK);
+ } else if (bdi_nr_reclaimable) {
+ bdi_nr_reclaimable = bdi_stat(bdi, BDI_RECLAIMABLE);
+ bdi_nr_writeback = bdi_stat(bdi, BDI_WRITEBACK);
+ }

- if (bdi_nr_reclaimable + bdi_nr_writeback <= bdi_thresh)
- break;
+ if (bdi_nr_reclaimable + bdi_nr_writeback <= bdi_thresh)
+ break;
+ if (pages_written >= write_chunk)
+ break; /* We've done our duty */

- pages_written += write_chunk - wbc.nr_to_write;
- if (pages_written >= write_chunk)
- break; /* We've done our duty */
- }
congestion_wait(WRITE, HZ/10);
}
Peter Zijlstra
2007-09-19 20:44:09 UTC
Permalink
On Wed, 19 Sep 2007 21:03:19 +0100 (BST) Hugh Dickins
Post by Hugh Dickins
Post by Andy Whitcroft
Seems I have a case of a largish i386 NUMA (NUMA-Q) which has a mkfs
=======================
mkfs.ext2 D c10220f4 0 6233 6222
[<c12194da>] io_schedule_timeout+0x1e/0x28
[<c10454b4>] congestion_wait+0x62/0x7a
[<c10402af>] get_dirty_limits+0x16a/0x172
[<c104040b>] balance_dirty_pages+0x154/0x1be
[<c103bda3>] generic_perform_write+0x168/0x18a
[<c103be38>] generic_file_buffered_write+0x73/0x107
[<c103c346>] __generic_file_aio_write_nolock+0x47a/0x4a5
[<c103c3b9>] generic_file_aio_write_nolock+0x48/0x9b
[<c105d2d6>] do_sync_write+0xbf/0xfc
[<c105d3a0>] vfs_write+0x8d/0x108
[<c105d4c3>] sys_write+0x41/0x67
[<c100260a>] syscall_call+0x7/0xb
=======================
[edited out some bogus lines from stale stack]
Post by Andy Whitcroft
This machine and others have run numerous test runs on this kernel and
this is the first time I've see a hang like this.
I've been seeing something like that on 4-way PPC64: in my case I've
shells hanging in D state trying to append to kernel build log on ext3
(the builds themselves going on elsewhere, in tmpfs): one of the shells
holding i_mutex and stuck doing congestion_waits from balance_dirty_pages.
Post by Andy Whitcroft
I wonder if this is the ultimate cause of the couple of mainline hangs
which were seen, but not diagnosed.
My *guess* is that this is peculiar to 2.6.23-rc6-mm1, and from Peter's
mm-per-device-dirty-threshold.patch. printks showed bdi_nr_reclaimable
0, bdi_nr_writeback 24, bdi_thresh 1 in balance_dirty_pages (though I've
not done enough to check if those really correlate with the hangs),
and I'm wondering if the bdi_stat_sum business is needed on the
!nr_reclaimable path.
FWIW my tired brain seems to think it the !nr_reclaimable path needs it
just the same. So this change seems to make sense for now :-)
Post by Hugh Dickins
So I'm running now with the patch below, good so far, but can't judge
until tomorrow whether it has actually addressed the problem seen.
---
mm/page-writeback.c | 53 +++++++++++++++++++-----------------------
1 file changed, 24 insertions(+), 29 deletions(-)
--- 2.6.23-rc6-mm1/mm/page-writeback.c 2007-09-18 12:28:25.000000000 +0100
+++ linux/mm/page-writeback.c 2007-09-19 20:00:46.000000000 +0100
@@ -379,7 +379,7 @@ static void balance_dirty_pages(struct a
bdi_nr_reclaimable = bdi_stat(bdi, BDI_RECLAIMABLE);
bdi_nr_writeback = bdi_stat(bdi, BDI_WRITEBACK);
if (bdi_nr_reclaimable + bdi_nr_writeback <= bdi_thresh)
- break;
+ break;
if (!bdi->dirty_exceeded)
bdi->dirty_exceeded = 1;
@@ -392,39 +392,34 @@ static void balance_dirty_pages(struct a
*/
if (bdi_nr_reclaimable) {
writeback_inodes(&wbc);
-
+ pages_written += write_chunk - wbc.nr_to_write;
get_dirty_limits(&background_thresh, &dirty_thresh,
&bdi_thresh, bdi);
+ }
- /*
- * In order to avoid the stacked BDI deadlock we need
- * to ensure we accurately count the 'dirty' pages when
- * the threshold is low.
- *
- * Otherwise it would be possible to get thresh+n pages
- * reported dirty, even though there are thresh-m pages
- * actually dirty; with m+n sitting in the percpu
- * deltas.
- */
- if (bdi_thresh < 2*bdi_stat_error(bdi)) {
- bdi_nr_reclaimable =
- bdi_stat_sum(bdi, BDI_RECLAIMABLE);
- bdi_nr_writeback =
- bdi_stat_sum(bdi, BDI_WRITEBACK);
- } else {
- bdi_nr_reclaimable =
- bdi_stat(bdi, BDI_RECLAIMABLE);
- bdi_nr_writeback =
- bdi_stat(bdi, BDI_WRITEBACK);
- }
+ /*
+ * In order to avoid the stacked BDI deadlock we need
+ * to ensure we accurately count the 'dirty' pages when
+ * the threshold is low.
+ *
+ * Otherwise it would be possible to get thresh+n pages
+ * reported dirty, even though there are thresh-m pages
+ * actually dirty; with m+n sitting in the percpu
+ * deltas.
+ */
+ if (bdi_thresh < 2*bdi_stat_error(bdi)) {
+ bdi_nr_reclaimable = bdi_stat_sum(bdi, BDI_RECLAIMABLE);
+ bdi_nr_writeback = bdi_stat_sum(bdi, BDI_WRITEBACK);
+ } else if (bdi_nr_reclaimable) {
+ bdi_nr_reclaimable = bdi_stat(bdi, BDI_RECLAIMABLE);
+ bdi_nr_writeback = bdi_stat(bdi, BDI_WRITEBACK);
+ }
- if (bdi_nr_reclaimable + bdi_nr_writeback <= bdi_thresh)
- break;
+ if (bdi_nr_reclaimable + bdi_nr_writeback <= bdi_thresh)
+ break;
+ if (pages_written >= write_chunk)
+ break; /* We've done our duty */
- pages_written += write_chunk - wbc.nr_to_write;
- if (pages_written >= write_chunk)
- break; /* We've done our duty */
- }
congestion_wait(WRITE, HZ/10);
}
Tilman Schmidt
2007-09-19 23:02:06 UTC
Permalink
I get several "duplicate file name" messages.
Hope Greg's the right one to cc on these.

<4>[ 21.211942] Duplicate file names "rtc" detected. [dump_trace+100/498] dump_trace+0x64/0x1f2
<4>[ 21.216801] [show_trace_log_lvl+26/47] show_trace_log_lvl+0x1a/0x2f
<4>[ 21.221639] [show_trace+18/20] show_trace+0x12/0x14
<4>[ 21.226307] [dump_stack+22/24] dump_stack+0x16/0x18
<4>[ 21.231063] [proc_register+315/332] proc_register+0x13b/0x14c
<4>[ 21.235814] [create_proc_entry+114/135] create_proc_entry+0x72/0x87
<4>[ 21.240562] [<faa1d123>] rtc_proc_add_device+0x1d/0x39 [rtc_core]
<4>[ 21.245304] [<faa1c1f9>] rtc_device_register+0x170/0x207 [rtc_core]
<4>[ 21.250077] [<faa3c5db>] cmos_do_probe+0x8d/0x1ee [rtc_cmos]
<4>[ 21.254715] [<faa3c77d>] cmos_pnp_probe+0x41/0x44 [rtc_cmos]
<4>[ 21.259477] [pnp_device_probe+102/135] pnp_device_probe+0x66/0x87
<4>[ 21.264206] [driver_probe_device+233/362] driver_probe_device+0xe9/0x16a
<4>[ 21.268738] [__driver_attach+108/165] __driver_attach+0x6c/0xa5
<4>[ 21.273387] [bus_for_each_dev+54/91] bus_for_each_dev+0x36/0x5b
<4>[ 21.277975] [driver_attach+25/27] driver_attach+0x19/0x1b
<4>[ 21.282501] [bus_add_driver+115/429] bus_add_driver+0x73/0x1ad
<4>[ 21.286984] [driver_register+103/108] driver_register+0x67/0x6c
<4>[ 21.291269] [pnp_register_driver+23/25] pnp_register_driver+0x17/0x19
<4>[ 21.295661] [<faa4000d>] cmos_init+0xd/0xf [rtc_cmos]
<4>[ 21.300044] [sys_init_module+5544/5953] sys_init_module+0x15a8/0x1741
<4>[ 21.304406] [sysenter_past_esp+107/181] sysenter_past_esp+0x6b/0xb5
<4>[ 21.308749] [phys_startup_32+3085673488/3221225472] 0xb7fba410
<4>[ 21.313108] =======================

<4>[ 22.699930] sysfs: duplicate filename 'bInterfaceNumber' can not be created
<4>[ 22.704755] WARNING: at fs/sysfs/dir.c:433 sysfs_add_one()
<4>[ 22.709606] [dump_trace+100/498] dump_trace+0x64/0x1f2
<4>[ 22.714323] [show_trace_log_lvl+26/47] show_trace_log_lvl+0x1a/0x2f
<4>[ 22.719203] [show_trace+18/20] show_trace+0x12/0x14
<4>[ 22.724040] [dump_stack+22/24] dump_stack+0x16/0x18
<4>[ 22.728890] [sysfs_add_one+87/188] sysfs_add_one+0x57/0xbc
<4>[ 22.733710] [sysfs_add_file+73/135] sysfs_add_file+0x49/0x87
<4>[ 22.738503] [sysfs_create_group+138/240] sysfs_create_group+0x8a/0xf0
<4>[ 22.743272] [<fa99c20a>] usb_create_sysfs_intf_files+0x2d/0xa2 [usbcore]
<4>[ 22.748043] [<fa9989ed>] usb_set_configuration+0x450/0x48d [usbcore]
<4>[ 22.752591] [<fa99fa9b>] generic_probe+0x53/0x94 [usbcore]
<4>[ 22.757127] [<fa99a00b>] usb_probe_device+0x35/0x3b [usbcore]
<4>[ 22.761788] [driver_probe_device+233/362] driver_probe_device+0xe9/0x16a
<4>[ 22.766444] [__device_attach+8/10] __device_attach+0x8/0xa
<4>[ 22.771053] [bus_for_each_drv+56/97] bus_for_each_drv+0x38/0x61
<4>[ 22.775701] [device_attach+112/133] device_attach+0x70/0x85
<4>[ 22.780304] [bus_attach_device+41/119] bus_attach_device+0x29/0x77
<4>[ 22.784900] [device_add+795/1342] device_add+0x31b/0x53e
<4>[ 22.789345] [<fa993de7>] usb_new_device+0x5c/0x168 [usbcore]
<4>[ 22.793968] [<fa9954f9>] hub_thread+0x6b9/0xaa5 [usbcore]
<4>[ 22.798452] [kthread+59/100] kthread+0x3b/0x64
<4>[ 22.803076] [kernel_thread_helper+7/16] kernel_thread_helper+0x7/0x10
<4>[ 22.807553] =======================

Then hwinfo triggers a few "sleeping function called from invalid context"
and "scheduling while atomic" messages of which I cannot make out the source.
Greg?

Sep 20 00:05:54 xenon kernel: [ 35.006948] hwinfo[4490]: segfault at b7dd2f10 eip b7dd2f10 esp bfeac9bc error 4
Sep 20 00:05:54 xenon kernel: [ 35.011097] BUG: sleeping function called from invalid context at kernel/rwsem.c:47
Sep 20 00:05:54 xenon kernel: [ 35.015276] in_atomic():1, irqs_disabled():0
Sep 20 00:05:54 xenon kernel: [ 35.019439] no locks held by hwinfo/4490.
Sep 20 00:05:54 xenon kernel: [ 35.023541] [<c0108441>] dump_trace+0x64/0x1f2
Sep 20 00:05:54 xenon kernel: [ 35.027698] [<c01085e9>] show_trace_log_lvl+0x1a/0x2f
Sep 20 00:05:54 xenon kernel: [ 35.032006] [<c010902b>] show_trace+0x12/0x14
Sep 20 00:05:54 xenon kernel: [ 35.036141] [<c0109154>] dump_stack+0x16/0x18
Sep 20 00:05:54 xenon kernel: [ 35.040457] [<c0123ecd>] __might_sleep+0xe5/0xeb
Sep 20 00:05:54 xenon kernel: [ 35.044704] [<c013f72d>] down_write+0x18/0x54
Sep 20 00:05:54 xenon kernel: [ 35.048762] [<c01890d7>] do_coredump+0x94/0x77d
Sep 20 00:05:54 xenon kernel: [ 35.052974] [<c0135295>] get_signal_to_deliver+0x408/0x434
Sep 20 00:05:54 xenon kernel: [ 35.057187] [<c010673a>] do_notify_resume+0x94/0x6a6
Sep 20 00:05:54 xenon kernel: [ 35.061447] [<c01072e5>] work_notifysig+0x13/0x1a
Sep 20 00:05:54 xenon kernel: [ 35.065682] [<b7dd2f10>] 0xb7dd2f10
Sep 20 00:05:54 xenon kernel: [ 35.069818] =======================
Sep 20 00:05:54 xenon kernel: [ 35.074064] note: hwinfo[4490] exited with preempt_count 1
Sep 20 00:05:54 xenon kernel: [ 35.078196] BUG: scheduling while atomic: hwinfo/4490/0x10000002
Sep 20 00:05:54 xenon kernel: [ 35.082295] no locks held by hwinfo/4490.
Sep 20 00:05:54 xenon kernel: [ 35.086568] [<c0108441>] dump_trace+0x64/0x1f2
Sep 20 00:05:54 xenon kernel: [ 35.090883] [<c01085e9>] show_trace_log_lvl+0x1a/0x2f
Sep 20 00:05:54 xenon kernel: [ 35.095248] [<c010902b>] show_trace+0x12/0x14
Sep 20 00:05:54 xenon kernel: [ 35.099541] [<c0109154>] dump_stack+0x16/0x18
Sep 20 00:05:54 xenon kernel: [ 35.103861] [<c012605c>] __schedule_bug+0x6e/0x75
Sep 20 00:05:54 xenon kernel: [ 35.107854] [<c030f65b>] __sched_text_start+0x83/0x59e
Sep 20 00:05:54 xenon kernel: [ 35.112041] [<c0126084>] __cond_resched+0x21/0x3b
Sep 20 00:05:54 xenon kernel: [ 35.115965] [<c031003b>] cond_resched+0x26/0x31
Sep 20 00:05:54 xenon kernel: [ 35.119975] [<c017059a>] unmap_vmas+0x461/0x580
Sep 20 00:05:54 xenon kernel: [ 35.123985] [<c017351b>] exit_mmap+0x7f/0x10f
Sep 20 00:05:54 xenon kernel: [ 35.128016] [<c012807b>] mmput+0x4d/0xcb
Sep 20 00:05:54 xenon kernel: [ 35.131781] [<c012bea5>] exit_mm+0xd7/0xdc
Sep 20 00:05:54 xenon kernel: [ 35.135519] [<c012d3bb>] do_exit+0x224/0x76b
Sep 20 00:05:54 xenon kernel: [ 35.139218] [<c012d972>] sys_exit_group+0x0/0x11
Sep 20 00:05:54 xenon kernel: [ 35.142903] [<c013529c>] get_signal_to_deliver+0x40f/0x434
Sep 20 00:05:54 xenon kernel: [ 35.146582] [<c010673a>] do_notify_resume+0x94/0x6a6
Sep 20 00:05:54 xenon kernel: [ 35.150285] [<c01072e5>] work_notifysig+0x13/0x1a
Sep 20 00:05:54 xenon kernel: [ 35.153904] [<b7dd2f10>] 0xb7dd2f10
Sep 20 00:05:54 xenon kernel: [ 35.157444] =======================
Sep 20 00:05:54 xenon kernel: [ 35.161014] BUG: scheduling while atomic: hwinfo/4490/0x10000002
Sep 20 00:05:54 xenon kernel: [ 35.164507] no locks held by hwinfo/4490.
Sep 20 00:05:54 xenon kernel: [ 35.168011] [<c0108441>] dump_trace+0x64/0x1f2
Sep 20 00:05:54 xenon kernel: [ 35.171522] [<c01085e9>] show_trace_log_lvl+0x1a/0x2f
Sep 20 00:05:54 xenon kernel: [ 35.175034] [<c010902b>] show_trace+0x12/0x14
Sep 20 00:05:54 xenon kernel: [ 35.178541] [<c0109154>] dump_stack+0x16/0x18
Sep 20 00:05:54 xenon kernel: [ 35.182055] [<c012605c>] __schedule_bug+0x6e/0x75
Sep 20 00:05:54 xenon kernel: [ 35.185571] [<c030f65b>] __sched_text_start+0x83/0x59e
Sep 20 00:05:54 xenon kernel: [ 35.189077] [<c0126084>] __cond_resched+0x21/0x3b
Sep 20 00:05:54 xenon kernel: [ 35.192563] [<c031003b>] cond_resched+0x26/0x31
Sep 20 00:05:54 xenon kernel: [ 35.196101] [<c017059a>] unmap_vmas+0x461/0x580
Sep 20 00:05:54 xenon kernel: [ 35.199546] [<c017351b>] exit_mmap+0x7f/0x10f
Sep 20 00:05:54 xenon kernel: [ 35.202995] [<c012807b>] mmput+0x4d/0xcb
Sep 20 00:05:54 xenon kernel: [ 35.206500] [<c012bea5>] exit_mm+0xd7/0xdc
Sep 20 00:05:54 xenon kernel: [ 35.209894] [<c012d3bb>] do_exit+0x224/0x76b
Sep 20 00:05:54 xenon kernel: [ 35.213330] [<c012d972>] sys_exit_group+0x0/0x11
Sep 20 00:05:54 xenon kernel: [ 35.216680] [<c013529c>] get_signal_to_deliver+0x40f/0x434
Sep 20 00:05:54 xenon kernel: [ 35.220103] [<c010673a>] do_notify_resume+0x94/0x6a6
Sep 20 00:05:54 xenon kernel: [ 35.223484] [<c01072e5>] work_notifysig+0x13/0x1a
Sep 20 00:05:54 xenon kernel: [ 35.226869] [<b7dd2f10>] 0xb7dd2f10
Sep 20 00:05:54 xenon kernel: [ 35.230247] =======================
Sep 20 00:05:54 xenon kernel: [ 35.233787] BUG: scheduling while atomic: hwinfo/4490/0x10000002
Sep 20 00:05:54 xenon kernel: [ 35.237071] no locks held by hwinfo/4490.
Sep 20 00:05:54 xenon kernel: [ 35.240305] [<c0108441>] dump_trace+0x64/0x1f2
Sep 20 00:05:54 xenon kernel: [ 35.243567] [<c01085e9>] show_trace_log_lvl+0x1a/0x2f
Sep 20 00:05:54 xenon kernel: [ 35.246825] [<c010902b>] show_trace+0x12/0x14
Sep 20 00:05:54 xenon kernel: [ 35.250075] [<c0109154>] dump_stack+0x16/0x18
Sep 20 00:05:54 xenon kernel: [ 35.253366] [<c012605c>] __schedule_bug+0x6e/0x75
Sep 20 00:05:54 xenon kernel: [ 35.256631] [<c030f65b>] __sched_text_start+0x83/0x59e
Sep 20 00:05:54 xenon kernel: [ 35.259895] [<c0126084>] __cond_resched+0x21/0x3b
Sep 20 00:05:54 xenon kernel: [ 35.263173] [<c031003b>] cond_resched+0x26/0x31
Sep 20 00:05:54 xenon kernel: [ 35.266441] [<c012c1ff>] put_files_struct+0x83/0xc0
Sep 20 00:05:54 xenon kernel: [ 35.269722] [<c012d3fc>] do_exit+0x265/0x76b
Sep 20 00:05:54 xenon kernel: [ 35.272987] [<c012d972>] sys_exit_group+0x0/0x11
Sep 20 00:05:54 xenon kernel: [ 35.276248] [<c013529c>] get_signal_to_deliver+0x40f/0x434
Sep 20 00:05:54 xenon kernel: [ 35.279545] [<c010673a>] do_notify_resume+0x94/0x6a6
Sep 20 00:05:54 xenon kernel: [ 35.282845] [<c01072e5>] work_notifysig+0x13/0x1a
Sep 20 00:05:54 xenon kernel: [ 35.286169] [<b7dd2f10>] 0xb7dd2f10
Sep 20 00:05:54 xenon kernel: [ 35.289474] =======================

And finally, X doesn't come up, it gets bogged down in a host of "sleeping
function called from invalid context" and "scheduling while atomic" messages.
No idea whom to CC on that.

Sep 20 00:06:06 xenon kernel: [ 53.742236] BUG: sleeping function called from invalid context at kernel/rwsem.c:47
Sep 20 00:06:06 xenon kernel: [ 53.742247] in_atomic():1, irqs_disabled():0
Sep 20 00:06:06 xenon kernel: [ 53.742251] no locks held by gdmgreeter/5809.
Sep 20 00:06:06 xenon kernel: [ 53.742265] [<c0108441>] dump_trace+0x64/0x1f2
Sep 20 00:06:06 xenon kernel: [ 53.742288] [<c01085e9>] show_trace_log_lvl+0x1a/0x2f
Sep 20 00:06:06 xenon kernel: [ 53.742305] [<c010902b>] show_trace+0x12/0x14
Sep 20 00:06:06 xenon kernel: [ 53.742318] [<c0109154>] dump_stack+0x16/0x18
Sep 20 00:06:06 xenon kernel: [ 53.742336] [<c0123ecd>] __might_sleep+0xe5/0xeb
Sep 20 00:06:06 xenon kernel: [ 53.742352] [<c013f72d>] down_write+0x18/0x54
Sep 20 00:06:06 xenon kernel: [ 53.742366] [<c01cf6b9>] do_shmat+0x216/0x384
Sep 20 00:06:06 xenon kernel: [ 53.742382] [<c010b491>] sys_ipc+0x148/0x1b5
Sep 20 00:06:06 xenon kernel: [ 53.742395] [<c010714e>] sysenter_past_esp+0x6b/0xb5
Sep 20 00:06:06 xenon kernel: [ 53.742411] [<b7fc0410>] 0xb7fc0410
Sep 20 00:06:06 xenon kernel: [ 53.742439] =======================
Sep 20 00:06:06 xenon kernel: [ 53.742563] BUG: scheduling while atomic: gdmgreeter/5809/0x00000005
Sep 20 00:06:06 xenon kernel: [ 53.742572] no locks held by gdmgreeter/5809.
Sep 20 00:06:06 xenon kernel: [ 53.742579] irq event stamp: 84510
Sep 20 00:06:06 xenon kernel: [ 53.742585] hardirqs last enabled at (84509): [<c031273f>] _spin_unlock_irqrestore+0x40/0x6d
Sep 20 00:06:06 xenon kernel: [ 53.742607] hardirqs last disabled at (84510): [<c0107167>] sysenter_past_esp+0x84/0xb5
Sep 20 00:06:06 xenon kernel: [ 53.742622] softirqs last enabled at (84410): [<c012f084>] __do_softirq+0xf5/0xfb
Sep 20 00:06:06 xenon kernel: [ 53.742640] softirqs last disabled at (84405): [<c01099ee>] do_softirq+0x77/0xf8
Sep 20 00:06:06 xenon kernel: [ 53.742660] [<c0108441>] dump_trace+0x64/0x1f2
Sep 20 00:06:06 xenon kernel: [ 53.742675] [<c01085e9>] show_trace_log_lvl+0x1a/0x2f
Sep 20 00:06:06 xenon kernel: [ 53.742687] [<c010902b>] show_trace+0x12/0x14
Sep 20 00:06:06 xenon kernel: [ 53.742694] [<c0109154>] dump_stack+0x16/0x18
Sep 20 00:06:06 xenon kernel: [ 53.742702] [<c012605c>] __schedule_bug+0x6e/0x75
Sep 20 00:06:06 xenon kernel: [ 53.742716] [<c030f65b>] __sched_text_start+0x83/0x59e
Sep 20 00:06:06 xenon kernel: [ 53.742730] [<c01072a6>] work_resched+0x5/0x31
Sep 20 00:06:06 xenon kernel: [ 53.742745] [<b7fc0410>] 0xb7fc0410
Sep 20 00:06:06 xenon kernel: [ 53.742760] =======================
Sep 20 00:06:06 xenon kernel: [ 53.742976] X[5716]: segfault at b7e4a5e0 eip b7e4a5e0 esp bf8eb3a8 error 4
Sep 20 00:06:06 xenon kernel: [ 53.742996] note: X[5716] exited with preempt_count 3
Sep 20 00:06:06 xenon kernel: [ 53.743449] BUG: scheduling while atomic: gdmgreeter/5809/0x00000005
Sep 20 00:06:06 xenon kernel: [ 53.743454] no locks held by gdmgreeter/5809.
Sep 20 00:06:06 xenon kernel: [ 53.743464] [<c0108441>] dump_trace+0x64/0x1f2
Sep 20 00:06:06 xenon kernel: [ 53.743476] [<c01085e9>] show_trace_log_lvl+0x1a/0x2f
Sep 20 00:06:06 xenon kernel: [ 53.743482] [<c010902b>] show_trace+0x12/0x14
Sep 20 00:06:06 xenon kernel: [ 53.743488] [<c0109154>] dump_stack+0x16/0x18
Sep 20 00:06:06 xenon kernel: [ 53.743493] [<c012605c>] __schedule_bug+0x6e/0x75
Sep 20 00:06:06 xenon kernel: [ 53.743500] [<c030f65b>] __sched_text_start+0x83/0x59e
Sep 20 00:06:06 xenon kernel: [ 53.743508] [<c03102da>] schedule_timeout+0x16/0x8e
Sep 20 00:06:06 xenon kernel: [ 53.743514] [<c018f9ea>] do_sys_poll+0x27b/0x346
Sep 20 00:06:06 xenon kernel: [ 53.743521] [<c0190578>] sys_poll+0x39/0x6c
Sep 20 00:06:06 xenon kernel: [ 53.743526] [<c010714e>] sysenter_past_esp+0x6b/0xb5
Sep 20 00:06:06 xenon kernel: [ 53.743535] [<b7fc0410>] 0xb7fc0410
Sep 20 00:06:06 xenon kernel: [ 53.743555] =======================
Sep 20 00:06:06 xenon kernel: [ 53.744705] BUG: scheduling while atomic: X/5716/0x10000004
Sep 20 00:06:06 xenon kernel: [ 53.744710] no locks held by X/5716.
Sep 20 00:06:06 xenon kernel: [ 53.744716] [<c0108441>] dump_trace+0x64/0x1f2
Sep 20 00:06:06 xenon kernel: [ 53.744725] [<c01085e9>] show_trace_log_lvl+0x1a/0x2f
Sep 20 00:06:06 xenon kernel: [ 53.744732] [<c010902b>] show_trace+0x12/0x14
Sep 20 00:06:06 xenon kernel: [ 53.744738] [<c0109154>] dump_stack+0x16/0x18
Sep 20 00:06:06 xenon kernel: [ 53.744745] [<c012605c>] __schedule_bug+0x6e/0x75
Sep 20 00:06:06 xenon kernel: [ 53.744752] [<c030f65b>] __sched_text_start+0x83/0x59e
Sep 20 00:06:06 xenon kernel: [ 53.744759] [<c0126084>] __cond_resched+0x21/0x3b
Sep 20 00:06:06 xenon kernel: [ 53.744766] [<c031003b>] cond_resched+0x26/0x31
Sep 20 00:06:06 xenon kernel: [ 53.744772] [<c017059a>] unmap_vmas+0x461/0x580
Sep 20 00:06:06 xenon kernel: [ 53.744780] [<c017351b>] exit_mmap+0x7f/0x10f
Sep 20 00:06:06 xenon kernel: [ 53.744789] [<c012807b>] mmput+0x4d/0xcb
Sep 20 00:06:06 xenon kernel: [ 53.744796] [<c012bea5>] exit_mm+0xd7/0xdc
Sep 20 00:06:06 xenon kernel: [ 53.744803] [<c012d3bb>] do_exit+0x224/0x76b
Sep 20 00:06:06 xenon kernel: [ 53.744810] [<c012d972>] sys_exit_group+0x0/0x11
Sep 20 00:06:06 xenon kernel: [ 53.744818] [<c013529c>] get_signal_to_deliver+0x40f/0x434
Sep 20 00:06:06 xenon kernel: [ 53.744826] [<c010673a>] do_notify_resume+0x94/0x6a6
Sep 20 00:06:06 xenon kernel: [ 53.744833] [<c01072e5>] work_notifysig+0x13/0x1a
Sep 20 00:06:06 xenon kernel: [ 53.744841] [<b7e4a5e0>] 0xb7e4a5e0
Sep 20 00:06:06 xenon kernel: [ 53.744850] =======================
Sep 20 00:06:06 xenon kernel: [ 53.748072] BUG: scheduling while atomic: X/5716/0x00000005
Sep 20 00:06:06 xenon kernel: [ 53.748076] no locks held by X/5716.
Sep 20 00:06:06 xenon kernel: [ 53.748082] [<c0108441>] dump_trace+0x64/0x1f2
Sep 20 00:06:06 xenon kernel: [ 53.748091] [<c01085e9>] show_trace_log_lvl+0x1a/0x2f
Sep 20 00:06:06 xenon kernel: [ 53.748098] [<c010902b>] show_trace+0x12/0x14
Sep 20 00:06:06 xenon kernel: [ 53.748104] [<c0109154>] dump_stack+0x16/0x18
Sep 20 00:06:06 xenon kernel: [ 53.748110] [<c012605c>] __schedule_bug+0x6e/0x75
Sep 20 00:06:06 xenon kernel: [ 53.748117] [<c030f65b>] __sched_text_start+0x83/0x59e
Sep 20 00:06:06 xenon kernel: [ 53.748125] [<c030fc2a>] wait_for_completion+0x74/0xaa
Sep 20 00:06:06 xenon kernel: [ 53.748131] [<c013a422>] synchronize_rcu+0x2d/0x33
Sep 20 00:06:06 xenon kernel: [ 53.748139] [<c028b474>] mousedev_detach_client+0x34/0x38
Sep 20 00:06:06 xenon kernel: [ 53.748148] [<c028b528>] mousedev_release+0x21/0x40
Sep 20 00:06:06 xenon kernel: [ 53.748155] [<c0185442>] __fput+0xb9/0x165
Sep 20 00:06:06 xenon kernel: [ 53.748162] [<c01855c6>] fput+0x32/0x36
Sep 20 00:06:06 xenon kernel: [ 53.748168] [<c0182c62>] filp_close+0x54/0x5c
Sep 20 00:06:06 xenon kernel: [ 53.748176] [<c012c1fa>] put_files_struct+0x7e/0xc0
Sep 20 00:06:06 xenon kernel: [ 53.748183] [<c012d3fc>] do_exit+0x265/0x76b
Sep 20 00:06:06 xenon kernel: [ 53.748191] [<c012d972>] sys_exit_group+0x0/0x11
Sep 20 00:06:06 xenon kernel: [ 53.748198] [<c013529c>] get_signal_to_deliver+0x40f/0x434
Sep 20 00:06:06 xenon kernel: [ 53.748205] [<c010673a>] do_notify_resume+0x94/0x6a6
Sep 20 00:06:06 xenon kernel: [ 53.748213] [<c01072e5>] work_notifysig+0x13/0x1a
Sep 20 00:06:06 xenon kernel: [ 53.748221] [<b7e4a5e0>] 0xb7e4a5e0
Sep 20 00:06:06 xenon kernel: [ 53.748229] =======================
Sep 20 00:06:06 xenon kernel: [ 53.753964] BUG: scheduling while atomic: X/5716/0x00000005
Sep 20 00:06:06 xenon kernel: [ 53.753974] 3 locks held by X/5716:
Sep 20 00:06:06 xenon kernel: [ 53.753977] #0: (&mousedev->mutex/31){--..}, at: [<c0310e02>] mutex_lock+0x1c/0x1f
Sep 20 00:06:06 xenon kernel: [ 53.753992] #1: (&mousedev->mutex#2){--..}, at: [<c0310e02>] mutex_lock+0x1c/0x1f
Sep 20 00:06:06 xenon kernel: [ 53.754002] #2: (&dev->mutex){--..}, at: [<c0310e02>] mutex_lock+0x1c/0x1f
Sep 20 00:06:06 xenon kernel: [ 53.754019] [<c0108441>] dump_trace+0x64/0x1f2
Sep 20 00:06:06 xenon kernel: [ 53.754029] [<c01085e9>] show_trace_log_lvl+0x1a/0x2f
Sep 20 00:06:06 xenon kernel: [ 53.754036] [<c010902b>] show_trace+0x12/0x14
Sep 20 00:06:06 xenon kernel: [ 53.754044] [<c0109154>] dump_stack+0x16/0x18
Sep 20 00:06:06 xenon kernel: [ 53.754051] [<c012605c>] __schedule_bug+0x6e/0x75
Sep 20 00:06:06 xenon kernel: [ 53.754059] [<c030f65b>] __sched_text_start+0x83/0x59e
Sep 20 00:06:06 xenon kernel: [ 53.754068] [<fa997422>] usb_kill_urb+0xa1/0xcd [usbcore]
Sep 20 00:06:06 xenon kernel: [ 53.754109] [<faa758bd>] usbhid_close+0x23/0x2e [usbhid]
Sep 20 00:06:06 xenon kernel: [ 53.754124] [<c02a3119>] hidinput_close+0xd/0xf
Sep 20 00:06:06 xenon kernel: [ 53.754132] [<c0289499>] input_close_device+0x3e/0x5a
Sep 20 00:06:06 xenon kernel: [ 53.754139] [<c028b4fc>] mousedev_close_device+0x84/0x8f
Sep 20 00:06:06 xenon kernel: [ 53.754145] [<c028b4c4>] mousedev_close_device+0x4c/0x8f
Sep 20 00:06:06 xenon kernel: [ 53.754150] [<c028b536>] mousedev_release+0x2f/0x40
Sep 20 00:06:06 xenon kernel: [ 53.754156] [<c0185442>] __fput+0xb9/0x165
Sep 20 00:06:06 xenon kernel: [ 53.754162] [<c01855c6>] fput+0x32/0x36
Sep 20 00:06:06 xenon kernel: [ 53.754167] [<c0182c62>] filp_close+0x54/0x5c
Sep 20 00:06:06 xenon kernel: [ 53.754173] [<c012c1fa>] put_files_struct+0x7e/0xc0
Sep 20 00:06:06 xenon kernel: [ 53.754179] [<c012d3fc>] do_exit+0x265/0x76b
Sep 20 00:06:06 xenon kernel: [ 53.754185] [<c012d972>] sys_exit_group+0x0/0x11
Sep 20 00:06:06 xenon kernel: [ 53.754190] [<c013529c>] get_signal_to_deliver+0x40f/0x434
Sep 20 00:06:06 xenon kernel: [ 53.754197] [<c010673a>] do_notify_resume+0x94/0x6a6
Sep 20 00:06:06 xenon kernel: [ 53.754204] [<c01072e5>] work_notifysig+0x13/0x1a
Sep 20 00:06:06 xenon kernel: [ 53.754211] [<b7e4a5e0>] 0xb7e4a5e0
Sep 20 00:06:06 xenon kernel: [ 53.754219] =======================
[etc. etc. - I can't seem to find a rule to it]

This is on the Pentium D 940 / Intel DQ965GF / Matrox G550 / openSUSE 10.2
system where I currently do all my kernel torturing. .config attached. Not
sure what other information to include. Just ask.

HTH
T.
--
Tilman Schmidt E-Mail: ***@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)
Andrew Morton
2007-09-19 23:24:38 UTC
Permalink
On Thu, 20 Sep 2007 01:02:06 +0200
Post by Tilman Schmidt
I get several "duplicate file name" messages.
Hope Greg's the right one to cc on these.
<4>[ 21.211942] Duplicate file names "rtc" detected. [dump_trace+100/498] dump_trace+0x64/0x1f2
<4>[ 21.216801] [show_trace_log_lvl+26/47] show_trace_log_lvl+0x1a/0x2f
<4>[ 21.221639] [show_trace+18/20] show_trace+0x12/0x14
<4>[ 21.226307] [dump_stack+22/24] dump_stack+0x16/0x18
<4>[ 21.231063] [proc_register+315/332] proc_register+0x13b/0x14c
<4>[ 21.235814] [create_proc_entry+114/135] create_proc_entry+0x72/0x87
<4>[ 21.240562] [<faa1d123>] rtc_proc_add_device+0x1d/0x39 [rtc_core]
<4>[ 21.245304] [<faa1c1f9>] rtc_device_register+0x170/0x207 [rtc_core]
<4>[ 21.250077] [<faa3c5db>] cmos_do_probe+0x8d/0x1ee [rtc_cmos]
<4>[ 21.254715] [<faa3c77d>] cmos_pnp_probe+0x41/0x44 [rtc_cmos]
<4>[ 21.259477] [pnp_device_probe+102/135] pnp_device_probe+0x66/0x87
<4>[ 21.264206] [driver_probe_device+233/362] driver_probe_device+0xe9/0x16a
<4>[ 21.268738] [__driver_attach+108/165] __driver_attach+0x6c/0xa5
<4>[ 21.273387] [bus_for_each_dev+54/91] bus_for_each_dev+0x36/0x5b
<4>[ 21.277975] [driver_attach+25/27] driver_attach+0x19/0x1b
<4>[ 21.282501] [bus_add_driver+115/429] bus_add_driver+0x73/0x1ad
<4>[ 21.286984] [driver_register+103/108] driver_register+0x67/0x6c
<4>[ 21.291269] [pnp_register_driver+23/25] pnp_register_driver+0x17/0x19
<4>[ 21.295661] [<faa4000d>] cmos_init+0xd/0xf [rtc_cmos]
<4>[ 21.300044] [sys_init_module+5544/5953] sys_init_module+0x15a8/0x1741
<4>[ 21.304406] [sysenter_past_esp+107/181] sysenter_past_esp+0x6b/0xb5
<4>[ 21.308749] [phys_startup_32+3085673488/3221225472] 0xb7fba410
<4>[ 21.313108] =======================
Nah, that's an rtc-specific problem.

I think David says that it's actually not a problem, but I didn't
really understand how this can be?

Perhaps I'll need to drop that debugging patch. Which would be a shame,
because it can detect real bugs. Perhaps it needs a strcmp("rtc") to
filter out the (surprising) false positive.
Chuck Ebbert
2007-09-19 23:28:23 UTC
Permalink
Post by Andrew Morton
Nah, that's an rtc-specific problem.
I think David says that it's actually not a problem, but I didn't
really understand how this can be?
Perhaps I'll need to drop that debugging patch. Which would be a shame,
because it can detect real bugs. Perhaps it needs a strcmp("rtc") to
filter out the (surprising) false positive.
AFAICT the rtc problem is caused by misconfiguration: both the new
and old rtc driver have been built and they are both trying to load.
Tilman Schmidt
2007-09-19 23:55:50 UTC
Permalink
Post by Chuck Ebbert
AFAICT the rtc problem is caused by misconfiguration: both the new
and old rtc driver have been built and they are both trying to load.
Rats. Sorry. I remember now. That's not the first time I am hit by
that one. I had even made a resolution to try and find out the correct
options to set. So what are they? CONFIG_RTC=y and CONFIG_RTC_DRV_CMOS=n?
Guess I should try that combination in my next round of tests.

Anyway, shouldn't there be a warning or at least some clear instructions?
As it is, both the old and the new driver claim in Kconfig that you need
them in order to access your RTC, and none of them even mentions the
other, so it's way too easy to end up enabling both of them.

So are all my other woes a consequence of that one?

Thanks,
T.
--
Tilman Schmidt E-Mail: ***@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)
David Brownell
2007-09-19 23:44:48 UTC
Permalink
Post by Andrew Morton
Post by Tilman Schmidt
<4>[ 21.211942] Duplicate file names "rtc" detected
Nah, that's an rtc-specific problem.
RTC-related ... but it's a procfs bug, since it's procfs which doesn't
even bother to check for duplicate names before it registers files.
And it's that duplication which is the problem. Try the patch in
this message

http://lkml.org/lkml/2007/9/19/18
Post by Andrew Morton
I think David says that it's actually not a problem, but I didn't
really understand how this can be?
I said it's not an RTC problem ... it's a procfs problem.

Trying to fix procfs bugs by changing RTC code is futile. ;)
Post by Andrew Morton
AFAICT the rtc problem is caused by misconfiguration: both the new
and old rtc driver have been built and they are both trying to load.
That _shouldn't_ be a problem at all; only one of them should be
able to bind to that hardware.

The only problem I see in these messages is that procfs bug.

- Dave
Andrew Morton
2007-09-20 00:06:04 UTC
Permalink
On Wed, 19 Sep 2007 16:44:48 -0700
Post by David Brownell
Post by Andrew Morton
Post by Tilman Schmidt
<4>[ 21.211942] Duplicate file names "rtc" detected
Nah, that's an rtc-specific problem.
RTC-related ... but it's a procfs bug, since it's procfs which doesn't
even bother to check for duplicate names before it registers files.
So you keep on claiming, but I don't think I've yet seen a description of
the *reason* why two copies of this file are being created, and a
description of why that is an OK thing for the kernel to be doing.
Post by David Brownell
Post by Andrew Morton
AFAICT the rtc problem is caused by misconfiguration: both the new
and old rtc driver have been built and they are both trying to load.
That _shouldn't_ be a problem at all; only one of them should be
able to bind to that hardware.
The only problem I see in these messages is that procfs bug.
It's not obvious that this is only a procfs bug. If some part of the
kernel tries to add a procfs file which is already there, that's often a
bug in the caller.

Yes, procfs should have been checking for this. But it is too late now for
us to just fail out of the procfs registration code. Because this can
cause previously buggy-but-works-ok code to now fail completely.

So I think the best we can do now is to retain the runtime warning and to
continue to "succeed" and to identify all the problematic codesites and to
either fix them or to convince ourselves that they really are working as
intended.
David Brownell
2007-09-20 04:43:14 UTC
Permalink
Post by Andrew Morton
On Wed, 19 Sep 2007 16:44:48 -0700
Post by David Brownell
Post by Andrew Morton
Post by Tilman Schmidt
<4>[ 21.211942] Duplicate file names "rtc" detected
Nah, that's an rtc-specific problem.
RTC-related ... but it's a procfs bug, since it's procfs which doesn't
even bother to check for duplicate names before it registers files.
So you keep on claiming, but I don't think I've yet seen a description of
the *reason* why two copies of this file are being created,
Post by David Brownell
The missing step seems to be that proc_register() doesn't bother
to check whether there's already an entry for that file. Which
is what the appended *UNTESTED* patch does (it compiles though).
Although maybe you meant me to parse that differently ... as in,
not "why is procfs doing this broken thing?" but rather "how is it
that procfs fault (non)handling code ended up getting used?".

That's always seemed self-evident: the RTC framework was creating
it for /dev/rtc0 (presumably, rtc-cmos), while at the same time the
legacy drivers/char/rtc.c was creating it for /dev/rtc.

Workaround by configuring just one, and the problem goes away.
(Although it *ought* to be OK to configure both, with all the normal
resource exclusions kicking in to ensure only one will run.)
Post by Andrew Morton
and a
description of why that is an OK thing for the kernel to be doing.
It's not a wrong thing, at any rate. This is a fairly basic task
in any filesystem: mutual exclusion. Code is allowed to rely on
filesystems acting correctly...
Post by Andrew Morton
Post by David Brownell
Post by Andrew Morton
AFAICT the rtc problem is caused by misconfiguration: both the new
and old rtc driver have been built and they are both trying to load.
That _shouldn't_ be a problem at all; only one of them should be
able to bind to that hardware.
The only problem I see in these messages is that procfs bug.
It's not obvious that this is only a procfs bug. If some part of the
kernel tries to add a procfs file which is already there, that's often a
bug in the caller.
Not really; procfs is supposed to not create it if it's already there!!
Reasonable callers will cope with "it didn't get created", and that's
all they should really need to do.
Post by Andrew Morton
Yes, procfs should have been checking for this. But it is too late now for
us to just fail out of the procfs registration code. Because this can
cause previously buggy-but-works-ok code to now fail completely.
What do you mean by too late "now" ... just-before-2.6.23?

I'm a bit puzzled why this issue cropped up suddenly, when the
"two RTC drivers" configs have been behaving fine (presumably
failing properly, but at least not generating problem reports)
for some time. One of the procfs changes must have caused this
trouble.

And what would an example be of buggy-but-works code, which would
then be broken if the procfs stopped being buggy?
Post by Andrew Morton
So I think the best we can do now is to retain the runtime warning and to
continue to "succeed" and to identify all the problematic codesites and to
either fix them or to convince ourselves that they really are working as
intended.
At a micro level, both the relevant call sites already have code
to tolerate the "couldn't create that file" error, which looked
correct at a quick reading.

- Dave
Andrew Morton
2007-09-20 06:11:21 UTC
Permalink
Post by David Brownell
Post by Andrew Morton
On Wed, 19 Sep 2007 16:44:48 -0700
Post by David Brownell
Post by Andrew Morton
Post by Tilman Schmidt
<4>[ 21.211942] Duplicate file names "rtc" detected
Nah, that's an rtc-specific problem.
RTC-related ... but it's a procfs bug, since it's procfs which doesn't
even bother to check for duplicate names before it registers files.
So you keep on claiming, but I don't think I've yet seen a description of
the *reason* why two copies of this file are being created,
Post by David Brownell
The missing step seems to be that proc_register() doesn't bother
to check whether there's already an entry for that file. Which
is what the appended *UNTESTED* patch does (it compiles though).
Although maybe you meant me to parse that differently ... as in,
not "why is procfs doing this broken thing?" but rather "how is it
that procfs fault (non)handling code ended up getting used?".
That's always seemed self-evident: the RTC framework was creating
it for /dev/rtc0 (presumably, rtc-cmos), while at the same time the
legacy drivers/char/rtc.c was creating it for /dev/rtc.
Workaround by configuring just one, and the problem goes away.
(Although it *ought* to be OK to configure both, with all the normal
resource exclusions kicking in to ensure only one will run.)
Head still spinning.

a) "rtc0" != "rtc" ??

b) The kernel is trying to register two procfs files of the same name!
If that's a configuration error then we have a Kconfiguration bug.
Post by David Brownell
Post by Andrew Morton
and a
description of why that is an OK thing for the kernel to be doing.
It's not a wrong thing, at any rate. This is a fairly basic task
in any filesystem: mutual exclusion. Code is allowed to rely on
filesystems acting correctly...
We're relying on procfs behaviour to prevent registration of two rtc
devices? That's a strange means of arbitration. And what happens
when CONFIG_PROC_FS=n?
Post by David Brownell
Post by Andrew Morton
Post by David Brownell
Post by Andrew Morton
AFAICT the rtc problem is caused by misconfiguration: both the new
and old rtc driver have been built and they are both trying to load.
That _shouldn't_ be a problem at all; only one of them should be
able to bind to that hardware.
The only problem I see in these messages is that procfs bug.
It's not obvious that this is only a procfs bug. If some part of the
kernel tries to add a procfs file which is already there, that's often a
bug in the caller.
Not really; procfs is supposed to not create it if it's already there!!
Reasonable callers will cope with "it didn't get created", and that's
all they should really need to do.
Post by Andrew Morton
Yes, procfs should have been checking for this. But it is too late now for
us to just fail out of the procfs registration code. Because this can
cause previously buggy-but-works-ok code to now fail completely.
What do you mean by too late "now" ... just-before-2.6.23?
No.

What I mean is that we cannot change procfs as you propose until we have
located and fixed all places in the kernel which can cause duplicated
procfs names. (Good luck with that).

Because we've had this happening before, and *the driver kept working*
(apart from, presumably, some of their procfs features which, presumably,
nobody used much).

With the change which you propose, these drivers will probably stop
working, because they will newly find their procfs registration failed.
Post by David Brownell
I'm a bit puzzled why this issue cropped up suddenly, when the
"two RTC drivers" configs have been behaving fine (presumably
failing properly, but at least not generating problem reports)
for some time. One of the procfs changes must have caused this
trouble.
I'm not sure that anything _has_ changed. It's just that a few people have
suddenly noticed duplicated rtc entris in /proc. Perhaps theye were there
for some time.
Post by David Brownell
And what would an example be of buggy-but-works code, which would
then be broken if the procfs stopped being buggy?
A driver which checks the return value from procfs registration and which
then errors out (as it should) if that registration fails.
Post by David Brownell
Post by Andrew Morton
So I think the best we can do now is to retain the runtime warning and to
continue to "succeed" and to identify all the problematic codesites and to
either fix them or to convince ourselves that they really are working as
intended.
At a micro level, both the relevant call sites already have code
to tolerate the "couldn't create that file" error, which looked
correct at a quick reading.
- Dave
Kay Sievers
2007-09-20 07:54:57 UTC
Permalink
Post by Andrew Morton
Post by David Brownell
Post by Andrew Morton
On Wed, 19 Sep 2007 16:44:48 -0700
Post by David Brownell
Post by Andrew Morton
Post by Tilman Schmidt
<4>[ 21.211942] Duplicate file names "rtc" detected
Nah, that's an rtc-specific problem.
RTC-related ... but it's a procfs bug, since it's procfs which doesn't
even bother to check for duplicate names before it registers files.
So you keep on claiming, but I don't think I've yet seen a description of
the *reason* why two copies of this file are being created,
Post by David Brownell
The missing step seems to be that proc_register() doesn't bother
to check whether there's already an entry for that file. Which
is what the appended *UNTESTED* patch does (it compiles though).
Although maybe you meant me to parse that differently ... as in,
not "why is procfs doing this broken thing?" but rather "how is it
that procfs fault (non)handling code ended up getting used?".
That's always seemed self-evident: the RTC framework was creating
it for /dev/rtc0 (presumably, rtc-cmos), while at the same time the
legacy drivers/char/rtc.c was creating it for /dev/rtc.
Workaround by configuring just one, and the problem goes away.
(Although it *ought* to be OK to configure both, with all the normal
resource exclusions kicking in to ensure only one will run.)
Head still spinning.
a) "rtc0" != "rtc" ??
b) The kernel is trying to register two procfs files of the same name!
If that's a configuration error then we have a Kconfiguration bug.
Post by David Brownell
Post by Andrew Morton
and a
description of why that is an OK thing for the kernel to be doing.
It's not a wrong thing, at any rate. This is a fairly basic task
in any filesystem: mutual exclusion. Code is allowed to rely on
filesystems acting correctly...
We're relying on procfs behaviour to prevent registration of two rtc
devices? That's a strange means of arbitration. And what happens
when CONFIG_PROC_FS=n?
Post by David Brownell
Post by Andrew Morton
Post by David Brownell
Post by Andrew Morton
AFAICT the rtc problem is caused by misconfiguration: both the new
and old rtc driver have been built and they are both trying to load.
That _shouldn't_ be a problem at all; only one of them should be
able to bind to that hardware.
The only problem I see in these messages is that procfs bug.
It's not obvious that this is only a procfs bug. If some part of the
kernel tries to add a procfs file which is already there, that's often a
bug in the caller.
Not really; procfs is supposed to not create it if it's already there!!
Reasonable callers will cope with "it didn't get created", and that's
all they should really need to do.
Post by Andrew Morton
Yes, procfs should have been checking for this. But it is too late now for
us to just fail out of the procfs registration code. Because this can
cause previously buggy-but-works-ok code to now fail completely.
What do you mean by too late "now" ... just-before-2.6.23?
No.
What I mean is that we cannot change procfs as you propose until we have
located and fixed all places in the kernel which can cause duplicated
procfs names. (Good luck with that).
Because we've had this happening before, and *the driver kept working*
(apart from, presumably, some of their procfs features which, presumably,
nobody used much).
With the change which you propose, these drivers will probably stop
working, because they will newly find their procfs registration failed.
Post by David Brownell
I'm a bit puzzled why this issue cropped up suddenly, when the
"two RTC drivers" configs have been behaving fine (presumably
failing properly, but at least not generating problem reports)
for some time. One of the procfs changes must have caused this
trouble.
I'm not sure that anything _has_ changed. It's just that a few people have
suddenly noticed duplicated rtc entris in /proc. Perhaps theye were there
for some time.
Post by David Brownell
And what would an example be of buggy-but-works code, which would
then be broken if the procfs stopped being buggy?
A driver which checks the return value from procfs registration and which
then errors out (as it should) if that registration fails.
Isn't that all caused by the rtc driver registering itself without
checking if it is able to grab the device? Wouldn't moving the
request_resource() before doing any device registration do the magic?

Kay
Joseph Fannin
2007-09-19 23:58:28 UTC
Permalink
Post by Andrew Morton
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc6/2.6.23-rc6-mm1/
2.6.23-rc6-mm1
[patch submitter cc'd]

I had to reverse
convert-cpu_sibling_map-to-a-per_cpu-data-array-ppc64.patch (and the
fix on top of it) to get past this error on 32bit powerpc:

make[1]: Entering directory `/usr/src/ctesiphon/linux-2.6.23-rc6-mm1'
CHK include/linux/version.h
CHK include/linux/utsrelease.h
CC arch/powerpc/kernel/asm-offsets.s
In file included from include/linux/smp.h:19,
from include/linux/sched.h:67,
from arch/powerpc/kernel/asm-offsets.c:17:
include/asm/smp.h:63: error: expected declaration specifiers or ‘...’ before ‘cpu_sibling_map’
include/asm/smp.h:63: warning: data definition has no type or storage class
include/asm/smp.h:63: warning: type defaults to ‘int’ in declaration of ‘DECLARE_PER_CPU’
make[2]: *** [arch/powerpc/kernel/asm-offsets.s] Error 1

I dunno if this will build or work with these reverted (I'm still
looking at other build failures) but backing these out got the build
moving again.

My .config is attached.
--
Joseph Fannin
***@gmail.com
Andrew Morton
2007-09-20 00:09:34 UTC
Permalink
On Wed, 19 Sep 2007 19:58:28 -0400
Post by Joseph Fannin
Post by Andrew Morton
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc6/2.6.23-rc6-mm1/
2.6.23-rc6-mm1
[patch submitter cc'd]
I had to reverse
convert-cpu_sibling_map-to-a-per_cpu-data-array-ppc64.patch (and the
make[1]: Entering directory `/usr/src/ctesiphon/linux-2.6.23-rc6-mm1'
CHK include/linux/version.h
CHK include/linux/utsrelease.h
CC arch/powerpc/kernel/asm-offsets.s
In file included from include/linux/smp.h:19,
from include/linux/sched.h:67,
include/asm/smp.h:63: error: expected declaration specifiers or ___...___ before ___cpu_sibling_map___
include/asm/smp.h:63: warning: data definition has no type or storage class
include/asm/smp.h:63: warning: type defaults to ___int___ in declaration of ___DECLARE_PER_CPU___
make[2]: *** [arch/powerpc/kernel/asm-offsets.s] Error 1
I dunno if this will build or work with these reverted (I'm still
looking at other build failures) but backing these out got the build
moving again.
This, methinks.

--- a/include/asm-powerpc/smp.h~convert-cpu_sibling_map-to-a-per_cpu-data-array-ppc64-fix-2
+++ a/include/asm-powerpc/smp.h
@@ -25,8 +25,8 @@

#ifdef CONFIG_PPC64
#include <asm/paca.h>
-#include <asm/percpu.h>
#endif
+#include <asm/percpu.h>

extern int boot_cpuid;



(conditional includes are evil)
Cedric Le Goater
2007-09-20 08:41:50 UTC
Permalink
Hello !
Post by Andrew Morton
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc6/2.6.23-rc6-mm1/
make-access-to-tasks-nsproxy-lighter.patch breaks unshare()

when called from unshare(), switch_task_namespaces() takes an
extra refcount on the nsproxy, leading to a memory leak of
nsproxy objects.

Now the problem is that we still need that extra ref when called
from daemonize(). Here's an ugly fix for it.

Signed-off-by: Cedric Le Goater <***@fr.ibm.com>
---
include/linux/nsproxy.h | 5 +++++
kernel/exit.c | 2 ++
kernel/nsproxy.c | 7 -------
3 files changed, 7 insertions(+), 7 deletions(-)

Index: 2.6.23-rc6-mm1/kernel/nsproxy.c
===================================================================
--- 2.6.23-rc6-mm1.orig/kernel/nsproxy.c
+++ 2.6.23-rc6-mm1/kernel/nsproxy.c
@@ -25,11 +25,6 @@ static struct kmem_cache *nsproxy_cachep

struct nsproxy init_nsproxy = INIT_NSPROXY(init_nsproxy);

-static inline void get_nsproxy(struct nsproxy *ns)
-{
- atomic_inc(&ns->count);
-}
-
/*
* creates a copy of "orig" with refcount 1.
*/
@@ -208,8 +203,6 @@ void switch_task_namespaces(struct task_
if (ns == new)
return;

- if (new)
- get_nsproxy(new);
rcu_assign_pointer(p->nsproxy, new);

if (ns && atomic_dec_and_test(&ns->count)) {
Index: 2.6.23-rc6-mm1/kernel/exit.c
===================================================================
--- 2.6.23-rc6-mm1.orig/kernel/exit.c
+++ 2.6.23-rc6-mm1/kernel/exit.c
@@ -408,6 +408,8 @@ void daemonize(const char *name, ...)
current->fs = fs;
atomic_inc(&fs->count);

+ if (current->nsproxy != init_task.nsproxy)
+ get_nsproxy(init_task.nsproxy);
switch_task_namespaces(current, init_task.nsproxy);

exit_files(current);
Index: 2.6.23-rc6-mm1/include/linux/nsproxy.h
===================================================================
--- 2.6.23-rc6-mm1.orig/include/linux/nsproxy.h
+++ 2.6.23-rc6-mm1/include/linux/nsproxy.h
@@ -77,6 +77,11 @@ static inline void put_nsproxy(struct ns
}
}

+static inline void get_nsproxy(struct nsproxy *ns)
+{
+ atomic_inc(&ns->count);
+}
+
#ifdef CONFIG_CONTAINER_NS
int ns_container_clone(struct task_struct *tsk);
#else

Continue reading on narkive:
Loading...