Discussion:
2.6.24-rc4-mm1
(too old to reply)
Andrew Morton
2007-12-05 05:20:10 UTC
Permalink
Temporarily at

http://userweb.kernel.org/~akpm/2.6.24-rc4-mm1/

Will appear later at

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc4/2.6.24-rc4-mm1/


- Lots of device IDs have been removed from the e1000 driver and moved over
to e1000e. So if your e1000 stops working, you forgot to set CONFIG_E1000E.

- The s390 build is still broken.



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. These probably are at least compilable.

- More-than-daily -mm snapshots may be found at
http://userweb.kernel.org/~akpm/mmotm/. These are almost certainly not
compileable.



Changes since 2.6.24-rc3-mm2:


origin.patch
git-acpi.patch
git-alsa.patch
git-agpgart.patch
git-arm.patch
git-avr32.patch
git-avr32-fixup.patch
git-cpufreq.patch
git-powerpc.patch
git-powerpc-galak.patch
git-drm.patch
git-dvb.patch
git-hwmon.patch
git-gfs2-nmw.patch
git-hid.patch
git-hrt.patch
git-ieee1394.patch
git-infiniband.patch
git-input.patch
git-jfs.patch
git-kbuild.patch
git-kvm.patch
git-lblnet.patch
git-leds.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-netdev-all.patch
git-battery.patch
git-nfsd.patch
git-ocfs2.patch
git-parisc.patch
git-selinux.patch
git-s390.patch
git-sched.patch
git-sh.patch
git-scsi-misc.patch
git-sparc64.patch
git-unionfs.patch
git-v9fs.patch
git-watchdog.patch
git-wireless.patch
git-ipwireless_cs.patch
git-x86.patch
git-newsetup.patch
git-xfs.patch
git-cryptodev.patch
git-xtensa.patch

git trees

-update-checkpatchpl-to-version-012.patch
-file-capabilities-allow-sigcont-within-session-v2.patch
-cris-build-fixes-atomich-needs-compilerh.patch
-atmel_spi-labels-gpios-better.patch
-ps3-prefix-all-ps3-specific-kernel-modules-with.patch
-ps3fb-video-memory-size-cleanups.patch
-fix-boot-problem-with-iseries-lacking-hugepage-support.patch
-uml-build-fix.patch
-xen-mask-_page_pcd-from-ptes.patch
-pnp-increase-the-maximum-number-of-resources.patch
-pnp-increase-the-maximum-number-of-resources-fix.patch
-proc-fix-null-i_fop-oops.patch
-wait_task_stopped-dont-use-task_pid_nr_ns-lockless.patch
-proc-remove-races-from-proc_id_readdir.patch
-tpm-tis-device-driver-locality-request.patch
-termios-document-callback-more-clearly.patch
-s3c24xx-ensure-we-only-configure-valid-gpios.patch
-s3c2410-add-bus-number-to-spi-gpio-driver.patch
-ipc-lost-unlock-and-fput-in-mqueuec-on-error-path.patch
-fix-linux-kdh-usage-in-userspace.patch
-fix-linux-kdh-usage-in-userspace-checkpatch-fixes.patch
-m68k-zorro7xx-needs-asm-amigahwh.patch
-fb_ddc-fix-ddc-lines-quirk.patch
-drivers-pnp-resourcec-add-missing-pci_dev_put.patch
-mfd-sm501-debug-typo-fix.patch
-isolate-the-uts-namespaces-domainname-and-hostname-back.patch
-the-namespaces-compatibility-list.patch
-atmel_lcdfb-lcdc-startup-fix.patch
-dmaengine-correct-invalid-assumptions-in-the-kconfig-text.patch
-ip22zilog-fix-lockup-and-sysrq.patch
-fix-up-ext2_fsh-for-userspace-after-reservations-backport.patch
-hexdump-dont-print-bytes-with-bit-7-set.patch
-file-capabilities-dont-prevent-signaling-setuid-root.patch
-isdn-bootup-crash-fix-2624-rc3-git1.patch
-uml-fix-no_hz-busy-loop.patch
-leak-in-do_ubd_request.patch
-revert-keyspan-init-termios-properly.patch
-x86_64-efi-boot-support-efi-frame-buffer.patch
-x86_64-efi-boot-support-efi-boot-document.patch
-memory-hotplug-fix-fix-section-mismatch-in-vmammap_allock_block.patch
-memory-hotplug-x86_64-fix-section-mismatch-in-init_memory_mapping.patch
-fuse-fix-reading-past-eof.patch
-fuse-cleanup-add-fuse_get_attr_version.patch
-fuse-pass-open-flags-to-read-and-write.patch
-fuse-fix-fuse_file_ops-sending.patch
-fuse-fix-uninitialized-field-in-fuse_inode.patch
-fuse-fix-attribute-caching-after-rename.patch
-sound-core-memallocc-add-missing-pci_dev_put.patch
-arm-fix-memset-size-error.patch
-gregkh-driver-allow-legacy_ptys-to-be-set-to-0.patch
-gregkh-driver-create-sys-power-when-config_pm-is-set.patch
-gregkh-driver-uio-fix-up-the-uio-documentation.patch
-gregkh-driver-uio-add-uio-documentation-target-to-docbook-makefile.patch
-gregkh-driver-kobject-two-typo-fixes.patch
-gregkh-driver-sysfs-fix-off-by-one-error-in-fill_read_buffer.patch
-gregkh-driver-nozomi.patch
-git-drm-warning-fix.patch
-clocksource-make-clocksource_mask-bullet-proof.patch
-time-fold-__get_realtime_clock_ts-into-getnstimeofday.patch
-clean-hungarian-notation-from-timers.patch
-timer-cleanups.patch
-more-timer-related-cleanups.patch
-ata_generic-unindent-loop-in-generic_set_mode.patch
-libata-export-xfermode--pata-timing-related-functions.patch
-libata-clean-up-xfermode--pata-timing-related-stuff.patch
-libata-kill-ata_id_to_dma_mode.patch
-libata-separate-out-ata_acpi_gtm_xfermask-from-pacpi_discover_modes.patch
-libata-fix-ata_acpi_gtm_xfermask.patch
-libata-implement-ata_timing_cycle2mode-and-use-it-in-libata-acpi-and-pata_acpi.patch
-libata-implement-ata_acpi_init_gtm.patch
-libata-reimplement-ata_acpi_cbl_80wire-using-ata_acpi_gtm_xfermask.patch
-libata-add-ata_cbl_pata_ign.patch
-pata_amd-update-mode-selection-for-nv-patas.patch
-sata_nv-dont-use-legacy-dma-in-adma-mode-v3.patch
-ide-mm-alim15x3-add-mitac-8317-and-derivatives-to-ali_cable_override.patch
-ide-mm-ide-fix-host-drivers-depending-on-ide_generic-to-probe-for-interfaces.patch
-fix-config_mtd_sharp_sl-if-config_mtd=m-try2.patch
-net-irda-parametersc-trivial-fixes.patch
-net-fix-tx-bug-vlan-in-vlan.patch
-xfrm_policy-warning-fix.patch
-phy-implement-release-function.patch
-git-nfsd-fix-nfsd_idmap-stubs.patch
-arch-parisc-remove-duplicate-includes.patch
-gregkh-pci-pci-pcie-portdriver-initialize-returned-value.patch
-gregkh-pci-pci-drivers-pci-pci-sysfsc-add-missing-pci_dev_put.patch
-gregkh-usb-usb-fix-usb_ohci_hcd_ssb-dependencies.patch
-gregkh-usb-usb-omap_udc-build-fix.patch
-gregkh-usb-usb-pl2303-add-support-for-corega-cg-usbrs232r.patch
-gregkh-usb-usb-storage-always-set-the-allow_restart-flag.patch
-gregkh-usb-usb-fix-priority-mistakes-in-drivers-usb-core-hubc.patch
-gregkh-usb-usb-free-memory-when-writing-fails-in-usb-serial-mos7840c.patch
-gregkh-usb-usb-fix-usbled-disconnect-read-race-2.patch
-gregkh-usb-usbserial-fix-inconsistent-lock-state.patch
-gregkh-usb-usb-fix-signr-comment-in-usbdevice_fsh.patch
-gregkh-usb-usb-power-management-documenation-update.patch
-gregkh-usb-usb-fix-locks-and-urb-status-in-adutux.patch
-gregkh-usb-usb-add-support-for-an-older-firmware-revision-for-the-nikon-d200.patch
-gregkh-usb-usb-fix-directory-references-in-usb-readme.patch
-gregkh-usb-usb-remove-usb-hub-entry-from-maintainers.patch
-gregkh-usb-usb-mailing-lists-have-changed.patch
-gregkh-usb-usb-hcd-avoid-duplicate-local_irq_disable.patch
-gregkh-usb-usb-sierra-new-product-id.patch
-gregkh-usb-usb-keep-track-of-whether-interface-sysfs-files-exist.patch
-gregkh-usb-usb-uevent-environment-key-fix.patch
-gregkh-usb-usb-make-the-microtek-driver-and-hal-cooperate.patch
-gregkh-usb-usb-fix-up-ehci-startup-synchronization.patch
-gregkh-usb-usb-usb-storage-unusual_devs-entry-for-jetflash-ts1gjf2a.patch
-gregkh-usb-usb-s3c2410-gadget-header-move-fixups.patch
-gregkh-usb-usb-s3c2410-gadget-allow-sharing-of-vbus-irq.patch
-gregkh-usb-usb-s3c2410-gadget-ensure-vbus-pin-in-input-mode-during-read.patch
-watchdog-add-nano-7240-driver-2.patch
-txx9-watchdog-support-for-rbhma3100rbhma4200rbhma4500.patch
-x86_64-set-cpu_index-to-nr_cpus-instead-of-0.patch
-x86_64-do-not-set-boot-cpu-in-cpu_online_map-at-x86_64_start_kernel.patch
-vmlinux_32ldss-remove-repeated-comment-from-the-x86-32-linker-script.patch
-x86_64-make-sparsemem-vmemmap-the-only-memory-model.patch
-rtc-convert-mutex-to-bitfield.patch
-drm-i915-fix-pointer-strip.patch
-pata_amd-pata_via-de-couple-programming-of-pio-mwdma-and-udma-timings.patch
-frv-fix-the-extern-declaration-of-kallsyms_num_syms.patch
-frv-arrange-things-such-that-bra-can-reach-from-the-trap.patch
-wait_task_stopped-pass-correct-exit_code-to.patch
-tty-add-the-new-termios2-ioctls-to-the-compatible.patch
-acpi-avoid-references-to-impossible-processors.patch
-fix-proc-net-breakage.patch
-lguest-prevent-visws-or-voyager-randconfigs.patch
-x86-paravirt-revert-exports-to-restore-old-behaviour.patch
-optimize-i8259-code-a-bit.patch
-mm-prevent-dereferencing-non-allocated-per_cpu-variables.patch
-mm-prevent-dereferencing-non-allocated-per_cpu-variables-fix.patch
-fall-back-on-interrupt-disable-in-cmpxchg8b-on-80386-and-80486.patch
-kernel-modulec-make_driver_name-can-use-kasrpintf.patch
-lockdep-show-held-locks-when-showing-a-stackdump.patch
-kmap_atomic-debugging.patch

Merged into mainline or a subsystem tree

+aio-only-account-i-o-wait-time-in-read_events-if-there-are-active-requests.patch
+fix-cloneclone_newpid.patch
+rtc-assure-proper-memory-ordering-with-respect-to-rtc_dev_busy-flag.patch
+ufs-fix-nexstep-dir-block-size.patch
+ufs-fix-nexstep-dir-block-size-checkpatch-fixes.patch
+aoe-properly-initialise-the-request_queues-backing_dev_info.patch
+mm-backing-devc-fix-percpu_counter_destroy-call-bug-in-bdi_init.patch
+add-export_symbolksize.patch
+spi-use-mutex-not-semaphore.patch
+spi-at25-driver-is-for-eeprom-not-flash.patch
+spi-simplify-spi_sync-calling-convention.patch
+spi-use-simplified-spi_sync-calling-convention.patch
+spi-initial-bf54x-spi-support.patch
+spi-bfin-spi-uses-portmux-calls.patch
+spi-spi_bfin-cleanups-error-handling.patch
+spi-spi_bfin-handles-spi_transfercs_change.patch
+spi-spi_bfin-dont-bypass-spi-framework.patch
+spi-spi_bfin-uses-platform-device-resources.patch
+spi-spi_bfin-uses-portmux-for-additional-busses.patch
+spi-spi_bfin-rearrange-portmux-calls.patch
+spi-spi_bfin-change-handling-of-communication-parameters.patch
+spi-spi_bfin-relocate-spin-waits.patch
+spi-spi_bfin-handle-multiple-spi_masters.patch
+spi-spi_bfin-bugfix-for-816-bit-word-sizes.patch
+spi-spi_bfin-update-handling-of-delay-after-deselect.patch
+spi-spi_bfin-resequence-dma-start-stop.patch
+blackfin-spi-driver-use-cpu_relax-to-replace-continue-in-while-busywait.patch
+blackfin-spi-driver-use-void-__iomem-for-regs_base.patch
+blackfin-spi-driver-move-hard-coded-pin_req-to-board-file.patch
+blackfin-spi-driver-reconfigure-speed_hz-and-bits_per_word-in-each-spi-transfer.patch
+avoid-potential-null-dereference-in-unregister_sysctl_table.patch
+gpio_cs5535-disable-aux-on-output.patch
+mm-fix-xip-file-writes.patch
+revert-dpt_i2o-convert-to-scsi-hotplug-model.patch

2.6.24 queue

+__group_complete_signal-fix-coredump-with-group-stop-race.patch
+remove-handle_group_stop-in-favor-of-do_signal_stop.patch
+exec-rework-the-group-exit-and-fix-the-race-with-kill.patch

Maybe 2.6.24

+timerfd-v3-new-timerfd-api-ia64-fix.patch
+timerfd-v3-new-timerfd-api-m68k-fix.patch
+timerfd-v3-new-timerfd-api-mips-fix.patch
+timerfd-v3-new-timerfd-api-arch-fixes.patch
+timerfd-v3-new-timerfd-api-powerpc-fix.patch
+timerfd-v3-new-timerfd-api-update-sys_nic-with-the-new-timerfd-syscalls.patch

Maybe fix timerfd-v3-new-timerfd-api.patch just a bit.

+sdio-fix-module-device-table-definition-for-m68k.patch
+jbd-fix-assertion-failure-in-fs-jbd-checkpointc.patch
+proc-fix-pde-refcounting.patch

Maybe 2.6.24

+git-avr32-fixup.patch

Fix conflicts in git-avr32.patch

+powerpc-invalid-size-for-swapper_pg_dir-with-config_pte_64bit=y.patch

powerpc fix

+gregkh-driver-nozomi.patch
+gregkh-driver-kobject-convert-hvc_console-to-use-kref-not-kobject.patch
+gregkh-driver-kobject-convert-hvcs-to-use-kref-not-kobject.patch
+gregkh-driver-kobject-grab-the-kset-reference-in-kobject_add-not-kobject_init.patch
+gregkh-driver-kobject-clean-up-debugging-messages.patch
+gregkh-driver-usb-use-proper-call-to-driver_create_file.patch
+gregkh-driver-pcmcia-use-proper-call-to-driver_create_file.patch
+gregkh-driver-pci-use-proper-call-to-driver_create_file.patch
+gregkh-driver-pci-remove-foolish-code-from-pci-driverc.patch
+gregkh-driver-driver-core-move-the-driver-specific-module-code-into-the-driver-core.patch
+gregkh-driver-driver-core-move-the-static-kobject-out-of-struct-driver.patch
+gregkh-driver-driver-core-clean-up-debugging-messages.patch
+gregkh-driver-kobject-fix-up-kobject_set_name-to-use-kvasprintf.patch
+gregkh-driver-kobject-add-kobject_init_ng-kobject_add_ng-and-kobject_init_and_add-functions.patch
+gregkh-driver-driver-core-fix-class-glue-dir-cleanup-logic.patch
+gregkh-driver-sysfs-fix-sys-module-holders-after-sysfs-logic-change.patch
+gregkh-driver-kobject-drop-child-parent-ref-at-unregistration.patch
+gregkh-driver-block-device.patch

driver tree updates

+driver-tree-broke-infiniband.patch
+gregkh-driver-driver-core-move-the-driver-specific-module-code-into-the-driver-core-fix.patch

Fixes for driver tree

+jdelvare-i2c-i2c-remove-redundant-gpio-drivers.patch

i2c tree update

+applesmc-sensors-set-for-macbook2.patch

sensors driver update

+apanel-free-input-device-on-close.patch
+apanel-change-name-of-led.patch
+apanel-detach-on-shutdown.patch
+apanel-use-generic-keycode-routines.patch

Update fujitsu-application-panel-driver.patch

+ads7846-stop-updating-dev-powerpower_state.patch

input driver fix

+libata-xfer_mask-is-unsigned-int-not-unsigned-long-fix.patch
+libata-set-proper-ata-udma-mode-for-bf548-according-to-system-clock-checkpatch-fixes.patch
+ata-ahci-enclosure-management-via-led.patch
+libata-fix-early-use-of-port-printk-checkpatch-fixes.patch

sata/pata things

+ide-mm-ide-scsi-add-ide_scsi_hex_dump-helper.patch
+ide-mm-ide-add-missing-checks-for-control-register-existence.patch
+ide-mm-ide-deprecate-config_blk_dev_offboard.patch
+ide-mm-ide-fix-ide_scan_pcibus-error-message.patch
+ide-mm-ide-coding-style-fixes-for-drivers-ide-setup-pci-c.patch
+ide-mm-ide-add-sys-bus-ide-devices-model-firmware-serial-sysfs-entries.patch
+ide-mm-ide-fix-host-drivers-depending-on-ide_generic-to-probe-for-interfaces-take-2.patch
+ide-mm-au1xxx-ide-au_ide_probe-fix.patch
+ide-mm-au1xxx-ide-use-ide_init_port_hw.patch
+ide-mm-ide-always-use-ide_std_init_ports-in-setup-pci-c.patch
+ide-mm-ide-use-ide_init_port_hw-in-setup-pci-c.patch
+ide-mm-rapide-remove-write-only-hwif-hwif_data.patch
+ide-mm-ide-pmac-use-custom-hwif-sg_max_nents-only-if-dma-support-is-enabled.patch
+ide-mm-ide-add-ide_set_irq-inline-helper.patch
+ide-mm-ide-print-banner-message-once-per-controller-in-m68k-host-drivers.patch
+ide-mm-ide-move-config_idepci_pcibus_order-code-to-ide-scan-pci-c.patch
+ide-mm-ide-make-config_idepci_pcibus_order-visible-and-deprecate-it.patch

IDE tree updates

-git-mips-fixup.patch

Unneeded

+remove-trailing-nuls-from-network-bonding-sysfs-interface.patch
+net-bonding-return-nothing-for-not-applicable-values.patch
+net-bonding-purely-cosmetic-rename-a-local-variable.patch

net things

+net-smc911x-shut-up-compiler-warnings.patch
+bnx2x-depends-on-zlib_inflate.patch

netdev things

+pcmcia-stop-updating-dev-powerpower_state.patch

pcmcia fix

+quirk-enable-msi-mapping-on-ht1000-v2.patch

Fix quirk-enable-msi-mapping-on-ht1000.patch

-git-sh-fixup.patch

Unneeded

+drivers-scsi-sgiwd93c-export-sgiwd93_reset.patch
+scsi-qla2xxx-qla_osc-section-fix.patch

scsi fixes

-bidi-support-scsi_data_buffer-broke-qla1280.patch
-bidi-support-scsi_data_buffer-broke-lots-of-stuff.patch

Folded into bidi-support-scsi_data_buffer.patch

+scsi-pending-arm-convert-to-accessors.patch

scsi fix

+edgeport-usb-serial-converter-convert-es_sem-to-mutex.patch
+usb-testing-driver-convert-dev-sem-to-mutex.patch
+usb-testing-driver-dont-free-a-locked-mutex.patch

USB things

+git-watchdog-hpwdt-build-fix.patch
+add-support-for-sb1-hardware-watchdog.patch
+add-support-for-sb1-hardware-watchdog-fix.patch

watchdog things

+iwlwifi-3945-fix-race-conditional-panic.patch
+iwlwifi-4965-fix-race-conditional-panic.patch
+net-mac80211-fix-inappropriate-memory-freeing.patch
+bcm43xx_debugfs-sscanf-fix.patch

wireless fixes

+revert-git-kvm-changes-in-arch-x86-kconfig.patch
git-x86.patch
+revert-revert-git-kvm-changes-in-arch-x86-kconfig.patch

Make git-x86 apply

-git-x86-build-fix.patch

Unneeded

+git-x86-__vdso_getcpu-warning-fix.patch
+uml-add-asm-um-asmh.patch
+clocksource-make-clocksource_mask-bullet-proof.patch
+time-fold-__get_realtime_clock_ts-into-getnstimeofday.patch

x86 stuff

+git-cryptodev-fixup.patch

Fix conflicts in git-cryptodev

+ieee80211_rate-missed-unlock.patch
+slubs-ksize-fails-for-size-2048.patch
+vm-security-add-security-hook-to-do_brk.patch

More 2.6.24 things

+vmstat-remove-prefetch.patch
+mm-sparsec-improve-the-error-handling-for-sparse_add_one_section.patch
+mm-dont-waste-swap-on-locked-pages.patch
+skip-writing-data-pages-when-inode-is-under-i_sync.patch

MM updates

+add-64-bit-capability-support-to-the-kernel-capabilities-export-__cap_-symbols.patch
+capabilities-introduce-per-process-capability-bounding-set-capabilities-correct-logic-at-capset_check.patch

Fix 64-bit capabilities

+smack-using-capabilities-32-and-33-update-cap_last_cap-to-reflect-cap_mac_admin.patch
+smack-mutex-capability-pointers-and-spelling-cleanup.patch

smack updates

+nommu-add-new-vmalloc_user-and-remap_vmalloc_range-interfaces.patch

nommu update

+uml-fix-command-line-cflags-and-ldflags-support.patch
+uml-style-fixes-in-arch-um-os-linux.patch

UML updates

+printk-trivial-optimizations-fix.patch

Fix printk-trivial-optimizations.patch

-partitions-use-kasprintf.patch

Dropped due to rejects

+inotify-send-in_attrib-events-when-link-count-changes-fix.patch
+reiserfs-complement-va_start-with-va_end.patch
+get-rid-of-nr_open-and-introduce-a-sysctl_nr_open.patch
+synclink-standardize-format-of-linux-header-file-includes-with.patch
+kernel-add-mutex_lock_killable.patch
+vfs-use-mutex_lock_killable-in-vfs_readdir.patch
+fix-__const_udelay-declaration-and-definition-mismatches.patch
+drivers-char-randomcwrite_pool-cond_resched-needed.patch
+kill-an-unused-ptr_err-in-bdev_cache_init.patch
+remove-rcu_assign_pointer-penalty-for-null-pointers.patch
+remove-superfluous-checks-for-config_blk_dev_initrd-from-initramfsc.patch
+serial-use-sgi_has_zilog-for-ip22_zilog-depends.patch
+char-use-sgi_has_ds1286-for-sgi_ds1286-depends.patch
+clean-up-drivers-char-rtcc.patch
+sc26xx-new-serial-driver-for-sc2681-uarts.patch
+sc26xx-new-serial-driver-for-sc2681-uarts-update.patch
+inotify-fix-race.patch
+inotify-remove-debug-code.patch
+documentation-about-unaligned-memory-access.patch
+drivers-char-tty_ioc-remove-pty_sem.patch
+drivers-isdn-i4l-isdn_ttyc-remove-write_sem.patch
+unix98-allocated_ptys_lock-semaphore-to-mutex.patch
+kallsyms-should-prefer-non-weak-symbols.patch
+kallsyms-should-prefer-non-weak-symbols-checkpatch-fixes.patch

Misc

+move-kprobes-examples-to-samples-resend-vs-git-x86.patch

Fix move-kprobes-examples-to-samples-resend.patch

+gigaset-permit-module-unload.patch

gigaset fix

+rtc-cmos-alarm-acts-as-oneshot.patch
+platform-real-time-clock-driver-for-dallas-1511-chip.patch
+#
+blackfin-rtc-driver-the-frequency-function-is-in-units-of-hz-not-units-of-seconds-so-lock-our-driver-down-to-1-hz.patch
+blackfin-rtc-driver-we-pass-in-a-struct-device-to-the-irq-handler-not-a-struct-platform_device-so-fix-the-irq-handler.patch
+blackfin-rtc-driver-cleanup-proc-handler-we-dont-need-rtc-reg-dump-now-that-we-have-mmr-filesystem-in-sysfs.patch
+blackfin-rtc-driver-use-dev_dbg-rather-than-pr_stamp.patch
+blackfin-rtc-driver-read_alarm-checks-the-enabled-field-not-the-pending-field.patch
+blackfin-rtc-driver-shave-off-another-memcpy-by-using-assignment.patch
+blackfin-rtc-driver-convert-sync-wait-to-use-the-irq-write-complete-notice.patch

rtc updates

+fbmon-remove-unnecessary-local-variable.patch
+fbmon-cleanup-trailing-whitespaces.patch
+fbmon-cleanup-trailing-whitespaces-checkpatch-fixes.patch

fbdev queue

+declare-pnp-option-parsing-functions-as-__init.patch
+declare-pnp-option-parsing-functions-as-__init-checkpatch-fixes.patch
+isapnp-driver-semaphore-to-mutex.patch
+isapnp-driver-semaphore-to-mutex-fix.patch
+isapnp-driver-semaphore-to-mutex-fix-fix.patch

pnp updates

-ext4-add-block-bitmap-validation-fix.patch

Folded into ext4-add-block-bitmap-validation.patch

-ext4-fix-up-ext4fs_debug-builds-checkpatch-fixes.patch

Folded into ext4-fix-up-ext4fs_debug-builds.patch

+jbd2-fix-assertion-failure-in-fs-jbd2-checkpointc.patch
+ext4-check-for-the-correct-error-return-from-ext4_ext_get_blocks.patch
+ext4-check-for-the-correct-error-return-from-ext4_ext_get_blocks-fix.patch

ext4 updates

+memory-controller-improve-user-interface-memory-controller-enhancements-for-reclaiming-take2-possible-race-fix-in-res_counter.patch
+per-zone-and-reclaim-enhancements-for-memory-controller-take-3-per-zone-active-inactive-counter-memory-controller-enhancements-for-reclaiming-take2-clean-up-remove-unused-variable.patch
+per-zone-and-reclaim-enhancements-for-memory-controller-take-3-per-zone-active-inactive-counter-memory-controller-enhancements-for-reclaiming-take2-add-bug_on-in-mem_cgroup_zoneinfo.patch
+per-zone-and-reclaim-enhancements-for-memory-controller-take-3-per-zone-lru-for-cgroup-bugfix-for-memory-cgroup-per-zone-struct-allocation.patch
+per-zone-and-reclaim-enhancements-for-memory-controller-take-3-per-zone-lru-for-cgroup-memory-controller-enhancements-for-reclaiming-take2-define-free_mem_cgroup_per_zone_info.patch

Update cgroups memory controller patches in -mm.

-add-cmpxchg_local-to-sh-use-generic-cmpxchg-instead-of-cmpxchg_u32.patch

Dropped due to rejects

+proc-seqfile-convert-proc_pid_status-to-properly-handle-pid-namespaces.patch
+proc-seqfile-convert-proc_pid_status-to-properly-handle-pid-namespaces-checkpatch-fixes.patch
+proc-seqfile-convert-proc_pid_status-to-properly-handle-pid-namespaces-fix.patch

procfs work

+fix-setsid-for-sub-namespace-sbin-init.patch
+teach-set_special_pids-to-use-struct-pid.patch
+move-daemonized-kernel-threads-into-the-swappers-session.patch
+start-the-global-sbin-init-with-00-special-pids.patch
+clocksource-remove-redundant-code.patch
+clockevent-simplify-list-operations.patch
+timekeeping-rename-timekeeping_is_continuous-to-timekeeping_valid_for_hres.patch
+time-fix-typo-in-comments.patch
+time-delete-comments-that-refer-to-noexistent-symbols.patch

Core kernel updates

+aout-move-stack_top-to-asm-processorh.patch
+aout-mark-arches-that-support-aout-format.patch
+aout-suppress-aout-library-support-if-config_arch_supports_aout.patch
+aout-suppress-aout-library-support-if-config_arch_supports_aout-vs-git-x86.patch
+aout-suppress-aout-library-support-if-config_arch_supports_aout-vs-sanitize-the-type-of-struct-useru_ar0.patch
+aout-remove-unnecessary-inclusions-of-asm-linux-aouth.patch
+aout-remove-unnecessary-inclusions-of-asm-linux-aouth-alpha-fix.patch
+usb-net2280-cant-have-a-function-called-show_registers.patch
+mn10300-allocate-serial-port-uart-ids-for-on-chip-serial-ports.patch
+mn10300-add-the-mn10300-am33-architecture-to-the-kernel.patch
+mn10300-add-the-mn10300-am33-architecture-to-the-kernel-fix.patch
+mn10300-add-platform-mtd-support-for-the-asb2303-board.patch

mn10300 architecture and associated stuff

+rewrite-rd.patch
+rewrite-rd-fix.patch
+rewrite-rd-fixes.patch

Reimplamantation of the ramdisk driver

+linux-kernel-markers-support-multiple-probes.patch
+linux-kernel-markers-support-multiple-probes-update.patch
+linux-kernel-markers-create-modpost-file.patch

markers update

+cramfs-make-cramfs-little-endian-only.patch
+cramfs-make-cramfs-little-endian-only-update.patch
+cramfs-make-cramfs-little-endian-only-fix.patch
+cramfs-update-documentation.patch

cramfs work (needs updating)

+reiser4-new-export-ops-update.patch
+reiser4-specify-splice-file-operations.patch

reiser5 updates


4453 commits in 1478 patch files


All patches:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc4/2.6.24-rc4-mm1/patch-list


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Olof Johansson
2007-12-05 09:20:10 UTC
Permalink
powerpc allyesconfig fails on the following two drivers (iseries_defconfig
fails for the veth one):

drivers/net/ehea/ehea_main.c: In function 'ehea_driver_sysfs_add':
drivers/net/ehea/ehea_main.c:2812: error: 'struct device_driver' has no member named 'kobj'
drivers/net/ehea/ehea_main.c:2815: error: 'struct device_driver' has no member named 'kobj'
drivers/net/ehea/ehea_main.c:2818: error: 'struct device_driver' has no member named 'kobj'
drivers/net/ehea/ehea_main.c: In function 'ehea_driver_sysfs_remove':
drivers/net/ehea/ehea_main.c:2830: error: 'struct device_driver' has no member named 'kobj'
drivers/net/iseries_veth.c: In function 'veth_module_init':
drivers/net/iseries_veth.c:1714: error: 'struct device_driver' has no member named 'kobj'

I'm guessing it's some of Greg's kobj/driver patches that missed to
change this, but it's not obvious to me how it should be fixed.


-Olof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Kamalesh Babulal
2007-12-05 13:20:12 UTC
Permalink
Post by Olof Johansson
powerpc allyesconfig fails on the following two drivers (iseries_defconfig
drivers/net/ehea/ehea_main.c:2812: error: 'struct device_driver' has no member named 'kobj'
drivers/net/ehea/ehea_main.c:2815: error: 'struct device_driver' has no member named 'kobj'
drivers/net/ehea/ehea_main.c:2818: error: 'struct device_driver' has no member named 'kobj'
drivers/net/ehea/ehea_main.c:2830: error: 'struct device_driver' has no member named 'kobj'
drivers/net/iseries_veth.c:1714: error: 'struct device_driver' has no member named 'kobj'
I'm guessing it's some of Greg's kobj/driver patches that missed to
change this, but it's not obvious to me how it should be fixed.
-Olof
Hi,

Probably this patch should fix the build failure (The kobject related
structure have been moved to driver_private struct).

Signed-off-by: Kamalesh Babulal <***@linux.vnet.ibm.com>
--
--- linux-2.6.24-rc4/drivers/net/ehea/ehea_main.c 2007-12-04 09:56:10.000000000 +0530
+++ linux-2.6.24-rc4/drivers/net/ehea/~ehea_main.c 2007-12-05 18:01:31.000000000 +0530
@@ -2809,7 +2809,7 @@ static int ehea_driver_sysfs_add(struct
{
int ret;

- ret = sysfs_create_link(&driver->kobj, &dev->kobj,
+ ret = sysfs_create_link(&driver->driver_private->kobj, &dev->kobj,
kobject_name(&dev->kobj));
if (ret == 0) {
ret = sysfs_create_link(&dev->kobj, &driver->kobj,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Greg KH
2007-12-05 15:50:09 UTC
Permalink
Post by Kamalesh Babulal
Post by Olof Johansson
powerpc allyesconfig fails on the following two drivers (iseries_defconfig
drivers/net/ehea/ehea_main.c:2812: error: 'struct device_driver' has no member named 'kobj'
drivers/net/ehea/ehea_main.c:2815: error: 'struct device_driver' has no member named 'kobj'
drivers/net/ehea/ehea_main.c:2818: error: 'struct device_driver' has no member named 'kobj'
drivers/net/ehea/ehea_main.c:2830: error: 'struct device_driver' has no member named 'kobj'
drivers/net/iseries_veth.c:1714: error: 'struct device_driver' has no member named 'kobj'
I'm guessing it's some of Greg's kobj/driver patches that missed to
change this, but it's not obvious to me how it should be fixed.
-Olof
Hi,
Probably this patch should fix the build failure (The kobject related
structure have been moved to driver_private struct).
Yes, but as driver_private is not known by any driver, I don't think
this patch will work at all.
Post by Kamalesh Babulal
--
--- linux-2.6.24-rc4/drivers/net/ehea/ehea_main.c 2007-12-04 09:56:10.000000000 +0530
+++ linux-2.6.24-rc4/drivers/net/ehea/~ehea_main.c 2007-12-05 18:01:31.000000000 +0530
@@ -2809,7 +2809,7 @@ static int ehea_driver_sysfs_add(struct
{
int ret;
- ret = sysfs_create_link(&driver->kobj, &dev->kobj,
+ ret = sysfs_create_link(&driver->driver_private->kobj, &dev->kobj,
kobject_name(&dev->kobj));
What are you trying to do here? The driver core already sets up this
symlink for you automatically, why are you createing yet-another-link
with a different name? This should just be removed entirely, it's not
needed at all.

So, to fix the build properly, just delete the sysfs_create_link() call
entirely.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Kamalesh Babulal
2007-12-05 14:20:10 UTC
Permalink
Hi Andrew,

The 2.6.24-rc4-mm1 kernel build fails with build failure,

CC drivers/char/hvcs.o
drivers/char/hvcs.c: In function ‘hvcs_open’:
drivers/char/hvcs.c:1180: error: wrong type argument to unary exclamation mark
make[2]: *** [drivers/char/hvcs.o] Error 1
make[1]: *** [drivers/char] Error 2
make: *** [drivers] Error 2

The kref_get begin void return type, check for the kobject return type
as in the previous kobject_get()

if (!kref_get(&hvcsd->kref)) {
spin_unlock_irqrestore(&hvcsd->lock, flags);
printk(KERN_ERR "HVCS: Kobject of open"
" hvcs doesn't exist.\n");
return -EFAULT; /* Is this the right return value? */
}

I have tested for the build failure only.

Signed-off-by: Kamalesh Babulal <***@linux.vnet.ibm.com>
--
--- linux-2.6.24-rc4/drivers/char/hvcs.c 2007-12-05 12:17:37.000000000 +0530
+++ linux-2.6.24-rc4/drivers/char/~hvcs.c 2007-12-05 19:17:12.000000000 +0530
@@ -1177,12 +1177,8 @@ fast_open:
hvcsd = tty->driver_data;

spin_lock_irqsave(&hvcsd->lock, flags);
- if (!kref_get(&hvcsd->kref)) {
- spin_unlock_irqrestore(&hvcsd->lock, flags);
- printk(KERN_ERR "HVCS: Kobject of open"
- " hvcs doesn't exist.\n");
- return -EFAULT; /* Is this the right return value? */
- }
+ kref_get(&hvcsd->kref);
+ spin_unlock_irqrestore(&hvcsd->lock, flags);

hvcsd->open_count++;

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Greg KH
2007-12-05 15:50:09 UTC
Permalink
Post by Kamalesh Babulal
Hi Andrew,
The 2.6.24-rc4-mm1 kernel build fails with build failure,
CC drivers/char/hvcs.o
drivers/char/hvcs.c:1180: error: wrong type argument to unary exclamation mark
make[2]: *** [drivers/char/hvcs.o] Error 1
make[1]: *** [drivers/char] Error 2
make: *** [drivers] Error 2
Oops, sorry about that, my fault. I'll merge your fix in with my
original patch, thanks for it.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Balbir Singh
2007-12-06 18:30:19 UTC
Permalink
Post by Kamalesh Babulal
Hi Andrew,
The 2.6.24-rc4-mm1 kernel build fails with build failure,
CC drivers/char/hvcs.o
drivers/char/hvcs.c:1180: error: wrong type argument to unary exclamation mark
make[2]: *** [drivers/char/hvcs.o] Error 1
make[1]: *** [drivers/char] Error 2
make: *** [drivers] Error 2
The kref_get begin void return type, check for the kobject return type
as in the previous kobject_get()
if (!kref_get(&hvcsd->kref)) {
spin_unlock_irqrestore(&hvcsd->lock, flags);
printk(KERN_ERR "HVCS: Kobject of open"
" hvcs doesn't exist.\n");
return -EFAULT; /* Is this the right return value? */
}
I have tested for the build failure only.
--
--- linux-2.6.24-rc4/drivers/char/hvcs.c 2007-12-05 12:17:37.000000000 +0530
+++ linux-2.6.24-rc4/drivers/char/~hvcs.c 2007-12-05 19:17:12.000000000 +0530
hvcsd = tty->driver_data;
spin_lock_irqsave(&hvcsd->lock, flags);
- if (!kref_get(&hvcsd->kref)) {
- spin_unlock_irqrestore(&hvcsd->lock, flags);
- printk(KERN_ERR "HVCS: Kobject of open"
- " hvcs doesn't exist.\n");
- return -EFAULT; /* Is this the right return value? */
- }
+ kref_get(&hvcsd->kref);
+ spin_unlock_irqrestore(&hvcsd->lock, flags);
Why release the spinlock here? It's done after the count is incremented.
This patch does not seem correct.
Post by Kamalesh Babulal
hvcsd->open_count++;
--
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Kamalesh Babulal
2007-12-06 18:50:07 UTC
Permalink
Post by Balbir Singh
Post by Kamalesh Babulal
Hi Andrew,
The 2.6.24-rc4-mm1 kernel build fails with build failure,
CC drivers/char/hvcs.o
drivers/char/hvcs.c:1180: error: wrong type argument to unary exclamation mark
make[2]: *** [drivers/char/hvcs.o] Error 1
make[1]: *** [drivers/char] Error 2
make: *** [drivers] Error 2
The kref_get begin void return type, check for the kobject return type
as in the previous kobject_get()
if (!kref_get(&hvcsd->kref)) {
spin_unlock_irqrestore(&hvcsd->lock, flags);
printk(KERN_ERR "HVCS: Kobject of open"
" hvcs doesn't exist.\n");
return -EFAULT; /* Is this the right return value? */
}
I have tested for the build failure only.
--
--- linux-2.6.24-rc4/drivers/char/hvcs.c 2007-12-05 12:17:37.000000000 +0530
+++ linux-2.6.24-rc4/drivers/char/~hvcs.c 2007-12-05 19:17:12.000000000 +0530
hvcsd = tty->driver_data;
spin_lock_irqsave(&hvcsd->lock, flags);
- if (!kref_get(&hvcsd->kref)) {
- spin_unlock_irqrestore(&hvcsd->lock, flags);
- printk(KERN_ERR "HVCS: Kobject of open"
- " hvcs doesn't exist.\n");
- return -EFAULT; /* Is this the right return value? */
- }
+ kref_get(&hvcsd->kref);
+ spin_unlock_irqrestore(&hvcsd->lock, flags);
Why release the spinlock here? It's done after the count is incremented.
This patch does not seem correct.
Doh, you are correct, I'll make sure that I fix this up before applying
it.
thanks,
greg k-h
Sorry, my fault for overlooking that, thanks greg.
--
Thanks & Regards,
Kamalesh Babulal,

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Balbir Singh
2007-12-06 19:00:15 UTC
Permalink
Post by Balbir Singh
Why release the spinlock here? It's done after the count is incremented.
This patch does not seem correct.
Doh, you are correct, I'll make sure that I fix this up before applying
it.
thanks,
greg k-h
Hi, Greg,

I ran some tests with the fixed up version of this patch and the system
fails to come up.

I see the WARN_ON in lib/kref.c:33 and the system fails to boot beyond
that point. I have not yet found time to debug it though.
--
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Badari Pulavarty
2007-12-06 19:20:21 UTC
Permalink
Post by Balbir Singh
Post by Balbir Singh
Why release the spinlock here? It's done after the count is incremented.
This patch does not seem correct.
Doh, you are correct, I'll make sure that I fix this up before applying
it.
thanks,
greg k-h
Hi, Greg,
I ran some tests with the fixed up version of this patch and the system
fails to come up.
I see the WARN_ON in lib/kref.c:33 and the system fails to boot beyond
that point. I have not yet found time to debug it though.
Are you running into same issue, I am getting on my machine ? Are you
using IPR driver ?

Thanks,
Badari


e100: Intel(R) PRO/100 Network Driver, 3.5.23-k4-NAPI
e100: Copyright(c) 1999-2006 Intel Corporation
ipr: IBM Power RAID SCSI Device Driver version: 2.4.1 (April 24, 2007)
ipr 0000:d0:01.0: Found IOA with IRQ: 119
ipr 0000:d0:01.0: Starting IOA initialization sequence.
ipr 0000:d0:01.0: Adapter firmware version: 020A005E
ipr 0000:d0:01.0: IOA initialized.
scsi0 : IBM 570B Storage Adapter
scsi 0:0:3:0: Direct-Access IBM H0 HUS103014FL3800 RPQF PQ: 0 ANSI: 4
scsi 0:0:5:0: Direct-Access IBM H0 HUS103014FL3800 RPQF PQ: 0 ANSI: 4
scsi 0:0:8:0: Direct-Access IBM H0 HUS103014FL3800 RPQF PQ: 0 ANSI: 4
scsi 0:0:15:0: Enclosure IBM VSBPD4E2 U4SCSI 7134 PQ: 0 ANSI: 2
------------[ cut here ]------------
Badness at lib/kref.c:33
NIP: c0000000002e1254 LR: c0000000002dfbd8 CTR: c0000000002e60f0
REGS: c00000003f0db050 TRAP: 0700 Not tainted (2.6.24-rc4-mm1)
MSR: 8000000000029032 <EE,ME,IR,DR> CR: 28002042 XER: 0000000f
TASK = c00000003f0d78d0[1] 'swapper' THREAD: c00000003f0d8000 CPU: 0
GPR00: 0000000000000000 c00000003f0db2d0 c000000000724098 c00000003f131620
GPR04: fffffffffffffff1 fffffffffffffffe 000000000000000a ffffffffffffffff
GPR08: c00000003d4d9000 c00000003f0cbfe0 c000000000556591 0000000000000073
GPR12: 0000000024002084 c000000000651980 0000000000000000 0000000000000000
GPR16: 0000000000000000 d000080080080000 c00000000064d6f0 c00000003d4d9570
GPR20: c00000003d4d94b8 0000000000000002 c00000003d4d9170 c00000003d4d9170
GPR24: c00000003d4d9000 0000000000000001 c00000003d570d58 c00000003d570d18
GPR28: 0000000000000000 c00000003d4d9260 c0000000006b5400 c00000003f131618
NIP [c0000000002e1254] .kref_get+0x10/0x2c
LR [c0000000002dfbd8] .kobject_get+0x24/0x40
Call Trace:
[c00000003f0db2d0] [c00000003f0db360] 0xc00000003f0db360 (unreliable)
[c00000003f0db350] [c0000000002e00e8] .kobject_add+0x8c/0x21c
[c00000003f0db3e0] [c000000000344b00] .device_add+0xd4/0x680
[c00000003f0db4a0] [c0000000003a1c4c] .scsi_alloc_target+0x218/0x404
[c00000003f0db570] [c0000000003a1fb4] .__scsi_scan_target+0xa8/0x640
[c00000003f0db6b0] [c0000000003a25c4] .scsi_scan_channel+0x78/0xdc
[c00000003f0db750] [c0000000003a26f8] .scsi_scan_host_selected+0xd0/0x140
[c00000003f0db7f0] [c0000000003c3ff4] .ipr_probe+0x1270/0x1348
[c00000003f0db960] [c0000000002f4808] .pci_device_probe+0x124/0x194
[c00000003f0dba10] [c000000000347e8c] .driver_probe_device+0x110/0x1f0
[c00000003f0dbaa0] [c000000000348014] .__driver_attach+0xa8/0x134
[c00000003f0dbb30] [c0000000003472ac] .bus_for_each_dev+0x80/0xd0
[c00000003f0dbbe0] [c000000000347c14] .driver_attach+0x28/0x40
[c00000003f0dbc60] [c000000000346788] .bus_add_driver+0xfc/0x2d0
[c00000003f0dbd10] [c0000000003482cc] .driver_register+0x80/0x9c
[c00000003f0dbd90] [c0000000002f4bb0] .__pci_register_driver+0x5c/0xcc
[c00000003f0dbe20] [c000000000604b38] .ipr_init+0x38/0x50
[c00000003f0dbea0] [c0000000005d6428] .kernel_init+0x214/0x3ec
[c00000003f0dbf90] [c000000000026734] .kernel_thread+0x4c/0x68
Instruction dump:
e8410028 39200001 38210080 7d234b78 e8010010 ebc1fff0 7c0803a6 4e800020
80030000 7c0007b4 2f800000 409e0008 <0fe00000> 7c001828 30000001



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Balbir Singh
2007-12-07 01:30:14 UTC
Permalink
Post by Badari Pulavarty
Post by Balbir Singh
Post by Balbir Singh
Why release the spinlock here? It's done after the count is incremented.
This patch does not seem correct.
Doh, you are correct, I'll make sure that I fix this up before applying
it.
thanks,
greg k-h
Hi, Greg,
I ran some tests with the fixed up version of this patch and the system
fails to come up.
I see the WARN_ON in lib/kref.c:33 and the system fails to boot beyond
that point. I have not yet found time to debug it though.
Are you running into same issue, I am getting on my machine ? Are you
using IPR driver ?
Badari,

I am unable to get past lib/kref.c:33 and cut here. The machine just
stalls, I see no output at the console. I don't get a backtrace like you
do, even with xmon enabled :(
Post by Badari Pulavarty
Thanks,
Badari
--
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Greg KH
2007-12-06 20:30:33 UTC
Permalink
Post by Balbir Singh
Post by Balbir Singh
Why release the spinlock here? It's done after the count is incremented.
This patch does not seem correct.
Doh, you are correct, I'll make sure that I fix this up before applying
it.
thanks,
greg k-h
Hi, Greg,
I ran some tests with the fixed up version of this patch and the system
fails to come up.
I see the WARN_ON in lib/kref.c:33 and the system fails to boot beyond
that point. I have not yet found time to debug it though.
That's not good, that warning means that someone has tried to use this
kref _before_ it was initialized, so there is a logic error in the code
that was previously being papered over with the lack of this message in
the kobject code.

I do have this same message availble as a patch for the kobject core, it
would be interesting if you could just run 2.6.24-rc4 with just this
patch:
http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-01-driver/kobject-warn.patch

it might take some fuzz to fit properly, but all you really want to do
is add:
WARN_ON(atomic_read(&kobj->kref.refcount));
before the kref_init() call in kobject_init().

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Badari Pulavarty
2007-12-07 00:00:14 UTC
Permalink
Post by Greg KH
Post by Balbir Singh
Post by Balbir Singh
Why release the spinlock here? It's done after the count is incremented.
This patch does not seem correct.
Doh, you are correct, I'll make sure that I fix this up before applying
it.
thanks,
greg k-h
Hi, Greg,
I ran some tests with the fixed up version of this patch and the system
fails to come up.
I see the WARN_ON in lib/kref.c:33 and the system fails to boot beyond
that point. I have not yet found time to debug it though.
That's not good, that warning means that someone has tried to use this
kref _before_ it was initialized, so there is a logic error in the code
that was previously being papered over with the lack of this message in
the kobject code.
I do have this same message availble as a patch for the kobject core, it
would be interesting if you could just run 2.6.24-rc4 with just this
http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-01-driver/kobject-warn.patch
it might take some fuzz to fit properly, but all you really want to do
WARN_ON(atomic_read(&kobj->kref.refcount));
before the kref_init() call in kobject_init().
thanks,
greg k-h
2.6.24-rc4 with above patch booted fine without any warnings.
But 2.6.24-rc4-mm1 doesn't boot, it hangs after following messages.


e100: Intel(R) PRO/100 Network Driver, 3.5.23-k4-NAPI
e100: Copyright(c) 1999-2006 Intel Corporation
ipr: IBM Power RAID SCSI Device Driver version: 2.4.1 (April 24, 2007)
ipr 0000:d0:01.0: Found IOA with IRQ: 119
ipr 0000:d0:01.0: Starting IOA initialization sequence.
ipr 0000:d0:01.0: Adapter firmware version: 020A005E
ipr 0000:d0:01.0: IOA initialized.
scsi0 : IBM 570B Storage Adapter
scsi 0:0:3:0: Direct-Access IBM H0 HUS103014FL3800 RPQF PQ: 0 ANSI: 4
scsi 0:0:5:0: Direct-Access IBM H0 HUS103014FL3800 RPQF PQ: 0 ANSI: 4
scsi 0:0:8:0: Direct-Access IBM H0 HUS103014FL3800 RPQF PQ: 0 ANSI: 4
scsi 0:0:15:0: Enclosure IBM VSBPD4E2 U4SCSI 7134 PQ: 0 ANSI: 2
------------[ cut here ]------------
Badness at lib/kref.c:33
NIP: c0000000002e1254 LR: c0000000002dfbd8 CTR: c0000000002e60f0
REGS: c00000003f0db050 TRAP: 0700 Not tainted (2.6.24-rc4-mm1)
MSR: 8000000000029032 <EE,ME,IR,DR> CR: 28002042 XER: 0000000f
TASK = c00000003f0d78d0[1] 'swapper' THREAD: c00000003f0d8000 CPU: 0
GPR00: 0000000000000000 c00000003f0db2d0 c000000000724098 c00000003f131620
GPR04: fffffffffffffff1 fffffffffffffffe 000000000000000a ffffffffffffffff
GPR08: c00000003d4d9000 c00000003f0cbfe0 c000000000556591 0000000000000073
GPR12: 0000000024002084 c000000000651980 0000000000000000 0000000000000000
GPR16: 0000000000000000 d000080080080000 c00000000064d6f0 c00000003d4d9570
GPR20: c00000003d4d94b8 0000000000000002 c00000003d4d9170 c00000003d4d9170
GPR24: c00000003d4d9000 0000000000000001 c00000003d570d58 c00000003d570d18
GPR28: 0000000000000000 c00000003d4d9260 c0000000006b5400 c00000003f131618
NIP [c0000000002e1254] .kref_get+0x10/0x2c
LR [c0000000002dfbd8] .kobject_get+0x24/0x40
Call Trace:
[c00000003f0db2d0] [c00000003f0db360] 0xc00000003f0db360 (unreliable)
[c00000003f0db350] [c0000000002e00e8] .kobject_add+0x8c/0x21c
[c00000003f0db3e0] [c000000000344b00] .device_add+0xd4/0x680
[c00000003f0db4a0] [c0000000003a1c4c] .scsi_alloc_target+0x218/0x404
[c00000003f0db570] [c0000000003a1fb4] .__scsi_scan_target+0xa8/0x640
[c00000003f0db6b0] [c0000000003a25c4] .scsi_scan_channel+0x78/0xdc
[c00000003f0db750] [c0000000003a26f8] .scsi_scan_host_selected+0xd0/0x140
[c00000003f0db7f0] [c0000000003c3ff4] .ipr_probe+0x1270/0x1348
[c00000003f0db960] [c0000000002f4808] .pci_device_probe+0x124/0x194
[c00000003f0dba10] [c000000000347e8c] .driver_probe_device+0x110/0x1f0
[c00000003f0dbaa0] [c000000000348014] .__driver_attach+0xa8/0x134
[c00000003f0dbb30] [c0000000003472ac] .bus_for_each_dev+0x80/0xd0
[c00000003f0dbbe0] [c000000000347c14] .driver_attach+0x28/0x40
[c00000003f0dbc60] [c000000000346788] .bus_add_driver+0xfc/0x2d0
[c00000003f0dbd10] [c0000000003482cc] .driver_register+0x80/0x9c
[c00000003f0dbd90] [c0000000002f4bb0] .__pci_register_driver+0x5c/0xcc
[c00000003f0dbe20] [c000000000604b38] .ipr_init+0x38/0x50
[c00000003f0dbea0] [c0000000005d6428] .kernel_init+0x214/0x3ec
[c00000003f0dbf90] [c000000000026734] .kernel_thread+0x4c/0x68
Instruction dump:
e8410028 39200001 38210080 7d234b78 e8010010 ebc1fff0 7c0803a6 4e800020
80030000 7c0007b4 2f800000 409e0008 <0fe00000> 7c001828 30000001


Thanks,
Badari

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Greg KH
2007-12-07 00:30:17 UTC
Permalink
Post by Badari Pulavarty
Post by Greg KH
Post by Balbir Singh
Post by Balbir Singh
Why release the spinlock here? It's done after the count is incremented.
This patch does not seem correct.
Doh, you are correct, I'll make sure that I fix this up before applying
it.
thanks,
greg k-h
Hi, Greg,
I ran some tests with the fixed up version of this patch and the system
fails to come up.
I see the WARN_ON in lib/kref.c:33 and the system fails to boot beyond
that point. I have not yet found time to debug it though.
That's not good, that warning means that someone has tried to use this
kref _before_ it was initialized, so there is a logic error in the code
that was previously being papered over with the lack of this message in
the kobject code.
I do have this same message availble as a patch for the kobject core, it
would be interesting if you could just run 2.6.24-rc4 with just this
http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-01-driver/kobject-warn.patch
it might take some fuzz to fit properly, but all you really want to do
WARN_ON(atomic_read(&kobj->kref.refcount));
before the kref_init() call in kobject_init().
thanks,
greg k-h
2.6.24-rc4 with above patch booted fine without any warnings.
But 2.6.24-rc4-mm1 doesn't boot, it hangs after following messages.
e100: Intel(R) PRO/100 Network Driver, 3.5.23-k4-NAPI
e100: Copyright(c) 1999-2006 Intel Corporation
ipr: IBM Power RAID SCSI Device Driver version: 2.4.1 (April 24, 2007)
ipr 0000:d0:01.0: Found IOA with IRQ: 119
ipr 0000:d0:01.0: Starting IOA initialization sequence.
ipr 0000:d0:01.0: Adapter firmware version: 020A005E
ipr 0000:d0:01.0: IOA initialized.
scsi0 : IBM 570B Storage Adapter
scsi 0:0:3:0: Direct-Access IBM H0 HUS103014FL3800 RPQF PQ: 0 ANSI: 4
scsi 0:0:5:0: Direct-Access IBM H0 HUS103014FL3800 RPQF PQ: 0 ANSI: 4
scsi 0:0:8:0: Direct-Access IBM H0 HUS103014FL3800 RPQF PQ: 0 ANSI: 4
scsi 0:0:15:0: Enclosure IBM VSBPD4E2 U4SCSI 7134 PQ: 0 ANSI: 2
------------[ cut here ]------------
Badness at lib/kref.c:33
NIP: c0000000002e1254 LR: c0000000002dfbd8 CTR: c0000000002e60f0
REGS: c00000003f0db050 TRAP: 0700 Not tainted (2.6.24-rc4-mm1)
MSR: 8000000000029032 <EE,ME,IR,DR> CR: 28002042 XER: 0000000f
TASK = c00000003f0d78d0[1] 'swapper' THREAD: c00000003f0d8000 CPU: 0
GPR00: 0000000000000000 c00000003f0db2d0 c000000000724098 c00000003f131620
GPR04: fffffffffffffff1 fffffffffffffffe 000000000000000a ffffffffffffffff
GPR08: c00000003d4d9000 c00000003f0cbfe0 c000000000556591 0000000000000073
GPR12: 0000000024002084 c000000000651980 0000000000000000 0000000000000000
GPR16: 0000000000000000 d000080080080000 c00000000064d6f0 c00000003d4d9570
GPR20: c00000003d4d94b8 0000000000000002 c00000003d4d9170 c00000003d4d9170
GPR24: c00000003d4d9000 0000000000000001 c00000003d570d58 c00000003d570d18
GPR28: 0000000000000000 c00000003d4d9260 c0000000006b5400 c00000003f131618
NIP [c0000000002e1254] .kref_get+0x10/0x2c
LR [c0000000002dfbd8] .kobject_get+0x24/0x40
[c00000003f0db2d0] [c00000003f0db360] 0xc00000003f0db360 (unreliable)
[c00000003f0db350] [c0000000002e00e8] .kobject_add+0x8c/0x21c
[c00000003f0db3e0] [c000000000344b00] .device_add+0xd4/0x680
[c00000003f0db4a0] [c0000000003a1c4c] .scsi_alloc_target+0x218/0x404
[c00000003f0db570] [c0000000003a1fb4] .__scsi_scan_target+0xa8/0x640
[c00000003f0db6b0] [c0000000003a25c4] .scsi_scan_channel+0x78/0xdc
[c00000003f0db750] [c0000000003a26f8] .scsi_scan_host_selected+0xd0/0x140
[c00000003f0db7f0] [c0000000003c3ff4] .ipr_probe+0x1270/0x1348
This looks like a scsi issue to me, I don't see how the kref changes
could cause this backtrace/oops, do you?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Kamalesh Babulal
2007-12-07 03:10:10 UTC
Permalink
Post by Greg KH
Post by Badari Pulavarty
Post by Greg KH
Post by Balbir Singh
Post by Balbir Singh
Why release the spinlock here? It's done after the count is incremented.
This patch does not seem correct.
Doh, you are correct, I'll make sure that I fix this up before applying
it.
thanks,
greg k-h
Hi, Greg,
I ran some tests with the fixed up version of this patch and the system
fails to come up.
I see the WARN_ON in lib/kref.c:33 and the system fails to boot beyond
that point. I have not yet found time to debug it though.
That's not good, that warning means that someone has tried to use this
kref _before_ it was initialized, so there is a logic error in the code
that was previously being papered over with the lack of this message in
the kobject code.
I do have this same message availble as a patch for the kobject core, it
would be interesting if you could just run 2.6.24-rc4 with just this
http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-01-driver/kobject-warn.patch
it might take some fuzz to fit properly, but all you really want to do
WARN_ON(atomic_read(&kobj->kref.refcount));
before the kref_init() call in kobject_init().
thanks,
greg k-h
2.6.24-rc4 with above patch booted fine without any warnings.
But 2.6.24-rc4-mm1 doesn't boot, it hangs after following messages.
e100: Intel(R) PRO/100 Network Driver, 3.5.23-k4-NAPI
e100: Copyright(c) 1999-2006 Intel Corporation
ipr: IBM Power RAID SCSI Device Driver version: 2.4.1 (April 24, 2007)
ipr 0000:d0:01.0: Found IOA with IRQ: 119
ipr 0000:d0:01.0: Starting IOA initialization sequence.
ipr 0000:d0:01.0: Adapter firmware version: 020A005E
ipr 0000:d0:01.0: IOA initialized.
scsi0 : IBM 570B Storage Adapter
scsi 0:0:3:0: Direct-Access IBM H0 HUS103014FL3800 RPQF PQ: 0 ANSI: 4
scsi 0:0:5:0: Direct-Access IBM H0 HUS103014FL3800 RPQF PQ: 0 ANSI: 4
scsi 0:0:8:0: Direct-Access IBM H0 HUS103014FL3800 RPQF PQ: 0 ANSI: 4
scsi 0:0:15:0: Enclosure IBM VSBPD4E2 U4SCSI 7134 PQ: 0 ANSI: 2
------------[ cut here ]------------
Badness at lib/kref.c:33
NIP: c0000000002e1254 LR: c0000000002dfbd8 CTR: c0000000002e60f0
REGS: c00000003f0db050 TRAP: 0700 Not tainted (2.6.24-rc4-mm1)
MSR: 8000000000029032 <EE,ME,IR,DR> CR: 28002042 XER: 0000000f
TASK = c00000003f0d78d0[1] 'swapper' THREAD: c00000003f0d8000 CPU: 0
GPR00: 0000000000000000 c00000003f0db2d0 c000000000724098 c00000003f131620
GPR04: fffffffffffffff1 fffffffffffffffe 000000000000000a ffffffffffffffff
GPR08: c00000003d4d9000 c00000003f0cbfe0 c000000000556591 0000000000000073
GPR12: 0000000024002084 c000000000651980 0000000000000000 0000000000000000
GPR16: 0000000000000000 d000080080080000 c00000000064d6f0 c00000003d4d9570
GPR20: c00000003d4d94b8 0000000000000002 c00000003d4d9170 c00000003d4d9170
GPR24: c00000003d4d9000 0000000000000001 c00000003d570d58 c00000003d570d18
GPR28: 0000000000000000 c00000003d4d9260 c0000000006b5400 c00000003f131618
NIP [c0000000002e1254] .kref_get+0x10/0x2c
LR [c0000000002dfbd8] .kobject_get+0x24/0x40
[c00000003f0db2d0] [c00000003f0db360] 0xc00000003f0db360 (unreliable)
[c00000003f0db350] [c0000000002e00e8] .kobject_add+0x8c/0x21c
[c00000003f0db3e0] [c000000000344b00] .device_add+0xd4/0x680
[c00000003f0db4a0] [c0000000003a1c4c] .scsi_alloc_target+0x218/0x404
[c00000003f0db570] [c0000000003a1fb4] .__scsi_scan_target+0xa8/0x640
[c00000003f0db6b0] [c0000000003a25c4] .scsi_scan_channel+0x78/0xdc
[c00000003f0db750] [c0000000003a26f8] .scsi_scan_host_selected+0xd0/0x140
[c00000003f0db7f0] [c0000000003c3ff4] .ipr_probe+0x1270/0x1348
This looks like a scsi issue to me, I don't see how the kref changes
could cause this backtrace/oops, do you?
thanks,
greg k-h
The 2.6.24-rc4 with the above patch, boots fine for me either, and with
2.6.24-rc4-mm1 i get similar backtrace,

Badness at lib/kref.c:33
NIP: c00000000021908c LR: c000000000217b88 CTR: c00000000029b71c
REGS: c00000003c066fc0 TRAP: 0700 Not tainted (2.6.24-rc4-mm1-autokern1)
MSR: 8000000000029032 <EE,ME,IR,DR> CR: 88002022 XER: 00000001
TASK = c00000003ef4c840[339] 'insmod' THREAD: c00000003c064000 CPU: 0
GPR00: 0000000000000000 c00000003c067240 c0000000005d32c0 c00000003e0101a0
GPR04: fffffffffffffff2 fffffffffffffffe 000000000000000a 0000000000000002
GPR08: 0000000000000000 c00000003ef8ae50 ffffffffffffffff c000000000449269
GPR12: 0000000024002084 c000000000515980 0000000000000000 0000000000000000
GPR16: 0000000000000000 0000000000000000 0000000000240000 0000000000000000
GPR20: 0000000010000290 0000000000000002 c00000003ef3f970 c00000003ef3f970
GPR24: 0000000000000001 0000000000000000 c00000003c039958 c00000003c039918
GPR28: 0000000000000000 c00000003ef3fa60 c00000000058e588 c00000003e010198
NIP [c00000000021908c] .kref_get+0x10/0x2c
LR [c000000000217b88] .kobject_get+0x20/0x3c
Call Trace:
[c00000003c067240] [c000000000217a48] .kobject_set_name_vargs+0x38/0x60 (unreliable)
[c00000003c0672c0] [c000000000217ffc] .kobject_add+0x88/0x20c
[c00000003c067350] [c00000000029b7ec] .device_add+0xd0/0x648
[c00000003c067410] [d000000000613c84] .scsi_alloc_target+0x238/0x414 [scsi_mod]
[c00000003c0674e0] [d000000000614e70] .__scsi_scan_target+0xac/0x718 [scsi_mod]
[c00000003c067630] [d00000000061566c] .scsi_scan_channel+0x78/0xdc [scsi_mod]
[c00000003c0676d0] [d0000000006157f0] .scsi_scan_host_selected+0x120/0x194 [scsi_mod]
[c00000003c067780] [d000000000682148] .ibmvscsi_probe+0x450/0x4fc [ibmvscsic]
[c00000003c067870] [c000000000025fe8] .vio_bus_probe+0x74/0x9c
[c00000003c067900] [c00000000029f2c8] .driver_probe_device+0x110/0x1ec
[c00000003c067990] [c00000000029f57c] .__driver_attach+0xd0/0x160
[c00000003c067a20] [c00000000029da58] .bus_for_each_dev+0x7c/0xcc
[c00000003c067ad0] [c00000000029f634] .driver_attach+0x28/0x40
[c00000003c067b50] [c00000000029e6a4] .bus_add_driver+0xe8/0x2b4
[c00000003c067c00] [c00000000029fd80] .driver_register+0x80/0x9c
[c00000003c067c80] [c0000000000260b0] .vio_register_driver+0x40/0x5c
[c00000003c067d10] [d000000000682c04] .init_module+0x68/0xa4 [ibmvscsic]
[c00000003c067da0] [c00000000009301c] .sys_init_module+0xf4/0x1ac
[c00000003c067e30] [c00000000000872c] syscall_exit+0x0/0x40
Instruction dump:
7d808120 4e800020 38a00000 4bfffad0 38000001 90030000 7c0004ac 4e800020
80030000 7c0007b4 2f800000 40be0008 <0fe00000> 7c001828 30000001 7c00192d
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Greg KH
2007-12-07 05:20:05 UTC
Permalink
Post by Kamalesh Babulal
Post by Greg KH
Post by Badari Pulavarty
Post by Greg KH
Post by Balbir Singh
Post by Balbir Singh
Why release the spinlock here? It's done after the count is incremented.
This patch does not seem correct.
Doh, you are correct, I'll make sure that I fix this up before applying
it.
thanks,
greg k-h
Hi, Greg,
I ran some tests with the fixed up version of this patch and the system
fails to come up.
I see the WARN_ON in lib/kref.c:33 and the system fails to boot beyond
that point. I have not yet found time to debug it though.
That's not good, that warning means that someone has tried to use this
kref _before_ it was initialized, so there is a logic error in the code
that was previously being papered over with the lack of this message in
the kobject code.
I do have this same message availble as a patch for the kobject core, it
would be interesting if you could just run 2.6.24-rc4 with just this
http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-01-driver/kobject-warn.patch
it might take some fuzz to fit properly, but all you really want to do
WARN_ON(atomic_read(&kobj->kref.refcount));
before the kref_init() call in kobject_init().
thanks,
greg k-h
2.6.24-rc4 with above patch booted fine without any warnings.
But 2.6.24-rc4-mm1 doesn't boot, it hangs after following messages.
e100: Intel(R) PRO/100 Network Driver, 3.5.23-k4-NAPI
e100: Copyright(c) 1999-2006 Intel Corporation
ipr: IBM Power RAID SCSI Device Driver version: 2.4.1 (April 24, 2007)
ipr 0000:d0:01.0: Found IOA with IRQ: 119
ipr 0000:d0:01.0: Starting IOA initialization sequence.
ipr 0000:d0:01.0: Adapter firmware version: 020A005E
ipr 0000:d0:01.0: IOA initialized.
scsi0 : IBM 570B Storage Adapter
scsi 0:0:3:0: Direct-Access IBM H0 HUS103014FL3800 RPQF PQ: 0 ANSI: 4
scsi 0:0:5:0: Direct-Access IBM H0 HUS103014FL3800 RPQF PQ: 0 ANSI: 4
scsi 0:0:8:0: Direct-Access IBM H0 HUS103014FL3800 RPQF PQ: 0 ANSI: 4
scsi 0:0:15:0: Enclosure IBM VSBPD4E2 U4SCSI 7134 PQ: 0 ANSI: 2
------------[ cut here ]------------
Badness at lib/kref.c:33
NIP: c0000000002e1254 LR: c0000000002dfbd8 CTR: c0000000002e60f0
REGS: c00000003f0db050 TRAP: 0700 Not tainted (2.6.24-rc4-mm1)
MSR: 8000000000029032 <EE,ME,IR,DR> CR: 28002042 XER: 0000000f
TASK = c00000003f0d78d0[1] 'swapper' THREAD: c00000003f0d8000 CPU: 0
GPR00: 0000000000000000 c00000003f0db2d0 c000000000724098 c00000003f131620
GPR04: fffffffffffffff1 fffffffffffffffe 000000000000000a ffffffffffffffff
GPR08: c00000003d4d9000 c00000003f0cbfe0 c000000000556591 0000000000000073
GPR12: 0000000024002084 c000000000651980 0000000000000000 0000000000000000
GPR16: 0000000000000000 d000080080080000 c00000000064d6f0 c00000003d4d9570
GPR20: c00000003d4d94b8 0000000000000002 c00000003d4d9170 c00000003d4d9170
GPR24: c00000003d4d9000 0000000000000001 c00000003d570d58 c00000003d570d18
GPR28: 0000000000000000 c00000003d4d9260 c0000000006b5400 c00000003f131618
NIP [c0000000002e1254] .kref_get+0x10/0x2c
LR [c0000000002dfbd8] .kobject_get+0x24/0x40
[c00000003f0db2d0] [c00000003f0db360] 0xc00000003f0db360 (unreliable)
[c00000003f0db350] [c0000000002e00e8] .kobject_add+0x8c/0x21c
[c00000003f0db3e0] [c000000000344b00] .device_add+0xd4/0x680
[c00000003f0db4a0] [c0000000003a1c4c] .scsi_alloc_target+0x218/0x404
[c00000003f0db570] [c0000000003a1fb4] .__scsi_scan_target+0xa8/0x640
[c00000003f0db6b0] [c0000000003a25c4] .scsi_scan_channel+0x78/0xdc
[c00000003f0db750] [c0000000003a26f8] .scsi_scan_host_selected+0xd0/0x140
[c00000003f0db7f0] [c0000000003c3ff4] .ipr_probe+0x1270/0x1348
This looks like a scsi issue to me, I don't see how the kref changes
could cause this backtrace/oops, do you?
thanks,
greg k-h
The 2.6.24-rc4 with the above patch, boots fine for me either, and with
2.6.24-rc4-mm1 i get similar backtrace,
Badness at lib/kref.c:33
NIP: c00000000021908c LR: c000000000217b88 CTR: c00000000029b71c
REGS: c00000003c066fc0 TRAP: 0700 Not tainted (2.6.24-rc4-mm1-autokern1)
MSR: 8000000000029032 <EE,ME,IR,DR> CR: 88002022 XER: 00000001
TASK = c00000003ef4c840[339] 'insmod' THREAD: c00000003c064000 CPU: 0
GPR00: 0000000000000000 c00000003c067240 c0000000005d32c0 c00000003e0101a0
GPR04: fffffffffffffff2 fffffffffffffffe 000000000000000a 0000000000000002
GPR08: 0000000000000000 c00000003ef8ae50 ffffffffffffffff c000000000449269
GPR12: 0000000024002084 c000000000515980 0000000000000000 0000000000000000
GPR16: 0000000000000000 0000000000000000 0000000000240000 0000000000000000
GPR20: 0000000010000290 0000000000000002 c00000003ef3f970 c00000003ef3f970
GPR24: 0000000000000001 0000000000000000 c00000003c039958 c00000003c039918
GPR28: 0000000000000000 c00000003ef3fa60 c00000000058e588 c00000003e010198
NIP [c00000000021908c] .kref_get+0x10/0x2c
LR [c000000000217b88] .kobject_get+0x20/0x3c
[c00000003c067240] [c000000000217a48] .kobject_set_name_vargs+0x38/0x60 (unreliable)
[c00000003c0672c0] [c000000000217ffc] .kobject_add+0x88/0x20c
[c00000003c067350] [c00000000029b7ec] .device_add+0xd0/0x648
[c00000003c067410] [d000000000613c84] .scsi_alloc_target+0x238/0x414 [scsi_mod]
[c00000003c0674e0] [d000000000614e70] .__scsi_scan_target+0xac/0x718 [scsi_mod]
[c00000003c067630] [d00000000061566c] .scsi_scan_channel+0x78/0xdc [scsi_mod]
[c00000003c0676d0] [d0000000006157f0] .scsi_scan_host_selected+0x120/0x194 [scsi_mod]
[c00000003c067780] [d000000000682148] .ibmvscsi_probe+0x450/0x4fc [ibmvscsic]
[c00000003c067870] [c000000000025fe8] .vio_bus_probe+0x74/0x9c
[c00000003c067900] [c00000000029f2c8] .driver_probe_device+0x110/0x1ec
[c00000003c067990] [c00000000029f57c] .__driver_attach+0xd0/0x160
[c00000003c067a20] [c00000000029da58] .bus_for_each_dev+0x7c/0xcc
[c00000003c067ad0] [c00000000029f634] .driver_attach+0x28/0x40
[c00000003c067b50] [c00000000029e6a4] .bus_add_driver+0xe8/0x2b4
[c00000003c067c00] [c00000000029fd80] .driver_register+0x80/0x9c
[c00000003c067c80] [c0000000000260b0] .vio_register_driver+0x40/0x5c
[c00000003c067d10] [d000000000682c04] .init_module+0x68/0xa4 [ibmvscsic]
[c00000003c067da0] [c00000000009301c] .sys_init_module+0xf4/0x1ac
[c00000003c067e30] [c00000000000872c] syscall_exit+0x0/0x40
7d808120 4e800020 38a00000 4bfffad0 38000001 90030000 7c0004ac 4e800020
80030000 7c0007b4 2f800000 40be0008 <0fe00000> 7c001828 30000001 7c00192d
How about running 2.6.24-rc4 with _only_ the patch to this driver to
convert it to krefs? Does that combination cause problems?

The patch is at:
http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-01-driver/kobject-convert-hvcs-to-use-kref-not-kobject.patch

and you can also try:
http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-01-driver/kobject-convert-hvc_console-to-use-kref-not-kobject.patch
if you have the hardware.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Balbir Singh
2007-12-07 22:10:07 UTC
Permalink
Post by Greg KH
How about running 2.6.24-rc4 with _only_ the patch to this driver to
convert it to krefs? Does that combination cause problems?
http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-01-driver/kobject-convert-hvcs-to-use-kref-not-kobject.patch
This patch works fine with _changes_ on 2.6.24-rc4. I can confirm that
it's not a kref problem in that case. This patch still assumes that
kref_get() returns a value. This is no longer true. The kref_get() call
site needs to be changed.
--
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Greg KH
2007-12-06 20:00:24 UTC
Permalink
Post by Balbir Singh
Post by Kamalesh Babulal
Hi Andrew,
The 2.6.24-rc4-mm1 kernel build fails with build failure,
CC drivers/char/hvcs.o
drivers/char/hvcs.c:1180: error: wrong type argument to unary exclamation mark
make[2]: *** [drivers/char/hvcs.o] Error 1
make[1]: *** [drivers/char] Error 2
make: *** [drivers] Error 2
The kref_get begin void return type, check for the kobject return type
as in the previous kobject_get()
if (!kref_get(&hvcsd->kref)) {
spin_unlock_irqrestore(&hvcsd->lock, flags);
printk(KERN_ERR "HVCS: Kobject of open"
" hvcs doesn't exist.\n");
return -EFAULT; /* Is this the right return value? */
}
I have tested for the build failure only.
--
--- linux-2.6.24-rc4/drivers/char/hvcs.c 2007-12-05 12:17:37.000000000 +0530
+++ linux-2.6.24-rc4/drivers/char/~hvcs.c 2007-12-05 19:17:12.000000000 +0530
hvcsd = tty->driver_data;
spin_lock_irqsave(&hvcsd->lock, flags);
- if (!kref_get(&hvcsd->kref)) {
- spin_unlock_irqrestore(&hvcsd->lock, flags);
- printk(KERN_ERR "HVCS: Kobject of open"
- " hvcs doesn't exist.\n");
- return -EFAULT; /* Is this the right return value? */
- }
+ kref_get(&hvcsd->kref);
+ spin_unlock_irqrestore(&hvcsd->lock, flags);
Why release the spinlock here? It's done after the count is incremented.
This patch does not seem correct.
Doh, you are correct, I'll make sure that I fix this up before applying
it.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Alexey Dobriyan
2007-12-05 23:50:10 UTC
Permalink
Post by Andrew Morton
git-scsi-misc.patch
Apologies for not looking into the problem earlier. See
http://marc.info/?t=119628022300005&r=1&w=2
"2.6.24-rc3-mm2: Result: hostbyte=0x01 driverbyte=0x00\nend_request: I/O error"
for previous installment.

I've bisected it to the following patch in git-scsi-misc branch.
Revert on top of 2.6.24-rc4-mm1 also helps.

commit 8655a546c83fc43f0a73416bbd126d02de7ad6c0
Author: Hannes Reinecke <***@suse.de>
Date: Tue Nov 6 09:23:40 2007 +0100

[SCSI] Do not requeue requests if REQ_FAILFAST is set

Any requests with the REQ_FAILFAST flag set should not be requeued
to the requeust queue, but rather terminated directly.
Otherwise the multipath failover will stall until the command
timeout triggers.

Signed-off-by: Hannes Reinecke <***@suse.de>
Signed-off-by: James Bottomley <***@HansenPartnership.com>

diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 0f44bdb..0da0dd0 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -1286,6 +1286,11 @@ int scsi_prep_state_check(struct scsi_device *sdev, struct request *req)
*/
if (!(req->cmd_flags & REQ_PREEMPT))
ret = BLKPREP_DEFER;
+ /*
+ * Return failfast requests immediately
+ */
+ if (req->cmd_flags & REQ_FAILFAST)
+ ret = BLKPREP_KILL;
break;
default:
/*
@@ -1414,6 +1419,17 @@ static inline int scsi_host_queue_ready(struct request_queue *q,
return 1;
}

+static void __scsi_kill_request(struct request *req)
+{
+ struct scsi_cmnd *cmd = req->special;
+ struct scsi_device *sdev = cmd->device;
+
+ cmd->result = DID_NO_CONNECT << 16;
+ atomic_inc(&cmd->device->iorequest_cnt);
+ sdev->device_busy--;
+ __scsi_done(cmd);
+}
+
/*
* Kill a request for a dead device
*/
@@ -1527,8 +1543,16 @@ static void scsi_request_fn(struct request_queue *q)
* accept it.
*/
req = elv_next_request(q);
- if (!req || !scsi_dev_queue_ready(q, sdev))
+ if (!req)
+ break;
+
+ if (!scsi_dev_queue_ready(q, sdev)) {
+ if (req->cmd_flags & REQ_FAILFAST) {
+ scsi_kill_request(req, q);
+ continue;
+ }
break;
+ }

if (unlikely(!scsi_device_online(sdev))) {
sdev_printk(KERN_ERR, sdev,
@@ -1609,8 +1633,12 @@ static void scsi_request_fn(struct request_queue *q)
* later time.
*/
spin_lock_irq(q->queue_lock);
- blk_requeue_request(q, req);
- sdev->device_busy--;
+ if (unlikely(req->cmd_flags & REQ_FAILFAST))
+ __scsi_kill_request(req);
+ else {
+ blk_requeue_request(q, req);
+ sdev->device_busy--;
+ }
if(sdev->device_busy == 0)
blk_plug_device(q);
out:
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Hannes Reinecke
2007-12-06 08:00:13 UTC
Permalink
Post by Alexey Dobriyan
Post by Andrew Morton
git-scsi-misc.patch
Apologies for not looking into the problem earlier. See
http://marc.info/?t=119628022300005&r=1&w=2
"2.6.24-rc3-mm2: Result: hostbyte=0x01 driverbyte=0x00\nend_request: I/O error"
for previous installment.
I've bisected it to the following patch in git-scsi-misc branch.
Revert on top of 2.6.24-rc4-mm1 also helps.
commit 8655a546c83fc43f0a73416bbd126d02de7ad6c0
Date: Tue Nov 6 09:23:40 2007 +0100
[SCSI] Do not requeue requests if REQ_FAILFAST is set
Any requests with the REQ_FAILFAST flag set should not be requeued
to the requeust queue, but rather terminated directly.
Otherwise the multipath failover will stall until the command
timeout triggers.
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 0f44bdb..0da0dd0 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -1286,6 +1286,11 @@ int scsi_prep_state_check(struct scsi_device *sdev, struct request *req)
*/
if (!(req->cmd_flags & REQ_PREEMPT))
ret = BLKPREP_DEFER;
+ /*
+ * Return failfast requests immediately
+ */
+ if (req->cmd_flags & REQ_FAILFAST)
+ ret = BLKPREP_KILL;
break;
/*
@@ -1414,6 +1419,17 @@ static inline int scsi_host_queue_ready(struct request_queue *q,
return 1;
}
+static void __scsi_kill_request(struct request *req)
+{
+ struct scsi_cmnd *cmd = req->special;
+ struct scsi_device *sdev = cmd->device;
+
+ cmd->result = DID_NO_CONNECT << 16;
+ atomic_inc(&cmd->device->iorequest_cnt);
+ sdev->device_busy--;
+ __scsi_done(cmd);
+}
+
/*
* Kill a request for a dead device
*/
@@ -1527,8 +1543,16 @@ static void scsi_request_fn(struct request_queue *q)
* accept it.
*/
req = elv_next_request(q);
- if (!req || !scsi_dev_queue_ready(q, sdev))
+ if (!req)
+ break;
+
+ if (!scsi_dev_queue_ready(q, sdev)) {
+ if (req->cmd_flags & REQ_FAILFAST) {
+ scsi_kill_request(req, q);
+ continue;
+ }
break;
+ }
if (unlikely(!scsi_device_online(sdev))) {
sdev_printk(KERN_ERR, sdev,
@@ -1609,8 +1633,12 @@ static void scsi_request_fn(struct request_queue *q)
* later time.
*/
spin_lock_irq(q->queue_lock);
- blk_requeue_request(q, req);
- sdev->device_busy--;
+ if (unlikely(req->cmd_flags & REQ_FAILFAST))
+ __scsi_kill_request(req);
+ else {
+ blk_requeue_request(q, req);
+ sdev->device_busy--;
+ }
if(sdev->device_busy == 0)
blk_plug_device(q);
Yeah, sorry. That patch was bad. Please use the attached one instead.
Andrew, can you replace them?

Cheers,

Hannes
--
Dr. Hannes Reinecke zSeries & Storage
***@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Markus Rex, HRB 16746 (AG Nürnberg)
Jens Axboe
2007-12-06 12:20:10 UTC
Permalink
Post by Hannes Reinecke
Post by Alexey Dobriyan
Post by Andrew Morton
git-scsi-misc.patch
Apologies for not looking into the problem earlier. See
http://marc.info/?t=119628022300005&r=1&w=2
"2.6.24-rc3-mm2: Result: hostbyte=0x01 driverbyte=0x00\nend_request: I/O error"
for previous installment.
I've bisected it to the following patch in git-scsi-misc branch.
Revert on top of 2.6.24-rc4-mm1 also helps.
commit 8655a546c83fc43f0a73416bbd126d02de7ad6c0
Date: Tue Nov 6 09:23:40 2007 +0100
[SCSI] Do not requeue requests if REQ_FAILFAST is set
Any requests with the REQ_FAILFAST flag set should not be requeued
to the requeust queue, but rather terminated directly.
Otherwise the multipath failover will stall until the command
timeout triggers.
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 0f44bdb..0da0dd0 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -1286,6 +1286,11 @@ int scsi_prep_state_check(struct scsi_device *sdev, struct request *req)
*/
if (!(req->cmd_flags & REQ_PREEMPT))
ret = BLKPREP_DEFER;
+ /*
+ * Return failfast requests immediately
+ */
+ if (req->cmd_flags & REQ_FAILFAST)
+ ret = BLKPREP_KILL;
break;
/*
@@ -1414,6 +1419,17 @@ static inline int scsi_host_queue_ready(struct request_queue *q,
return 1;
}
+static void __scsi_kill_request(struct request *req)
+{
+ struct scsi_cmnd *cmd = req->special;
+ struct scsi_device *sdev = cmd->device;
+
+ cmd->result = DID_NO_CONNECT << 16;
+ atomic_inc(&cmd->device->iorequest_cnt);
+ sdev->device_busy--;
+ __scsi_done(cmd);
+}
+
/*
* Kill a request for a dead device
*/
@@ -1527,8 +1543,16 @@ static void scsi_request_fn(struct request_queue *q)
* accept it.
*/
req = elv_next_request(q);
- if (!req || !scsi_dev_queue_ready(q, sdev))
+ if (!req)
+ break;
+
+ if (!scsi_dev_queue_ready(q, sdev)) {
+ if (req->cmd_flags & REQ_FAILFAST) {
+ scsi_kill_request(req, q);
+ continue;
+ }
break;
+ }
if (unlikely(!scsi_device_online(sdev))) {
sdev_printk(KERN_ERR, sdev,
@@ -1609,8 +1633,12 @@ static void scsi_request_fn(struct request_queue *q)
* later time.
*/
spin_lock_irq(q->queue_lock);
- blk_requeue_request(q, req);
- sdev->device_busy--;
+ if (unlikely(req->cmd_flags & REQ_FAILFAST))
+ __scsi_kill_request(req);
+ else {
+ blk_requeue_request(q, req);
+ sdev->device_busy--;
+ }
if(sdev->device_busy == 0)
blk_plug_device(q);
Yeah, sorry. That patch was bad. Please use the attached one instead.
Andrew, can you replace them?
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Markus Rex, HRB 16746 (AG Nürnberg)
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 13e7e09..9ec1566 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -1284,13 +1284,15 @@ int scsi_prep_state_check(struct scsi_device *sdev, struct request *req)
/*
* If the devices is blocked we defer normal commands.
*/
- if (!(req->cmd_flags & REQ_PREEMPT))
- ret = BLKPREP_DEFER;
- /*
- * Return failfast requests immediately
- */
- if (req->cmd_flags & REQ_FAILFAST)
- ret = BLKPREP_KILL;
+ if (!(req->cmd_flags & REQ_PREEMPT)) {
+ /*
+ * Return failfast requests immediately
+ */
+ if (req->cmd_flags & REQ_FAILFAST)
+ ret = BLKPREP_KILL;
+ else
+ ret = BLKPREP_DEFER;
+ }
break;
/*
can we please stick to using blk_noretry_request() consistently, instead
of thwrowing REQ_FAILFAST tests in there?
--
Jens Axboe

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Alexey Dobriyan
2007-12-06 19:30:21 UTC
Permalink
Post by Hannes Reinecke
Post by Alexey Dobriyan
Post by Andrew Morton
git-scsi-misc.patch
Apologies for not looking into the problem earlier. See
http://marc.info/?t=119628022300005&r=1&w=2
"2.6.24-rc3-mm2: Result: hostbyte=0x01 driverbyte=0x00\nend_request: I/O error"
for previous installment.
I've bisected it to the following patch in git-scsi-misc branch.
Revert on top of 2.6.24-rc4-mm1 also helps.
commit 8655a546c83fc43f0a73416bbd126d02de7ad6c0
Date: Tue Nov 6 09:23:40 2007 +0100
[SCSI] Do not requeue requests if REQ_FAILFAST is set
Any requests with the REQ_FAILFAST flag set should not be requeued
to the requeust queue, but rather terminated directly.
Otherwise the multipath failover will stall until the command
timeout triggers.
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 0f44bdb..0da0dd0 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -1286,6 +1286,11 @@ int scsi_prep_state_check(struct scsi_device *sdev, struct request *req)
*/
if (!(req->cmd_flags & REQ_PREEMPT))
ret = BLKPREP_DEFER;
+ /*
+ * Return failfast requests immediately
+ */
+ if (req->cmd_flags & REQ_FAILFAST)
+ ret = BLKPREP_KILL;
break;
/*
@@ -1414,6 +1419,17 @@ static inline int scsi_host_queue_ready(struct request_queue *q,
return 1;
}
+static void __scsi_kill_request(struct request *req)
+{
+ struct scsi_cmnd *cmd = req->special;
+ struct scsi_device *sdev = cmd->device;
+
+ cmd->result = DID_NO_CONNECT << 16;
+ atomic_inc(&cmd->device->iorequest_cnt);
+ sdev->device_busy--;
+ __scsi_done(cmd);
+}
+
/*
* Kill a request for a dead device
*/
@@ -1527,8 +1543,16 @@ static void scsi_request_fn(struct request_queue *q)
* accept it.
*/
req = elv_next_request(q);
- if (!req || !scsi_dev_queue_ready(q, sdev))
+ if (!req)
+ break;
+
+ if (!scsi_dev_queue_ready(q, sdev)) {
+ if (req->cmd_flags & REQ_FAILFAST) {
+ scsi_kill_request(req, q);
+ continue;
+ }
break;
+ }
if (unlikely(!scsi_device_online(sdev))) {
sdev_printk(KERN_ERR, sdev,
@@ -1609,8 +1633,12 @@ static void scsi_request_fn(struct request_queue *q)
* later time.
*/
spin_lock_irq(q->queue_lock);
- blk_requeue_request(q, req);
- sdev->device_busy--;
+ if (unlikely(req->cmd_flags & REQ_FAILFAST))
+ __scsi_kill_request(req);
+ else {
+ blk_requeue_request(q, req);
+ sdev->device_busy--;
+ }
if(sdev->device_busy == 0)
blk_plug_device(q);
Yeah, sorry. That patch was bad. Please use the attached one instead.
Andrew, can you replace them?
Instead? It won't apply. And it doesn't help on top of git-scsi.
It helps if 3 hunks involving __scsi_kill_request() are ducked.
Post by Hannes Reinecke
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -1284,13 +1284,15 @@ int scsi_prep_state_check(struct scsi_device *sdev, struct request *req)
/*
* If the devices is blocked we defer normal commands.
*/
- if (!(req->cmd_flags & REQ_PREEMPT))
- ret = BLKPREP_DEFER;
- /*
- * Return failfast requests immediately
- */
- if (req->cmd_flags & REQ_FAILFAST)
- ret = BLKPREP_KILL;
+ if (!(req->cmd_flags & REQ_PREEMPT)) {
+ /*
+ * Return failfast requests immediately
+ */
+ if (req->cmd_flags & REQ_FAILFAST)
+ ret = BLKPREP_KILL;
+ else
+ ret = BLKPREP_DEFER;
+ }
break;
/*
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Kamalesh Babulal
2007-12-06 03:20:06 UTC
Permalink
Hi Andrew,

The 2.6.24-rc4-mm1 kernel build fails on s390x,

CC arch/s390/kernel/traps.o
In file included from include/asm/thread_info.h:39,
from include/linux/thread_info.h:21,
from include/linux/preempt.h:9,
from include/linux/spinlock.h:49,
from include/linux/seqlock.h:29,
from include/linux/time.h:8,
from include/linux/timex.h:57,
from include/linux/sched.h:53,
from arch/s390/kernel/traps.c:17:
include/asm/processor.h:191: warning: "struct seq_file" declared inside parameter list
include/asm/processor.h:191: warning: its scope is only this definition or declaration, which is probably not what you want
arch/s390/kernel/traps.c: In function `task_show_regs':
arch/s390/kernel/traps.c:226: error: implicit declaration of function `seq_printf'
make[1]: *** [arch/s390/kernel/traps.o] Error 1
make: *** [arch/s390/kernel] Error 2
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Andrew Morton
2007-12-06 07:20:08 UTC
Permalink
Post by Kamalesh Babulal
Hi Andrew,
The 2.6.24-rc4-mm1 kernel build fails on s390x,
CC arch/s390/kernel/traps.o
In file included from include/asm/thread_info.h:39,
from include/linux/thread_info.h:21,
from include/linux/preempt.h:9,
from include/linux/spinlock.h:49,
from include/linux/seqlock.h:29,
from include/linux/time.h:8,
from include/linux/timex.h:57,
from include/linux/sched.h:53,
include/asm/processor.h:191: warning: "struct seq_file" declared inside parameter list
include/asm/processor.h:191: warning: its scope is only this definition or declaration, which is probably not what you want
arch/s390/kernel/traps.c:226: error: implicit declaration of function `seq_printf'
make[1]: *** [arch/s390/kernel/traps.o] Error 1
make: *** [arch/s390/kernel] Error 2
thanks.

--- a/arch/s390/kernel/traps.c~proc-seqfile-convert-proc_pid_status-to-properly-handle-pid-namespaces-fix-2
+++ a/arch/s390/kernel/traps.c
@@ -24,6 +24,7 @@
#include <linux/smp.h>
#include <linux/init.h>
#include <linux/interrupt.h>
+#include <linux/seq_file.h>
#include <linux/delay.h>
#include <linux/module.h>
#include <linux/kdebug.h>
diff -puN include/asm-s390/processor.h~proc-seqfile-convert-proc_pid_status-to-properly-handle-pid-namespaces-fix-2 include/asm-s390/processor.h
--- a/include/asm-s390/processor.h~proc-seqfile-convert-proc_pid_status-to-properly-handle-pid-namespaces-fix-2
+++ a/include/asm-s390/processor.h
@@ -165,6 +165,7 @@ struct stack_frame {
/* Forward declaration, a strange C thing */
struct task_struct;
struct mm_struct;
+struct seq_file;

/* Free all resources held by a thread. */
extern void release_thread(struct task_struct *);
_


Unfortunately the current greg-versus-git-s390 snafu means that I'm not
cross-building s390.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Reuben Farrelly
2007-12-06 07:10:08 UTC
Permalink
Post by Andrew Morton
Temporarily at
http://userweb.kernel.org/~akpm/2.6.24-rc4-mm1/
Will appear later at
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc4/2.6.24-rc4-mm1/
- Lots of device IDs have been removed from the e1000 driver and moved over
to e1000e. So if your e1000 stops working, you forgot to set CONFIG_E1000E.
This non fatal oops which I have just noticed may be related to this change then
- certainly looks networking related.

WARNING: at net/ipv4/tcp_input.c:2518 tcp_fastretrans_alert()
Pid: 0, comm: swapper Not tainted 2.6.24-rc4-mm1 #1

Call Trace:
<IRQ> [<ffffffff8046e038>] tcp_fastretrans_alert+0x229/0xe63
[<ffffffff80470975>] tcp_ack+0xa3f/0x127d
[<ffffffff804747b7>] tcp_rcv_established+0x55f/0x7f8
[<ffffffff8047b1aa>] tcp_v4_do_rcv+0xdb/0x3a7
[<ffffffff881148a8>] :nf_conntrack:nf_ct_deliver_cached_events+0x75/0x99
[<ffffffff88120179>] :nf_conntrack_ipv4:ipv4_confirm+0x29/0x51
[<ffffffff8047db71>] tcp_v4_rcv+0x9be/0xaed
[<ffffffff80455eaa>] nf_hook_slow+0x60/0xdf
[<ffffffff8045db6b>] ip_local_deliver_finish+0xd3/0x253
[<ffffffff8045e146>] ip_local_deliver+0x3b/0x85
[<ffffffff8045d7f9>] ip_rcv_finish+0x119/0x3b8
[<ffffffff8045e030>] ip_rcv+0x231/0x30c
[<ffffffff8043ef39>] netif_receive_skb+0x215/0x299
[<ffffffff880b82b9>] :e1000e:e1000_receive_skb+0x4d/0x1db
[<ffffffff880bc200>] :e1000e:e1000_clean_rx_irq+0x12c/0x341
[<ffffffff880ba31a>] :e1000e:e1000_clean+0x306/0x58f
[<ffffffff8022a16a>] rebalance_domains+0xec/0x423
[<ffffffff80261332>] handle_edge_irq+0x97/0x13b
[<ffffffff804412d3>] net_rx_action+0xb8/0x11d
[<ffffffff802344f8>] __do_softirq+0x71/0xdd
[<ffffffff8020c8fc>] call_softirq+0x1c/0x30
[<ffffffff8020e7a5>] do_softirq+0x3d/0x8d
[<ffffffff80234485>] irq_exit+0x84/0x86
[<ffffffff8020e89e>] do_IRQ+0x7e/0xe4
[<ffffffff8020a908>] mwait_idle+0x0/0x58
[<ffffffff8020a7f1>] default_idle+0x0/0x43
[<ffffffff8020bc81>] ret_from_intr+0x0/0xa
<EOI> [<ffffffff8020a950>] mwait_idle+0x48/0x58
[<ffffffff80209f23>] enter_idle+0x22/0x24
[<ffffffff8020a897>] cpu_idle+0x63/0x88
[<ffffffff804ada75>] rest_init+0x55/0x60
[<ffffffff80627b9a>] start_kernel+0x2a4/0x32a
[<ffffffff8062710b>] _sinittext+0x10b/0x120

tornado home #

I have posted a full dmesg up as well as my .config and an lcpci at
http://www.reub.net/files/kernel/2.6.24-rc4-mm1/ .

Thanks,
Reuben
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
David Miller
2007-12-06 07:20:06 UTC
Permalink
From: Reuben Farrelly <reuben-***@reub.net>
Date: Thu, 06 Dec 2007 17:59:37 +1100
Post by Reuben Farrelly
Post by Andrew Morton
- Lots of device IDs have been removed from the e1000 driver and moved over
to e1000e. So if your e1000 stops working, you forgot to set CONFIG_E1000E.
This non fatal oops which I have just noticed may be related to this change then
- certainly looks networking related.
WARNING: at net/ipv4/tcp_input.c:2518 tcp_fastretrans_alert()
Pid: 0, comm: swapper Not tainted 2.6.24-rc4-mm1 #1
<IRQ> [<ffffffff8046e038>] tcp_fastretrans_alert+0x229/0xe63
[<ffffffff80470975>] tcp_ack+0xa3f/0x127d
[<ffffffff804747b7>] tcp_rcv_established+0x55f/0x7f8
[<ffffffff8047b1aa>] tcp_v4_do_rcv+0xdb/0x3a7
[<ffffffff881148a8>] :nf_conntrack:nf_ct_deliver_cached_events+0x75/0x99
No, it's from TCP assertions and changes added by Ilpo to the
net-2.6.25 tree recently.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Ilpo Järvinen
2007-12-07 13:20:06 UTC
Permalink
Post by David Miller
Date: Thu, 06 Dec 2007 17:59:37 +1100
Post by Reuben Farrelly
Post by Andrew Morton
- Lots of device IDs have been removed from the e1000 driver and moved over
to e1000e. So if your e1000 stops working, you forgot to set CONFIG_E1000E.
This non fatal oops which I have just noticed may be related to this change then
- certainly looks networking related.
WARNING: at net/ipv4/tcp_input.c:2518 tcp_fastretrans_alert()
Pid: 0, comm: swapper Not tainted 2.6.24-rc4-mm1 #1
<IRQ> [<ffffffff8046e038>] tcp_fastretrans_alert+0x229/0xe63
[<ffffffff80470975>] tcp_ack+0xa3f/0x127d
[<ffffffff804747b7>] tcp_rcv_established+0x55f/0x7f8
[<ffffffff8047b1aa>] tcp_v4_do_rcv+0xdb/0x3a7
[<ffffffff881148a8>] :nf_conntrack:nf_ct_deliver_cached_events+0x75/0x99
No, it's from TCP assertions and changes added by Ilpo to the
net-2.6.25 tree recently.
Yeah, this (very likely) due to the new SACK processing (in net-2.6.25).
I'll look what could go wrong with fack_count calculations, most likely
it's the reason (I've found earlier one out-of-place retransmission
segment in one of my test case which already indicated that there's
something incorrect with them but didn't have time to debug it yet).

Thanks for report. Some info about how easily you can reproduce &
couple of sentences about the test case might be useful later on when
evaluating the fix.
--
i.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Andrew Morton
2007-12-06 07:40:08 UTC
Permalink
Post by Reuben Farrelly
Post by Andrew Morton
Temporarily at
http://userweb.kernel.org/~akpm/2.6.24-rc4-mm1/
Will appear later at
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc4/2.6.24-rc4-mm1/
- Lots of device IDs have been removed from the e1000 driver and moved over
to e1000e. So if your e1000 stops working, you forgot to set CONFIG_E1000E.
This non fatal oops which I have just noticed may be related to this change then
- certainly looks networking related.
yep, but it isn't e1000. It's core TCP.
Post by Reuben Farrelly
WARNING: at net/ipv4/tcp_input.c:2518 tcp_fastretrans_alert()
Pid: 0, comm: swapper Not tainted 2.6.24-rc4-mm1 #1
<IRQ> [<ffffffff8046e038>] tcp_fastretrans_alert+0x229/0xe63
[<ffffffff80470975>] tcp_ack+0xa3f/0x127d
[<ffffffff804747b7>] tcp_rcv_established+0x55f/0x7f8
[<ffffffff8047b1aa>] tcp_v4_do_rcv+0xdb/0x3a7
[<ffffffff881148a8>] :nf_conntrack:nf_ct_deliver_cached_events+0x75/0x99
[<ffffffff88120179>] :nf_conntrack_ipv4:ipv4_confirm+0x29/0x51
[<ffffffff8047db71>] tcp_v4_rcv+0x9be/0xaed
[<ffffffff80455eaa>] nf_hook_slow+0x60/0xdf
[<ffffffff8045db6b>] ip_local_deliver_finish+0xd3/0x253
[<ffffffff8045e146>] ip_local_deliver+0x3b/0x85
[<ffffffff8045d7f9>] ip_rcv_finish+0x119/0x3b8
[<ffffffff8045e030>] ip_rcv+0x231/0x30c
[<ffffffff8043ef39>] netif_receive_skb+0x215/0x299
[<ffffffff880b82b9>] :e1000e:e1000_receive_skb+0x4d/0x1db
[<ffffffff880bc200>] :e1000e:e1000_clean_rx_irq+0x12c/0x341
[<ffffffff880ba31a>] :e1000e:e1000_clean+0x306/0x58f
[<ffffffff8022a16a>] rebalance_domains+0xec/0x423
[<ffffffff80261332>] handle_edge_irq+0x97/0x13b
[<ffffffff804412d3>] net_rx_action+0xb8/0x11d
[<ffffffff802344f8>] __do_softirq+0x71/0xdd
[<ffffffff8020c8fc>] call_softirq+0x1c/0x30
[<ffffffff8020e7a5>] do_softirq+0x3d/0x8d
[<ffffffff80234485>] irq_exit+0x84/0x86
[<ffffffff8020e89e>] do_IRQ+0x7e/0xe4
[<ffffffff8020a908>] mwait_idle+0x0/0x58
[<ffffffff8020a7f1>] default_idle+0x0/0x43
[<ffffffff8020bc81>] ret_from_intr+0x0/0xa
<EOI> [<ffffffff8020a950>] mwait_idle+0x48/0x58
[<ffffffff80209f23>] enter_idle+0x22/0x24
[<ffffffff8020a897>] cpu_idle+0x63/0x88
[<ffffffff804ada75>] rest_init+0x55/0x60
[<ffffffff80627b9a>] start_kernel+0x2a4/0x32a
[<ffffffff8062710b>] _sinittext+0x10b/0x120
tornado home #
I have posted a full dmesg up as well as my .config and an lcpci at
http://www.reub.net/files/kernel/2.6.24-rc4-mm1/ .
Ilpo, Reuben's kernel is talking to you ;)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Ilpo Järvinen
2007-12-10 12:30:25 UTC
Permalink
Post by Andrew Morton
Post by Reuben Farrelly
This non fatal oops which I have just noticed may be related to this change then
- certainly looks networking related.
yep, but it isn't e1000. It's core TCP.
Post by Reuben Farrelly
WARNING: at net/ipv4/tcp_input.c:2518 tcp_fastretrans_alert()
Pid: 0, comm: swapper Not tainted 2.6.24-rc4-mm1 #1
Ilpo, Reuben's kernel is talking to you ;)
...Please try the patch below. Andrew, this probably fixes your problem
(the packets <= tp->packets_out) as well.

Dave, please include this one to net-2.6.25.
--
i.

--
[PATCH] [TCP]: Fix fack_count miscountings (multiple places)

1) Fack_count is set incorrectly if the highest sent skb is
already sacked (the skb->prev won't return it because it's on
the other list already). These manifest as fackets_out counting
error later on, the second-order effects are very hard to track,
so it may fix all out-standing TCP bug reports.

2) Prev == NULL check was wrong way around

3) Last skb's fack count was incorrectly skipped while() {} loop

Signed-off-by: Ilpo Järvinen <***@helsinki.fi>
---
include/net/tcp.h | 22 ++++++++++++++++------
1 files changed, 16 insertions(+), 6 deletions(-)

diff --git a/include/net/tcp.h b/include/net/tcp.h
index 9dbed0b..11a7e3e 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -1337,10 +1337,20 @@ static inline struct sk_buff *tcp_send_head(struct sock *sk)
static inline void tcp_advance_send_head(struct sock *sk, struct sk_buff *skb)
{
struct sk_buff *prev = tcp_write_queue_prev(sk, skb);
+ unsigned int fc = 0;
+
+ if (prev == (struct sk_buff *)&sk->sk_write_queue)
+ prev = NULL;
+ else if (!tcp_skb_adjacent(sk, prev, skb))
+ prev = NULL;

- if (prev != (struct sk_buff *)&sk->sk_write_queue)
- TCP_SKB_CB(skb)->fack_count = TCP_SKB_CB(prev)->fack_count +
- tcp_skb_pcount(prev);
+ if ((prev == NULL) && !__tcp_write_queue_empty(sk, TCP_WQ_SACKED))
+ prev = __tcp_write_queue_tail(sk, TCP_WQ_SACKED);
+
+ if (prev != NULL)
+ fc = TCP_SKB_CB(prev)->fack_count + tcp_skb_pcount(prev);
+
+ TCP_SKB_CB(skb)->fack_count = fc;

sk->sk_send_head = tcp_write_queue_next(sk, skb);
if (sk->sk_send_head == (struct sk_buff *)&sk->sk_write_queue)
@@ -1464,7 +1474,7 @@ static inline struct sk_buff *__tcp_reset_fack_counts(struct sock *sk,
{
unsigned int fc = 0;

- if (prev == NULL)
+ if (prev != NULL)
fc = TCP_SKB_CB(*prev)->fack_count + tcp_skb_pcount(*prev);

BUG_ON((*prev != NULL) && !tcp_skb_adjacent(sk, *prev, skb));
@@ -1521,7 +1531,7 @@ static inline void tcp_reset_fack_counts(struct sock *sk, struct sk_buff *inskb)
skb[otherq] = prev->next;
}

- while (skb[queue] != __tcp_write_queue_tail(sk, queue)) {
+ do {
/* Lazy find for the other queue */
if (skb[queue] == NULL) {
skb[queue] = tcp_write_queue_find(sk, TCP_SKB_CB(prev)->seq,
@@ -1535,7 +1545,7 @@ static inline void tcp_reset_fack_counts(struct sock *sk, struct sk_buff *inskb)
break;

queue ^= TCP_WQ_SACKED;
- }
+ } while (skb[queue] != __tcp_write_queue_tail(sk, queue));
}

static inline void __tcp_insert_write_queue_after(struct sk_buff *skb,
--
1.5.0.6
Ilpo Järvinen
2007-12-10 20:10:13 UTC
Permalink
Post by Ilpo Järvinen
Dave, please include this one to net-2.6.25.
...
Post by Ilpo Järvinen
--
[PATCH] [TCP]: Fix fack_count miscountings (multiple places)
I've better version of this coming up, so Dave please don't put this one
into net-2.6.25 (noticed that both the original and the after patch code
can get to an infinite loop and the new code is flawed in some rare cases
still as well). I'll submit a better version soon.
--
i.
V***@vt.edu
2007-12-06 12:00:19 UTC
Permalink
Post by Andrew Morton
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc4/2.6.24-rc4-mm1/
Something in here broke LVM support - an initrd that has worked fine for
quite some time suddenly couldn't mount /dev/VolGroup00/root so we get the
infamous "Kernel panic - not syncing: Attempted to kill init!" when we
fall off the end of the initrd and haven't pivoted to the real disk.

It finds the disk OK:

[ 81.202310] sd 0:0:0:0: [sda] 156301488 512-byte hardware sectors (80026 MB)
[ 81.214466] sd 0:0:0:0: [sda] Write Protect is off
[ 81.226467] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 81.238436] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 81.250780] sda: sda1 sda2
[ 75.396119] sd 0:0:0:0: [sda] Attached SCSI disk

but then the lvm command says it can't find the volume group VolGroup00 (which
is actually sda2 - sda1 is a small /boot partition, rest of disk is LVM).

A quick look at the rc4-mm1 announcement doesn't have any obviously tempting
patch names to start at, so it looks like it's time to play mm-bisect. It may
take me a day or two, as I have some time management issues this week...
Andrew Morton
2007-12-06 12:10:14 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.24-rc4/2.6.24-rc4-mm1/
Something in here broke LVM support - an initrd that has worked fine for
quite some time suddenly couldn't mount /dev/VolGroup00/root so we get the
infamous "Kernel panic - not syncing: Attempted to kill init!" when we
fall off the end of the initrd and haven't pivoted to the real disk.
[ 81.202310] sd 0:0:0:0: [sda] 156301488 512-byte hardware sectors (80026 MB)
[ 81.214466] sd 0:0:0:0: [sda] Write Protect is off
[ 81.226467] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 81.238436] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 81.250780] sda: sda1 sda2
[ 75.396119] sd 0:0:0:0: [sda] Attached SCSI disk
but then the lvm command says it can't find the volume group VolGroup00 (which
is actually sda2 - sda1 is a small /boot partition, rest of disk is LVM).
A quick look at the rc4-mm1 announcement doesn't have any obviously tempting
patch names to start at, so it looks like it's time to play mm-bisect. It may
take me a day or two, as I have some time management issues this week...
OK, thanks.

First step would be to eliminate rewrite-rd.patch: maybe the ramdisk driver
in which that initrd resides is bust.

After that, agk-dm-dm-*.patch are of course the ones to look at.

Please keep dm-***@redhat.com cc'ed.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
V***@vt.edu
2007-12-06 19:20:11 UTC
Permalink
Post by Andrew Morton
Post by V***@vt.edu
Post by Andrew Morton
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc4/2.6.24-rc4-mm1/
Something in here broke LVM support - an initrd that has worked fine for
quite some time suddenly couldn't mount /dev/VolGroup00/root so we get the
infamous "Kernel panic - not syncing: Attempted to kill init!" when we
fall off the end of the initrd and haven't pivoted to the real disk.
[ 81.202310] sd 0:0:0:0: [sda] 156301488 512-byte hardware sectors (80026 MB)
[ 81.214466] sd 0:0:0:0: [sda] Write Protect is off
[ 81.226467] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 81.238436] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 81.250780] sda: sda1 sda2
[ 75.396119] sd 0:0:0:0: [sda] Attached SCSI disk
but then the lvm command says it can't find the volume group VolGroup00 (which
is actually sda2 - sda1 is a small /boot partition, rest of disk is LVM).
A quick look at the rc4-mm1 announcement doesn't have any obviously tempting
patch names to start at, so it looks like it's time to play mm-bisect. It may
take me a day or two, as I have some time management issues this week...
OK, thanks.
First step would be to eliminate rewrite-rd.patch: maybe the ramdisk driver
in which that initrd resides is bust.
After that, agk-dm-dm-*.patch are of course the ones to look at.
How did I not notice them? Yeah, those guys would be on the suspicious list...
I've gotten it down to about 128 patches, but it's interesting what ended
up bracketed by GOOD/BAD:

powerpc-invalid-size-for-swapper_pg_dir-with-config_pte_64bit=y.patch GOOD
#GREGKH-DRIVER-START
gregkh-driver-nozomi.patch
gregkh-moby-patch-tree....
unbork-gregkh-driver-kset-convert-sys-devices-to-use-kset_create-vioc.patch BAD

Would I be remiss in hypothesising that something in gregkh-driver-kobject-*
changed something, and now we need a agk-dm-dm-kobject-fixupage.patch?

The actual bug is probably elsewhere, but it *manifests* due to gregkh-driver
tree. Will probably be tomorrow before I get it down further...
Greg KH
2007-12-06 19:40:17 UTC
Permalink
Post by V***@vt.edu
Post by Andrew Morton
Post by V***@vt.edu
Post by Andrew Morton
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc4/2.6.24-rc4-mm1/
Something in here broke LVM support - an initrd that has worked fine for
quite some time suddenly couldn't mount /dev/VolGroup00/root so we get the
infamous "Kernel panic - not syncing: Attempted to kill init!" when we
fall off the end of the initrd and haven't pivoted to the real disk.
[ 81.202310] sd 0:0:0:0: [sda] 156301488 512-byte hardware sectors (80026 MB)
[ 81.214466] sd 0:0:0:0: [sda] Write Protect is off
[ 81.226467] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 81.238436] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 81.250780] sda: sda1 sda2
[ 75.396119] sd 0:0:0:0: [sda] Attached SCSI disk
but then the lvm command says it can't find the volume group VolGroup00 (which
is actually sda2 - sda1 is a small /boot partition, rest of disk is LVM).
A quick look at the rc4-mm1 announcement doesn't have any obviously tempting
patch names to start at, so it looks like it's time to play mm-bisect. It may
take me a day or two, as I have some time management issues this week...
OK, thanks.
First step would be to eliminate rewrite-rd.patch: maybe the ramdisk driver
in which that initrd resides is bust.
After that, agk-dm-dm-*.patch are of course the ones to look at.
How did I not notice them? Yeah, those guys would be on the suspicious list...
I've gotten it down to about 128 patches, but it's interesting what ended
powerpc-invalid-size-for-swapper_pg_dir-with-config_pte_64bit=y.patch GOOD
#GREGKH-DRIVER-START
gregkh-driver-nozomi.patch
gregkh-moby-patch-tree....
unbork-gregkh-driver-kset-convert-sys-devices-to-use-kset_create-vioc.patch BAD
Would I be remiss in hypothesising that something in gregkh-driver-kobject-*
changed something, and now we need a agk-dm-dm-kobject-fixupage.patch?
I don't know, it all depends on what is in the dm patches. Hopefully
everything that I have changed will manifest with a build breakage to
obviously detect that something needs to be fixed up.

But I've been known to mess things up that I didn't intend to :)

If there's anything that I can do to test this, please let me know.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
V***@vt.edu
2007-12-06 20:10:15 UTC
Permalink
Post by Greg KH
Post by V***@vt.edu
Would I be remiss in hypothesising that something in gregkh-driver-kobject-*
changed something, and now we need a agk-dm-dm-kobject-fixupage.patch?
I don't know, it all depends on what is in the dm patches. Hopefully
everything that I have changed will manifest with a build breakage to
obviously detect that something needs to be fixed up.
But I've been known to mess things up that I didn't intend to :)
Given that it *didn't* totally break the build, it's likely a fencepost error
or some similar issue...
Post by Greg KH
If there's anything that I can do to test this, please let me know.
I wanted to give a heads-up, in case there was a D'Oh! patch hiding. At worst,
I just need another 6 or 7 bisects to figure out which of those 120-ish patches
is the culprit. With luck I'll end up stopped on a patch that in retrospect
was obviously busticated. If not, we'll have to apply the usual more drastic
measures. If you don't have a box that's already demonstrating it, and you
don't have any obvious candidates, it's likely that the most productive
use of everybody's time is for you to chase down any other kobject issues
while I bisect the problem down further...
Kay Sievers
2007-12-06 22:10:11 UTC
Permalink
Post by Greg KH
Post by V***@vt.edu
Post by Andrew Morton
Post by V***@vt.edu
Post by Andrew Morton
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc4/2.6.24-rc4-mm1/
Something in here broke LVM support - an initrd that has worked fine for
quite some time suddenly couldn't mount /dev/VolGroup00/root so we get the
infamous "Kernel panic - not syncing: Attempted to kill init!" when we
fall off the end of the initrd and haven't pivoted to the real disk.
[ 81.202310] sd 0:0:0:0: [sda] 156301488 512-byte hardware sectors (80026 MB)
[ 81.214466] sd 0:0:0:0: [sda] Write Protect is off
[ 81.226467] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 81.238436] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 81.250780] sda: sda1 sda2
[ 75.396119] sd 0:0:0:0: [sda] Attached SCSI disk
but then the lvm command says it can't find the volume group VolGroup00 (which
is actually sda2 - sda1 is a small /boot partition, rest of disk is LVM).
A quick look at the rc4-mm1 announcement doesn't have any obviously tempting
patch names to start at, so it looks like it's time to play mm-bisect. It may
take me a day or two, as I have some time management issues this week...
OK, thanks.
First step would be to eliminate rewrite-rd.patch: maybe the ramdisk driver
in which that initrd resides is bust.
After that, agk-dm-dm-*.patch are of course the ones to look at.
How did I not notice them? Yeah, those guys would be on the suspicious list...
I've gotten it down to about 128 patches, but it's interesting what ended
powerpc-invalid-size-for-swapper_pg_dir-with-config_pte_64bit=y.patch GOOD
#GREGKH-DRIVER-START
gregkh-driver-nozomi.patch
gregkh-moby-patch-tree....
unbork-gregkh-driver-kset-convert-sys-devices-to-use-kset_create-vioc.patch BAD
Would I be remiss in hypothesising that something in gregkh-driver-kobject-*
changed something, and now we need a agk-dm-dm-kobject-fixupage.patch?
I don't know, it all depends on what is in the dm patches. Hopefully
everything that I have changed will manifest with a build breakage to
obviously detect that something needs to be fixed up.
But I've been known to mess things up that I didn't intend to :)
If there's anything that I can do to test this, please let me know.
What's the value of SYSFS_DEPRECATED? Care to set it to yes, if it isn't,
and try again?

A fix for LVM to handle symlinks instead of directories is in the LVM
CVS tree, but there wasn't a release since August.

Kay
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Alasdair G Kergon
2007-12-06 22:20:10 UTC
Permalink
Post by Kay Sievers
A fix for LVM to handle symlinks instead of directories is in the LVM
CVS tree, but there wasn't a release since August.
I released it yesterday:-)

Alasdair
--
***@redhat.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
V***@vt.edu
2007-12-06 23:20:10 UTC
Permalink
Post by Kay Sievers
What's the value of SYSFS_DEPRECATED? Care to set it to yes, if it isn't,
and try again?
I *knew* there was a D'Oh! error in here. ;)

Bisection is fast closing in on gregkh-driver-block-device.patch, which broke
my LVM almost the exact same way the *last* time it showed up in -mm ;)
Post by Kay Sievers
A fix for LVM to handle symlinks instead of directories is in the LVM
CVS tree, but there wasn't a release since August.
I seem to recall it was 'nash' rather than LVM that had the indigestion the
last time around.
Kay Sievers
2007-12-06 23:30:08 UTC
Permalink
Post by V***@vt.edu
Post by Kay Sievers
What's the value of SYSFS_DEPRECATED? Care to set it to yes, if it isn't,
and try again?
I *knew* there was a D'Oh! error in here. ;)
Bisection is fast closing in on gregkh-driver-block-device.patch, which broke
my LVM almost the exact same way the *last* time it showed up in -mm ;)
Oh, it must not, if SYSFS_DEPRECATED=y is set. I hope we fixed all
issues. Please let us know if it does not work, then we will need to
look into it.
Post by V***@vt.edu
Post by Kay Sievers
A fix for LVM to handle symlinks instead of directories is in the LVM
CVS tree, but there wasn't a release since August.
I seem to recall it was 'nash' rather than LVM that had the indigestion the
last time around.
I think that a recent nash should work, even with SYSFS_DEPRECATED=n.
Anyway, nothing should change when SYSFS_DEPRECATED set, nash works fine
here, with that.

Kay

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
V***@vt.edu
2007-12-07 18:30:15 UTC
Permalink
Post by Kay Sievers
Post by V***@vt.edu
Post by Kay Sievers
What's the value of SYSFS_DEPRECATED? Care to set it to yes, if it isn't,
and try again?
I *knew* there was a D'Oh! error in here. ;)
Bisection is fast closing in on gregkh-driver-block-device.patch, which broke
my LVM almost the exact same way the *last* time it showed up in -mm ;)
Oh, it must not, if SYSFS_DEPRECATED=y is set. I hope we fixed all
issues. Please let us know if it does not work, then we will need to
look into it.
I changed SYSFS_DEPRECATED to y, and it was able to boot with the same old
initrd I've been using for a while.

Note that I had it set to 'n' for at least the last 4-5 -mm kernels, so it
*was* working fine without it..
Post by Kay Sievers
Post by V***@vt.edu
Post by Kay Sievers
A fix for LVM to handle symlinks instead of directories is in the LVM
CVS tree, but there wasn't a release since August.
I seem to recall it was 'nash' rather than LVM that had the indigestion the
last time around.
I think that a recent nash should work, even with SYSFS_DEPRECATED=n.
Anyway, nothing should change when SYSFS_DEPRECATED set, nash works fine
here, with that.
It was working fine with =n here until -rc4-mm1 as well, that's why it's a bit
of a surprise. What got added to the 'deprecated' list in this iteration?

Now for the truly odd part - I just tried with a rebuilt initrd that included
the lvm.static from last night's Rawhide (lvm2-2.02.29-1.fc9). And that didn't
work any better.

So to summarize: (old lvm == 2.02.24)

release SYSFS_DEPRECATED lvm2 works
-rc3-mm2 N old yes
-rc4-mm1 N old no
-rc4-mm1 Y old yes
-rc4-mm1 N new no

(I'm sure looking at that, everybody is now going 'WTF??!?' ;)

gregkh-driver-driver-core-fix-class-glue-dir-cleanup-logic.patch and
gregkh-driver-block-device.patch are the only patches left in the (very small)
bisect window that reference SYSFS_DEPRECATED at all (according to grep)

Anybody got any brilliant ideas? :)
Kay Sievers
2007-12-07 18:50:12 UTC
Permalink
Post by V***@vt.edu
Post by Kay Sievers
Post by V***@vt.edu
Post by Kay Sievers
What's the value of SYSFS_DEPRECATED? Care to set it to yes, if it isn't,
and try again?
I *knew* there was a D'Oh! error in here. ;)
Bisection is fast closing in on gregkh-driver-block-device.patch, which broke
my LVM almost the exact same way the *last* time it showed up in -mm ;)
Oh, it must not, if SYSFS_DEPRECATED=y is set. I hope we fixed all
issues. Please let us know if it does not work, then we will need to
look into it.
I changed SYSFS_DEPRECATED to y, and it was able to boot with the same old
initrd I've been using for a while.
Great!
Post by V***@vt.edu
Note that I had it set to 'n' for at least the last 4-5 -mm kernels, so it
*was* working fine without it..
Yeah, but the raw block kobjects got converted to devices, which are
symlinks with SYSFS_DEPRECATED=n.
Post by V***@vt.edu
Post by Kay Sievers
Post by V***@vt.edu
Post by Kay Sievers
A fix for LVM to handle symlinks instead of directories is in the LVM
CVS tree, but there wasn't a release since August.
I seem to recall it was 'nash' rather than LVM that had the indigestion the
last time around.
I think that a recent nash should work, even with SYSFS_DEPRECATED=n.
Anyway, nothing should change when SYSFS_DEPRECATED set, nash works fine
here, with that.
It was working fine with =n here until -rc4-mm1 as well, that's why it's a bit
of a surprise. What got added to the 'deprecated' list in this iteration?
Block devices got integrated in the driver model.
Post by V***@vt.edu
Now for the truly odd part - I just tried with a rebuilt initrd that included
the lvm.static from last night's Rawhide (lvm2-2.02.29-1.fc9). And that didn't
work any better.
So to summarize: (old lvm == 2.02.24)
release SYSFS_DEPRECATED lvm2 works
-rc3-mm2 N old yes
-rc4-mm1 N old no
-rc4-mm1 Y old yes
-rc4-mm1 N new no
(I'm sure looking at that, everybody is now going 'WTF??!?' ;)
gregkh-driver-driver-core-fix-class-glue-dir-cleanup-logic.patch and
gregkh-driver-block-device.patch are the only patches left in the (very small)
bisect window that reference SYSFS_DEPRECATED at all (according to grep)
Anybody got any brilliant ideas? :)
I guess it's nash again, which version is it?

You probably need to wait for Red Hat to catch up, and don't disable
SYSFS_DEPRECATED for now, they don't support that.

Kay

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
V***@vt.edu
2007-12-07 20:30:08 UTC
Permalink
Post by Kay Sievers
Post by V***@vt.edu
Anybody got any brilliant ideas? :)
I guess it's nash again, which version is it?
Confirmed - nash again. 6.0.9 does not work, upgrading to 6.0.19 works.

init/Kconfig says this for SYSFS_DEPRECATED (which is where I got lead astray,
as most of my laptop is Fedora Rawhide and therefor "released this week"):

If you are using a distro that was released in 2006 or later,
it should be safe to say N here.

nash 6.0.9 came out in April 2007, and I suspect, but can't prove, that the
relevant change was this one:

* Mon Aug 27 2007 Peter Jones <***@redhat.com> - 6.0.12-2
- Fix segfault in scsi vpd probe code
- Fix block device creation

That was just over 3 months ago. We probably need to fix that help text,
but I admit not being sure what guidance we should give now....
Kay Sievers
2007-12-07 21:00:19 UTC
Permalink
Post by V***@vt.edu
Post by Kay Sievers
Post by V***@vt.edu
Anybody got any brilliant ideas? :)
I guess it's nash again, which version is it?
Confirmed - nash again. 6.0.9 does not work, upgrading to 6.0.19 works.
Oh, cool!

I expected 6.0.9 to contain the fix though:
http://lkml.org/lkml/2007/6/7/209
Post by V***@vt.edu
init/Kconfig says this for SYSFS_DEPRECATED (which is where I got lead astray,
If you are using a distro that was released in 2006 or later,
it should be safe to say N here.
nash 6.0.9 came out in April 2007, and I suspect, but can't prove, that the
- Fix segfault in scsi vpd probe code
- Fix block device creation
That was just over 3 months ago.
Yeah right, even if it is fixed earlier, it's at least 6 months.
Post by V***@vt.edu
We probably need to fix that help text,
but I admit not being sure what guidance we should give now....
Right, the help text needs to be changed. There are distros like Red Hat
which don't support !DEPRECATED at all today, so we should probably just
remove the date and add that to the help text.

On the other hand, we are currently considering making the DEPRECATED
behavior a boot-time option, so it can be changed on the kernel command
line instead of a compile option. There would only be a compile-time
default to set.
We will get to that after the current kobject work (~100 patches) in
Greg's tree is finished.

Thanks for your help and patience,
Kay

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Laurent Riffard
2007-12-06 22:30:25 UTC
Permalink
Post by Andrew Morton
Temporarily at
http://userweb.kernel.org/~akpm/2.6.24-rc4-mm1/
Will appear later at
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc4/2.6.24-rc4-mm1/
LDS arch/x86/vdso/vdso32/vdso32.lds
AS arch/x86/vdso/vdso32/note.o
AS arch/x86/vdso/vdso32/int80.o
VDSO arch/x86/vdso/vdso32-int80.so.dbg
OBJCOPY arch/x86/vdso/vdso32-int80.so
AS arch/x86/vdso/vdso32/sysenter.o
VDSO arch/x86/vdso/vdso32-sysenter.so.dbg
OBJCOPY arch/x86/vdso/vdso32-sysenter.so
AS arch/x86/vdso/vdso32.o
CC arch/x86/vdso/vdso32-setup.o
VDSOSYM arch/x86/vdso/vdso32-int80-syms.lds
VDSOSYM arch/x86/vdso/vdso32-sysenter-syms.lds
VDSOSYM arch/x86/vdso/vdso32-syms.lds
--- - 2007-12-06 23:23:08.785302925 +0100
+++ arch/x86/vdso/vdso32-int80-syms.lds 2007-12-06 23:23:08.000000000 +0100
@@ -3,4 +3,3 @@
VDSO32_sigreturn = 0x0400;
VDSO32_vsyscall = 0x0414;
VDSO32_vsyscall_eh_frame_size = 0x044;
-VDSO32_vsyscall_eh_frame_size = 0x058;
make[1]: *** [arch/x86/vdso/vdso32-syms.lds] Error 1
make: *** [arch/x86/vdso] Error 2


# cat arch/x86/vdso/vdso32-int80-syms.lds
VDSO32_PRELINK = 0x0;
VDSO32_rt_sigreturn = 0x040c;
VDSO32_sigreturn = 0x0400;
VDSO32_vsyscall = 0x0414;
VDSO32_vsyscall_eh_frame_size = 0x044;

# cat arch/x86/vdso/vdso32-sysenter-syms.lds
VDSO32_PRELINK = 0x0;
VDSO32_SYSENTER_RETURN = 0x0424;
VDSO32_rt_sigreturn = 0x040c;
VDSO32_sigreturn = 0x0400;
VDSO32_vsyscall = 0x0414;
VDSO32_vsyscall_eh_frame_size = 0x058;

# scripts/ver_linux
If some fields are empty or look unusual you may have an old version.
Compare to the current minimal requirements in Documentation/Changes.

Linux calimero 2.6.24-rc4-g81b45b40 #2 PREEMPT Thu Dec 6 00:39:02 CET 2007 i686 GNU/Linux

Gnu C 4.1.3
Gnu make 3.81
binutils 2.18
util-linux 2.13
mount 2.13
module-init-tools 3.3-pre2
e2fsprogs 1.40.2
reiserfsprogs 3.6.19
reiser4progs 1.0.6
pcmciautils 014
PPP 2.4.4
Linux C Library 2.6.1
Dynamic linker (ldd) 2.6.1
Procps 3.2.7
Net-tools 1.60
Console-tools 0.2.3
oprofile 0.9.3
Sh-utils 5.97
udev 113
wireless-tools 29
Modules Loaded radeon drm lp nls_iso8859_1 nls_cp850 vfat fat reiser4 lzo_decompress lzo_compress eeprom w83781d hwmon_vid snd_ens1371 gameport snd_ac97_codec ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event firewire_ohci firewire_core snd_seq sg crc_itu_t snd_timer snd_seq_device sr_mod cdrom uhci_hcd snd i2c_viapro ohci1394 ata_generic pcspkr floppy 8250_pnp 8250 serial_core soundcore snd_page_alloc via686a rtc ieee1394 usbcore parport_pc parport ne2k_pci 8390 via_agp agpgart evdev dm_snapshot reiserfs sd_mod pata_via libata scsi_mod dm_mirror dm_mod


.config attached
~~
laurent
Andrew Morton
2007-12-06 22:50:12 UTC
Permalink
On Thu, 06 Dec 2007 23:28:38 +0100
Post by Laurent Riffard
Post by Andrew Morton
Temporarily at
http://userweb.kernel.org/~akpm/2.6.24-rc4-mm1/
Will appear later at
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc4/2.6.24-rc4-mm1/
LDS arch/x86/vdso/vdso32/vdso32.lds
AS arch/x86/vdso/vdso32/note.o
AS arch/x86/vdso/vdso32/int80.o
VDSO arch/x86/vdso/vdso32-int80.so.dbg
OBJCOPY arch/x86/vdso/vdso32-int80.so
AS arch/x86/vdso/vdso32/sysenter.o
VDSO arch/x86/vdso/vdso32-sysenter.so.dbg
OBJCOPY arch/x86/vdso/vdso32-sysenter.so
AS arch/x86/vdso/vdso32.o
CC arch/x86/vdso/vdso32-setup.o
VDSOSYM arch/x86/vdso/vdso32-int80-syms.lds
VDSOSYM arch/x86/vdso/vdso32-sysenter-syms.lds
VDSOSYM arch/x86/vdso/vdso32-syms.lds
--- - 2007-12-06 23:23:08.785302925 +0100
+++ arch/x86/vdso/vdso32-int80-syms.lds 2007-12-06 23:23:08.000000000 +0100
@@ -3,4 +3,3 @@
VDSO32_sigreturn = 0x0400;
VDSO32_vsyscall = 0x0414;
VDSO32_vsyscall_eh_frame_size = 0x044;
-VDSO32_vsyscall_eh_frame_size = 0x058;
make[1]: *** [arch/x86/vdso/vdso32-syms.lds] Error 1
make: *** [arch/x86/vdso] Error 2
Dunno. Maybe Roland's VDSO rework?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Miles Lane
2007-12-06 23:30:08 UTC
Permalink
How can I find Roland's patches, so I can try backing them out?
I looked in the broken out patches and only saw one related
to VDSO. Backing it out did not help. I tried searching for
messages to LKML sent by "roland" but mostly got a bunch of
folks sending spam.

Thanks,
Miles
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Andrew Morton
2007-12-06 23:40:08 UTC
Permalink
On Thu, 6 Dec 2007 18:28:25 -0500
Post by Miles Lane
How can I find Roland's patches, so I can try backing them out?
I looked in the broken out patches and only saw one related
to VDSO. Backing it out did not help. I tried searching for
messages to LKML sent by "roland" but mostly got a bunch of
folks sending spam.
They're all clumped into git-x86.patch. Hard.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Miles Lane
2007-12-06 23:50:12 UTC
Permalink
I found:
http://marc.info/?l=linux-kernel&m=119550978915647&w=2
through
http://marc.info/?l=linux-kernel&m=119551057816829&w=2
(I was unable to locate the 6th patch in the set)

When I tried backing out the patches, there were tons of errors. I
guess I'll punt on trying to build this MM tree. Sorry.

Miles
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Ingo Molnar
2007-12-07 10:40:09 UTC
Permalink
Post by Andrew Morton
On Thu, 6 Dec 2007 18:28:25 -0500
Post by Miles Lane
How can I find Roland's patches, so I can try backing them out?
I looked in the broken out patches and only saw one related
to VDSO. Backing it out did not help. I tried searching for
messages to LKML sent by "roland" but mostly got a bunch of
folks sending spam.
They're all clumped into git-x86.patch. Hard.
in theory the git merges could be generated as a flat series of patch
files:

x86.git.foo-fixes.patch
x86.git.bar-updates.patch
x86.git.foo-fixes-feh.patch
...

which could also include the commit log. "git-log -p" might be a
suitable generator. For example, x86.git can be processed per commit,
via this script:

for N in `git-rev-list --reverse --no-merges --remove-empty master..mm`; do
git-log -p $N
done

the following git-export-quilt script (just wrote it, might be buggy, so
careful - and it blows away the patches/ directory wherever you run it)
will generate a series file into patches/series that can be applied via
quilt:

rm -rf patches
mkdir patches
for N in `git-rev-list --reverse --no-merges --remove-empty master..mm`; do
git-log -p -1 $N > .tmp
export SUBJECT=`head -5 .tmp | tail -1`

# generate filename out of subject line:
FILE=x86.git-"`echo $SUBJECT | cut -c10- |
tr '[:punct:] \t' '-' | tr -s - | tr '[:upper:]' '[:lower:]'`"

# generate unique name:
while [ -f patches/$FILE.patch ]; do FILE="$FILE"_; done

echo $FILE.patch
mv .tmp patches/$FILE.patch
echo $FILE.patch >> patches/series
done

ls -l patches/series

i ran this script over x86.git and it produced a patch series with 247
patches that quilt was able to push correctly. (in theory this concept
should work for other git trees too - but i have not tried it)

this would increase the series size quite substantially though - but it
would make cherry-picking and patch based bisection a lot easier.

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Roland McGrath
2007-12-07 01:20:07 UTC
Permalink
Some assembler versions automagically optimize .eh_frame contents,
changing their size. The CFI in sysenter.S was not using optimal
formatting, so it would be changed by newer/smarter assemblers.
This ran afoul of the wired constant for padding out the other vDSO
images to match its size. This changes the original hand-coded
source to use the optimal format encoding for its operations. That
leaves nothing more for a fancy assembler to do, so the sizes will
match the wired-in expected size regardless of the assembler version.

Signed-off-by: Roland McGrath <***@redhat.com>
---
arch/x86/vdso/vdso32/int80.S | 2 +-
arch/x86/vdso/vdso32/syscall.S | 2 +-
arch/x86/vdso/vdso32/sysenter.S | 18 ++++++------------
3 files changed, 8 insertions(+), 14 deletions(-)

diff --git a/arch/x86/vdso/vdso32/int80.S b/arch/x86/vdso/vdso32/int80.S
index be4b7a9..b15b7c0 100644
--- a/arch/x86/vdso/vdso32/int80.S
+++ b/arch/x86/vdso/vdso32/int80.S
@@ -50,7 +50,7 @@ __kernel_vsyscall:
/*
* Pad out the segment to match the size of the sysenter.S version.
*/
-VDSO32_vsyscall_eh_frame_size = 0x44
+VDSO32_vsyscall_eh_frame_size = 0x40
.section .data,"aw",@progbits
.space VDSO32_vsyscall_eh_frame_size-(.LENDFDEDLSI-.LSTARTFRAMEDLSI), 0
.previous
diff --git a/arch/x86/vdso/vdso32/syscall.S b/arch/x86/vdso/vdso32/syscall.S
index fe88d34..5415b56 100644
--- a/arch/x86/vdso/vdso32/syscall.S
+++ b/arch/x86/vdso/vdso32/syscall.S
@@ -71,7 +71,7 @@ __kernel_vsyscall:
/*
* Pad out the segment to match the size of the sysenter.S version.
*/
-VDSO32_vsyscall_eh_frame_size = 0x44
+VDSO32_vsyscall_eh_frame_size = 0x40
.section .data,"aw",@progbits
.space VDSO32_vsyscall_eh_frame_size-(.LENDFDE1-.LSTARTFRAME), 0
.previous
diff --git a/arch/x86/vdso/vdso32/sysenter.S b/arch/x86/vdso/vdso32/sysenter.S
index 902d5fc..e2800af 100644
--- a/arch/x86/vdso/vdso32/sysenter.S
+++ b/arch/x86/vdso/vdso32/sysenter.S
@@ -84,31 +84,25 @@ VDSO32_SYSENTER_RETURN: /* Symbol used by sysenter.c via vdso32-syms.h */
.uleb128 0
/* What follows are the instructions for the table generation.
We have to record all changes of the stack pointer. */
- .byte 0x04 /* DW_CFA_advance_loc4 */
- .long .Lpush_ecx-.LSTART_vsyscall
+ .byte 0x40 + (.Lpush_ecx-.LSTART_vsyscall) /* DW_CFA_advance_loc */
.byte 0x0e /* DW_CFA_def_cfa_offset */
.byte 0x08 /* RA at offset 8 now */
- .byte 0x04 /* DW_CFA_advance_loc4 */
- .long .Lpush_edx-.Lpush_ecx
+ .byte 0x40 + (.Lpush_edx-.Lpush_ecx) /* DW_CFA_advance_loc */
.byte 0x0e /* DW_CFA_def_cfa_offset */
.byte 0x0c /* RA at offset 12 now */
- .byte 0x04 /* DW_CFA_advance_loc4 */
- .long .Lenter_kernel-.Lpush_edx
+ .byte 0x40 + (.Lenter_kernel-.Lpush_edx) /* DW_CFA_advance_loc */
.byte 0x0e /* DW_CFA_def_cfa_offset */
.byte 0x10 /* RA at offset 16 now */
.byte 0x85, 0x04 /* DW_CFA_offset %ebp -16 */
/* Finally the epilogue. */
- .byte 0x04 /* DW_CFA_advance_loc4 */
- .long .Lpop_ebp-.Lenter_kernel
+ .byte 0x40 + (.Lpop_ebp-.Lenter_kernel) /* DW_CFA_advance_loc */
.byte 0x0e /* DW_CFA_def_cfa_offset */
.byte 0x0c /* RA at offset 12 now */
.byte 0xc5 /* DW_CFA_restore %ebp */
- .byte 0x04 /* DW_CFA_advance_loc4 */
- .long .Lpop_edx-.Lpop_ebp
+ .byte 0x40 + (.Lpop_edx-.Lpop_ebp) /* DW_CFA_advance_loc */
.byte 0x0e /* DW_CFA_def_cfa_offset */
.byte 0x08 /* RA at offset 8 now */
- .byte 0x04 /* DW_CFA_advance_loc4 */
- .long .Lpop_ecx-.Lpop_edx
+ .byte 0x40 + (.Lpop_ecx-.Lpop_edx) /* DW_CFA_advance_loc */
.byte 0x0e /* DW_CFA_def_cfa_offset */
.byte 0x04 /* RA at offset 4 now */
.align 4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Harvey Harrison
2007-12-07 01:30:12 UTC
Permalink
Post by Roland McGrath
Some assembler versions automagically optimize .eh_frame contents,
changing their size. The CFI in sysenter.S was not using optimal
formatting, so it would be changed by newer/smarter assemblers.
This ran afoul of the wired constant for padding out the other vDSO
images to match its size. This changes the original hand-coded
source to use the optimal format encoding for its operations. That
leaves nothing more for a fancy assembler to do, so the sizes will
match the wired-in expected size regardless of the assembler version.
Confirm this fixes the compile errors I was seeing with x86.git

Harvey

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Miles Lane
2007-12-07 03:30:09 UTC
Permalink
Thanks. That enabled me to compile as well. Now, if I can figure out
why the resulting kernel has a boot process that hangs... :-)

Miles
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Ingo Molnar
2007-12-07 09:50:10 UTC
Permalink
Post by Roland McGrath
Some assembler versions automagically optimize .eh_frame contents,
changing their size. The CFI in sysenter.S was not using optimal
formatting, so it would be changed by newer/smarter assemblers. This
ran afoul of the wired constant for padding out the other vDSO images
to match its size. This changes the original hand-coded source to use
the optimal format encoding for its operations. That leaves nothing
more for a fancy assembler to do, so the sizes will match the wired-in
expected size regardless of the assembler version.
thanks, applied.

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Dave Young
2007-12-07 02:20:06 UTC
Permalink
Hi,

2.6.24-rc4-mm1 build failed at drivers/net/wireless/ath5k/base.c for some inline functions like this:
drivers/net/wireless/ath5k/base.c:292: sorry, unimplemented: inlining failed in call to 'ath5k_extend_tsf': function body not available

fix it with adjust the order of inline function body.

Signed-off-by: Dave Young <***@gmail.com>

---
drivers/net/wireless/ath5k/base.c | 67 ++++++++++++++++----------------------
1 file changed, 29 insertions(+), 38 deletions(-)

diff -upr linux/drivers/net/wireless/ath5k/base.c linux.new/drivers/net/wireless/ath5k/base.c
--- linux/drivers/net/wireless/ath5k/base.c 2007-12-07 10:01:42.000000000 +0800
+++ linux.new/drivers/net/wireless/ath5k/base.c 2007-12-07 10:01:49.000000000 +0800
@@ -250,8 +250,19 @@ static int ath5k_rxbuf_setup(struct ath
static int ath5k_txbuf_setup(struct ath5k_softc *sc,
struct ath5k_buf *bf,
struct ieee80211_tx_control *ctl);
+
static inline void ath5k_txbuf_free(struct ath5k_softc *sc,
- struct ath5k_buf *bf);
+ struct ath5k_buf *bf)
+{
+ BUG_ON(!bf);
+ if (!bf->skb)
+ return;
+ pci_unmap_single(sc->pdev, bf->skbaddr, bf->skb->len,
+ PCI_DMA_TODEVICE);
+ dev_kfree_skb(bf->skb);
+ bf->skb = NULL;
+}
+
/* Queues setup */
static struct ath5k_txq *ath5k_txq_setup(struct ath5k_softc *sc,
int qtype, int subtype);
@@ -278,14 +289,29 @@ static int ath5k_beacon_setup(struct at
struct ieee80211_tx_control *ctl);
static void ath5k_beacon_send(struct ath5k_softc *sc);
static void ath5k_beacon_config(struct ath5k_softc *sc);
-static inline u64 ath5k_extend_tsf(struct ath5k_hw *ah, u32 rstamp);
+
+static inline u64 ath5k_extend_tsf(struct ath5k_hw *ah, u32 rstamp)
+{
+ u64 tsf = ath5k_hw_get_tsf64(ah);
+
+ if ((tsf & 0x7fff) < rstamp)
+ tsf -= 0x8000;
+
+ return (tsf & ~0x7fff) | rstamp;
+}
+
/* Interrupt handling */
static int ath5k_init(struct ath5k_softc *sc);
static int ath5k_stop_locked(struct ath5k_softc *sc);
static int ath5k_stop_hw(struct ath5k_softc *sc);
static irqreturn_t ath5k_intr(int irq, void *dev_id);
static void ath5k_tasklet_reset(unsigned long data);
-static inline void ath5k_update_txpow(struct ath5k_softc *sc);
+
+static inline void ath5k_update_txpow(struct ath5k_softc *sc)
+{
+ ath5k_hw_set_txpower_limit(sc->ah, 0);
+}
+
static void ath5k_calibrate(unsigned long data);
/* LED functions */
static void ath5k_led_off(unsigned long data);
@@ -1341,21 +1367,6 @@ err_unmap:
return ret;
}

-static inline void
-ath5k_txbuf_free(struct ath5k_softc *sc, struct ath5k_buf *bf)
-{
- BUG_ON(!bf);
- if (!bf->skb)
- return;
- pci_unmap_single(sc->pdev, bf->skbaddr, bf->skb->len,
- PCI_DMA_TODEVICE);
- dev_kfree_skb(bf->skb);
- bf->skb = NULL;
-}
-
-
-
-
/**************\
* Queues setup *
\**************/
@@ -2046,20 +2057,6 @@ ath5k_beacon_config(struct ath5k_softc *
#undef TSF_TO_TU
}

-static inline
-u64 ath5k_extend_tsf(struct ath5k_hw *ah, u32 rstamp)
-{
- u64 tsf = ath5k_hw_get_tsf64(ah);
-
- if ((tsf & 0x7fff) < rstamp)
- tsf -= 0x8000;
-
- return (tsf & ~0x7fff) | rstamp;
-}
-
-
-
-
/********************\
* Interrupt handling *
\********************/
@@ -2295,12 +2292,6 @@ ath5k_tasklet_reset(unsigned long data)
ath5k_reset(sc->hw);
}

-static inline void
-ath5k_update_txpow(struct ath5k_softc *sc)
-{
- ath5k_hw_set_txpower_limit(sc->ah, 0);
-}
-
/*
* Periodically recalibrate the PHY to account
* for temperature/environment changes.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Luis R. Rodriguez
2007-12-07 22:30:16 UTC
Permalink
Post by Dave Young
Hi,
drivers/net/wireless/ath5k/base.c:292: sorry, unimplemented: inlining failed in call to 'ath5k_extend_tsf': function body not available
fix it with adjust the order of inline function body.
Acked-by: Luis R. Rodriguez <***@winlab.rutgers.edu>

Thanks Dave. What version of gcc were you using? I haven't run into this.

BTW, nothing new was added in this patch, things were just shifted,
but even that may be copyrightable. Is it fair to assume you are
licensing these changes under the same license the file is in?

For this file we'd usually use:

Changes-licensed-under: 3-clause-BSD

For future reference:

http://linuxwireless.org/en/developers/Documentation/SubmittingPatches#Changes-licensed-undertag

Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Dave Young
2007-12-10 01:10:07 UTC
Permalink
Post by Luis R. Rodriguez
Post by Dave Young
Hi,
drivers/net/wireless/ath5k/base.c:292: sorry, unimplemented: inlining failed in call to 'ath5k_extend_tsf': function body not available
fix it with adjust the order of inline function body.
Thanks.
Post by Luis R. Rodriguez
Thanks Dave. What version of gcc were you using? I haven't run into this.
gcc 3.4.6
Post by Luis R. Rodriguez
BTW, nothing new was added in this patch, things were just shifted,
but even that may be copyrightable. Is it fair to assume you are
licensing these changes under the same license the file is in?
Ok, I don't care.
Post by Luis R. Rodriguez
Changes-licensed-under: 3-clause-BSD
http://linuxwireless.org/en/developers/Documentation/SubmittingPatches#Changes-licensed-undertag
Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Nick Kossifidis
2007-12-09 18:00:15 UTC
Permalink
Post by Dave Young
Hi,
drivers/net/wireless/ath5k/base.c:292: sorry, unimplemented: inlining failed in call to 'ath5k_extend_tsf': function body not available
fix it with adjust the order of inline function body.
---
drivers/net/wireless/ath5k/base.c | 67 ++++++++++++++++----------------------
1 file changed, 29 insertions(+), 38 deletions(-)
diff -upr linux/drivers/net/wireless/ath5k/base.c linux.new/drivers/net/wireless/ath5k/base.c
--- linux/drivers/net/wireless/ath5k/base.c 2007-12-07 10:01:42.000000000 +0800
+++ linux.new/drivers/net/wireless/ath5k/base.c 2007-12-07 10:01:49.000000000 +0800
@@ -250,8 +250,19 @@ static int ath5k_rxbuf_setup(struct ath
static int ath5k_txbuf_setup(struct ath5k_softc *sc,
struct ath5k_buf *bf,
struct ieee80211_tx_control *ctl);
+
static inline void ath5k_txbuf_free(struct ath5k_softc *sc,
- struct ath5k_buf *bf);
+ struct ath5k_buf *bf)
+{
+ BUG_ON(!bf);
+ if (!bf->skb)
+ return;
+ pci_unmap_single(sc->pdev, bf->skbaddr, bf->skb->len,
+ PCI_DMA_TODEVICE);
+ dev_kfree_skb(bf->skb);
+ bf->skb = NULL;
+}
+
/* Queues setup */
static struct ath5k_txq *ath5k_txq_setup(struct ath5k_softc *sc,
int qtype, int subtype);
@@ -278,14 +289,29 @@ static int ath5k_beacon_setup(struct at
struct ieee80211_tx_control *ctl);
static void ath5k_beacon_send(struct ath5k_softc *sc);
static void ath5k_beacon_config(struct ath5k_softc *sc);
-static inline u64 ath5k_extend_tsf(struct ath5k_hw *ah, u32 rstamp);
+
+static inline u64 ath5k_extend_tsf(struct ath5k_hw *ah, u32 rstamp)
+{
+ u64 tsf = ath5k_hw_get_tsf64(ah);
+
+ if ((tsf & 0x7fff) < rstamp)
+ tsf -= 0x8000;
+
+ return (tsf & ~0x7fff) | rstamp;
+}
+
/* Interrupt handling */
static int ath5k_init(struct ath5k_softc *sc);
static int ath5k_stop_locked(struct ath5k_softc *sc);
static int ath5k_stop_hw(struct ath5k_softc *sc);
static irqreturn_t ath5k_intr(int irq, void *dev_id);
static void ath5k_tasklet_reset(unsigned long data);
-static inline void ath5k_update_txpow(struct ath5k_softc *sc);
+
+static inline void ath5k_update_txpow(struct ath5k_softc *sc)
+{
+ ath5k_hw_set_txpower_limit(sc->ah, 0);
+}
+
static void ath5k_calibrate(unsigned long data);
/* LED functions */
static void ath5k_led_off(unsigned long data);
return ret;
}
-static inline void
-ath5k_txbuf_free(struct ath5k_softc *sc, struct ath5k_buf *bf)
-{
- BUG_ON(!bf);
- if (!bf->skb)
- return;
- pci_unmap_single(sc->pdev, bf->skbaddr, bf->skb->len,
- PCI_DMA_TODEVICE);
- dev_kfree_skb(bf->skb);
- bf->skb = NULL;
-}
-
-
-
-
/**************\
* Queues setup *
\**************/
@@ -2046,20 +2057,6 @@ ath5k_beacon_config(struct ath5k_softc *
#undef TSF_TO_TU
}
-static inline
-u64 ath5k_extend_tsf(struct ath5k_hw *ah, u32 rstamp)
-{
- u64 tsf = ath5k_hw_get_tsf64(ah);
-
- if ((tsf & 0x7fff) < rstamp)
- tsf -= 0x8000;
-
- return (tsf & ~0x7fff) | rstamp;
-}
-
-
-
-
/********************\
* Interrupt handling *
\********************/
@@ -2295,12 +2292,6 @@ ath5k_tasklet_reset(unsigned long data)
ath5k_reset(sc->hw);
}
-static inline void
-ath5k_update_txpow(struct ath5k_softc *sc)
-{
- ath5k_hw_set_txpower_limit(sc->ah, 0);
-}
-
/*
* Periodically recalibrate the PHY to account
* for temperature/environment changes.
We'll change their order in the code, plz keep prototype declarations
clean. I'll submit a patch asap on this.
--
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Fengguang Wu
2007-12-07 14:30:15 UTC
Permalink
Fix a panic, by changing
hidinput_mapping_quirks(,, unsigned long *bit,)
to
hidinput_mapping_quirks(,, unsigned long **bit,)

The `bit' in this function is an out parameter.

Cc: Jiri Kosina <***@suse.cz>
Signed-off-by: Fengguang Wu <***@mail.ustc.edu.cn>
---
drivers/hid/hid-input-quirks.c | 36 +++++++++++++++----------------
drivers/hid/hid-input.c | 2 -
include/linux/hid.h | 2 -
3 files changed, 20 insertions(+), 20 deletions(-)

--- linux-2.6.24-rc4-mm1.orig/include/linux/hid.h
+++ linux-2.6.24-rc4-mm1/include/linux/hid.h
@@ -526,7 +526,7 @@ extern void hidinput_disconnect(struct h
int hid_set_field(struct hid_field *, unsigned, __s32);
int hid_input_report(struct hid_device *, int type, u8 *, int, int);
int hidinput_find_field(struct hid_device *hid, unsigned int type, unsigned int code, struct hid_field **field);
-int hidinput_mapping_quirks(struct hid_usage *, struct input_dev *, unsigned long *, int *);
+int hidinput_mapping_quirks(struct hid_usage *, struct input_dev *, unsigned long **, int *);
void hidinput_event_quirks(struct hid_device *, struct hid_field *, struct hid_usage *, __s32);
int hidinput_apple_event(struct hid_device *, struct input_dev *, struct hid_usage *, __s32);
void hid_input_field(struct hid_device *hid, struct hid_field *field, __u8 *data, int interrupt);
--- linux-2.6.24-rc4-mm1.orig/drivers/hid/hid-input.c
+++ linux-2.6.24-rc4-mm1/drivers/hid/hid-input.c
@@ -382,7 +382,7 @@ static void hidinput_configure_usage(str
}

/* handle input mappings for quirky devices */
- ret = hidinput_mapping_quirks(usage, input, bit, &max);
+ ret = hidinput_mapping_quirks(usage, input, &bit, &max);
if (ret)
goto mapped;

--- linux-2.6.24-rc4-mm1.orig/drivers/hid/hid-input-quirks.c
+++ linux-2.6.24-rc4-mm1/drivers/hid/hid-input-quirks.c
@@ -16,16 +16,16 @@
#include <linux/input.h>
#include <linux/hid.h>

-#define map_abs(c) do { usage->code = c; usage->type = EV_ABS; bit = input->absbit; *max = ABS_MAX; } while (0)
-#define map_rel(c) do { usage->code = c; usage->type = EV_REL; bit = input->relbit; *max = REL_MAX; } while (0)
-#define map_key(c) do { usage->code = c; usage->type = EV_KEY; bit = input->keybit; *max = KEY_MAX; } while (0)
-#define map_led(c) do { usage->code = c; usage->type = EV_LED; bit = input->ledbit; *max = LED_MAX; } while (0)
+#define map_abs(c) do { usage->code = c; usage->type = EV_ABS; *bit = input->absbit; *max = ABS_MAX; } while (0)
+#define map_rel(c) do { usage->code = c; usage->type = EV_REL; *bit = input->relbit; *max = REL_MAX; } while (0)
+#define map_key(c) do { usage->code = c; usage->type = EV_KEY; *bit = input->keybit; *max = KEY_MAX; } while (0)
+#define map_led(c) do { usage->code = c; usage->type = EV_LED; *bit = input->ledbit; *max = LED_MAX; } while (0)

-#define map_abs_clear(c) do { map_abs(c); clear_bit(c, bit); } while (0)
-#define map_key_clear(c) do { map_key(c); clear_bit(c, bit); } while (0)
+#define map_abs_clear(c) do { map_abs(c); clear_bit(c, *bit); } while (0)
+#define map_key_clear(c) do { map_key(c); clear_bit(c, *bit); } while (0)

static int quirk_belkin_wkbd(struct hid_usage *usage, struct input_dev *input,
- unsigned long *bit, int *max)
+ unsigned long **bit, int *max)
{
if ((usage->hid & HID_USAGE_PAGE) != HID_UP_CONSUMER)
return 0;
@@ -41,7 +41,7 @@ static int quirk_belkin_wkbd(struct hid_
}

static int quirk_cherry_cymotion(struct hid_usage *usage, struct input_dev *input,
- unsigned long *bit, int *max)
+ unsigned long **bit, int *max)
{
if ((usage->hid & HID_USAGE_PAGE) != HID_UP_CONSUMER)
return 0;
@@ -57,7 +57,7 @@ static int quirk_cherry_cymotion(struct
}

static int quirk_logitech_ultrax_remote(struct hid_usage *usage, struct input_dev *input,
- unsigned long *bit, int *max)
+ unsigned long **bit, int *max)
{
if ((usage->hid & HID_USAGE_PAGE) != HID_UP_LOGIVENDOR)
return 0;
@@ -90,7 +90,7 @@ static int quirk_logitech_ultrax_remote(
}

static int quirk_chicony_tactical_pad(struct hid_usage *usage, struct input_dev *input,
- unsigned long *bit, int *max)
+ unsigned long **bit, int *max)
{
if ((usage->hid & HID_USAGE_PAGE) != HID_UP_MSVENDOR)
return 0;
@@ -115,7 +115,7 @@ static int quirk_chicony_tactical_pad(st
}

static int quirk_microsoft_ergonomy_kb(struct hid_usage *usage, struct input_dev *input,
- unsigned long *bit, int *max)
+ unsigned long **bit, int *max)
{
if ((usage->hid & HID_USAGE_PAGE) != HID_UP_MSVENDOR)
return 0;
@@ -138,7 +138,7 @@ static int quirk_microsoft_ergonomy_kb(s
}

static int quirk_microsoft_presenter_8k(struct hid_usage *usage, struct input_dev *input,
- unsigned long *bit, int *max)
+ unsigned long **bit, int *max)
{
if ((usage->hid & HID_USAGE_PAGE) != HID_UP_MSVENDOR)
return 0;
@@ -156,7 +156,7 @@ static int quirk_microsoft_presenter_8k(
}

static int quirk_petalynx_remote(struct hid_usage *usage, struct input_dev *input,
- unsigned long *bit, int *max)
+ unsigned long **bit, int *max)
{
if (((usage->hid & HID_USAGE_PAGE) != HID_UP_LOGIVENDOR) &&
((usage->hid & HID_USAGE_PAGE) != HID_UP_CONSUMER))
@@ -184,7 +184,7 @@ static int quirk_petalynx_remote(struct
}

static int quirk_logitech_wireless(struct hid_usage *usage, struct input_dev *input,
- unsigned long *bit, int *max)
+ unsigned long **bit, int *max)
{
if ((usage->hid & HID_USAGE_PAGE) != HID_UP_CONSUMER)
return 0;
@@ -236,7 +236,7 @@ static int quirk_logitech_wireless(struc
}

static int quirk_cherry_genius_29e(struct hid_usage *usage, struct input_dev *input,
- unsigned long *bit, int *max)
+ unsigned long **bit, int *max)
{
if ((usage->hid & HID_USAGE_PAGE) != HID_UP_CONSUMER)
return 0;
@@ -254,7 +254,7 @@ static int quirk_cherry_genius_29e(struc
}

static int quirk_btc_8193(struct hid_usage *usage, struct input_dev *input,
- unsigned long *bit, int *max)
+ unsigned long **bit, int *max)
{
if ((usage->hid & HID_USAGE_PAGE) != HID_UP_CONSUMER)
return 0;
@@ -307,7 +307,7 @@ static int quirk_btc_8193(struct hid_usa
static const struct hid_input_blacklist {
__u16 idVendor;
__u16 idProduct;
- int (*quirk)(struct hid_usage *, struct input_dev *, unsigned long *, int *);
+ int (*quirk)(struct hid_usage *, struct input_dev *, unsigned long **, int *);
} hid_input_blacklist[] = {
{ VENDOR_ID_BELKIN, DEVICE_ID_BELKIN_WIRELESS_KEYBOARD, quirk_belkin_wkbd },

@@ -335,7 +335,7 @@ static const struct hid_input_blacklist

int hidinput_mapping_quirks(struct hid_usage *usage,
struct input_dev *input,
- unsigned long *bit, int *max)
+ unsigned long **bit, int *max)
{
struct hid_device *device = input_get_drvdata(input);
int i = 0;

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Jiri Kosina
2007-12-10 10:10:07 UTC
Permalink
Post by Fengguang Wu
Fix a panic, by changing
hidinput_mapping_quirks(,, unsigned long *bit,)
to
hidinput_mapping_quirks(,, unsigned long **bit,)
The `bit' in this function is an out parameter.
Thanks for catching this, I will apply it to my tree.
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Jiri Slaby
2007-12-07 14:40:13 UTC
Permalink
Post by Andrew Morton
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc4/2.6.24-rc4-mm1/
git-sched.patch
breaks suspend here since -rc3-mm2. More precisely, this one:
softlockup: automatically detect hung TASK_UNINTERRUPTIBLE tasks

2.6.24-rc4-mm1 minus this one works just fine. Otherwise disks stop, graphics
stops and then it hangs not powering down.

Core 2 Duo, SMP kernel, voluntary preempt, 250 HZ, SLUB, 64 bit.

Ideas?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Ingo Molnar
2007-12-07 15:20:08 UTC
Permalink
Post by Jiri Slaby
Post by Andrew Morton
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc4/2.6.24-rc4-mm1/
git-sched.patch
softlockup: automatically detect hung TASK_UNINTERRUPTIBLE tasks
2.6.24-rc4-mm1 minus this one works just fine. Otherwise disks stop, graphics
stops and then it hangs not powering down.
Core 2 Duo, SMP kernel, voluntary preempt, 250 HZ, SLUB, 64 bit.
Ideas?
thanks for tracking it down. Does the patch below help?

Ingo

---
kernel/softlockup.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)

Index: linux/kernel/softlockup.c
===================================================================
--- linux.orig/kernel/softlockup.c
+++ linux/kernel/softlockup.c
@@ -101,7 +101,11 @@ void softlockup_tick(void)

now = get_timestamp(this_cpu);

- /* Warn about unreasonable delays: */
+ /* Wake up the high-prio watchdog task every second: */
+ if (now > (touch_timestamp + 1))
+ wake_up_process(per_cpu(watchdog_task, this_cpu));
+
+ /* Warn about unreasonable 10+ seconds delays: */
if (now <= (touch_timestamp + softlockup_thresh))
return;

@@ -214,7 +218,7 @@ static int watchdog(void *__bind_cpu)
*/
while (!kthread_should_stop()) {
touch_softlockup_watchdog();
- msleep_interruptible(10000);
+ schedule();

/*
* Only do the hung-tasks check on one CPU:
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Ingo Molnar
2007-12-07 18:00:27 UTC
Permalink
Post by Ingo Molnar
thanks for tracking it down. Does the patch below help?
oops, that should be the patch below. Otherwise the watchdog kernel
threads will just loop around.

Ingo

---
kernel/softlockup.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)

Index: linux/kernel/softlockup.c
===================================================================
--- linux.orig/kernel/softlockup.c
+++ linux/kernel/softlockup.c
@@ -101,7 +101,11 @@ void softlockup_tick(void)

now = get_timestamp(this_cpu);

- /* Warn about unreasonable delays: */
+ /* Wake up the high-prio watchdog task every second: */
+ if (now > (touch_timestamp + 1))
+ wake_up_process(per_cpu(watchdog_task, this_cpu));
+
+ /* Warn about unreasonable 10+ seconds delays: */
if (now <= (touch_timestamp + softlockup_thresh))
return;

@@ -213,8 +217,9 @@ static int watchdog(void *__bind_cpu)
* debug-printout triggers in softlockup_tick().
*/
while (!kthread_should_stop()) {
+ set_current_state(TASK_INTERRUPTIBLE);
touch_softlockup_watchdog();
- msleep_interruptible(10000);
+ schedule();

/*
* Only do the hung-tasks check on one CPU:
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Jiri Slaby
2007-12-08 08:20:07 UTC
Permalink
Post by Ingo Molnar
Post by Ingo Molnar
thanks for tracking it down. Does the patch below help?
oops, that should be the patch below. Otherwise the watchdog kernel
threads will just loop around.
Ingo
---
kernel/softlockup.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
Index: linux/kernel/softlockup.c
===================================================================
--- linux.orig/kernel/softlockup.c
+++ linux/kernel/softlockup.c
@@ -101,7 +101,11 @@ void softlockup_tick(void)
now = get_timestamp(this_cpu);
- /* Warn about unreasonable delays: */
+ /* Wake up the high-prio watchdog task every second: */
+ if (now > (touch_timestamp + 1))
+ wake_up_process(per_cpu(watchdog_task, this_cpu));
+
+ /* Warn about unreasonable 10+ seconds delays: */
if (now <= (touch_timestamp + softlockup_thresh))
return;
@@ -213,8 +217,9 @@ static int watchdog(void *__bind_cpu)
* debug-printout triggers in softlockup_tick().
*/
while (!kthread_should_stop()) {
+ set_current_state(TASK_INTERRUPTIBLE);
touch_softlockup_watchdog();
- msleep_interruptible(10000);
+ schedule();
/*
Unfortunately no change here.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Ingo Molnar
2007-12-08 08:50:07 UTC
Permalink
Post by Jiri Slaby
Unfortunately no change here.
could you try to revert this change:

-int softlockup_thresh = 10;
+int softlockup_thresh = 60;

i.e. change the value of softlockup_thresh back to 10. You should be
able to tweak this runtime as well, without patching the kernel:

echo 10 > /proc/sys/kernel/softlockup_thresh

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Jiri Slaby
2007-12-08 09:30:14 UTC
Permalink
Post by Ingo Molnar
Post by Jiri Slaby
Unfortunately no change here.
-int softlockup_thresh = 10;
+int softlockup_thresh = 60;
i.e. change the value of softlockup_thresh back to 10. You should be
echo 10 > /proc/sys/kernel/softlockup_thresh
What should have this changed? I can't see any difference.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Ingo Molnar
2007-12-08 15:30:23 UTC
Permalink
Post by Jiri Slaby
Post by Ingo Molnar
Post by Jiri Slaby
Unfortunately no change here.
-int softlockup_thresh = 10;
+int softlockup_thresh = 60;
i.e. change the value of softlockup_thresh back to 10. You should be
echo 10 > /proc/sys/kernel/softlockup_thresh
What should have this changed? I can't see any difference.
it changes the wakeup frequency of the softlockup thread.

i'm wondering why it had no effect now - the new code is in essence a
NOP over what we had. Could you send me your current (modified)
kernel/softlockup.c code?

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Jiri Slaby
2007-12-08 17:40:11 UTC
Permalink
Post by Ingo Molnar
i'm wondering why it had no effect now - the new code is in essence a
NOP over what we had. Could you send me your current (modified)
kernel/softlockup.c code?
Only these changes:
diff --git a/kernel/softlockup.c b/kernel/softlockup.c
index e50b44a..7011549 100644
--- a/kernel/softlockup.c
+++ b/kernel/softlockup.c
@@ -25,7 +25,7 @@ static DEFINE_PER_CPU(unsigned long, print_timestamp);
static DEFINE_PER_CPU(struct task_struct *, watchdog_task);

static int did_panic;
-int softlockup_thresh = 60;
+int softlockup_thresh = 10;

static int
softlock_panic(struct notifier_block *this, unsigned long event, void *ptr)
@@ -101,7 +101,11 @@ void softlockup_tick(void)

now = get_timestamp(this_cpu);

- /* Warn about unreasonable delays: */
+ /* Wake up the high-prio watchdog task every second: */
+ if (now > (touch_timestamp + 1))
+ wake_up_process(per_cpu(watchdog_task, this_cpu));
+
+ /* Warn about unreasonable 10+ seconds delays: */
if (now <= (touch_timestamp + softlockup_thresh))
return;

@@ -213,8 +217,9 @@ static int watchdog(void *__bind_cpu)
* debug-printout triggers in softlockup_tick().
*/
while (!kthread_should_stop()) {
+ set_current_state(TASK_INTERRUPTIBLE);
touch_softlockup_watchdog();
- msleep_interruptible(10000);
+ schedule();

/*
* Only do the hung-tasks check on one CPU:


Whole file:
http://www.fi.muni.cz/~xslaby/sklad/softlockup.c
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Jiri Slaby
2007-12-08 17:50:07 UTC
Permalink
Post by Ingo Molnar
i'm wondering why it had no effect now - the new code is in essence a
NOP over what we had.
Maybe a dumb question. Why those changes in process_32.c in the patch and not in
process_64.c?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Ingo Molnar
2007-12-09 08:10:07 UTC
Permalink
Post by Jiri Slaby
Post by Ingo Molnar
i'm wondering why it had no effect now - the new code is in essence a
NOP over what we had.
Maybe a dumb question. Why those changes in process_32.c in the patch
and not in process_64.c?
not a dumb question at all - i forgot about it. Find the updated patch
below.

( sidenote: this shows the x86 unification concept in action. You
noticed the missing _64.c probably because you saw a _32.c file
modified in the patch and the rule is that if we modify a _32.c file
then the matching _64.c file needs to be updated too. If this had been
an old-style pre-unification arch/i386/kernel/process.c file you'd not
have been able to tell this from just looking at the patch file - and
we'd possibly have missed to include a fix on the 64-bit side. With
the unification of files we are realizing it how many times this
happened in the past (and went unnoticed). )

Ingo

--------------------->
Subject: x86: idle wakeup event in the HLT loop
From: Ingo Molnar <***@elte.hu>

do a proper idle-wakeup event on HLT as well - some CPUs stop the TSC
in HLT too, not just when going through the ACPI methods.

(the ACPI idle code already does this.)

[ update the 64-bit side too, as noticed by Jiri Slaby. ]

Signed-off-by: Ingo Molnar <***@elte.hu>
---
arch/x86/kernel/process_32.c | 15 ++++++++++++---
arch/x86/kernel/process_64.c | 13 ++++++++++---
2 files changed, 22 insertions(+), 6 deletions(-)

Index: linux-x86.q/arch/x86/kernel/process_32.c
===================================================================
--- linux-x86.q.orig/arch/x86/kernel/process_32.c
+++ linux-x86.q/arch/x86/kernel/process_32.c
@@ -113,10 +113,19 @@ void default_idle(void)
smp_mb();

local_irq_disable();
- if (!need_resched())
+ if (!need_resched()) {
+ ktime_t t0, t1;
+ u64 t0n, t1n;
+
+ t0 = ktime_get();
+ t0n = ktime_to_ns(t0);
safe_halt(); /* enables interrupts racelessly */
- else
- local_irq_enable();
+ local_irq_disable();
+ t1 = ktime_get();
+ t1n = ktime_to_ns(t1);
+ sched_clock_idle_wakeup_event(t1n - t0n);
+ }
+ local_irq_enable();
current_thread_info()->status |= TS_POLLING;
} else {
/* loop is done by the caller */
Index: linux-x86.q/arch/x86/kernel/process_64.c
===================================================================
--- linux-x86.q.orig/arch/x86/kernel/process_64.c
+++ linux-x86.q/arch/x86/kernel/process_64.c
@@ -116,9 +116,16 @@ static void default_idle(void)
smp_mb();
local_irq_disable();
if (!need_resched()) {
- /* Enables interrupts one instruction before HLT.
- x86 special cases this so there is no race. */
- safe_halt();
+ ktime_t t0, t1;
+ u64 t0n, t1n;
+
+ t0 = ktime_get();
+ t0n = ktime_to_ns(t0);
+ safe_halt(); /* enables interrupts racelessly */
+ local_irq_disable();
+ t1 = ktime_get();
+ t1n = ktime_to_ns(t1);
+ sched_clock_idle_wakeup_event(t1n - t0n);
} else
local_irq_enable();
current_thread_info()->status |= TS_POLLING;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Jiri Slaby
2007-12-08 23:20:09 UTC
Permalink
Post by Ingo Molnar
i'm wondering why it had no effect now
diff --git a/kernel/cpu.c b/kernel/cpu.c
index e0d3a4f..a46c252 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -47,15 +47,21 @@ void __init cpu_hotplug_init(void)
}

#ifdef CONFIG_HOTPLUG_CPU
-
+#include <asm/io.h>
void get_online_cpus(void)
{
+ outb(0x20, 0x80);
might_sleep();
+ outb(0x21, 0x80);
if (cpu_hotplug.active_writer == current)
return;
+ outb(0x22, 0x80);
mutex_lock(&cpu_hotplug.lock);
+ outb(0x23, 0x80);
cpu_hotplug.refcount++;
+ outb(0x24, 0x80);
mutex_unlock(&cpu_hotplug.lock);
+ outb(0x25, 0x80);

}
EXPORT_SYMBOL_GPL(get_online_cpus);

produces 0x22 on the LCD (called from watchdog kthread).

Going to catch some sleep,
--js
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Ingo Molnar
2007-12-09 07:50:06 UTC
Permalink
Post by Jiri Slaby
Post by Ingo Molnar
i'm wondering why it had no effect now
diff --git a/kernel/cpu.c b/kernel/cpu.c
index e0d3a4f..a46c252 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -47,15 +47,21 @@ void __init cpu_hotplug_init(void)
}
#ifdef CONFIG_HOTPLUG_CPU
-
+#include <asm/io.h>
void get_online_cpus(void)
{
+ outb(0x20, 0x80);
might_sleep();
+ outb(0x21, 0x80);
ah. If you comment out get_online_cpus()/put_online_cpus() from
kernel/softlockup.c, does it start working?

Gautham, any ideas?

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Jiri Slaby
2007-12-09 09:10:06 UTC
Permalink
Post by Ingo Molnar
ah. If you comment out get_online_cpus()/put_online_cpus() from
kernel/softlockup.c, does it start working?
Yes indeed. (the process_64 part of the previous patch applied, but I think it
has no effect to this issue?)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Jiri Slaby
2007-12-10 09:00:21 UTC
Permalink
commit 15bfb662b35c609490185fba2fd4713d230b9374
Date: Mon Dec 10 13:41:45 2007 +0530
softlockup: remove get_online_cpus() which doesn't help here.
The get_online_cpus() protection seems to be bogus
in kernel/softlockup.c as cpu cached in check_cpu can go offline
once we do a put_online_cpus().
mutex_down(&cpu_hotplug.lock);
/* All subsequent get_online_cpus
* will be blocked till we're
* done with this cpu-hotplug
* operation.
*/
get_online_cpus();
/* watchdog is blocked
Thus we cannot
go further until
the cpu-hotplug
operation completes
*/
kthread_stop(watchdog_thread);
/* we're trying to stop a
* thread which is blocked
* waiting for us to finish.
*
* Since we cannot finish until
* the thread stops, we deadlock here!
*/
diff --git a/kernel/softlockup.c b/kernel/softlockup.c
index e50b44a..576eb9c 100644
--- a/kernel/softlockup.c
+++ b/kernel/softlockup.c
@@ -219,9 +219,7 @@ static int watchdog(void *__bind_cpu)
/*
*/
- get_online_cpus();
check_cpu = any_online_cpu(cpu_online_map);
- put_online_cpus();
if (this_cpu != check_cpu)
continue;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Ingo Molnar
2007-12-10 09:20:11 UTC
Permalink
softlockup: remove get_online_cpus() which doesn't help here.
The get_online_cpus() protection seems to be bogus in
kernel/softlockup.c as cpu cached in check_cpu can go offline once
we do a put_online_cpus().
i'm wondering, what's the proper CPU-hotplug safe sequence here then?
I'm picking a CPU number from cpu_online_map, and that CPU could go away
while i'm still using it, right? What's saving us here?

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Gautham R Shenoy
2007-12-10 10:20:13 UTC
Permalink
Post by Ingo Molnar
softlockup: remove get_online_cpus() which doesn't help here.
The get_online_cpus() protection seems to be bogus in
kernel/softlockup.c as cpu cached in check_cpu can go offline once
we do a put_online_cpus().
i'm wondering, what's the proper CPU-hotplug safe sequence here then?
I'm picking a CPU number from cpu_online_map, and that CPU could go away
while i'm still using it, right? What's saving us here?
In this particular case, we are trying to see if any task on a particular
cpu has not been scheduled for a really long time. If we do this check
on a cpu which has gone offline, then
a) If the tasks have not been migrated on to another cpu yet, we will
still perform that check and yell if something has been holding any task
for a sufficiently long time.
b) If the tasks have been migrated off, then we have nothing to check.

However, if we still want that particular cpu to not go offline during
the check, then could we use the following patch

commit a49736844717e00f7a37c96368cea8fec7eb31cf
Author: Gautham R Shenoy <***@in.ibm.com>
Date: Mon Dec 10 15:43:32 2007 +0530

CPU-Hotplug: Add try_get_online_cpus()

Add the fastpath code, try_get_online_cpus() which will
return 1 once it has managed to hold the reference to the cpu_online_map
if there are no threads trying to perform a cpu-hotplug.

Use the primitive in the softlockup code.

Signed-off-by: Gautham R Shenoy <***@in.ibm.com>
Cc: Ingo Molnar <***@elte.hu>
Cc: Thomas Gleixner <***@linuxtronix.de>
Cc: Jiri Slaby <***@gmail.com>

diff --git a/include/linux/cpu.h b/include/linux/cpu.h
index e0132cb..d236e21 100644
--- a/include/linux/cpu.h
+++ b/include/linux/cpu.h
@@ -107,6 +107,7 @@ static inline void cpuhotplug_mutex_unlock(struct mutex *cpu_hp_mutex)
}

extern void get_online_cpus(void);
+extern int try_get_online_cpus(void);
extern void put_online_cpus(void);
#define hotcpu_notifier(fn, pri) { \
static struct notifier_block fn##_nb = \
@@ -127,6 +128,9 @@ static inline void cpuhotplug_mutex_unlock(struct mutex *cpu_hp_mutex)

#define get_online_cpus() do { } while (0)
#define put_online_cpus() do { } while (0)
+static inline int try_get_online_cpus(void)
+{ return 1;}
+
#define hotcpu_notifier(fn, pri) do { (void)(fn); } while (0)
/* These aren't inline functions due to a GCC bug. */
#define register_hotcpu_notifier(nb) ({ (void)(nb); 0; })
diff --git a/kernel/cpu.c b/kernel/cpu.c
index e0d3a4f..38537c9 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -48,11 +48,35 @@ void __init cpu_hotplug_init(void)

#ifdef CONFIG_HOTPLUG_CPU

+/*
+ * try_get_online_cpus(): Tries to hold a reference
+ * to the cpu_online_map if no one is trying to perform
+ * a cpu-hotplug operation. This is the fastpath code for
+ * get_online_cpus.
+ *
+ * Returns 1 if there is no cpu-hotplug operation
+ * currently in progress.
+ */
+int try_get_online_cpus(void)
+{
+ if(!cpu_hotplug.active_writer) {
+ cpu_hotplug.refcount++;
+ return 1;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(try_get_online_cpus);
+
void get_online_cpus(void)
{
might_sleep();
if (cpu_hotplug.active_writer == current)
return;
+ if (try_get_online_cpus())
+ return;
+
+ /* The writer exists, hence the slowpath */
mutex_lock(&cpu_hotplug.lock);
cpu_hotplug.refcount++;
mutex_unlock(&cpu_hotplug.lock);
@@ -120,6 +144,11 @@ static void cpu_hotplug_begin(void)
mutex_lock(&cpu_hotplug.lock);

cpu_hotplug.active_writer = current;
+ synchronize_sched();
+ /* New users of get_online_cpus() will see a non-NULL value
+ * for cpu_hotplug.active_writer here and will take the slowpath
+ */
+
add_wait_queue_exclusive(&cpu_hotplug.writer_queue, &wait);
while (cpu_hotplug.refcount) {
set_current_state(TASK_UNINTERRUPTIBLE);
diff --git a/kernel/softlockup.c b/kernel/softlockup.c
index 576eb9c..cb0616d 100644
--- a/kernel/softlockup.c
+++ b/kernel/softlockup.c
@@ -150,8 +150,8 @@ static void check_hung_task(struct task_struct *t, unsigned long now)
sysctl_hung_task_warnings--;

/*
- * Ok, the task did not get scheduled for more than 2 minutes,
- * complain:
+ * Ok, the task did not get scheduled for more than
+ * sysctl_hung_task_timeout_secs, complain:
*/
printk(KERN_ERR "INFO: task %s:%d blocked for more than "
"%ld seconds.\n", t->comm, t->pid,
@@ -216,16 +216,21 @@ static int watchdog(void *__bind_cpu)
touch_softlockup_watchdog();
msleep_interruptible(10000);

+ /*
+ * If a cpu-hotplug operation is in progress
+ * we can come back later
+ */
+ if (!try_get_online_cpus())
+ continue;
/*
* Only do the hung-tasks check on one CPU:
*/
check_cpu = any_online_cpu(cpu_online_map);

- if (this_cpu != check_cpu)
- continue;
-
- if (sysctl_hung_task_timeout_secs)
+ if ((this_cpu == check_cpu) && sysctl_hung_task_timeout_secs)
check_hung_uninterruptible_tasks(this_cpu);
+
+ put_online_cpus();
}

return 0;
Post by Ingo Molnar
Ingo
--
Gautham R Shenoy
Linux Technology Center
IBM India.
"Freedom comes with a price tag of responsibility, which is still a bargain,
because Freedom is priceless!"
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Ingo Molnar
2007-12-10 10:30:22 UTC
Permalink
Post by Gautham R Shenoy
Post by Ingo Molnar
i'm wondering, what's the proper CPU-hotplug safe sequence here
then? I'm picking a CPU number from cpu_online_map, and that CPU
could go away while i'm still using it, right? What's saving us
here?
In this particular case, we are trying to see if any task on a
particular cpu has not been scheduled for a really long time. If we do
this check on a cpu which has gone offline, then a) If the tasks have
not been migrated on to another cpu yet, we will still perform that
check and yell if something has been holding any task for a
sufficiently long time. b) If the tasks have been migrated off, then
we have nothing to check.
say we've got 100 CPUs, so we've got 100 watchdog tasks running - one
for each CPU. Checking for hung tasks is a global operation not a
per-CPU operation (we iterate over the global tasklist), hence only one
CPU should really be calling this function. That online-cpus logic
achieves this by picking a single CPU. Perhaps it would be better to
keep a hung_task_checker_cpu variable that is driven from a
CPU-hotplug-down notifier? That way if a CPU is brought down we can
update hung_task_checker_cpu to another, still-online CPU. (this would
also be faster, because event-driven)

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Gautham R Shenoy
2007-12-10 11:30:17 UTC
Permalink
Post by Ingo Molnar
Post by Gautham R Shenoy
Post by Ingo Molnar
i'm wondering, what's the proper CPU-hotplug safe sequence here
then? I'm picking a CPU number from cpu_online_map, and that CPU
could go away while i'm still using it, right? What's saving us
here?
In this particular case, we are trying to see if any task on a
particular cpu has not been scheduled for a really long time. If we do
this check on a cpu which has gone offline, then a) If the tasks have
not been migrated on to another cpu yet, we will still perform that
check and yell if something has been holding any task for a
sufficiently long time. b) If the tasks have been migrated off, then
we have nothing to check.
say we've got 100 CPUs, so we've got 100 watchdog tasks running - one
for each CPU. Checking for hung tasks is a global operation not a
per-CPU operation (we iterate over the global tasklist), hence only one
CPU should really be calling this function. That online-cpus logic
achieves this by picking a single CPU. Perhaps it would be better to
keep a hung_task_checker_cpu variable that is driven from a
CPU-hotplug-down notifier? That way if a CPU is brought down we can
update hung_task_checker_cpu to another, still-online CPU. (this would
also be faster, because event-driven)
Do you mean something like this?

From: Gautham R Shenoy <***@in.ibm.com>

softlockup: update check_cpu during cpu-hotplug

Update the check_cpu value during a cpu-hotplug operation
so that we don't check for hung tasks on a cpu which is about
to go offline.

Signed-off-by: Gautham R Shenoy <***@in.ibm.com>
Cc: Ingo Molnar <***@elte.hu>
Cc: Thomas Gleixner <***@linuxtronix.de>
Cc: Jiri Slaby <***@gmail.com>
---

kernel/softlockup.c | 14 ++++++++++++--
1 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/kernel/softlockup.c b/kernel/softlockup.c
index 576eb9c..b1a8c7c 100644
--- a/kernel/softlockup.c
+++ b/kernel/softlockup.c
@@ -194,6 +194,9 @@ static void check_hung_uninterruptible_tasks(int this_cpu)
read_unlock(&tasklist_lock);
}

+
+static int check_cpu = -1;
+
/*
* The watchdog thread - runs every second and touches the timestamp.
*/
@@ -219,8 +222,6 @@ static int watchdog(void *__bind_cpu)
/*
* Only do the hung-tasks check on one CPU:
*/
- check_cpu = any_online_cpu(cpu_online_map);
-
if (this_cpu != check_cpu)
continue;

@@ -255,6 +256,7 @@ cpu_callback(struct notifier_block *nfb, unsigned long action, void *hcpu)
break;
case CPU_ONLINE:
case CPU_ONLINE_FROZEN:
+ check_cpu = any_online_cpu(cpu_online_map);
wake_up_process(per_cpu(watchdog_task, hotcpu));
break;
#ifdef CONFIG_HOTPLUG_CPU
@@ -265,6 +267,14 @@ cpu_callback(struct notifier_block *nfb, unsigned long action, void *hcpu)
/* Unbind so it can run. Fall thru. */
kthread_bind(per_cpu(watchdog_task, hotcpu),
any_online_cpu(cpu_online_map));
+ case CPU_DOWN_PREPARE:
+ case CPU_DOWN_PREPARE_FROZEN:
+ if (hotcpu == check_cpu) {
+ cpumask_t temp_cpu_online_map = cpu_online_map;
+ cpu_clear(hotcpu, temp_cpu_online_map);
+ check_cpu = any_online_cpu(temp_cpu_online_map);
+ }
+ break;
case CPU_DEAD:
case CPU_DEAD_FROZEN:
p = per_cpu(watchdog_task, hotcpu);
Post by Ingo Molnar
Ingo
Thanks and Regards
gautham.
--
Gautham R Shenoy
Linux Technology Center
IBM India.
"Freedom comes with a price tag of responsibility, which is still a bargain,
because Freedom is priceless!"
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Ingo Molnar
2007-12-10 11:30:20 UTC
Permalink
Post by Gautham R Shenoy
Post by Ingo Molnar
say we've got 100 CPUs, so we've got 100 watchdog tasks running -
one for each CPU. Checking for hung tasks is a global operation not
a per-CPU operation (we iterate over the global tasklist), hence
only one CPU should really be calling this function. That
online-cpus logic achieves this by picking a single CPU. Perhaps it
would be better to keep a hung_task_checker_cpu variable that is
driven from a CPU-hotplug-down notifier? That way if a CPU is
brought down we can update hung_task_checker_cpu to another,
still-online CPU. (this would also be faster, because event-driven)
Do you mean something like this?
yeah, thanks - queued it up.
Post by Gautham R Shenoy
+static int check_cpu = -1;
+ check_cpu = any_online_cpu(cpu_online_map);
wake_up_process(per_cpu(watchdog_task, hotcpu));
break;
do we bring the boot CPU online too - i.e. will check_cpu be properly
initialized on UP too?

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Gautham R Shenoy
2007-12-10 12:00:19 UTC
Permalink
Post by Ingo Molnar
Post by Gautham R Shenoy
Post by Ingo Molnar
say we've got 100 CPUs, so we've got 100 watchdog tasks running -
one for each CPU. Checking for hung tasks is a global operation not
a per-CPU operation (we iterate over the global tasklist), hence
only one CPU should really be calling this function. That
online-cpus logic achieves this by picking a single CPU. Perhaps it
would be better to keep a hung_task_checker_cpu variable that is
driven from a CPU-hotplug-down notifier? That way if a CPU is
brought down we can update hung_task_checker_cpu to another,
still-online CPU. (this would also be faster, because event-driven)
Do you mean something like this?
yeah, thanks - queued it up.
Stupid me! I forgot to remove the local variable check_cpu in static
int watchdog(void * __bind_cpu). Could you please correct it before
applying?
Post by Ingo Molnar
Post by Gautham R Shenoy
+static int check_cpu = -1;
+ check_cpu = any_online_cpu(cpu_online_map);
wake_up_process(per_cpu(watchdog_task, hotcpu));
break;
do we bring the boot CPU online too - i.e. will check_cpu be properly
initialized on UP too?
Yes, it does.
Post by Ingo Molnar
Ingo
Thanks and Regards
gautham.
--
Gautham R Shenoy
Linux Technology Center
IBM India.
"Freedom comes with a price tag of responsibility, which is still a bargain,
because Freedom is priceless!"
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Ingo Molnar
2007-12-10 09:40:21 UTC
Permalink
Further more this can cause a deadlock since we're calling
get_online_cpus() from the watchdog thread's context, which is going
to be kthread_stop'ed from a cpu-hotplug context. This is what I think
was happening in the case reported by Jiri.
Please find the patch below.
thanks, and i've updated sched-devel.git.

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Gautham R Shenoy
2007-12-10 10:10:14 UTC
Permalink
Post by Ingo Molnar
Post by Jiri Slaby
Post by Ingo Molnar
i'm wondering why it had no effect now
diff --git a/kernel/cpu.c b/kernel/cpu.c
index e0d3a4f..a46c252 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -47,15 +47,21 @@ void __init cpu_hotplug_init(void)
}
#ifdef CONFIG_HOTPLUG_CPU
-
+#include <asm/io.h>
void get_online_cpus(void)
{
+ outb(0x20, 0x80);
might_sleep();
+ outb(0x21, 0x80);
ah. If you comment out get_online_cpus()/put_online_cpus() from
kernel/softlockup.c, does it start working?
Gautham, any ideas?
Hi Ingo,

From the code I fail to see how get_online_cpus() can help us.

+ /*
+ * Only do the hung-tasks check on one CPU:
+ */
+ get_online_cpus();
+ check_cpu = any_online_cpu(cpu_online_map);
+ put_online_cpus();

check_cpu can go offline here, no?

+
+ if (this_cpu != check_cpu)
+ continue;
+
+ if (sysctl_hung_task_timeout_secs)
+ check_hung_uninterruptible_tasks(this_cpu);

Further more this can cause a deadlock since we're calling
get_online_cpus() from the watchdog thread's context,
which is going to be kthread_stop'ed from a cpu-hotplug context.
This is what I think was happening in the case reported by Jiri.

Please find the patch below.

Thanks and Regards
gautham.

commit 15bfb662b35c609490185fba2fd4713d230b9374
Author: Gautham R Shenoy <***@in.ibm.com>
Date: Mon Dec 10 13:41:45 2007 +0530

softlockup: remove get_online_cpus() which doesn't help here.

The get_online_cpus() protection seems to be bogus
in kernel/softlockup.c as cpu cached in check_cpu can go offline
once we do a put_online_cpus().

This can also cause deadlock during a cpu offline as follows:

WATCHDOG_THREAD: OFFLINE_CPU:
mutex_down(&cpu_hotplug.lock);
/* All subsequent get_online_cpus
* will be blocked till we're
* done with this cpu-hotplug
* operation.
*/

get_online_cpus();
/* watchdog is blocked
Thus we cannot
go further until
the cpu-hotplug
operation completes
*/
CPU_DEAD:
kthread_stop(watchdog_thread);

/* we're trying to stop a
* thread which is blocked
* waiting for us to finish.
*
* Since we cannot finish until
* the thread stops, we deadlock here!
*/

Signed-off-by: Gautham R Shenoy <***@in.ibm.com>
Cc: Ingo Molnar <***@elte.hu>
Cc: Thomas Gleixner <***@linuxtronix.de>
Cc: Arjan van de Van <***@linux.intel.com>
Cc: Jiri Slaby <***@gmail.com>

diff --git a/kernel/softlockup.c b/kernel/softlockup.c
index e50b44a..576eb9c 100644
--- a/kernel/softlockup.c
+++ b/kernel/softlockup.c
@@ -219,9 +219,7 @@ static int watchdog(void *__bind_cpu)
/*
* Only do the hung-tasks check on one CPU:
*/
- get_online_cpus();
check_cpu = any_online_cpu(cpu_online_map);
- put_online_cpus();

if (this_cpu != check_cpu)
continue;
--
Gautham R Shenoy
Linux Technology Center
IBM India.
"Freedom comes with a price tag of responsibility, which is still a bargain,
because Freedom is priceless!"
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Mariusz Kozlowski
2007-12-07 18:20:12 UTC
Permalink
Hello,

This patch fixes the compilation breakage. Normally you don't see
that as this piece of code is under #ifdef DEBUG. This was introduced by
git-md-accel.patch at line 3179.

Signed-off-by: Mariusz Kozlowski <***@tuxland.pl>

drivers/md/raid5.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-2.6.24-rc4-mm1-a/drivers/md/raid5.c 2007-12-06 09:27:02.000000000 +0100
+++ linux-2.6.24-rc4-mm1-b/drivers/md/raid5.c 2007-12-06 09:28:14.000000000 +0100
@@ -4972,7 +4972,7 @@ static void print_sh (struct seq_file *s
seq_printf(seq, "sh %llu, count %d.\n",
(unsigned long long)sh->sector, atomic_read(&sh->count));
seq_printf(seq, "sh %llu, ", (unsigned long long)sh->sector);
- for (i = 0; i < sh->sq->disks; i++) {
+ for (i = 0; i < sh->sq->disks; i++)
seq_printf(seq, "(cache%d: %p %ld) ",
i, sh->dev[i].page, sh->dev[i].flags);
seq_printf(seq, "\n");


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Mariusz Kozlowski
2007-12-08 00:00:10 UTC
Permalink
Hello,

I tried it on sun ultra 60 (dual sparc64) station. Unfortunately it failed
to compile.

AS arch/sparc64/lib/xor.o
AR arch/sparc64/lib/lib.a
GEN .version
CHK include/linux/compile.h
dnsdomainname: Unknown host
UPD include/linux/compile.h
CC init/version.o
LD init/built-in.o
LD .tmp_vmlinux1
arch/sparc64/kernel/head.o: In function `sys_call_table32':
arch/sparc64/kernel/head.S:(.text+0x224e0): undefined reference to `compat_sys_timerfd'
make: *** [.tmp_vmlinux1] Error 1

Any hints?

Regards,

Mariusz

Linux sparc64 2.6.23-gentoo-r3 #4 SMP PREEMPT Sat Dec 8 00:50:12 CET 2007 sparc64 sun4u TI UltraSparc II (BlackBird) GNU/Linux

Gnu C 4.1.1
Gnu make 3.81
binutils 2.17
util-linux 2.12r
mount 2.12r
module-init-tools 3.2.2
e2fsprogs 1.39
Linux C Library 2.5
Dynamic linker (ldd) 2.5
Procps 3.2.6
Net-tools 1.60
Kbd 1.12
Sh-utils 6.4
udev 104
Modules Loaded sr_mod cdrom sg
Andrew Morton
2007-12-08 00:10:07 UTC
Permalink
On Sat, 8 Dec 2007 01:04:55 +0100
Post by Mariusz Kozlowski
Hello,
I tried it on sun ultra 60 (dual sparc64) station. Unfortunately it failed
to compile.
AS arch/sparc64/lib/xor.o
AR arch/sparc64/lib/lib.a
GEN .version
CHK include/linux/compile.h
dnsdomainname: Unknown host
UPD include/linux/compile.h
CC init/version.o
LD init/built-in.o
LD .tmp_vmlinux1
arch/sparc64/kernel/head.S:(.text+0x224e0): undefined reference to `compat_sys_timerfd'
make: *** [.tmp_vmlinux1] Error 1
argh, sorry, I am soooooo fed up with fixing that patch.

--- a/arch/sparc64/kernel/systbls.S~timerfd-v3-new-timerfd-api-sparc64-fix
+++ a/arch/sparc64/kernel/systbls.S
@@ -80,7 +80,7 @@ sys_call_table32:
.word sys_fchmodat, sys_faccessat, compat_sys_pselect6, compat_sys_ppoll, sys_unshare
/*300*/ .word compat_sys_set_robust_list, compat_sys_get_robust_list, compat_sys_migrate_pages, compat_sys_mbind, compat_sys_get_mempolicy
.word compat_sys_set_mempolicy, compat_sys_kexec_load, compat_sys_move_pages, sys_getcpu, compat_sys_epoll_pwait
-/*310*/ .word compat_sys_utimensat, compat_sys_signalfd, compat_sys_timerfd, sys_eventfd, compat_sys_fallocate
+/*310*/ .word compat_sys_utimensat, compat_sys_signalfd, sys_ni_syscall, sys_eventfd, compat_sys_fallocate

#endif /* CONFIG_COMPAT */

_

Or should this have been sys_nis_syscall()?


I should have picked this up in cross-build testing but iirc
sparc64 broke for other reasons. Let me check on that.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Mariusz Kozlowski
2007-12-08 09:10:13 UTC
Permalink
Post by Andrew Morton
Post by Mariusz Kozlowski
LD .tmp_vmlinux1
arch/sparc64/kernel/head.S:(.text+0x224e0): undefined reference to `compat_sys_timerfd'
make: *** [.tmp_vmlinux1] Error 1
argh, sorry, I am soooooo fed up with fixing that patch.
--- a/arch/sparc64/kernel/systbls.S~timerfd-v3-new-timerfd-api-sparc64-fix
+++ a/arch/sparc64/kernel/systbls.S
.word sys_fchmodat, sys_faccessat, compat_sys_pselect6, compat_sys_ppoll, sys_unshare
/*300*/ .word compat_sys_set_robust_list, compat_sys_get_robust_list, compat_sys_migrate_pages, compat_sys_mbind, compat_sys_get_mempolicy
.word compat_sys_set_mempolicy, compat_sys_kexec_load, compat_sys_move_pages, sys_getcpu, compat_sys_epoll_pwait
-/*310*/ .word compat_sys_utimensat, compat_sys_signalfd, compat_sys_timerfd, sys_eventfd, compat_sys_fallocate
+/*310*/ .word compat_sys_utimensat, compat_sys_signalfd, sys_ni_syscall, sys_eventfd, compat_sys_fallocate
#endif /* CONFIG_COMPAT */
Ok - that helped.

Thanks,

Mariusz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
David Miller
2007-12-11 10:20:12 UTC
Permalink
From: Andrew Morton <***@linux-foundation.org>
Date: Fri, 7 Dec 2007 16:08:00 -0800
Post by Andrew Morton
Or should this have been sys_nis_syscall()?
sys_nis_syscall() was used in cases on sparc where we wanted
to get a log of invocations of unimplemented syscalls, as it
aided debugging and anaylsis.

But the usefulness of such things I think is long gone, so
what I'll likely do is kill the sys_nis_syscall stuff from the
sparc ports.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Mariusz Kozlowski
2007-12-08 18:20:15 UTC
Permalink
Hello,

The box is sun ultra 60 (dual sparc64). This was caught when
system (gentoo) was emerging some package.

[27006.402237] kernel BUG at fs/jbd/transaction.c:1894!
[27006.402268] \|/ ____ \|/
[27006.402274] "@'/ .. \`@"
[27006.402279] /_| \__/ |_\
[27006.402285] \__U_/
[27006.402298] rm(4713): Kernel bad sw trap 5 [#1]
[27006.402538] TSTATE: 0000009911009605 TPC: 000000000053b1cc TNPC: 000000000053b1d0 Y: 00000000 Not tainted
[27006.402579] TPC: <journal_invalidatepage+0x3d4/0x460>
[27006.402593] g0: 0000000000000002 g1: 0000000000000000 g2: 0000000000000001 g3: fffff800a7d90000
[27006.402610] g4: fffff800b54ea460 g5: fffff8007f832000 g6: fffff800a7d90000 g7: 000000000076d868
[27006.402627] o0: 000000000072b660 o1: 0000000000000766 o2: 0000000000000002 o3: 0000000000000001
[27006.402644] o4: 00000000008a2940 o5: 0000000000000000 sp: fffff800a7d92c91 ret_pc: 000000000053b1c4
[27006.402665] RPC: <journal_invalidatepage+0x3cc/0x460>
[27006.402679] l0: fffff800afbf4070 l1: 000000000069511c l2: 0000000000002000 l3: 0000000000000000
[27006.402696] l4: 0000000000000001 l5: fffff800ba4cb730 l6: fffff800bf1cd338 l7: 0000000000000001
[27006.402713] i0: fffff800bf1cd000 i1: 0000000201db2708 i2: 0000000000000000 i3: 0000000000727000
[27006.402730] i4: 0000000000200000 i5: fffff800bf1cd028 i6: fffff800a7d92d51 i7: 0000000000529254
[27006.402763] I7: <ext3_invalidatepage+0x3c/0x60>
[27006.402776] Caller[0000000000529254]: ext3_invalidatepage+0x3c/0x60
[27006.402800] Caller[00000000004b22fc]: do_invalidatepage+0x24/0x60
[27006.402826] Caller[00000000004b29c4]: truncate_complete_page+0x6c/0x80
[27006.402849] Caller[00000000004b2a6c]: truncate_inode_pages_range+0x94/0x440
[27006.402872] Caller[00000000004b2e2c]: truncate_inode_pages+0x14/0x20
[27006.402894] Caller[0000000000529888]: ext3_delete_inode+0x10/0x160
[27006.402918] Caller[00000000004e7ca0]: generic_delete_inode+0x88/0x120
[27006.402949] Caller[00000000004e7e60]: generic_drop_inode+0x128/0x1c0
[27006.402971] Caller[00000000004e75d4]: iput+0x7c/0xa0
[27006.402992] Caller[00000000004dd680]: do_unlinkat+0x108/0x1a0
[27006.403024] Caller[00000000004dd884]: sys_unlinkat+0x2c/0x60
[27006.403047] Caller[00000000004062d4]: linux_sparc_syscall32+0x3c/0x40
[27006.403081] Caller[00000000f7e7d0ec]: 0xf7e7d0f4
[27006.403102] Instruction DUMP: 92102766 7ffbbeaf 90122260 <91d02005> 92102780 7ffbbeab 90122260 91d02005 7ffbbea8

After this happend, one (out of two) cpu got consumed (in kernel space) trying to
complete io. Process stuck in D state, wchan says it was in sync_buffer() which
you can see also in 'SysRq : Show Blocked State' below.

[27422.874858] SysRq : Show Blocked State
[27422.877086] task PC stack pid father
[27422.877143] rm D 00000000004f8f68 0 4966 4860
[27422.877160] Call Trace:
[27422.877167] [0000000000692840] io_schedule+0x28/0x40
[27422.877182] [00000000004f8f68] sync_buffer+0x50/0x60
[27422.877198] [0000000000692a58] __wait_on_bit_lock+0x60/0xa0
[27422.877213] [0000000000692ae4] out_of_line_wait_on_bit_lock+0x4c/0x60
[27422.877228] [00000000004f9328] __lock_buffer+0x30/0x40
[27422.877242] [000000000053b024] journal_invalidatepage+0x22c/0x460
[27422.877268] [0000000000529254] ext3_invalidatepage+0x3c/0x60
[27422.877297] [00000000004b22fc] do_invalidatepage+0x24/0x60
[27422.877316] [00000000004b29c4] truncate_complete_page+0x6c/0x80
[27422.877332] [00000000004b2a6c] truncate_inode_pages_range+0x94/0x440
[27422.877349] [00000000004b2e2c] truncate_inode_pages+0x14/0x20
[27422.877364] [0000000000529888] ext3_delete_inode+0x10/0x160
[27422.877381] [00000000004e7ca0] generic_delete_inode+0x88/0x120
[27422.877405] [00000000004e7e60] generic_drop_inode+0x128/0x1c0
[27422.877421] [00000000004e75d4] iput+0x7c/0xa0
[27422.877435] [00000000004dd680] do_unlinkat+0x108/0x1a0

The downside is that it is unclear to me how to reproduce that - it just happens sometimes.
Also from time to time I get warnings about tcp_fastretrans_alert(), but it seems they do no harm.

[30014.779310] WARNING: at net/ipv4/tcp_input.c:2518 tcp_fastretrans_alert()
[30014.781630] Call Trace:
[30014.783976] [00000000006551c8] tcp_fastretrans_alert+0x70/0xe00
[30014.786312] [0000000000657c60] tcp_ack+0x988/0x10c0
[30014.788702] [000000000065bd80] tcp_rcv_established+0x408/0x840
[30014.791074] [00000000006634dc] tcp_v4_do_rcv+0xe4/0x4a0
[30014.793440] [000000000066632c] tcp_v4_rcv+0xa34/0xb20
[30014.795762] [0000000000643a10] ip_local_deliver+0xd8/0x2c0
[30014.798102] [0000000000643ed4] ip_rcv+0x2dc/0x640
[30014.800431] [000000000062424c] netif_receive_skb+0x334/0x400
[30014.802762] [0000000000627228] process_backlog+0x90/0x140
[30014.805097] [0000000000626d28] net_rx_action+0x190/0x260
[30014.807462] [0000000000475ea8] __do_softirq+0x90/0x140
[30014.809794] [0000000000475fe0] do_softirq+0x88/0xa0
[30014.812134] [000000000047608c] irq_exit+0x94/0xc0
[30014.814453] [000000000042f53c] handler_irq+0xa4/0xc0
[30014.816800] [0000000000426f30] sunos_sys_table+0x560/0x728
[30014.819133] [00000000004286d8] cpu_idle+0x20/0xe0

Linux sparc64 2.6.24-rc4-mm1 #2 SMP PREEMPT Sat Dec 8 10:59:35 CET 2007 sparc64 sun4u TI UltraSparc II (BlackBird) GNU/Linux

Gnu C 4.1.1
Gnu make 3.81
binutils 2.18
util-linux 2.12r
mount 2.12r
module-init-tools 3.2.2
e2fsprogs 1.40.2
Linux C Library 2.5
Dynamic linker (ldd) 2.5
Procps 3.2.7
Net-tools 1.60
Kbd 1.13
Sh-utils 6.9
udev 104
Modules Loaded sr_mod cdrom sg

Regards,

Mariusz
Andrew Morton
2007-12-08 18:30:13 UTC
Permalink
Post by Mariusz Kozlowski
The box is sun ultra 60 (dual sparc64). This was caught when
system (gentoo) was emerging some package.
[27006.402237] kernel BUG at fs/jbd/transaction.c:1894!
That's

J_ASSERT_BH(bh, !buffer_jbddirty(bh));

at the end of journal_unmap_buffer().

I don't recall seeing that before and I can't think of anything we've
done recently which could cause it, sorry.
Post by Mariusz Kozlowski
[27006.402268] \|/ ____ \|/
[27006.402279] /_| \__/ |_\
[27006.402285] \__U_/
x86 needs that.
Post by Mariusz Kozlowski
[27006.402298] rm(4713): Kernel bad sw trap 5 [#1]
[27006.402538] TSTATE: 0000009911009605 TPC: 000000000053b1cc TNPC: 000000000053b1d0 Y: 00000000 Not tainted
[27006.402579] TPC: <journal_invalidatepage+0x3d4/0x460>
[27006.402593] g0: 0000000000000002 g1: 0000000000000000 g2: 0000000000000001 g3: fffff800a7d90000
[27006.402610] g4: fffff800b54ea460 g5: fffff8007f832000 g6: fffff800a7d90000 g7: 000000000076d868
[27006.402627] o0: 000000000072b660 o1: 0000000000000766 o2: 0000000000000002 o3: 0000000000000001
[27006.402644] o4: 00000000008a2940 o5: 0000000000000000 sp: fffff800a7d92c91 ret_pc: 000000000053b1c4
[27006.402665] RPC: <journal_invalidatepage+0x3cc/0x460>
[27006.402679] l0: fffff800afbf4070 l1: 000000000069511c l2: 0000000000002000 l3: 0000000000000000
[27006.402696] l4: 0000000000000001 l5: fffff800ba4cb730 l6: fffff800bf1cd338 l7: 0000000000000001
[27006.402713] i0: fffff800bf1cd000 i1: 0000000201db2708 i2: 0000000000000000 i3: 0000000000727000
[27006.402730] i4: 0000000000200000 i5: fffff800bf1cd028 i6: fffff800a7d92d51 i7: 0000000000529254
[27006.402763] I7: <ext3_invalidatepage+0x3c/0x60>
[27006.402776] Caller[0000000000529254]: ext3_invalidatepage+0x3c/0x60
[27006.402800] Caller[00000000004b22fc]: do_invalidatepage+0x24/0x60
[27006.402826] Caller[00000000004b29c4]: truncate_complete_page+0x6c/0x80
[27006.402849] Caller[00000000004b2a6c]: truncate_inode_pages_range+0x94/0x440
[27006.402872] Caller[00000000004b2e2c]: truncate_inode_pages+0x14/0x20
[27006.402894] Caller[0000000000529888]: ext3_delete_inode+0x10/0x160
[27006.402918] Caller[00000000004e7ca0]: generic_delete_inode+0x88/0x120
[27006.402949] Caller[00000000004e7e60]: generic_drop_inode+0x128/0x1c0
[27006.402971] Caller[00000000004e75d4]: iput+0x7c/0xa0
[27006.402992] Caller[00000000004dd680]: do_unlinkat+0x108/0x1a0
[27006.403024] Caller[00000000004dd884]: sys_unlinkat+0x2c/0x60
[27006.403047] Caller[00000000004062d4]: linux_sparc_syscall32+0x3c/0x40
[27006.403081] Caller[00000000f7e7d0ec]: 0xf7e7d0f4
[27006.403102] Instruction DUMP: 92102766 7ffbbeaf 90122260 <91d02005> 92102780 7ffbbeab 90122260 91d02005 7ffbbea8
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
David Miller
2007-12-09 08:50:07 UTC
Permalink
From: Andrew Morton <***@linux-foundation.org>
Date: Sat, 8 Dec 2007 10:22:39 -0800
Post by Greg KH
That's
J_ASSERT_BH(bh, !buffer_jbddirty(bh));
at the end of journal_unmap_buffer().
I don't recall seeing that before and I can't think of anything we've
done recently which could cause it, sorry.
If the per-cpu data patches are in the -mm tree that is the first
place I would start looking at for possible cause.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Andrew Morton
2007-12-09 09:10:08 UTC
Permalink
Post by David Miller
Date: Sat, 8 Dec 2007 10:22:39 -0800
Post by Greg KH
That's
J_ASSERT_BH(bh, !buffer_jbddirty(bh));
at the end of journal_unmap_buffer().
I don't recall seeing that before and I can't think of anything we've
done recently which could cause it, sorry.
If the per-cpu data patches are in the -mm tree that is the first
place I would start looking at for possible cause.
They aren't. The dust hadn't settled enough on those when Christoph shot
through on vacation.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Reuben Farrelly
2007-12-10 14:50:09 UTC
Permalink
Post by Andrew Morton
Temporarily at
http://userweb.kernel.org/~akpm/2.6.24-rc4-mm1/
Will appear later at
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc4/2.6.24-rc4-mm1/
- Lots of device IDs have been removed from the e1000 driver and moved over
to e1000e. So if your e1000 stops working, you forgot to set CONFIG_E1000E.
- The s390 build is still broken.
I'm seeing this most incredibly unhelpful (to debug) but fortunately
reproduceable problem (so far 4/4 times) on this -mm kernel. I thought this
problem may have been related to another bug which I have reported (A TCP oops)
but even after applying a likely fix for that I am still seeing this problem.

The machine boots up perfectly fine and runs good until I load it up.
In this case I can reliably cause this to occur by pulling a 3G ISO across the
GigE network from my Linux box to my PC. After maybe 50M or so, the console
just displays this (ignore initial boot banner):

----------

* Starting local ... [ ok ]


This is tornado.reub.net (Linux x86_64 2.6.24-rc4-mm1) 00:24:01

tornado login: *** buffer overf

-------

Yes - after displaying the 'f' in what I can only guess is the word 'overflow',
the box spontaneously reboots. There is no further console output until it
starts to come back up again.

The problem does not exist in 2.6.23-gentoo kernels nor in a vanilla
2.6.24-rc4-git6 (phew!), so this looks to be an -mm only problem at this stage.

I enabled a number of kernel debugging options but then I got no output at all
when the machine crashed.

I'm at a bit of a loss as to which subsystem this might be coming from, so I'm
not sure who to CC.

Box information is (still) up at http://www.reub.net/files/kernel/2.6.24-rc4-mm1/

Thanks,
Reuben




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Andrew Morton
2007-12-10 21:20:13 UTC
Permalink
On Tue, 11 Dec 2007 01:48:39 +1100
Post by Reuben Farrelly
Post by Andrew Morton
Temporarily at
http://userweb.kernel.org/~akpm/2.6.24-rc4-mm1/
Will appear later at
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc4/2.6.24-rc4-mm1/
- Lots of device IDs have been removed from the e1000 driver and moved over
to e1000e. So if your e1000 stops working, you forgot to set CONFIG_E1000E.
- The s390 build is still broken.
I'm seeing this most incredibly unhelpful (to debug) but fortunately
reproduceable problem (so far 4/4 times) on this -mm kernel. I thought this
problem may have been related to another bug which I have reported (A TCP oops)
but even after applying a likely fix for that I am still seeing this problem.
The machine boots up perfectly fine and runs good until I load it up.
In this case I can reliably cause this to occur by pulling a 3G ISO across the
GigE network from my Linux box to my PC. After maybe 50M or so, the console
----------
* Starting local ... [ ok ]
This is tornado.reub.net (Linux x86_64 2.6.24-rc4-mm1) 00:24:01
tornado login: *** buffer overf
-------
Yes - after displaying the 'f' in what I can only guess is the word 'overflow',
the box spontaneously reboots. There is no further console output until it
starts to come back up again.
The problem does not exist in 2.6.23-gentoo kernels nor in a vanilla
2.6.24-rc4-git6 (phew!), so this looks to be an -mm only problem at this stage.
I enabled a number of kernel debugging options but then I got no output at all
when the machine crashed.
I'm at a bit of a loss as to which subsystem this might be coming from, so I'm
not sure who to CC.
Box information is (still) up at http://www.reub.net/files/kernel/2.6.24-rc4-mm1/
hm. grepping around for "buffer overflow" doesn't turn up anything except in
drivers which you won't be using on that machine.

I'd be suspecting networking, obviously. If you're feeling keen could you please
grep a 2.6.24-rc4 tree and apply 2.6.24-rc4-mm1's origin.patch and git-net.patch
and see if the bug is still present?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Reuben Farrelly
2007-12-11 14:20:13 UTC
Permalink
Post by Andrew Morton
On Tue, 11 Dec 2007 01:48:39 +1100
Post by Reuben Farrelly
Post by Andrew Morton
Temporarily at
http://userweb.kernel.org/~akpm/2.6.24-rc4-mm1/
Will appear later at
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc4/2.6.24-rc4-mm1/
- Lots of device IDs have been removed from the e1000 driver and moved over
to e1000e. So if your e1000 stops working, you forgot to set CONFIG_E1000E.
- The s390 build is still broken.
I'm seeing this most incredibly unhelpful (to debug) but fortunately
reproduceable problem (so far 4/4 times) on this -mm kernel. I thought this
problem may have been related to another bug which I have reported (A TCP oops)
but even after applying a likely fix for that I am still seeing this problem.
The machine boots up perfectly fine and runs good until I load it up.
In this case I can reliably cause this to occur by pulling a 3G ISO across the
GigE network from my Linux box to my PC. After maybe 50M or so, the console
----------
* Starting local ... [ ok ]
This is tornado.reub.net (Linux x86_64 2.6.24-rc4-mm1) 00:24:01
tornado login: *** buffer overf
-------
Yes - after displaying the 'f' in what I can only guess is the word 'overflow',
the box spontaneously reboots. There is no further console output until it
starts to come back up again.
The problem does not exist in 2.6.23-gentoo kernels nor in a vanilla
2.6.24-rc4-git6 (phew!), so this looks to be an -mm only problem at this stage.
I enabled a number of kernel debugging options but then I got no output at all
when the machine crashed.
I'm at a bit of a loss as to which subsystem this might be coming from, so I'm
not sure who to CC.
Box information is (still) up at http://www.reub.net/files/kernel/2.6.24-rc4-mm1/
hm. grepping around for "buffer overflow" doesn't turn up anything except in
drivers which you won't be using on that machine.
I'd be suspecting networking, obviously. If you're feeling keen could you please
grep a 2.6.24-rc4 tree and apply 2.6.24-rc4-mm1's origin.patch and git-net.patch
and see if the bug is still present?
No - seems to be fine with just origin.patch and git-net.patch.

Just for good measure I then reverted git-net.patch and applied
git-netdev-all.patch instead, and still wasn't able to trigger the reboot or
console message, no matter how hard I tried.

I guess for now I'll sit on it, and if it appears in the next -mm it'll probably
annoy me enough and inspire me to dig deeper (or, "guess" deeper, given the lack
of direction as to where to even begin).

Reuben
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Martin Bligh
2007-12-11 16:50:13 UTC
Permalink
Post by Andrew Morton
- Lots of device IDs have been removed from the e1000 driver and
moved over to e1000e. So if your e1000 stops working, you forgot
to set CONFIG_E1000E.
Wouldn't it make sense to just default this to on if E1000 was on?
As far as I can see that's not true, which will screwing everybody
for no good reason (plus breaking all the automated testing, etc etc)?
Much though I love random refactoring, it is fairly painful to just
keep changing the names of things.


I can't see this compile failure posted anywhere:
http://test.kernel.org/results/IBM/126049/build/debug/stderr

arch/x86/vdso/vdso32/sigreturn.S: Assembler messages:
arch/x86/vdso/vdso32/sigreturn.S:23: Error: suffix or operands invalid
for `pop'

arch/x86/vdso/vdso32/syscall.S:25: Error: suffix or operands invalid for
`pop'
make[1]: *** [arch/x86/vdso/vdso32/syscall.o] Error 1
make: *** [arch/x86/vdso] Error 2


Nor this one:
http://test.kernel.org/results/IBM/126096/build/debug/stderr

drivers/char/hvcs.c: In function ‘hvcs_open’:
drivers/char/hvcs.c:1180: error: wrong type argument to unary
exclamation mark
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Randy Dunlap
2007-12-11 17:10:12 UTC
Permalink
Post by Martin Bligh
Post by Andrew Morton
- Lots of device IDs have been removed from the e1000 driver and
moved over to e1000e. So if your e1000 stops working, you forgot
to set CONFIG_E1000E.
Wouldn't it make sense to just default this to on if E1000 was on?
As far as I can see that's not true, which will screwing everybody
for no good reason (plus breaking all the automated testing, etc etc)?
Much though I love random refactoring, it is fairly painful to just
keep changing the names of things.
http://test.kernel.org/results/IBM/126049/build/debug/stderr
arch/x86/vdso/vdso32/sigreturn.S:23: Error: suffix or operands invalid
for `pop'
arch/x86/vdso/vdso32/syscall.S:25: Error: suffix or operands invalid for
`pop'
make[1]: *** [arch/x86/vdso/vdso32/syscall.o] Error 1
make: *** [arch/x86/vdso] Error 2
I see those on one build machine but not on another, so I thought
that it was a tools issue...
Post by Martin Bligh
http://test.kernel.org/results/IBM/126096/build/debug/stderr
drivers/char/hvcs.c:1180: error: wrong type argument to unary
exclamation mark
See http://marc.info/?l=linux-kernel&m=119700448119646
for patches.


---
~Randy
Features and documentation: http://lwn.net/Articles/260136/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Martin Bligh
2007-12-11 18:00:13 UTC
Permalink
Post by Randy Dunlap
Post by Martin Bligh
http://test.kernel.org/results/IBM/126049/build/debug/stderr
arch/x86/vdso/vdso32/sigreturn.S:23: Error: suffix or operands invalid
for `pop'
arch/x86/vdso/vdso32/syscall.S:25: Error: suffix or operands invalid for
`pop'
make[1]: *** [arch/x86/vdso/vdso32/syscall.o] Error 1
make: *** [arch/x86/vdso] Error 2
I see those on one build machine but not on another, so I thought
that it was a tools issue...
If so, it's a tools issue that worked fine until -mm1, which makes
it a kernel problem in my mind ;-)
Post by Randy Dunlap
Post by Martin Bligh
http://test.kernel.org/results/IBM/126096/build/debug/stderr
drivers/char/hvcs.c:1180: error: wrong type argument to unary
exclamation mark
See http://marc.info/?l=linux-kernel&m=119700448119646
for patches.
Thanks,

M.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Andrew Morton
2007-12-11 20:40:10 UTC
Permalink
Post by Andrew Morton
- Lots of device IDs have been removed from the e1000 driver and moved over
to e1000e. So if your e1000 stops working, you forgot to set CONFIG_E1000E.
Wouldn't it make sense to just default this to on if E1000 was on, rather
than screwing
everybody for no good reason (plus breaking all the automated testing, etc
etc)?
Much though I love random refactoring, it is fairly painful to just keep
changing the
names of things.
(cc netdev and Auke)

Yes, that would be very sensible. CONFIG_E1000E should default to whatever
CONFIG_E1000 was set to.
http://test.kernel.org/results/IBM/126049/build/debug/stderr
arch/x86/vdso/vdso32/sigreturn.S:23: Error: suffix or operands invalid for `pop'
arch/x86/vdso/vdso32/syscall.S:25: Error: suffix or operands invalid for `pop'
make[1]: *** [arch/x86/vdso/vdso32/syscall.o] Error 1
make: *** [arch/x86/vdso] Error 2
(cc Ingo and Thomas)
http://test.kernel.org/results/IBM/126096/build/debug/stderr
drivers/char/hvcs.c:1180: error: wrong type argument to unary exclamation mark
(cc Greg)

Caused by gregkh-driver-kobject-convert-hvcs-to-use-kref-not-kobject.patch.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Ingo Molnar
2007-12-11 21:30:16 UTC
Permalink
Post by Andrew Morton
Post by Martin Bligh
http://test.kernel.org/results/IBM/126049/build/debug/stderr
arch/x86/vdso/vdso32/sigreturn.S:23: Error: suffix or operands invalid for `pop'
arch/x86/vdso/vdso32/syscall.S:25: Error: suffix or operands invalid for `pop'
make[1]: *** [arch/x86/vdso/vdso32/syscall.o] Error 1
make: *** [arch/x86/vdso] Error 2
(cc Ingo and Thomas)
Roland says:

| That seems like it must be a tool problem. The V=1 output would show
| if those compiles missed -m32 or something. But even in the wrong
| mode, this error does not make sense. The assembly code it's citing
| is identical to the old arch/x86/ia32/vsyscall-syscall.S code.

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Kok, Auke
2007-12-11 21:40:06 UTC
Permalink
Post by Andrew Morton
Post by Andrew Morton
- Lots of device IDs have been removed from the e1000 driver and moved over
to e1000e. So if your e1000 stops working, you forgot to set CONFIG_E1000E.
Wouldn't it make sense to just default this to on if E1000 was on, rather
than screwing
everybody for no good reason (plus breaking all the automated testing, etc
etc)?
Much though I love random refactoring, it is fairly painful to just keep
changing the
names of things.
(cc netdev and Auke)
Yes, that would be very sensible. CONFIG_E1000E should default to whatever
CONFIG_E1000 was set to.
which is "y" for x86 and friends, ppc, arm and ia64 through 'defconfig'. the
Kconfig files do not have defaults in them.

I can send a patch to adjust the defconfig files, would that be OK? I certainly
think that would be reasonable, I dislike setting defaults through defconfig for
network drivers myself and rather would not do that.

Auke
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Kok, Auke
2007-12-11 22:10:15 UTC
Permalink
Post by Kok, Auke
Post by Andrew Morton
Post by Andrew Morton
- Lots of device IDs have been removed from the e1000 driver and moved over
to e1000e. So if your e1000 stops working, you forgot to set CONFIG_E1000E.
Wouldn't it make sense to just default this to on if E1000 was on, rather
than screwing
everybody for no good reason (plus breaking all the automated testing, etc
etc)?
Much though I love random refactoring, it is fairly painful to just keep
changing the
names of things.
(cc netdev and Auke)
Yes, that would be very sensible. CONFIG_E1000E should default to whatever
CONFIG_E1000 was set to.
which is "y" for x86 and friends, ppc, arm and ia64 through 'defconfig'. the
Kconfig files do not have defaults in them.
I can send a patch to adjust the defconfig files, would that be OK? I certainly
think that would be reasonable, I dislike setting defaults through defconfig for
network drivers myself and rather would not do that.
that should read "dislike setting defaults through Kconfig ..."

Auke
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Continue reading on narkive:
Loading...