2007-12-05 05:17:20

by Andrew Morton

[permalink] [raw]
Subject: 2.6.24-rc4-mm1


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 [email protected]

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

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

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

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

- 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


2007-12-05 09:11:20

by Olof Johansson

[permalink] [raw]
Subject: 2.6.24-rc4-mm1: kobj changes fallout on powerpc

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

2007-12-05 13:12:29

by Kamalesh Babulal

[permalink] [raw]
Subject: Re: 2.6.24-rc4-mm1: kobj changes fallout on powerpc

On Wed, Dec 05, 2007 at 03:15:15AM -0600, Olof Johansson wrote:
> 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
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 <[email protected]>
--
--- 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,

2007-12-05 14:12:18

by Kamalesh Babulal

[permalink] [raw]
Subject: Re: 2.6.24-rc4-mm1 kobject changes broken with hvcs driver on powerpc

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 <[email protected]>
--
--- 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++;

2007-12-05 15:44:54

by Greg KH

[permalink] [raw]
Subject: Re: 2.6.24-rc4-mm1 kobject changes broken with hvcs driver on powerpc

On Wed, Dec 05, 2007 at 07:42:02PM +0530, Kamalesh Babulal wrote:
> 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

Oops, sorry about that, my fault. I'll merge your fix in with my
original patch, thanks for it.

greg k-h

2007-12-05 15:45:13

by Greg KH

[permalink] [raw]
Subject: Re: 2.6.24-rc4-mm1: kobj changes fallout on powerpc

On Wed, Dec 05, 2007 at 06:41:40PM +0530, Kamalesh Babulal wrote:
> On Wed, Dec 05, 2007 at 03:15:15AM -0600, Olof Johansson wrote:
> > 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
> 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.

> Signed-off-by: Kamalesh Babulal <[email protected]>
> --
> --- 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

2007-12-05 23:42:18

by Alexey Dobriyan

[permalink] [raw]
Subject: 2.6.24-rc4-mm1: hostbyte=0x01 driverbyte=0x00 (now bisected)

> 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 <[email protected]>
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 <[email protected]>
Signed-off-by: James Bottomley <[email protected]>

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:

2007-12-06 03:15:53

by Kamalesh Babulal

[permalink] [raw]
Subject: Re: 2.6.24-rc4-mm1 Kernel build fails on S390x

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.

2007-12-06 07:06:56

by Reuben Farrelly

[permalink] [raw]
Subject: Re: 2.6.24-rc4-mm1

On 5/12/2007 4:17 PM, Andrew Morton wrote:
> 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

2007-12-06 07:09:40

by David Miller

[permalink] [raw]
Subject: Re: 2.6.24-rc4-mm1

From: Reuben Farrelly <[email protected]>
Date: Thu, 06 Dec 2007 17:59:37 +1100

> On 5/12/2007 4:17 PM, Andrew Morton wrote:
> > - 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

No, it's from TCP assertions and changes added by Ilpo to the
net-2.6.25 tree recently.

2007-12-06 07:19:38

by Andrew Morton

[permalink] [raw]
Subject: Re: 2.6.24-rc4-mm1 Kernel build fails on S390x

On Thu, 06 Dec 2007 08:45:37 +0530 Kamalesh Babulal <[email protected]> wrote:

> 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.

--- 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.

2007-12-06 07:35:32

by Andrew Morton

[permalink] [raw]
Subject: Re: 2.6.24-rc4-mm1

On Thu, 06 Dec 2007 17:59:37 +1100 Reuben Farrelly <[email protected]> wrote:

> On 5/12/2007 4:17 PM, Andrew Morton wrote:
> > 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.

> 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/ .
>

Ilpo, Reuben's kernel is talking to you ;)

2007-12-06 07:52:41

by Hannes Reinecke

[permalink] [raw]
Subject: Re: 2.6.24-rc4-mm1: hostbyte=0x01 driverbyte=0x00 (now bisected)

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;
default:
/*


Attachments:
tmp (758.00 B)

2007-12-06 11:49:41

by Valdis Klētnieks

[permalink] [raw]
Subject: Re: 2.6.24-rc4-mm1

On Tue, 04 Dec 2007 21:17:01 PST, Andrew Morton said:
> 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...



Attachments:
(No filename) (226.00 B)

2007-12-06 12:05:39

by Andrew Morton

[permalink] [raw]
Subject: Re: 2.6.24-rc4-mm1

On Thu, 06 Dec 2007 06:49:24 -0500 [email protected] wrote:

> On Tue, 04 Dec 2007 21:17:01 PST, Andrew Morton said:
> > 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...
>

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 [email protected] cc'ed.

2007-12-06 12:11:23

by Jens Axboe

[permalink] [raw]
Subject: Re: 2.6.24-rc4-mm1: hostbyte=0x01 driverbyte=0x00 (now bisected)

On Thu, Dec 06 2007, Hannes Reinecke wrote:
> Alexey Dobriyan wrote:
> >> 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 <[email protected]>
> > 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 <[email protected]>
> > Signed-off-by: James Bottomley <[email protected]>
> >
> > 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:
> Yeah, sorry. That patch was bad. Please use the attached one instead.
> Andrew, can you replace them?
>
> Cheers,
>
> Hannes
> --
> Dr. Hannes Reinecke zSeries & Storage
> [email protected] +49 911 74053 688
> 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;
> default:
> /*

can we please stick to using blk_noretry_request() consistently, instead
of thwrowing REQ_FAILFAST tests in there?


--
Jens Axboe

2007-12-06 18:20:37

by Balbir Singh

[permalink] [raw]
Subject: Re: 2.6.24-rc4-mm1 kobject changes broken with hvcs driver on powerpc

Kamalesh Babulal wrote:
> 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 <[email protected]>
> --
> --- 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);
>

Why release the spinlock here? It's done after the count is incremented.
This patch does not seem correct.

> hvcsd->open_count++;
>


--
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL

2007-12-06 18:49:34

by Kamalesh Babulal

[permalink] [raw]
Subject: Re: 2.6.24-rc4-mm1 kobject changes broken with hvcs driver on powerpc

Greg KH wrote:
> On Thu, Dec 06, 2007 at 11:49:59PM +0530, Balbir Singh wrote:
>> Kamalesh Babulal wrote:
>>> 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 <[email protected]>
>>> --
>>> --- 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);
>>>
>> 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,

2007-12-06 18:59:30

by Balbir Singh

[permalink] [raw]
Subject: Re: 2.6.24-rc4-mm1 kobject changes broken with hvcs driver on powerpc

Greg KH wrote:

>> 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

2007-12-06 19:18:51

by Valdis Klētnieks

[permalink] [raw]
Subject: Re: 2.6.24-rc4-mm1

On Thu, 06 Dec 2007 04:04:20 PST, Andrew Morton said:

> > > 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...
> >
>
> 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...

> Please keep [email protected] cc'ed.

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...


Attachments:
(No filename) (226.00 B)

2007-12-06 19:19:45

by Badari Pulavarty

[permalink] [raw]
Subject: Re: 2.6.24-rc4-mm1 kobject changes broken with hvcs driver on powerpc

On Fri, 2007-12-07 at 00:28 +0530, Balbir Singh wrote:
> Greg KH wrote:
>
> >> 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


2007-12-06 19:20:17

by Alexey Dobriyan

[permalink] [raw]
Subject: Re: 2.6.24-rc4-mm1: hostbyte=0x01 driverbyte=0x00 (now bisected)

On Thu, Dec 06, 2007 at 08:52:29AM +0100, Hannes Reinecke wrote:
> Alexey Dobriyan wrote:
> >> 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 <[email protected]>
> > 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 <[email protected]>
> > Signed-off-by: James Bottomley <[email protected]>
> >
> > 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:
> 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.

> --- 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;
> default:
> /*

2007-12-06 19:36:00

by Greg KH

[permalink] [raw]
Subject: Re: 2.6.24-rc4-mm1

On Thu, Dec 06, 2007 at 02:18:08PM -0500, [email protected] wrote:
> On Thu, 06 Dec 2007 04:04:20 PST, Andrew Morton said:
>
> > > > 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...
> > >
> >
> > 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...
>
> > Please keep [email protected] cc'ed.
>
> 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?

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

2007-12-06 19:50:21

by Greg KH

[permalink] [raw]
Subject: Re: 2.6.24-rc4-mm1 kobject changes broken with hvcs driver on powerpc

On Thu, Dec 06, 2007 at 11:49:59PM +0530, Balbir Singh wrote:
> Kamalesh Babulal wrote:
> > 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 <[email protected]>
> > --
> > --- 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);
> >
>
> 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

2007-12-06 20:05:07

by Valdis Klētnieks

[permalink] [raw]
Subject: Re: 2.6.24-rc4-mm1

On Thu, 06 Dec 2007 11:38:43 PST, Greg KH said:
> > 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...

> 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...


Attachments:
(No filename) (226.00 B)

2007-12-06 20:29:08

by Greg KH

[permalink] [raw]
Subject: Re: 2.6.24-rc4-mm1 kobject changes broken with hvcs driver on powerpc

On Fri, Dec 07, 2007 at 12:28:58AM +0530, Balbir Singh wrote:
> Greg KH wrote:
>
> >> 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

2007-12-06 22:04:23

by Kay Sievers

[permalink] [raw]
Subject: Re: [dm-devel] Re: 2.6.24-rc4-mm1

On Dec 6, 2007 8:38 PM, Greg KH <[email protected]> wrote:
> On Thu, Dec 06, 2007 at 02:18:08PM -0500, [email protected] wrote:
> > On Thu, 06 Dec 2007 04:04:20 PST, Andrew Morton said:
> >
> > > > > 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...
> > > >
> > >
> > > 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...
> >
> > > Please keep [email protected] cc'ed.
> >
> > 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?
>
> 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

2007-12-06 22:12:34

by Alasdair G Kergon

[permalink] [raw]
Subject: Re: [dm-devel] Re: 2.6.24-rc4-mm1

On Thu, Dec 06, 2007 at 11:04:12PM +0100, Kay Sievers wrote:
> 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
--
[email protected]

2007-12-06 22:28:52

by Laurent Riffard

[permalink] [raw]
Subject: Re: 2.6.24-rc4-mm1: VDSOSYM build error

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.24-rc4-mm1
# Thu Dec 6 23:05:19 2007
#
# CONFIG_64BIT is not set
CONFIG_X86_32=y
# CONFIG_X86_64 is not set
CONFIG_X86=y
CONFIG_GENERIC_TIME=y
CONFIG_GENERIC_CMOS_UPDATE=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_SEMAPHORE_SLEEPERS=y
CONFIG_FAST_CMPXCHG_LOCAL=y
CONFIG_MMU=y
CONFIG_ZONE_DMA=y
CONFIG_QUICKLIST=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_GENERIC_BUG=y
# CONFIG_GENERIC_GPIO is not set
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_DMI=y
# CONFIG_RWSEM_GENERIC_SPINLOCK is not set
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
# CONFIG_ARCH_HAS_ILOG2_U32 is not set
# CONFIG_ARCH_HAS_ILOG2_U64 is not set
CONFIG_GENERIC_CALIBRATE_DELAY=y
# CONFIG_GENERIC_TIME_VSYSCALL is not set
# CONFIG_ZONE_DMA32 is not set
CONFIG_ARCH_POPULATES_NODE_MAP=y
# CONFIG_AUDIT_ARCH is not set
CONFIG_ARCH_SUPPORTS_AOUT=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_X86_BIOS_REBOOT=y
CONFIG_KTIME_SCALAR=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"

#
# General setup
#
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_TASKSTATS is not set
# CONFIG_AUDIT is not set
# CONFIG_IKCONFIG is not set
CONFIG_LOG_BUF_SHIFT=15
# CONFIG_CGROUPS is not set
CONFIG_FAIR_GROUP_SCHED=y
CONFIG_FAIR_USER_SCHED=y
# CONFIG_FAIR_CGROUP_SCHED is not set
CONFIG_SYSFS_DEPRECATED=y
# CONFIG_RELAY is not set
# CONFIG_NAMESPACES is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SYSCTL=y
CONFIG_EMBEDDED=y
CONFIG_UID16=y
CONFIG_SYSCTL_SYSCALL=y
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_ANON_INODES=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_SLAB=y
# CONFIG_SLUB is not set
# CONFIG_SLOB is not set
CONFIG_PROC_PAGE_MONITOR=y
CONFIG_RT_MUTEXES=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
# CONFIG_MODVERSIONS is not set
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y
CONFIG_BLOCK=y
# CONFIG_LBD is not set
# CONFIG_BLK_DEV_IO_TRACE is not set
# CONFIG_LSF is not set
# CONFIG_BLK_DEV_BSG is not set

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

#
# Processor type and features
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ=y
# CONFIG_HIGH_RES_TIMERS is not set
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
# CONFIG_SMP is not set
CONFIG_X86_PC=y
# CONFIG_X86_ELAN is not set
# CONFIG_X86_VOYAGER is not set
# CONFIG_X86_NUMAQ is not set
# CONFIG_X86_SUMMIT is not set
# CONFIG_X86_BIGSMP is not set
# CONFIG_X86_VISWS is not set
# CONFIG_X86_GENERICARCH is not set
# CONFIG_X86_ES7000 is not set
# CONFIG_X86_RDC321X is not set
# CONFIG_X86_VSMP is not set
CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y
# CONFIG_PARAVIRT_GUEST is not set
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMII is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUMM is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
CONFIG_MK7=y
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MEFFICEON is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MGEODEGX1 is not set
# CONFIG_MGEODE_LX is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_MVIAC7 is not set
# CONFIG_MPSC is not set
# CONFIG_MCORE2 is not set
# CONFIG_GENERIC_CPU is not set
# CONFIG_X86_GENERIC is not set
CONFIG_X86_CMPXCHG=y
CONFIG_X86_L1_CACHE_SHIFT=6
CONFIG_X86_XADD=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_USE_3DNOW=y
CONFIG_X86_TSC=y
CONFIG_X86_CMOV=y
CONFIG_X86_MINIMUM_CPU_FAMILY=4
CONFIG_X86_DEBUGCTLMSR=y
CONFIG_HPET_TIMER=y
CONFIG_ARCH_SUPPORTS_KVM=y
# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
CONFIG_PREEMPT=y
CONFIG_PREEMPT_BKL=y
CONFIG_X86_UP_APIC=y
CONFIG_X86_UP_IOAPIC=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_MCE=y
CONFIG_X86_MCE_NONFATAL=m
CONFIG_X86_MCE_P4THERMAL=y
CONFIG_VM86=y
# CONFIG_TOSHIBA is not set
# CONFIG_I8K is not set
CONFIG_X86_REBOOTFIXUPS=y
# CONFIG_MICROCODE is not set
CONFIG_X86_MSR=m
# CONFIG_X86_CPUID is not set
CONFIG_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set
CONFIG_VMSPLIT_3G=y
# CONFIG_VMSPLIT_3G_OPT is not set
# CONFIG_VMSPLIT_2G is not set
# CONFIG_VMSPLIT_2G_OPT is not set
# CONFIG_VMSPLIT_1G is not set
CONFIG_PAGE_OFFSET=0xC0000000
# CONFIG_X86_PAE is not set
CONFIG_ARCH_FLATMEM_ENABLE=y
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_SELECT_MEMORY_MODEL=y
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y
# CONFIG_DISCONTIGMEM_MANUAL is not set
# CONFIG_SPARSEMEM_MANUAL is not set
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
CONFIG_SPARSEMEM_STATIC=y
# CONFIG_SPARSEMEM_VMEMMAP_ENABLE is not set
CONFIG_SPLIT_PTLOCK_CPUS=4
# CONFIG_RESOURCES_64BIT is not set
CONFIG_ZONE_DMA_FLAG=1
CONFIG_BOUNCE=y
CONFIG_NR_QUICK=1
CONFIG_VIRT_TO_BUS=y
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
# CONFIG_EFI is not set
CONFIG_SECCOMP=y
# CONFIG_HZ_100 is not set
CONFIG_HZ_250=y
# CONFIG_HZ_300 is not set
# CONFIG_HZ_1000 is not set
CONFIG_HZ=250
CONFIG_KEXEC=y
CONFIG_PHYSICAL_START=0x100000
# CONFIG_RELOCATABLE is not set
CONFIG_PHYSICAL_ALIGN=0x100000
# CONFIG_COMPAT_VDSO is not set

#
# Power management options
#
CONFIG_PM=y
# CONFIG_PM_LEGACY is not set
# CONFIG_PM_DEBUG is not set
CONFIG_PM_SLEEP=y
CONFIG_SUSPEND_UP_POSSIBLE=y
CONFIG_SUSPEND=y
CONFIG_HIBERNATION_UP_POSSIBLE=y
CONFIG_HIBERNATION=y
CONFIG_PM_STD_PARTITION="/dev/hdb6"
CONFIG_ACPI=y
CONFIG_ACPI_SLEEP=y
# CONFIG_ACPI_PROCFS is not set
CONFIG_ACPI_PROCFS_POWER=y
CONFIG_ACPI_PROC_EVENT=y
# CONFIG_ACPI_AC is not set
# CONFIG_ACPI_BATTERY is not set
CONFIG_ACPI_BUTTON=y
CONFIG_ACPI_FAN=y
# CONFIG_ACPI_DOCK is not set
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_THERMAL=y
# CONFIG_ACPI_ASUS is not set
# CONFIG_ACPI_TOSHIBA is not set
CONFIG_ACPI_BLACKLIST_YEAR=0
CONFIG_ACPI_DEBUG=y
# CONFIG_ACPI_DEBUG_FUNC_TRACE is not set
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_SYSTEM=y
CONFIG_X86_PM_TIMER=y
# CONFIG_ACPI_CONTAINER is not set
# CONFIG_ACPI_SBS is not set
# CONFIG_APM is not set

#
# CPU Frequency scaling
#
# CONFIG_CPU_FREQ is not set
# CONFIG_CPU_IDLE is not set

#
# Bus options (PCI etc.)
#
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GOMMCONFIG is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_MMCONFIG=y
CONFIG_PCI_DOMAINS=y
# CONFIG_PCIEPORTBUS is not set
CONFIG_ARCH_SUPPORTS_MSI=y
# CONFIG_PCI_MSI is not set
# CONFIG_PCI_LEGACY is not set
# CONFIG_PCI_DEBUG is not set
CONFIG_HT_IRQ=y
CONFIG_ISA_DMA_API=y
CONFIG_ISA=y
# CONFIG_EISA is not set
# CONFIG_MCA is not set
# CONFIG_SCx200 is not set
# CONFIG_PCCARD is not set
# CONFIG_HOTPLUG_PCI is not set

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

#
# Networking
#
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=m
# CONFIG_PACKET_MMAP is not set
CONFIG_UNIX=y
CONFIG_XFRM=y
CONFIG_XFRM_USER=m
# CONFIG_XFRM_SUB_POLICY is not set
# CONFIG_XFRM_MIGRATE is not set
# CONFIG_NET_KEY is not set
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_ADVANCED_ROUTER=y
CONFIG_ASK_IP_FIB_HASH=y
# CONFIG_IP_FIB_TRIE is not set
CONFIG_IP_FIB_HASH=y
# CONFIG_IP_MULTIPLE_TABLES is not set
# CONFIG_IP_ROUTE_MULTIPATH is not set
CONFIG_IP_ROUTE_VERBOSE=y
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_IP_MROUTE is not set
# CONFIG_ARPD is not set
CONFIG_SYN_COOKIES=y
CONFIG_INET_AH=m
CONFIG_INET_ESP=m
CONFIG_INET_IPCOMP=m
CONFIG_INET_XFRM_TUNNEL=m
CONFIG_INET_TUNNEL=m
# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
# CONFIG_INET_XFRM_MODE_TUNNEL is not set
CONFIG_INET_XFRM_MODE_BEET=y
# CONFIG_INET_LRO is not set
CONFIG_INET_DIAG=m
CONFIG_INET_TCP_DIAG=m
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_CUBIC=y
CONFIG_DEFAULT_TCP_CONG="cubic"
# CONFIG_TCP_MD5SIG is not set
# CONFIG_IP_VS is not set
# CONFIG_IPV6 is not set
# CONFIG_INET6_XFRM_TUNNEL is not set
# CONFIG_INET6_TUNNEL is not set
# CONFIG_NETWORK_SECMARK is not set
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set

#
# Core Netfilter Configuration
#
CONFIG_NETFILTER_NETLINK=m
CONFIG_NETFILTER_NETLINK_QUEUE=m
CONFIG_NETFILTER_NETLINK_LOG=m
# CONFIG_NF_CONNTRACK_ENABLED is not set
# CONFIG_NF_CONNTRACK is not set
CONFIG_NETFILTER_XTABLES=m
CONFIG_NETFILTER_XT_TARGET_CLASSIFY=m
# CONFIG_NETFILTER_XT_TARGET_DSCP is not set
CONFIG_NETFILTER_XT_TARGET_MARK=m
CONFIG_NETFILTER_XT_TARGET_NFQUEUE=m
# CONFIG_NETFILTER_XT_TARGET_NFLOG is not set
# CONFIG_NETFILTER_XT_TARGET_TCPMSS is not set
CONFIG_NETFILTER_XT_MATCH_COMMENT=m
# CONFIG_NETFILTER_XT_MATCH_DCCP is not set
# CONFIG_NETFILTER_XT_MATCH_DSCP is not set
# CONFIG_NETFILTER_XT_MATCH_ESP is not set
# CONFIG_NETFILTER_XT_MATCH_LENGTH is not set
CONFIG_NETFILTER_XT_MATCH_LIMIT=m
CONFIG_NETFILTER_XT_MATCH_MAC=m
CONFIG_NETFILTER_XT_MATCH_MARK=m
CONFIG_NETFILTER_XT_MATCH_POLICY=m
# CONFIG_NETFILTER_XT_MATCH_MULTIPORT is not set
# CONFIG_NETFILTER_XT_MATCH_PKTTYPE is not set
# CONFIG_NETFILTER_XT_MATCH_QUOTA is not set
# CONFIG_NETFILTER_XT_MATCH_REALM is not set
CONFIG_NETFILTER_XT_MATCH_SCTP=m
# CONFIG_NETFILTER_XT_MATCH_STATISTIC is not set
CONFIG_NETFILTER_XT_MATCH_STRING=m
CONFIG_NETFILTER_XT_MATCH_TCPMSS=m
# CONFIG_NETFILTER_XT_MATCH_TIME is not set
# CONFIG_NETFILTER_XT_MATCH_U32 is not set
# CONFIG_NETFILTER_XT_MATCH_HASHLIMIT is not set

#
# IP: Netfilter Configuration
#
CONFIG_IP_NF_QUEUE=m
CONFIG_IP_NF_IPTABLES=m
CONFIG_IP_NF_MATCH_IPRANGE=m
CONFIG_IP_NF_MATCH_TOS=m
CONFIG_IP_NF_MATCH_RECENT=m
# CONFIG_IP_NF_MATCH_ECN is not set
# CONFIG_IP_NF_MATCH_AH is not set
# CONFIG_IP_NF_MATCH_TTL is not set
CONFIG_IP_NF_MATCH_OWNER=m
CONFIG_IP_NF_MATCH_ADDRTYPE=m
CONFIG_IP_NF_FILTER=m
CONFIG_IP_NF_TARGET_REJECT=m
CONFIG_IP_NF_TARGET_LOG=m
CONFIG_IP_NF_TARGET_ULOG=m
CONFIG_IP_NF_MANGLE=m
CONFIG_IP_NF_TARGET_TOS=m
CONFIG_IP_NF_TARGET_ECN=m
CONFIG_IP_NF_TARGET_TTL=m
# CONFIG_IP_NF_RAW is not set
CONFIG_IP_NF_ARPTABLES=m
CONFIG_IP_NF_ARPFILTER=m
# CONFIG_IP_NF_ARP_MANGLE is not set
# CONFIG_IP_DCCP is not set
# CONFIG_IP_SCTP is not set
# CONFIG_TIPC is not set
CONFIG_ATM=m
CONFIG_ATM_CLIP=m
# CONFIG_ATM_CLIP_NO_ICMP is not set
# CONFIG_ATM_LANE is not set
CONFIG_ATM_BR2684=m
# CONFIG_ATM_BR2684_IPFILTER is not set
# CONFIG_BRIDGE is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
CONFIG_NET_SCHED=y

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

#
# Classification
#
CONFIG_NET_CLS=y
CONFIG_NET_CLS_BASIC=m
CONFIG_NET_CLS_TCINDEX=m
CONFIG_NET_CLS_ROUTE4=m
CONFIG_NET_CLS_ROUTE=y
CONFIG_NET_CLS_FW=m
CONFIG_NET_CLS_U32=m
CONFIG_CLS_U32_PERF=y
CONFIG_CLS_U32_MARK=y
CONFIG_NET_CLS_RSVP=m
# CONFIG_NET_CLS_RSVP6 is not set
# CONFIG_NET_EMATCH is not set
CONFIG_NET_CLS_ACT=y
CONFIG_NET_ACT_POLICE=y
# CONFIG_NET_ACT_GACT is not set
# CONFIG_NET_ACT_MIRRED is not set
# CONFIG_NET_ACT_IPT is not set
# CONFIG_NET_ACT_NAT is not set
# CONFIG_NET_ACT_PEDIT is not set
# CONFIG_NET_ACT_SIMP is not set
CONFIG_NET_CLS_POLICE=y
# CONFIG_NET_CLS_IND is not set
CONFIG_NET_SCH_FIFO=y

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_HAMRADIO is not set
# CONFIG_CAN is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
# CONFIG_AF_RXRPC is not set

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

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=m
# CONFIG_DEBUG_DRIVER is not set
# CONFIG_DEBUG_DEVRES is not set
# CONFIG_SYS_HYPERVISOR is not set
# CONFIG_CONNECTOR is not set
# CONFIG_MTD is not set
CONFIG_PARPORT=m
CONFIG_PARPORT_PC=m
# CONFIG_PARPORT_PC_FIFO is not set
# CONFIG_PARPORT_PC_SUPERIO is not set
# CONFIG_PARPORT_GSC is not set
# CONFIG_PARPORT_AX88796 is not set
CONFIG_PARPORT_1284=y
CONFIG_PNP=y
# CONFIG_PNP_DEBUG is not set

#
# Protocols
#
# CONFIG_ISAPNP is not set
# CONFIG_PNPBIOS is not set
CONFIG_PNPACPI=y
CONFIG_BLK_DEV=y
CONFIG_BLK_DEV_FD=m
# CONFIG_BLK_DEV_XD is not set
# CONFIG_PARIDE is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=m
CONFIG_BLK_DEV_CRYPTOLOOP=m
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_SX8 is not set
# CONFIG_BLK_DEV_UB is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=4096
CONFIG_CDROM_PKTCDVD=m
CONFIG_CDROM_PKTCDVD_BUFFERS=8
# CONFIG_CDROM_PKTCDVD_WCACHE is not set
# CONFIG_ATA_OVER_ETH is not set
# CONFIG_MISC_DEVICES is not set
# CONFIG_IDE is not set

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

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

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

#
# SCSI Transports
#
CONFIG_SCSI_SPI_ATTRS=m
CONFIG_SCSI_FC_ATTRS=m
# CONFIG_SCSI_ISCSI_ATTRS is not set
# CONFIG_SCSI_SAS_LIBSAS is not set
# CONFIG_SCSI_SRP_ATTRS is not set
# CONFIG_SCSI_LOWLEVEL is not set
CONFIG_ATA=m
# CONFIG_ATA_NONSTANDARD is not set
CONFIG_ATA_ACPI=y
# CONFIG_SATA_AHCI is not set
# CONFIG_SATA_SVW is not set
# CONFIG_ATA_PIIX is not set
# CONFIG_SATA_MV is not set
# CONFIG_SATA_NV is not set
# CONFIG_PDC_ADMA is not set
# CONFIG_SATA_QSTOR is not set
# CONFIG_SATA_PROMISE is not set
# CONFIG_SATA_SX4 is not set
# CONFIG_SATA_SIL is not set
# CONFIG_SATA_SIL24 is not set
# CONFIG_SATA_SIS is not set
# CONFIG_SATA_ULI is not set
# CONFIG_SATA_VIA is not set
# CONFIG_SATA_VITESSE is not set
# CONFIG_SATA_INIC162X is not set
# CONFIG_PATA_ACPI is not set
# CONFIG_PATA_ALI is not set
# CONFIG_PATA_AMD is not set
# CONFIG_PATA_ARTOP is not set
# CONFIG_PATA_ATIIXP is not set
# CONFIG_PATA_CMD640_PCI is not set
# CONFIG_PATA_CMD64X is not set
# CONFIG_PATA_CS5520 is not set
# CONFIG_PATA_CS5530 is not set
# CONFIG_PATA_CS5535 is not set
# CONFIG_PATA_CS5536 is not set
# CONFIG_PATA_CYPRESS is not set
# CONFIG_PATA_EFAR is not set
CONFIG_ATA_GENERIC=m
# CONFIG_PATA_HPT366 is not set
# CONFIG_PATA_HPT37X is not set
# CONFIG_PATA_HPT3X2N is not set
# CONFIG_PATA_HPT3X3 is not set
# CONFIG_PATA_IT821X is not set
# CONFIG_PATA_IT8213 is not set
# CONFIG_PATA_JMICRON is not set
# CONFIG_PATA_LEGACY is not set
# CONFIG_PATA_TRIFLEX is not set
# CONFIG_PATA_MARVELL is not set
# CONFIG_PATA_MPIIX is not set
# CONFIG_PATA_OLDPIIX is not set
# CONFIG_PATA_NETCELL is not set
# CONFIG_PATA_NINJA32 is not set
# CONFIG_PATA_NS87410 is not set
# CONFIG_PATA_NS87415 is not set
# CONFIG_PATA_OPTI is not set
# CONFIG_PATA_OPTIDMA is not set
# CONFIG_PATA_PDC_OLD is not set
# CONFIG_PATA_QDI is not set
# CONFIG_PATA_RADISYS is not set
# CONFIG_PATA_RZ1000 is not set
# CONFIG_PATA_SC1200 is not set
# CONFIG_PATA_SERVERWORKS is not set
# CONFIG_PATA_PDC2027X is not set
# CONFIG_PATA_SIL680 is not set
# CONFIG_PATA_SIS is not set
CONFIG_PATA_VIA=m
# CONFIG_PATA_WINBOND is not set
# CONFIG_PATA_WINBOND_VLB is not set
CONFIG_PATA_PLATFORM=m
CONFIG_MD=y
CONFIG_BLK_DEV_MD=m
CONFIG_MD_LINEAR=m
CONFIG_MD_RAID0=m
CONFIG_MD_RAID1=m
CONFIG_MD_RAID10=m
CONFIG_MD_RAID456=m
CONFIG_MD_RAID5_RESHAPE=y
# CONFIG_MD_MULTIPATH is not set
# CONFIG_MD_FAULTY is not set
CONFIG_BLK_DEV_DM=m
# CONFIG_DM_DEBUG is not set
CONFIG_DM_CRYPT=m
CONFIG_DM_SNAPSHOT=m
CONFIG_DM_MIRROR=m
# CONFIG_DM_ZERO is not set
# CONFIG_DM_MULTIPATH is not set
# CONFIG_DM_DELAY is not set
CONFIG_DM_UEVENT=y
# CONFIG_FUSION is not set

#
# IEEE 1394 (FireWire) support
#
CONFIG_FIREWIRE=m
CONFIG_FIREWIRE_OHCI=m
# CONFIG_FIREWIRE_SBP2 is not set
CONFIG_IEEE1394=m

#
# Subsystem Options
#
# CONFIG_IEEE1394_VERBOSEDEBUG is not set

#
# Controllers
#
# CONFIG_IEEE1394_PCILYNX is not set
CONFIG_IEEE1394_OHCI1394=m

#
# Protocols
#
CONFIG_IEEE1394_VIDEO1394=m
# CONFIG_IEEE1394_SBP2 is not set
# CONFIG_IEEE1394_ETH1394_ROM_ENTRY is not set
# CONFIG_IEEE1394_ETH1394 is not set
CONFIG_IEEE1394_DV1394=m
CONFIG_IEEE1394_RAWIO=m
# CONFIG_I2O is not set
# CONFIG_MACINTOSH_DRIVERS is not set
CONFIG_NETDEVICES=y
# CONFIG_NETDEVICES_MULTIQUEUE is not set
# CONFIG_IFB is not set
CONFIG_DUMMY=m
CONFIG_BONDING=m
# CONFIG_MACVLAN is not set
# CONFIG_EQUALIZER is not set
CONFIG_TUN=m
# CONFIG_VETH is not set
# CONFIG_NET_SB1000 is not set
# CONFIG_IP1000 is not set
# CONFIG_ARCNET is not set
# CONFIG_PHYLIB is not set
CONFIG_NET_ETHERNET=y
CONFIG_MII=m
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
# CONFIG_CASSINI is not set
# CONFIG_NET_VENDOR_3COM is not set
# CONFIG_LANCE is not set
# CONFIG_NET_VENDOR_SMC is not set
# CONFIG_NET_VENDOR_RACAL is not set
# CONFIG_NET_TULIP is not set
# CONFIG_AT1700 is not set
# CONFIG_DEPCA is not set
# CONFIG_HP100 is not set
# CONFIG_NET_ISA is not set
# CONFIG_IBM_NEW_EMAC_ZMII is not set
# CONFIG_IBM_NEW_EMAC_RGMII is not set
# CONFIG_IBM_NEW_EMAC_TAH is not set
# CONFIG_IBM_NEW_EMAC_EMAC4 is not set
CONFIG_NET_PCI=y
# CONFIG_PCNET32 is not set
# CONFIG_AMD8111_ETH is not set
# CONFIG_ADAPTEC_STARFIRE is not set
# CONFIG_AC3200 is not set
# CONFIG_APRICOT is not set
# CONFIG_B44 is not set
# CONFIG_FORCEDETH is not set
# CONFIG_CS89x0 is not set
# CONFIG_EEPRO100 is not set
# CONFIG_E100 is not set
# CONFIG_FEALNX is not set
# CONFIG_NATSEMI is not set
CONFIG_NE2K_PCI=m
# CONFIG_8139CP is not set
# CONFIG_8139TOO is not set
# CONFIG_R6040 is not set
# CONFIG_SIS900 is not set
# CONFIG_EPIC100 is not set
# CONFIG_SUNDANCE is not set
# CONFIG_TLAN is not set
# CONFIG_VIA_RHINE is not set
# CONFIG_SC92031 is not set
# CONFIG_NET_POCKET is not set
# CONFIG_NETDEV_1000 is not set
# CONFIG_NETDEV_10000 is not set
# CONFIG_TR is not set

#
# Wireless LAN
#
# CONFIG_WLAN_PRE80211 is not set
CONFIG_WLAN_80211=y
# CONFIG_IPW2100 is not set
# CONFIG_IPW2200 is not set
# CONFIG_LIBERTAS is not set
# CONFIG_AIRO is not set
# CONFIG_HERMES is not set
# CONFIG_ATMEL is not set
# CONFIG_USB_ATMEL is not set
# CONFIG_PRISM54 is not set
# CONFIG_USB_ZD1201 is not set
# CONFIG_HOSTAP is not set

#
# USB Network Adapters
#
# CONFIG_USB_CATC is not set
# CONFIG_USB_KAWETH is not set
# CONFIG_USB_PEGASUS is not set
# CONFIG_USB_RTL8150 is not set
# CONFIG_USB_USBNET is not set
# CONFIG_WAN is not set
# CONFIG_ATM_DRIVERS is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
# CONFIG_PLIP is not set
CONFIG_PPP=m
# CONFIG_PPP_MULTILINK is not set
CONFIG_PPP_FILTER=y
CONFIG_PPP_ASYNC=m
CONFIG_PPP_SYNC_TTY=m
CONFIG_PPP_DEFLATE=m
CONFIG_PPP_BSDCOMP=m
# CONFIG_PPP_MPPE is not set
CONFIG_PPPOE=m
CONFIG_PPPOATM=m
# CONFIG_PPPOL2TP is not set
# CONFIG_SLIP is not set
CONFIG_SLHC=m
# CONFIG_NET_FC is not set
# CONFIG_SHAPER is not set
# CONFIG_NETCONSOLE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set
# CONFIG_ISDN is not set
# CONFIG_PHONE is not set

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

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

#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_LKKBD is not set
# CONFIG_KEYBOARD_XTKBD is not set
# CONFIG_KEYBOARD_NEWTON is not set
# CONFIG_KEYBOARD_STOWAWAY is not set
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
# CONFIG_MOUSE_PS2_ALPS is not set
# CONFIG_MOUSE_PS2_LOGIPS2PP is not set
# CONFIG_MOUSE_PS2_SYNAPTICS is not set
# CONFIG_MOUSE_PS2_LIFEBOOK is not set
# CONFIG_MOUSE_PS2_TRACKPOINT is not set
# CONFIG_MOUSE_PS2_TOUCHKIT is not set
# CONFIG_MOUSE_PS2_ELANTECH is not set
# CONFIG_MOUSE_SERIAL is not set
# CONFIG_MOUSE_APPLETOUCH is not set
# CONFIG_MOUSE_INPORT is not set
# CONFIG_MOUSE_LOGIBM is not set
# CONFIG_MOUSE_PC110PAD is not set
# CONFIG_MOUSE_VSXXXAA is not set
CONFIG_INPUT_JOYSTICK=y
CONFIG_JOYSTICK_ANALOG=m
# CONFIG_JOYSTICK_A3D is not set
# CONFIG_JOYSTICK_ADI is not set
# CONFIG_JOYSTICK_COBRA is not set
# CONFIG_JOYSTICK_GF2K is not set
# CONFIG_JOYSTICK_GRIP is not set
# CONFIG_JOYSTICK_GRIP_MP is not set
# CONFIG_JOYSTICK_GUILLEMOT is not set
# CONFIG_JOYSTICK_INTERACT is not set
# CONFIG_JOYSTICK_SIDEWINDER is not set
# CONFIG_JOYSTICK_TMDC is not set
# CONFIG_JOYSTICK_IFORCE is not set
# CONFIG_JOYSTICK_WARRIOR is not set
# CONFIG_JOYSTICK_MAGELLAN is not set
# CONFIG_JOYSTICK_SPACEORB is not set
# CONFIG_JOYSTICK_SPACEBALL is not set
# CONFIG_JOYSTICK_STINGER is not set
# CONFIG_JOYSTICK_TWIDJOY is not set
# CONFIG_JOYSTICK_DB9 is not set
# CONFIG_JOYSTICK_GAMECON is not set
# CONFIG_JOYSTICK_TURBOGRAFX is not set
# CONFIG_JOYSTICK_JOYDUMP is not set
# CONFIG_JOYSTICK_XPAD is not set
# CONFIG_INPUT_TABLET is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
CONFIG_INPUT_MISC=y
CONFIG_INPUT_PCSPKR=m
# CONFIG_INPUT_APANEL is not set
# CONFIG_INPUT_WISTRON_BTNS is not set
# CONFIG_INPUT_ATLAS_BTNS is not set
# CONFIG_INPUT_ATI_REMOTE is not set
# CONFIG_INPUT_ATI_REMOTE2 is not set
# CONFIG_INPUT_KEYSPAN_REMOTE is not set
# CONFIG_INPUT_POWERMATE is not set
# CONFIG_INPUT_YEALINK is not set
CONFIG_INPUT_UINPUT=m

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

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

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

#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=m
# CONFIG_SERIAL_JSM is not set
CONFIG_UNIX98_PTYS=y
# CONFIG_LEGACY_PTYS is not set
CONFIG_PRINTER=m
# CONFIG_LP_CONSOLE is not set
# CONFIG_PPDEV is not set
# CONFIG_TIPAR is not set
# CONFIG_IPMI_HANDLER is not set
# CONFIG_HW_RANDOM is not set
# CONFIG_NVRAM is not set
CONFIG_RTC=m
# CONFIG_GEN_RTC is not set
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
# CONFIG_SONYPI is not set
# CONFIG_MWAVE is not set
# CONFIG_PC8736x_GPIO is not set
# CONFIG_NSC_GPIO is not set
# CONFIG_CS5535_GPIO is not set
# CONFIG_RAW_DRIVER is not set
# CONFIG_HPET is not set
# CONFIG_HANGCHECK_TIMER is not set
# CONFIG_TCG_TPM is not set
# CONFIG_TELCLOCK is not set
CONFIG_DEVPORT=y
CONFIG_I2C=y
CONFIG_I2C_BOARDINFO=y
CONFIG_I2C_CHARDEV=m

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

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

#
# Miscellaneous I2C Chip support
#
# CONFIG_DS1682 is not set
CONFIG_SENSORS_EEPROM=m
# CONFIG_SENSORS_PCF8574 is not set
# CONFIG_PCF8575 is not set
# CONFIG_SENSORS_PCA9539 is not set
# CONFIG_SENSORS_PCF8591 is not set
# CONFIG_SENSORS_MAX6875 is not set
# CONFIG_SENSORS_TSL2550 is not set
# CONFIG_OZ99X is not set
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
# CONFIG_I2C_DEBUG_CHIP is not set

#
# SPI support
#
# CONFIG_SPI is not set
# CONFIG_SPI_MASTER is not set
# CONFIG_W1 is not set
# CONFIG_POWER_SUPPLY is not set
CONFIG_HWMON=y
CONFIG_HWMON_VID=m
# CONFIG_SENSORS_ABITUGURU is not set
# CONFIG_SENSORS_ABITUGURU3 is not set
# CONFIG_SENSORS_AD7418 is not set
# CONFIG_SENSORS_ADM1021 is not set
# CONFIG_SENSORS_ADM1025 is not set
# CONFIG_SENSORS_ADM1026 is not set
# CONFIG_SENSORS_ADM1029 is not set
# CONFIG_SENSORS_ADM1031 is not set
# CONFIG_SENSORS_ADM9240 is not set
# CONFIG_SENSORS_ADT7470 is not set
# CONFIG_SENSORS_K8TEMP is not set
# CONFIG_SENSORS_ASB100 is not set
# CONFIG_SENSORS_ATXP1 is not set
# CONFIG_SENSORS_DS1621 is not set
# CONFIG_SENSORS_I5K_AMB is not set
# CONFIG_SENSORS_F71805F is not set
# CONFIG_SENSORS_F71882FG is not set
# CONFIG_SENSORS_F75375S is not set
# CONFIG_SENSORS_FSCHER is not set
# CONFIG_SENSORS_FSCPOS is not set
# CONFIG_SENSORS_FSCHMD is not set
# CONFIG_SENSORS_GL518SM is not set
# CONFIG_SENSORS_GL520SM is not set
# CONFIG_SENSORS_CORETEMP is not set
# CONFIG_SENSORS_IT87 is not set
# CONFIG_SENSORS_LM63 is not set
# CONFIG_SENSORS_LM75 is not set
# CONFIG_SENSORS_LM77 is not set
# CONFIG_SENSORS_LM78 is not set
CONFIG_SENSORS_LM80=m
# CONFIG_SENSORS_LM83 is not set
# CONFIG_SENSORS_LM85 is not set
# CONFIG_SENSORS_LM87 is not set
# CONFIG_SENSORS_LM90 is not set
# CONFIG_SENSORS_LM92 is not set
# CONFIG_SENSORS_LM93 is not set
# CONFIG_SENSORS_MAX1619 is not set
# CONFIG_SENSORS_MAX6650 is not set
# CONFIG_SENSORS_PC87360 is not set
# CONFIG_SENSORS_PC87427 is not set
# CONFIG_SENSORS_SIS5595 is not set
# CONFIG_SENSORS_DME1737 is not set
# CONFIG_SENSORS_SMSC47M1 is not set
# CONFIG_SENSORS_SMSC47M192 is not set
# CONFIG_SENSORS_SMSC47B397 is not set
# CONFIG_SENSORS_THMC50 is not set
CONFIG_SENSORS_VIA686A=m
# CONFIG_SENSORS_VT1211 is not set
# CONFIG_SENSORS_VT8231 is not set
CONFIG_SENSORS_W83781D=m
# CONFIG_SENSORS_W83791D is not set
# CONFIG_SENSORS_W83792D is not set
# CONFIG_SENSORS_W83793 is not set
# CONFIG_SENSORS_W83L785TS is not set
# CONFIG_SENSORS_W83L786NG is not set
# CONFIG_SENSORS_W83627HF is not set
# CONFIG_SENSORS_W83627EHF is not set
# CONFIG_SENSORS_HDAPS is not set
# CONFIG_SENSORS_APPLESMC is not set
# CONFIG_HWMON_DEBUG_CHIP is not set
# CONFIG_WATCHDOG is not set

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

#
# Multifunction device drivers
#
# CONFIG_MFD_SM501 is not set

#
# Multimedia devices
#
CONFIG_VIDEO_DEV=m
CONFIG_VIDEO_V4L1=y
CONFIG_VIDEO_V4L1_COMPAT=y
CONFIG_VIDEO_V4L2=y
CONFIG_VIDEO_CAPTURE_DRIVERS=y
# CONFIG_VIDEO_ADV_DEBUG is not set
CONFIG_VIDEO_HELPER_CHIPS_AUTO=y
# CONFIG_VIDEO_VIVI is not set
# CONFIG_VIDEO_BT848 is not set
# CONFIG_VIDEO_PMS is not set
# CONFIG_VIDEO_BWQCAM is not set
# CONFIG_VIDEO_CQCAM is not set
# CONFIG_VIDEO_W9966 is not set
# CONFIG_VIDEO_CPIA is not set
# CONFIG_VIDEO_CPIA2 is not set
# CONFIG_VIDEO_SAA5246A is not set
# CONFIG_VIDEO_SAA5249 is not set
# CONFIG_TUNER_3036 is not set
# CONFIG_VIDEO_STRADIS is not set
# CONFIG_VIDEO_ZORAN is not set
# CONFIG_VIDEO_SAA7134 is not set
# CONFIG_VIDEO_MXB is not set
# CONFIG_VIDEO_DPC is not set
# CONFIG_VIDEO_HEXIUM_ORION is not set
# CONFIG_VIDEO_HEXIUM_GEMINI is not set
# CONFIG_VIDEO_CX88 is not set
# CONFIG_VIDEO_IVTV is not set
# CONFIG_VIDEO_CAFE_CCIC is not set
CONFIG_V4L_USB_DRIVERS=y
# CONFIG_VIDEO_PVRUSB2 is not set
# CONFIG_VIDEO_EM28XX is not set
# CONFIG_VIDEO_USBVISION is not set
# CONFIG_USB_VICAM is not set
# CONFIG_USB_IBMCAM is not set
# CONFIG_USB_KONICAWC is not set
# CONFIG_USB_QUICKCAM_MESSENGER is not set
# CONFIG_USB_ET61X251 is not set
# CONFIG_VIDEO_OVCAMCHIP is not set
# CONFIG_USB_W9968CF is not set
# CONFIG_USB_OV511 is not set
# CONFIG_USB_SE401 is not set
# CONFIG_USB_SN9C102 is not set
# CONFIG_USB_STV680 is not set
# CONFIG_USB_ZC0301 is not set
# CONFIG_USB_PWC is not set
# CONFIG_USB_ZR364XX is not set
# CONFIG_RADIO_ADAPTERS is not set
# CONFIG_DVB_CORE is not set
# CONFIG_DAB is not set

#
# Graphics support
#
CONFIG_AGP=m
# CONFIG_AGP_ALI is not set
# CONFIG_AGP_ATI is not set
# CONFIG_AGP_AMD is not set
# CONFIG_AGP_AMD64 is not set
# CONFIG_AGP_INTEL is not set
# CONFIG_AGP_NVIDIA is not set
# CONFIG_AGP_SIS is not set
# CONFIG_AGP_SWORKS is not set
CONFIG_AGP_VIA=m
# CONFIG_AGP_EFFICEON is not set
CONFIG_DRM=m
# CONFIG_DRM_TDFX is not set
# CONFIG_DRM_R128 is not set
CONFIG_DRM_RADEON=m
# CONFIG_DRM_MGA is not set
# CONFIG_DRM_SIS is not set
# CONFIG_DRM_VIA is not set
# CONFIG_DRM_SAVAGE is not set
# CONFIG_VGASTATE is not set
# CONFIG_VIDEO_OUTPUT_CONTROL is not set
CONFIG_FB=y
CONFIG_FIRMWARE_EDID=y
CONFIG_FB_DDC=y
CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y
# CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set
# CONFIG_FB_SYS_FILLRECT is not set
# CONFIG_FB_SYS_COPYAREA is not set
# CONFIG_FB_SYS_IMAGEBLIT is not set
# CONFIG_FB_SYS_FOPS is not set
CONFIG_FB_DEFERRED_IO=y
# CONFIG_FB_SVGALIB is not set
# CONFIG_FB_MACMODES is not set
# CONFIG_FB_BACKLIGHT is not set
CONFIG_FB_MODE_HELPERS=y
# CONFIG_FB_TILEBLITTING is not set

#
# Frame buffer hardware drivers
#
# CONFIG_FB_CIRRUS is not set
# CONFIG_FB_PM2 is not set
# CONFIG_FB_CYBER2000 is not set
# CONFIG_FB_ARC is not set
# CONFIG_FB_ASILIANT is not set
# CONFIG_FB_IMSTT is not set
# CONFIG_FB_VGA16 is not set
CONFIG_FB_VESA=y
# CONFIG_FB_EFI is not set
# CONFIG_FB_HECUBA is not set
# CONFIG_FB_HGA is not set
# CONFIG_FB_S1D13XXX is not set
# CONFIG_FB_NVIDIA is not set
# CONFIG_FB_RIVA is not set
# CONFIG_FB_I810 is not set
# CONFIG_FB_LE80578 is not set
# CONFIG_FB_INTEL is not set
# CONFIG_FB_MATROX is not set
CONFIG_FB_RADEON=y
CONFIG_FB_RADEON_I2C=y
# CONFIG_FB_RADEON_BACKLIGHT is not set
# CONFIG_FB_RADEON_DEBUG is not set
# CONFIG_FB_ATY128 is not set
# CONFIG_FB_ATY is not set
# CONFIG_FB_S3 is not set
# CONFIG_FB_SAVAGE is not set
# CONFIG_FB_SIS is not set
# CONFIG_FB_NEOMAGIC is not set
# CONFIG_FB_KYRO is not set
# CONFIG_FB_3DFX is not set
# CONFIG_FB_VOODOO1 is not set
# CONFIG_FB_VT8623 is not set
# CONFIG_FB_CYBLA is not set
# CONFIG_FB_TRIDENT is not set
# CONFIG_FB_ARK is not set
# CONFIG_FB_PM3 is not set
# CONFIG_FB_GEODE is not set
# CONFIG_FB_VIRTUAL is not set
# CONFIG_BACKLIGHT_LCD_SUPPORT is not set

#
# Display device support
#
# CONFIG_DISPLAY_SUPPORT is not set

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

#
# Sound
#
CONFIG_SOUND=m

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

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

#
# ISA devices
#
# CONFIG_SND_ADLIB is not set
# CONFIG_SND_AD1816A is not set
# CONFIG_SND_AD1848 is not set
# CONFIG_SND_ALS100 is not set
# CONFIG_SND_AZT2320 is not set
# CONFIG_SND_CMI8330 is not set
# CONFIG_SND_CS4231 is not set
# CONFIG_SND_CS4232 is not set
# CONFIG_SND_CS4236 is not set
# CONFIG_SND_DT019X is not set
# CONFIG_SND_ES968 is not set
# CONFIG_SND_ES1688 is not set
# CONFIG_SND_ES18XX is not set
# CONFIG_SND_SC6000 is not set
# CONFIG_SND_GUSCLASSIC is not set
# CONFIG_SND_GUSEXTREME is not set
# CONFIG_SND_GUSMAX is not set
# CONFIG_SND_INTERWAVE is not set
# CONFIG_SND_INTERWAVE_STB is not set
# CONFIG_SND_OPL3SA2 is not set
# CONFIG_SND_OPTI92X_AD1848 is not set
# CONFIG_SND_OPTI92X_CS4231 is not set
# CONFIG_SND_OPTI93X is not set
# CONFIG_SND_MIRO is not set
# CONFIG_SND_SB8 is not set
# CONFIG_SND_SB16 is not set
# CONFIG_SND_SBAWE is not set
# CONFIG_SND_SGALAXY is not set
# CONFIG_SND_SSCAPE is not set
# CONFIG_SND_WAVEFRONT is not set

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

#
# USB devices
#
CONFIG_SND_USB_AUDIO=m
# CONFIG_SND_USB_USX2Y is not set
# CONFIG_SND_USB_CAIAQ is not set

#
# System on Chip audio support
#
# CONFIG_SND_SOC is not set

#
# SoC Audio support for SuperH
#

#
# Open Sound System
#
# CONFIG_SOUND_PRIME is not set
CONFIG_AC97_BUS=m
CONFIG_HID_SUPPORT=y
CONFIG_HID=m
# CONFIG_HID_DEBUG is not set
# CONFIG_HIDRAW is not set

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

#
# USB HID Boot Protocol drivers
#
# CONFIG_USB_KBD is not set
# CONFIG_USB_MOUSE is not set
CONFIG_USB_SUPPORT=y
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB_ARCH_HAS_EHCI=y
CONFIG_USB=m
# CONFIG_USB_DEBUG is not set
# CONFIG_USB_ANNOUNCE_NEW_DEVICES is not set

#
# Miscellaneous USB options
#
CONFIG_USB_DEVICEFS=y
CONFIG_USB_DEVICE_CLASS=y
CONFIG_USB_DYNAMIC_MINORS=y
CONFIG_USB_SUSPEND=y
# CONFIG_USB_PERSIST is not set
# CONFIG_USB_OTG is not set

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

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

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

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

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

#
# USB port drivers
#
# CONFIG_USB_USS720 is not set

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

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

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

#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set
# CONFIG_MMC is not set
# CONFIG_NEW_LEDS is not set
CONFIG_EDAC=y

#
# Reporting subsystems
#
# CONFIG_EDAC_DEBUG is not set
CONFIG_EDAC_MM_EDAC=m
CONFIG_EDAC_AMD76X=m
# CONFIG_EDAC_E7XXX is not set
# CONFIG_EDAC_E752X is not set
# CONFIG_EDAC_I82875P is not set
# CONFIG_EDAC_I82975X is not set
# CONFIG_EDAC_I3000 is not set
# CONFIG_EDAC_I82860 is not set
# CONFIG_EDAC_R82600 is not set
# CONFIG_EDAC_I5000 is not set
# CONFIG_RTC_CLASS is not set
# CONFIG_DMADEVICES is not set
# CONFIG_AUXDISPLAY is not set
# CONFIG_VIRTUALIZATION is not set

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

#
# Firmware Drivers
#
CONFIG_EDD=y
# CONFIG_DELL_RBU is not set
# CONFIG_DCDBAS is not set
CONFIG_DMIID=y

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

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

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

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

#
# Layered filesystems
#
CONFIG_ECRYPT_FS=m
# CONFIG_UNION_FS is not set

#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_CRAMFS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_ROMFS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set
CONFIG_NETWORK_FILESYSTEMS=y
# CONFIG_NFS_FS is not set
# CONFIG_NFSD is not set
# CONFIG_SMB_FS is not set
CONFIG_CIFS=m
CONFIG_CIFS_STATS=y
# CONFIG_CIFS_STATS2 is not set
# CONFIG_CIFS_WEAK_PW_HASH is not set
CONFIG_CIFS_XATTR=y
CONFIG_CIFS_POSIX=y
# CONFIG_CIFS_DEBUG2 is not set
# CONFIG_CIFS_EXPERIMENTAL is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set

#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
# CONFIG_ACORN_PARTITION is not set
# CONFIG_OSF_PARTITION is not set
# CONFIG_AMIGA_PARTITION is not set
# CONFIG_ATARI_PARTITION is not set
# CONFIG_MAC_PARTITION is not set
CONFIG_MSDOS_PARTITION=y
# CONFIG_BSD_DISKLABEL is not set
# CONFIG_MINIX_SUBPARTITION is not set
# CONFIG_SOLARIS_X86_PARTITION is not set
# CONFIG_UNIXWARE_DISKLABEL is not set
# CONFIG_LDM_PARTITION is not set
# CONFIG_SGI_PARTITION is not set
# CONFIG_ULTRIX_PARTITION is not set
# CONFIG_SUN_PARTITION is not set
# CONFIG_KARMA_PARTITION is not set
# CONFIG_EFI_PARTITION is not set
# CONFIG_SYSV68_PARTITION is not set
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
CONFIG_NLS_CODEPAGE_437=m
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
CONFIG_NLS_CODEPAGE_850=m
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
CONFIG_NLS_ASCII=m
CONFIG_NLS_ISO8859_1=m
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
CONFIG_NLS_ISO8859_15=m
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
CONFIG_NLS_UTF8=m
# CONFIG_DLM is not set
CONFIG_INSTRUMENTATION=y
CONFIG_PROFILING=y
CONFIG_OPROFILE=m
# CONFIG_KPROBES is not set
# CONFIG_MARKERS is not set

#
# Kernel hacking
#
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_PRINTK_TIME=y
CONFIG_ENABLE_WARN_DEPRECATED=y
CONFIG_ENABLE_MUST_CHECK=y
CONFIG_MAGIC_SYSRQ=y
# CONFIG_UNUSED_SYMBOLS is not set
# CONFIG_PAGE_OWNER is not set
CONFIG_DEBUG_FS=y
# CONFIG_HEADERS_CHECK is not set
CONFIG_DEBUG_KERNEL=y
# CONFIG_DEBUG_SHIRQ is not set
# CONFIG_DETECT_SOFTLOCKUP is not set
# CONFIG_SCHED_DEBUG is not set
# CONFIG_SCHEDSTATS is not set
# CONFIG_TIMER_STATS is not set
CONFIG_DEBUG_SLAB=y
CONFIG_DEBUG_SLAB_LEAK=y
CONFIG_DEBUG_PREEMPT=y
# CONFIG_DEBUG_RT_MUTEXES is not set
# CONFIG_RT_MUTEX_TESTER is not set
CONFIG_DEBUG_SPINLOCK=y
CONFIG_DEBUG_MUTEXES=y
CONFIG_DEBUG_LOCK_ALLOC=y
CONFIG_PROVE_LOCKING=y
CONFIG_LOCKDEP=y
# CONFIG_LOCK_STAT is not set
# CONFIG_DEBUG_LOCKDEP is not set
CONFIG_TRACE_IRQFLAGS=y
CONFIG_DEBUG_SPINLOCK_SLEEP=y
CONFIG_DEBUG_LOCKING_API_SELFTESTS=y
CONFIG_STACKTRACE=y
# CONFIG_DEBUG_KOBJECT is not set
CONFIG_DEBUG_BUGVERBOSE=y
# CONFIG_DEBUG_INFO is not set
# CONFIG_DEBUG_VM is not set
# CONFIG_DEBUG_LIST is not set
# CONFIG_DEBUG_SG is not set
CONFIG_FRAME_POINTER=y
# CONFIG_PROFILE_LIKELY is not set
# CONFIG_FORCED_INLINING is not set
# CONFIG_BOOT_PRINTK_DELAY is not set
# CONFIG_DEBUG_SYNCHRO_TEST is not set
# CONFIG_RCU_TORTURE_TEST is not set
# CONFIG_FAULT_INJECTION is not set
# CONFIG_SAMPLES is not set
CONFIG_EARLY_PRINTK=y
CONFIG_DEBUG_STACKOVERFLOW=y
CONFIG_DEBUG_STACK_USAGE=y

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

#
# Security options
#
CONFIG_KEYS=y
# CONFIG_KEYS_DEBUG_PROC_KEYS is not set
# CONFIG_SECURITY is not set
# CONFIG_SECURITY_FILE_CAPABILITIES is not set
CONFIG_XOR_BLOCKS=m
CONFIG_ASYNC_CORE=m
CONFIG_ASYNC_MEMCPY=m
CONFIG_ASYNC_XOR=m
CONFIG_CRYPTO=y
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_BLKCIPHER=m
CONFIG_CRYPTO_HASH=y
CONFIG_CRYPTO_MANAGER=y
CONFIG_CRYPTO_HMAC=y
# CONFIG_CRYPTO_XCBC is not set
# CONFIG_CRYPTO_NULL is not set
# CONFIG_CRYPTO_MD4 is not set
CONFIG_CRYPTO_MD5=y
CONFIG_CRYPTO_SHA1=m
CONFIG_CRYPTO_SHA256=m
CONFIG_CRYPTO_SHA512=m
# CONFIG_CRYPTO_WP512 is not set
# CONFIG_CRYPTO_TGR192 is not set
# CONFIG_CRYPTO_GF128MUL is not set
CONFIG_CRYPTO_ECB=m
CONFIG_CRYPTO_CBC=m
CONFIG_CRYPTO_PCBC=m
# CONFIG_CRYPTO_LRW is not set
# CONFIG_CRYPTO_XTS is not set
# CONFIG_CRYPTO_CTR is not set
# CONFIG_CRYPTO_GCM is not set
# CONFIG_CRYPTO_CRYPTD is not set
CONFIG_CRYPTO_DES=m
# CONFIG_CRYPTO_FCRYPT is not set
CONFIG_CRYPTO_BLOWFISH=m
# CONFIG_CRYPTO_TWOFISH is not set
# CONFIG_CRYPTO_TWOFISH_586 is not set
# CONFIG_CRYPTO_SERPENT is not set
CONFIG_CRYPTO_AES=m
CONFIG_CRYPTO_AES_586=m
# CONFIG_CRYPTO_CAST5 is not set
# CONFIG_CRYPTO_CAST6 is not set
# CONFIG_CRYPTO_TEA is not set
CONFIG_CRYPTO_ARC4=m
# CONFIG_CRYPTO_KHAZAD is not set
# CONFIG_CRYPTO_ANUBIS is not set
# CONFIG_CRYPTO_SEED is not set
# CONFIG_CRYPTO_SALSA20 is not set
CONFIG_CRYPTO_DEFLATE=m
CONFIG_CRYPTO_MICHAEL_MIC=m
CONFIG_CRYPTO_CRC32C=m
# CONFIG_CRYPTO_CAMELLIA is not set
# CONFIG_CRYPTO_TEST is not set
# CONFIG_CRYPTO_AUTHENC is not set
# CONFIG_CRYPTO_HW is not set

#
# Library routines
#
CONFIG_BITREVERSE=y
CONFIG_CRC_CCITT=m
# CONFIG_CRC16 is not set
CONFIG_CRC_ITU_T=m
CONFIG_CRC32=y
# CONFIG_CRC7 is not set
CONFIG_LIBCRC32C=m
CONFIG_ZLIB_INFLATE=m
CONFIG_ZLIB_DEFLATE=m
CONFIG_LZO_COMPRESS=m
CONFIG_LZO_DECOMPRESS=m
CONFIG_TEXTSEARCH=y
CONFIG_TEXTSEARCH_KMP=m
CONFIG_TEXTSEARCH_BM=m
CONFIG_TEXTSEARCH_FSM=m
CONFIG_PLIST=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y


Attachments:
.config (47.74 kB)

2007-12-06 22:39:39

by Andrew Morton

[permalink] [raw]
Subject: Re: 2.6.24-rc4-mm1: VDSOSYM build error

On Thu, 06 Dec 2007 23:28:38 +0100
Laurent Riffard <[email protected]> wrote:

> Le 05.12.2007 06:17, Andrew Morton a ?crit :
> > 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?

2007-12-06 23:13:08

by Valdis Klētnieks

[permalink] [raw]
Subject: Re: [dm-devel] Re: 2.6.24-rc4-mm1

On Thu, 06 Dec 2007 23:04:12 +0100, Kay Sievers said:

> 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 ;)

> 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.








Attachments:
(No filename) (226.00 B)

2007-12-06 23:25:30

by Kay Sievers

[permalink] [raw]
Subject: Re: [dm-devel] Re: 2.6.24-rc4-mm1

On Thu, 2007-12-06 at 18:12 -0500, [email protected] wrote:
> On Thu, 06 Dec 2007 23:04:12 +0100, Kay Sievers said:
>
> > 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.

> > 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

2007-12-06 23:28:35

by Miles Lane

[permalink] [raw]
Subject: Re: 2.6.24-rc4-mm1: VDSOSYM build error

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

2007-12-06 23:35:27

by Andrew Morton

[permalink] [raw]
Subject: Re: 2.6.24-rc4-mm1: VDSOSYM build error

On Thu, 6 Dec 2007 18:28:25 -0500
"Miles Lane" <[email protected]> wrote:

> 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.

2007-12-06 23:47:52

by Miles Lane

[permalink] [raw]
Subject: Re: 2.6.24-rc4-mm1: VDSOSYM build error

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

2007-12-06 23:53:18

by Badari Pulavarty

[permalink] [raw]
Subject: Re: 2.6.24-rc4-mm1 kobject changes broken with hvcs driver on powerpc

On Thu, 2007-12-06 at 12:31 -0800, Greg KH wrote:
> On Fri, Dec 07, 2007 at 12:28:58AM +0530, Balbir Singh wrote:
> > Greg KH wrote:
> >
> > >> 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

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

2007-12-07 00:29:26

by Greg KH

[permalink] [raw]
Subject: Re: 2.6.24-rc4-mm1 kobject changes broken with hvcs driver on powerpc

On Thu, Dec 06, 2007 at 03:54:51PM -0800, Badari Pulavarty wrote:
> On Thu, 2007-12-06 at 12:31 -0800, Greg KH wrote:
> > On Fri, Dec 07, 2007 at 12:28:58AM +0530, Balbir Singh wrote:
> > > Greg KH wrote:
> > >
> > > >> 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
>
> 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

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

2007-12-07 01:15:24

by Roland McGrath

[permalink] [raw]
Subject: [PATCH x86/mm] x86 vDSO: canonicalize sysenter .eh_frame


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 <[email protected]>
---
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

2007-12-07 01:28:00

by Harvey Harrison

[permalink] [raw]
Subject: Re: [PATCH x86/mm] x86 vDSO: canonicalize sysenter .eh_frame

On Thu, 2007-12-06 at 17:14 -0800, Roland McGrath wrote:
> 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 <[email protected]>

Confirm this fixes the compile errors I was seeing with x86.git

Harvey

2007-12-07 01:29:44

by Balbir Singh

[permalink] [raw]
Subject: Re: 2.6.24-rc4-mm1 kobject changes broken with hvcs driver on powerpc

Badari Pulavarty wrote:
> On Fri, 2007-12-07 at 00:28 +0530, Balbir Singh wrote:
>> Greg KH wrote:
>>
>>>> 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 :(

> Thanks,
> Badari
>
>


--
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL

2007-12-07 02:12:46

by Dave Young

[permalink] [raw]
Subject: Re: 2.6.24-rc4-mm1

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 <[email protected]>

---
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.

2007-12-07 03:02:41

by Kamalesh Babulal

[permalink] [raw]
Subject: Re: 2.6.24-rc4-mm1 kobject changes broken with hvcs driver on powerpc

Greg KH wrote:
> On Thu, Dec 06, 2007 at 03:54:51PM -0800, Badari Pulavarty wrote:
>> On Thu, 2007-12-06 at 12:31 -0800, Greg KH wrote:
>>> On Fri, Dec 07, 2007 at 12:28:58AM +0530, Balbir Singh wrote:
>>>> Greg KH wrote:
>>>>
>>>>>> 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
>> 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
>
> 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.

2007-12-07 03:27:17

by Miles Lane

[permalink] [raw]
Subject: Re: [PATCH x86/mm] x86 vDSO: canonicalize sysenter .eh_frame

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

2007-12-07 05:12:56

by Greg KH

[permalink] [raw]
Subject: Re: 2.6.24-rc4-mm1 kobject changes broken with hvcs driver on powerpc

On Fri, Dec 07, 2007 at 08:32:26AM +0530, Kamalesh Babulal wrote:
> Greg KH wrote:
> > On Thu, Dec 06, 2007 at 03:54:51PM -0800, Badari Pulavarty wrote:
> >> On Thu, 2007-12-06 at 12:31 -0800, Greg KH wrote:
> >>> On Fri, Dec 07, 2007 at 12:28:58AM +0530, Balbir Singh wrote:
> >>>> Greg KH wrote:
> >>>>
> >>>>>> 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
> >> 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
> >
> > 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

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

2007-12-07 09:45:23

by Ingo Molnar

[permalink] [raw]
Subject: Re: [PATCH x86/mm] x86 vDSO: canonicalize sysenter .eh_frame


* Roland McGrath <[email protected]> wrote:

> 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 <[email protected]> ---

thanks, applied.

Ingo

2007-12-07 10:37:48

by Ingo Molnar

[permalink] [raw]
Subject: Re: 2.6.24-rc4-mm1: VDSOSYM build error


* Andrew Morton <[email protected]> wrote:

> On Thu, 6 Dec 2007 18:28:25 -0500
> "Miles Lane" <[email protected]> wrote:
>
> > 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

2007-12-07 13:17:05

by Ilpo Järvinen

[permalink] [raw]
Subject: Re: 2.6.24-rc4-mm1

On Wed, 5 Dec 2007, David Miller wrote:

> From: Reuben Farrelly <[email protected]>
> Date: Thu, 06 Dec 2007 17:59:37 +1100
>
> > On 5/12/2007 4:17 PM, Andrew Morton wrote:
> > > - 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
>
> 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.

2007-12-07 14:20:40

by Wu Fengguang

[permalink] [raw]
Subject: [PATCH BUGFIX] hid: the `bit' in hidinput_mapping_quirks() is an out parameter

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 <[email protected]>
Signed-off-by: Fengguang Wu <[email protected]>
---
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;

2007-12-07 14:35:10

by Jiri Slaby

[permalink] [raw]
Subject: broken suspend (sched related) [Was: 2.6.24-rc4-mm1]

On 12/05/2007 06:17 AM, Andrew Morton wrote:
> 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?

2007-12-07 15:12:32

by Ingo Molnar

[permalink] [raw]
Subject: Re: broken suspend (sched related) [Was: 2.6.24-rc4-mm1]


* Jiri Slaby <[email protected]> wrote:

> On 12/05/2007 06:17 AM, Andrew Morton wrote:
> > 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?

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:

2007-12-07 17:54:44

by Ingo Molnar

[permalink] [raw]
Subject: Re: broken suspend (sched related) [Was: 2.6.24-rc4-mm1]


* Ingo Molnar <[email protected]> wrote:

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

2007-12-07 18:12:16

by Mariusz Kozlowski

[permalink] [raw]
Subject: [PATCH] md: balance braces in raid5 debug code

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 <[email protected]>

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");

2007-12-07 18:21:33

by Valdis Klētnieks

[permalink] [raw]
Subject: Re: [dm-devel] Re: 2.6.24-rc4-mm1

On Fri, 07 Dec 2007 00:24:04 +0100, Kay Sievers said:
> On Thu, 2007-12-06 at 18:12 -0500, [email protected] wrote:
> > On Thu, 06 Dec 2007 23:04:12 +0100, Kay Sievers said:
> >
> > > 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..

> > > 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? :)





Attachments:
(No filename) (226.00 B)

2007-12-07 18:44:44

by Kay Sievers

[permalink] [raw]
Subject: Re: [dm-devel] Re: 2.6.24-rc4-mm1

On Fri, 2007-12-07 at 13:20 -0500, [email protected] wrote:
> On Fri, 07 Dec 2007 00:24:04 +0100, Kay Sievers said:
> > On Thu, 2007-12-06 at 18:12 -0500, [email protected] wrote:
> > > On Thu, 06 Dec 2007 23:04:12 +0100, Kay Sievers said:
> > >
> > > > 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!

> 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.

> > > > 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.

> 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

2007-12-07 20:28:58

by Valdis Klētnieks

[permalink] [raw]
Subject: Re: [dm-devel] Re: 2.6.24-rc4-mm1

On Fri, 07 Dec 2007 19:44:29 +0100, Kay Sievers said:

> > 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 <[email protected]> - 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....


Attachments:
(No filename) (226.00 B)

2007-12-07 20:50:42

by Kay Sievers

[permalink] [raw]
Subject: Re: [dm-devel] Re: 2.6.24-rc4-mm1

On Fri, 2007-12-07 at 15:28 -0500, [email protected] wrote:
> On Fri, 07 Dec 2007 19:44:29 +0100, Kay Sievers said:
>
> > > 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

> 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 <[email protected]> - 6.0.12-2
> - 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.

> 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

2007-12-07 22:01:39

by Balbir Singh

[permalink] [raw]
Subject: Re: 2.6.24-rc4-mm1 kobject changes broken with hvcs driver on powerpc


> 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

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

2007-12-07 22:22:36

by Luis R. Rodriguez

[permalink] [raw]
Subject: Re: 2.6.24-rc4-mm1

On Dec 6, 2007 9:12 PM, Dave Young <[email protected]> wrote:
> 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 <[email protected]>

Acked-by: Luis R. Rodriguez <[email protected]>

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

2007-12-07 23:56:53

by Mariusz Kozlowski

[permalink] [raw]
Subject: Re: 2.6.24-rc4-mm1: undefined reference to `compat_sys_timerfd' on sparc64

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


Attachments:
(No filename) (1.10 kB)
sparc64-config (25.02 kB)
Download all attachments

2007-12-08 00:08:20

by Andrew Morton

[permalink] [raw]
Subject: Re: 2.6.24-rc4-mm1: undefined reference to `compat_sys_timerfd' on sparc64

On Sat, 8 Dec 2007 01:04:55 +0100
Mariusz Kozlowski <[email protected]> wrote:

> 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

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.

2007-12-08 08:11:18

by Jiri Slaby

[permalink] [raw]
Subject: Re: broken suspend (sched related) [Was: 2.6.24-rc4-mm1]

On 12/07/2007 06:51 PM, Ingo Molnar wrote:
> * Ingo Molnar <[email protected]> wrote:
>
>> 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:

Unfortunately no change here.

2007-12-08 08:40:22

by Ingo Molnar

[permalink] [raw]
Subject: Re: broken suspend (sched related) [Was: 2.6.24-rc4-mm1]


* Jiri Slaby <[email protected]> wrote:

> 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

2007-12-08 09:08:46

by Mariusz Kozlowski

[permalink] [raw]
Subject: Re: 2.6.24-rc4-mm1: undefined reference to `compat_sys_timerfd' on sparc64


> > 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
>
> 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 */

Ok - that helped.

Thanks,

Mariusz

2007-12-08 09:23:56

by Jiri Slaby

[permalink] [raw]
Subject: Re: broken suspend (sched related) [Was: 2.6.24-rc4-mm1]

On 12/08/2007 09:39 AM, Ingo Molnar wrote:
> * Jiri Slaby <[email protected]> wrote:
>
>> 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

What should have this changed? I can't see any difference.

2007-12-08 15:25:46

by Ingo Molnar

[permalink] [raw]
Subject: Re: broken suspend (sched related) [Was: 2.6.24-rc4-mm1]


* Jiri Slaby <[email protected]> wrote:

> On 12/08/2007 09:39 AM, Ingo Molnar wrote:
> > * Jiri Slaby <[email protected]> wrote:
> >
> >> 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
>
> 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

2007-12-08 17:34:37

by Jiri Slaby

[permalink] [raw]
Subject: Re: broken suspend (sched related) [Was: 2.6.24-rc4-mm1]

On 12/08/2007 04:24 PM, Ingo Molnar wrote:
> 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

2007-12-08 17:43:57

by Jiri Slaby

[permalink] [raw]
Subject: Re: broken suspend (sched related) [Was: 2.6.24-rc4-mm1]

On 12/08/2007 04:24 PM, Ingo Molnar wrote:
> 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?

2007-12-08 18:12:08

by Mariusz Kozlowski

[permalink] [raw]
Subject: Re: 2.6.24-rc4-mm1: some issues on sparc64

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


Attachments:
(No filename) (5.62 kB)
sparc64-2.6.24-rc4-mm1.config (25.02 kB)
Download all attachments

2007-12-08 18:22:57

by Andrew Morton

[permalink] [raw]
Subject: Re: 2.6.24-rc4-mm1: some issues on sparc64

On Sat, 8 Dec 2007 19:20:28 +0100 Mariusz Kozlowski <[email protected]> wrote:

> 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.

> [27006.402268] \|/ ____ \|/
> [27006.402274] "@'/ .. \`@"
> [27006.402279] /_| \__/ |_\
> [27006.402285] \__U_/

x86 needs that.

> [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

2007-12-08 23:13:11

by Jiri Slaby

[permalink] [raw]
Subject: Re: broken suspend (sched related) [Was: 2.6.24-rc4-mm1]

On 12/08/2007 04:24 PM, Ingo Molnar wrote:
> 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

2007-12-09 07:47:28

by Ingo Molnar

[permalink] [raw]
Subject: Re: broken suspend (sched related) [Was: 2.6.24-rc4-mm1]


* Jiri Slaby <[email protected]> wrote:

> On 12/08/2007 04:24 PM, Ingo Molnar wrote:
> > 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

2007-12-09 08:07:15

by Ingo Molnar

[permalink] [raw]
Subject: Re: broken suspend (sched related) [Was: 2.6.24-rc4-mm1]


* Jiri Slaby <[email protected]> wrote:

> On 12/08/2007 04:24 PM, Ingo Molnar wrote:
> > 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 <[email protected]>

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 <[email protected]>
---
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;

2007-12-09 08:45:30

by David Miller

[permalink] [raw]
Subject: Re: 2.6.24-rc4-mm1: some issues on sparc64

From: Andrew Morton <[email protected]>
Date: Sat, 8 Dec 2007 10:22:39 -0800

> 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.

2007-12-09 09:03:42

by Andrew Morton

[permalink] [raw]
Subject: Re: 2.6.24-rc4-mm1: some issues on sparc64

On Sun, 09 Dec 2007 00:45:17 -0800 (PST) David Miller <[email protected]> wrote:

> From: Andrew Morton <[email protected]>
> Date: Sat, 8 Dec 2007 10:22:39 -0800
>
> > 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.

2007-12-09 09:09:38

by Jiri Slaby

[permalink] [raw]
Subject: Re: broken suspend (sched related) [Was: 2.6.24-rc4-mm1]

On 12/09/2007 08:46 AM, Ingo Molnar wrote:
> 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?)

2007-12-09 17:55:49

by Nick Kossifidis

[permalink] [raw]
Subject: Re: 2.6.24-rc4-mm1

2007/12/7, Dave Young <[email protected]>:
> 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 <[email protected]>
>
> ---
> 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.
>

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

2007-12-10 01:07:39

by Dave Young

[permalink] [raw]
Subject: Re: 2.6.24-rc4-mm1

On Dec 8, 2007 6:22 AM, Luis R. Rodriguez <[email protected]> wrote:
> On Dec 6, 2007 9:12 PM, Dave Young <[email protected]> wrote:
> > 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 <[email protected]>
>
> Acked-by: Luis R. Rodriguez <[email protected]>

Thanks.

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

gcc 3.4.6

>
> 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.

>
> 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
>

2007-12-10 08:55:46

by Jiri Slaby

[permalink] [raw]
Subject: Re: broken suspend (sched related) [Was: 2.6.24-rc4-mm1]

On 12/10/2007 09:19 AM, Gautham R Shenoy wrote:
> commit 15bfb662b35c609490185fba2fd4713d230b9374
> Author: Gautham R Shenoy <[email protected]>
> 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 <[email protected]>
> Cc: Ingo Molnar <[email protected]>
> Cc: Thomas Gleixner <[email protected]>
> Cc: Arjan van de Van <[email protected]>
> Cc: Jiri Slaby <[email protected]>

Tested-by: Jiri Slaby <[email protected]>

> 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;
>

2007-12-10 09:12:09

by Ingo Molnar

[permalink] [raw]
Subject: Re: broken suspend (sched related) [Was: 2.6.24-rc4-mm1]


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

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

2007-12-10 09:31:05

by Ingo Molnar

[permalink] [raw]
Subject: Re: broken suspend (sched related) [Was: 2.6.24-rc4-mm1]


* Gautham R Shenoy <[email protected]> wrote:

> 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

Subject: Re: broken suspend (sched related) [Was: 2.6.24-rc4-mm1]

On Sun, Dec 09, 2007 at 08:46:47AM +0100, Ingo Molnar wrote:
>
> * Jiri Slaby <[email protected]> wrote:
>
> > On 12/08/2007 04:24 PM, Ingo Molnar wrote:
> > > 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 <[email protected]>
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 <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Arjan van de Van <[email protected]>
Cc: Jiri Slaby <[email protected]>

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!"

2007-12-10 10:04:25

by Jiri Kosina

[permalink] [raw]
Subject: Re: [PATCH BUGFIX] hid: the `bit' in hidinput_mapping_quirks() is an out parameter

On Fri, 7 Dec 2007, Fengguang Wu wrote:

> 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

Subject: Re: broken suspend (sched related) [Was: 2.6.24-rc4-mm1]

On Mon, Dec 10, 2007 at 10:10:52AM +0100, Ingo Molnar wrote:
>
> > > 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:
>
> 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 <[email protected]>
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 <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Jiri Slaby <[email protected]>

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;






>
> 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!"

2007-12-10 10:23:23

by Ingo Molnar

[permalink] [raw]
Subject: Re: broken suspend (sched related) [Was: 2.6.24-rc4-mm1]


* Gautham R Shenoy <[email protected]> wrote:

> > 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

Subject: Re: broken suspend (sched related) [Was: 2.6.24-rc4-mm1]

On Mon, Dec 10, 2007 at 11:21:57AM +0100, Ingo Molnar wrote:
>
> * Gautham R Shenoy <[email protected]> wrote:
>
> > > 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 <[email protected]>

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 <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Jiri Slaby <[email protected]>
---

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);



>
> 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!"

2007-12-10 11:29:31

by Ingo Molnar

[permalink] [raw]
Subject: Re: broken suspend (sched related) [Was: 2.6.24-rc4-mm1]


* Gautham R Shenoy <[email protected]> wrote:

> > 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.

one question:

> +static int check_cpu = -1;

> case CPU_ONLINE:
> case CPU_ONLINE_FROZEN:
> + 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

2007-12-10 11:50:19

by Gautham R Shenoy

[permalink] [raw]
Subject: Re: broken suspend (sched related) [Was: 2.6.24-rc4-mm1]

On Dec 10, 2007 4:58 PM, Ingo Molnar <[email protected]> wrote:
>
> * Gautham R Shenoy <[email protected]> wrote:
>
> > > 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?

>
> one question:
>
> > +static int check_cpu = -1;
>
> > case CPU_ONLINE:
> > case CPU_ONLINE_FROZEN:
> > + 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.
>
> 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!"

2007-12-10 12:24:46

by Ilpo Järvinen

[permalink] [raw]
Subject: Re: 2.6.24-rc4-mm1

On Wed, 5 Dec 2007, Andrew Morton wrote:

> On Thu, 06 Dec 2007 17:59:37 +1100 Reuben Farrelly <[email protected]> wrote:
>
> > 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.
>
> > 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 <[email protected]>
---
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

2007-12-10 14:48:58

by Reuben Farrelly

[permalink] [raw]
Subject: Re: 2.6.24-rc4-mm1



On 5/12/2007 4:17 PM, Andrew Morton wrote:
> 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



2007-12-10 20:05:38

by Ilpo Järvinen

[permalink] [raw]
Subject: Re: 2.6.24-rc4-mm1

On Mon, 10 Dec 2007, Ilpo J?rvinen wrote:

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

...

> --
> [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.

2007-12-10 21:11:55

by Andrew Morton

[permalink] [raw]
Subject: Re: 2.6.24-rc4-mm1

On Tue, 11 Dec 2007 01:48:39 +1100
Reuben Farrelly <[email protected]> wrote:

>
>
> On 5/12/2007 4:17 PM, Andrew Morton wrote:
> > 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/
>

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?

2007-12-11 10:15:58

by David Miller

[permalink] [raw]
Subject: Re: 2.6.24-rc4-mm1: undefined reference to `compat_sys_timerfd' on sparc64

From: Andrew Morton <[email protected]>
Date: Fri, 7 Dec 2007 16:08:00 -0800

> 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.

2007-12-11 14:13:15

by Reuben Farrelly

[permalink] [raw]
Subject: Re: 2.6.24-rc4-mm1



On 11/12/2007 8:11 AM, Andrew Morton wrote:
> On Tue, 11 Dec 2007 01:48:39 +1100
> Reuben Farrelly <[email protected]> wrote:
>
>>
>> On 5/12/2007 4:17 PM, Andrew Morton wrote:
>>> 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/
>>
>
> 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

2007-12-11 16:44:39

by Martin Bligh

[permalink] [raw]
Subject: Re: 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.


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

2007-12-11 17:01:19

by Randy Dunlap

[permalink] [raw]
Subject: Re: 2.6.24-rc4-mm1

On Tue, 11 Dec 2007 08:20:05 -0800 Martin Bligh wrote:

> > - 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

I see those on one build machine but not on another, so I thought
that it was a tools issue...


> 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

See http://marc.info/?l=linux-kernel&m=119700448119646
for patches.


---
~Randy
Features and documentation: http://lwn.net/Articles/260136/

2007-12-11 17:50:55

by Martin Bligh

[permalink] [raw]
Subject: Re: 2.6.24-rc4-mm1

>> 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
>
> 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 ;-)

>> 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
>
> See http://marc.info/?l=linux-kernel&m=119700448119646
> for patches.


Thanks,

M.

2007-12-11 20:38:27

by Andrew Morton

[permalink] [raw]
Subject: Re: 2.6.24-rc4-mm1

On Tue, 11 Dec 2007 08:13:52 -0800 "Martin Bligh" <[email protected]> wrote:

> >
> >
> > - 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.

>
> 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

(cc Ingo and Thomas)

>
> 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
>

(cc Greg)

Caused by gregkh-driver-kobject-convert-hvcs-to-use-kref-not-kobject.patch.

2007-12-11 21:21:14

by Ingo Molnar

[permalink] [raw]
Subject: Re: 2.6.24-rc4-mm1


* Andrew Morton <[email protected]> wrote:

> > 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
>
> (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

2007-12-11 21:30:11

by Kok, Auke

[permalink] [raw]
Subject: Re: 2.6.24-rc4-mm1

Andrew Morton wrote:
> On Tue, 11 Dec 2007 08:13:52 -0800 "Martin Bligh" <[email protected]> wrote:
>
>>>
>>> - 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

2007-12-11 22:02:17

by Kok, Auke

[permalink] [raw]
Subject: Re: 2.6.24-rc4-mm1

Kok, Auke wrote:
> Andrew Morton wrote:
>> On Tue, 11 Dec 2007 08:13:52 -0800 "Martin Bligh" <[email protected]> wrote:
>>
>>>> - 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

2007-12-11 22:12:10

by Andrew Morton

[permalink] [raw]
Subject: Re: 2.6.24-rc4-mm1

On Tue, 11 Dec 2007 13:26:58 -0800
"Kok, Auke" <[email protected]> wrote:

> Andrew Morton wrote:
> > On Tue, 11 Dec 2007 08:13:52 -0800 "Martin Bligh" <[email protected]> wrote:
> >
> >>>
> >>> - 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 wouldn't be looking at defconfig files - I don't think many people use
them. Most people use their previous config, via oldconfig.

So what we want here is to give them E1000E if they had previously been
using E1000. I don't know how one would do this in Kconfig.

2007-12-11 22:28:51

by Kok, Auke

[permalink] [raw]
Subject: Re: 2.6.24-rc4-mm1

Andrew Morton wrote:
> On Tue, 11 Dec 2007 13:26:58 -0800
> "Kok, Auke" <[email protected]> wrote:
>
>> Andrew Morton wrote:
>>> On Tue, 11 Dec 2007 08:13:52 -0800 "Martin Bligh" <[email protected]> wrote:
>>>
>>>>> - 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 wouldn't be looking at defconfig files - I don't think many people use
> them. Most people use their previous config, via oldconfig.
>
> So what we want here is to give them E1000E if they had previously been
> using E1000. I don't know how one would do this in Kconfig.

ditto. I doubt that "SELECT E1000E" would be a good idea here (maybe not even
work), and I can't think of anything else.

Auke

2007-12-11 23:17:31

by Randy Dunlap

[permalink] [raw]
Subject: Re: 2.6.24-rc4-mm1

On Tue, 11 Dec 2007 14:17:16 -0800 Kok, Auke wrote:

> Andrew Morton wrote:
> > On Tue, 11 Dec 2007 13:26:58 -0800
> > "Kok, Auke" <[email protected]> wrote:
> >
> >> Andrew Morton wrote:
> >>> On Tue, 11 Dec 2007 08:13:52 -0800 "Martin Bligh" <[email protected]> wrote:
> >>>
> >>>>> - 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 wouldn't be looking at defconfig files - I don't think many people use
> > them. Most people use their previous config, via oldconfig.
> >
> > So what we want here is to give them E1000E if they had previously been
> > using E1000. I don't know how one would do this in Kconfig.
>
> ditto. I doubt that "SELECT E1000E" would be a good idea here (maybe not even
> work), and I can't think of anything else.

"default E1000" in E1000E seems to work for me.

---

From: Randy Dunlap <[email protected]>

Make E1000E default to the same kconfig setting as E1000,
at least for -mm testing.

Signed-off-by: Randy Dunlap <[email protected]>
---
drivers/net/Kconfig | 1 +
1 file changed, 1 insertion(+)

--- linux-2.6.24-rc4-mm1.orig/drivers/net/Kconfig
+++ linux-2.6.24-rc4-mm1/drivers/net/Kconfig
@@ -1986,6 +1986,7 @@ config E1000_DISABLE_PACKET_SPLIT
config E1000E
tristate "Intel(R) PRO/1000 PCI-Express Gigabit Ethernet support"
depends on PCI
+ default E1000
---help---
This driver supports the PCI-Express Intel(R) PRO/1000 gigabit
ethernet family of adapters. For PCI or PCI-X e1000 adapters,

2007-12-12 04:16:40

by Rik van Riel

[permalink] [raw]
Subject: Re: 2.6.24-rc4-mm1

On Tue, 4 Dec 2007 21:17:01 -0800
Andrew Morton <[email protected]> wrote:

> Changes since 2.6.24-rc3-mm2:

2.6.24-rc4-mm1 brought a nice TCP oops on my x86_64 system, while I
was stress-testing the VM and watching via ssh:

general protection fault: 0000 [1] SMP
last sysfs file: /sys/devices/pci0000:00/0000:00:1c.5/0000:04:00.0/irq
CPU 1
Modules linked in: nfs lockd nfs_acl rfcomm l2cap bluetooth autofs4 sunrpc ipv6 acpi_cpufreq dm_multipath parport_pc e1000e parport firewire_ohci button i2c_i801 i2c_core i82975x_edac pcspkr firewire_core serio_raw edac_core rtc_cmos floppy crc_itu_t sg sr_mod cdrom pata_marvell ata_piix dm_snapshot dm_zero dm_mirror dm_mod ahci libata sd_mod scsi_mod ext3 jbd mbcache uhci_hcd ohci_hcd ehci_hcd
Pid: 2946, comm: sshd Not tainted 2.6.24-rc4-mm1 #1
RIP: 0010:[<ffffffff81227add>] [<ffffffff81227add>] __tcp_rb_insert+0x1a/0x67
RSP: 0018:ffff810066401c88 EFLAGS: 00010202
RAX: 6b6b6b6b6b6b6b6b RBX: ffff810076e9f000 RCX: ffff81003ddc9900
RDX: 6b6b6b6b6b6b6bab RSI: ffff81006ed1b148 RDI: 6b6b6b6b6b6b6b5b
RBP: ffff81006ed1aa00 R08: ffff810076e9f010 R09: 00000000bef8d64e
R10: ffffffff81228926 R11: ffffffff8110b2aa R12: ffff810066401de8
R13: 00000000000000e0 R14: ffff810066401ee8 R15: 0000000000000001
FS: 00007f1c2c10d780(0000) GS:ffff81007f801578(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000002aabfd3 CR3: 00000000665e3000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process sshd (pid: 2946, threadinfo ffff810066400000, task ffff8100665ce000)
Stack: ffff81003ddc9900 ffffffff81228b26 0000000000000000 0000000100000000
ffff810066401ee8 00000000810574da 000004e000000040 000000e0000004e0
00007f1c2c797620 0000000000000246 0000000066401d60 0000000000000000
Call Trace:
[<ffffffff81228b26>] tcp_sendmsg+0x21f/0xb00
[<ffffffff811f0435>] sock_aio_write+0xf8/0x110
[<ffffffff810a9451>] do_sync_write+0xc9/0x10c
[<ffffffff811071d3>] file_has_perm+0x9a/0xa9
[<ffffffff8104e29a>] autoremove_wake_function+0x0/0x2e
[<ffffffff81059db6>] __lock_acquire+0x50f/0xc8e
[<ffffffff810574da>] lock_release_holdtime+0x27/0x48
[<ffffffff810a9c53>] vfs_write+0xd9/0x16f
[<ffffffff810aa1fd>] sys_write+0x45/0x6e
[<ffffffff8100c0ba>] tracesys+0xdc/0xe1


Code: 44 3b 4a 1c 79 10 44 3b 4a 18 78 04 0f 0b eb fe 48 8d 50 10
RIP [<ffffffff81227add>] __tcp_rb_insert+0x1a/0x67
RSP <ffff810066401c88>


--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

2007-12-12 17:58:19

by Cédric Le Goater

[permalink] [raw]
Subject: Re: 2.6.24-rc4-mm1

Ilpo J?rvinen wrote:
> On Wed, 5 Dec 2007, David Miller wrote:
>
>> From: Reuben Farrelly <[email protected]>
>> Date: Thu, 06 Dec 2007 17:59:37 +1100
>>
>>> On 5/12/2007 4:17 PM, Andrew Morton wrote:
>>>> - 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
>> 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 also got plenty of these when untaring a tarball on NFS.

C.

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

Call Trace:
<IRQ> [<ffffffff804115bf>] tcp_fastretrans_alert+0xb6/0xbf2
[<ffffffff80413f30>] tcp_ack+0xdf3/0xfbe
[<ffffffff803da8fb>] sk_reset_timer+0x17/0x23
[<ffffffff80416d1e>] tcp_rcv_established+0xf3/0x76d
[<ffffffff8041d231>] tcp_v4_do_rcv+0x37/0x3aa
[<ffffffff8041fb1f>] tcp_v4_rcv+0x9a9/0xa76
[<ffffffff80402e4e>] ip_local_deliver_finish+0x161/0x23c
[<ffffffff80403363>] ip_local_deliver+0x72/0x77
[<ffffffff80402ca9>] ip_rcv_finish+0x371/0x3b5
[<ffffffff804032bd>] ip_rcv+0x292/0x2c6
[<ffffffff803e3dcc>] netif_receive_skb+0x267/0x340
[<ffffffff8806eff4>] :tg3:tg3_poll+0x5d2/0x89e
[<ffffffff803e639d>] net_rx_action+0xd5/0x1ad
[<ffffffff8023b605>] __do_softirq+0x5f/0xe3
[<ffffffff8020c86c>] call_softirq+0x1c/0x28
[<ffffffff8020e739>] do_softirq+0x39/0x9f
[<ffffffff8023b5a4>] irq_exit+0x4e/0x50
[<ffffffff8020e880>] do_IRQ+0xb7/0xd7
[<ffffffff8020a803>] mwait_idle+0x0/0x55
[<ffffffff8020bb66>] ret_from_intr+0x0/0xf
<EOI> [<ffffffff8024d623>] __atomic_notifier_call_chain+0x20/0x83
[<ffffffff8020a84b>] mwait_idle+0x48/0x55
[<ffffffff80209e79>] enter_idle+0x22/0x24
[<ffffffff8020a793>] cpu_idle+0xa1/0xc5
[<ffffffff8021dfd5>] start_secondary+0x3b9/0x3c5

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

Call Trace:
<IRQ> [<ffffffff804115bf>] tcp_fastretrans_alert+0xb6/0xbf2
[<ffffffff80413f30>] tcp_ack+0xdf3/0xfbe
[<ffffffff804153b8>] tcp_data_queue+0x5da/0xb0a
[<ffffffff80416d1e>] tcp_rcv_established+0xf3/0x76d
[<ffffffff8041d231>] tcp_v4_do_rcv+0x37/0x3aa
[<ffffffff8041fb1f>] tcp_v4_rcv+0x9a9/0xa76
[<ffffffff80402e4e>] ip_local_deliver_finish+0x161/0x23c
[<ffffffff80403363>] ip_local_deliver+0x72/0x77
[<ffffffff80402ca9>] ip_rcv_finish+0x371/0x3b5
[<ffffffff804032bd>] ip_rcv+0x292/0x2c6
[<ffffffff803e3dcc>] netif_receive_skb+0x267/0x340
[<ffffffff8806eff4>] :tg3:tg3_poll+0x5d2/0x89e
[<ffffffff803e639d>] net_rx_action+0xd5/0x1ad
[<ffffffff8023b605>] __do_softirq+0x5f/0xe3
[<ffffffff8020c86c>] call_softirq+0x1c/0x28
[<ffffffff8020e739>] do_softirq+0x39/0x9f
[<ffffffff8023b5a4>] irq_exit+0x4e/0x50
[<ffffffff8020e880>] do_IRQ+0xb7/0xd7
[<ffffffff8020a803>] mwait_idle+0x0/0x55
[<ffffffff8020bb66>] ret_from_intr+0x0/0xf
<EOI> [<ffffffff8024d623>] __atomic_notifier_call_chain+0x20/0x83
[<ffffffff8020a84b>] mwait_idle+0x48/0x55
[<ffffffff80209e79>] enter_idle+0x22/0x24
[<ffffffff8020a793>] cpu_idle+0xa1/0xc5
[<ffffffff8021dfd5>] start_secondary+0x3b9/0x3c5

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

Call Trace:
<IRQ> [<ffffffff804115bf>] tcp_fastretrans_alert+0xb6/0xbf2
[<ffffffff80413f30>] tcp_ack+0xdf3/0xfbe
[<ffffffff804153b8>] tcp_data_queue+0x5da/0xb0a
[<ffffffff80416d1e>] tcp_rcv_established+0xf3/0x76d
[<ffffffff8041d231>] tcp_v4_do_rcv+0x37/0x3aa
[<ffffffff8041fb1f>] tcp_v4_rcv+0x9a9/0xa76
[<ffffffff80402e4e>] ip_local_deliver_finish+0x161/0x23c
[<ffffffff80403363>] ip_local_deliver+0x72/0x77
[<ffffffff80402ca9>] ip_rcv_finish+0x371/0x3b5
[<ffffffff804032bd>] ip_rcv+0x292/0x2c6
[<ffffffff803e3dcc>] netif_receive_skb+0x267/0x340
[<ffffffff8806eff4>] :tg3:tg3_poll+0x5d2/0x89e
[<ffffffff803e639d>] net_rx_action+0xd5/0x1ad
[<ffffffff8023b605>] __do_softirq+0x5f/0xe3
[<ffffffff8020c86c>] call_softirq+0x1c/0x28
[<ffffffff8020e739>] do_softirq+0x39/0x9f
[<ffffffff8023b5a4>] irq_exit+0x4e/0x50
[<ffffffff8020e880>] do_IRQ+0xb7/0xd7
[<ffffffff8020a803>] mwait_idle+0x0/0x55
[<ffffffff8020bb66>] ret_from_intr+0x0/0xf
<EOI> [<ffffffff8024d623>] __atomic_notifier_call_chain+0x20/0x83
[<ffffffff8020a84b>] mwait_idle+0x48/0x55
[<ffffffff80209e79>] enter_idle+0x22/0x24
[<ffffffff8020a793>] cpu_idle+0xa1/0xc5
[<ffffffff8021dfd5>] start_secondary+0x3b9/0x3c5

2007-12-12 19:21:44

by Cédric Le Goater

[permalink] [raw]
Subject: Re: 2.6.24-rc4-mm1

Ilpo J?rvinen wrote:
> On Wed, 5 Dec 2007, Andrew Morton wrote:
>
>> On Thu, 06 Dec 2007 17:59:37 +1100 Reuben Farrelly <[email protected]> wrote:
>>
>>> 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.
>>
>>> 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.

nah. I got the WARNINGs again with this patch.

C.

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

2007-12-13 17:38:59

by Cédric Le Goater

[permalink] [raw]
Subject: tcp_sacktag_one() WARNING (was Re: 2.6.24-rc4-mm1)

Cedric Le Goater wrote:
> Ilpo J?rvinen wrote:
>> On Wed, 5 Dec 2007, Andrew Morton wrote:
>>
>>> On Thu, 06 Dec 2007 17:59:37 +1100 Reuben Farrelly <[email protected]> wrote:
>>>
>>>> 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.
>>>
>>>> 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.
>
> nah. I got the WARNINGs again with this patch.

I got this new one on a 2.6.24-rc5-mm1. It looked similar ?

C.

WARNING: at /home/legoater/linux/2.6.24-rc5-mm1/net/ipv4/tcp_input.c:1280 tcp_sacktag_one()
Pid: 0, comm: swapper Not tainted 2.6.24-rc5-mm1 #1

Call Trace:
<IRQ> [<ffffffff80410e0e>] tcp_sacktag_walk+0x2bc/0x62a
[<ffffffff80411711>] tcp_sacktag_write_queue+0x595/0xa7c
[<ffffffff8028ce66>] kfree+0xd4/0xe0
[<ffffffff80411e9f>] tcp_ack+0x2a7/0xfc7
[<ffffffff80252ca1>] mark_held_locks+0x47/0x6a
[<ffffffff80252e5c>] trace_hardirqs_on+0xfe/0x139
[<ffffffff80415d59>] tcp_rcv_established+0x66a/0x76d
[<ffffffff8041bd35>] tcp_v4_do_rcv+0x37/0x3aa
[<ffffffff8041e623>] tcp_v4_rcv+0x9a9/0xa76
[<ffffffff80401832>] ip_local_deliver_finish+0x161/0x23c
[<ffffffff80401d47>] ip_local_deliver+0x72/0x77
[<ffffffff8040168d>] ip_rcv_finish+0x371/0x3b5
[<ffffffff80401ca1>] ip_rcv+0x292/0x2c6
[<ffffffff803e2aae>] netif_receive_skb+0x267/0x340
[<ffffffff8806eff4>] :tg3:tg3_poll+0x5d2/0x89e
[<ffffffff803e505c>] net_rx_action+0xd5/0x1ad
[<ffffffff8023b0b9>] __do_softirq+0x5f/0xe3
[<ffffffff8020c8ec>] call_softirq+0x1c/0x28
[<ffffffff8020e7b9>] do_softirq+0x39/0x9f
[<ffffffff8023b058>] irq_exit+0x4e/0x50
[<ffffffff8020e900>] do_IRQ+0xb7/0xd7
[<ffffffff8020a892>] mwait_idle+0x0/0x52
[<ffffffff8020bbe6>] ret_from_intr+0x0/0xf
<EOI> [<ffffffff8024d0cb>] __atomic_notifier_call_chain+0x20/0x83
[<ffffffff8020a8da>] mwait_idle+0x48/0x52
[<ffffffff80209e79>] enter_idle+0x22/0x24
[<ffffffff8020a822>] cpu_idle+0xa1/0xc5
[<ffffffff8021e755>] start_secondary+0x3b9/0x3c5

2007-12-13 17:45:31

by Cédric Le Goater

[permalink] [raw]
Subject: Re: 2.6.24-rc4-mm1 - BUG in tcp_fragment

Andrew Morton wrote:
> 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/

I got this one while compiling on NFS.

C.

kernel BUG at /home/legoater/linux/2.6.24-rc4-mm1/include/net/tcp.h:1480!
invalid opcode: 0000 [1] SMP
last sysfs file: /sys/devices/pci0000:00/0000:00:1e.0/0000:01:01.0/local_cpus
CPU 1
Modules linked in: autofs4 nfs lockd sunrpc tg3 sg joydev ext3 jbd ehci_hcd ohci_hcd uhci_hcd
Pid: 0, comm: swapper Not tainted 2.6.24-rc4-mm1 #3
RIP: 0010:[<ffffffff80418d93>] [<ffffffff80418d93>] tcp_fragment+0x5ee/0x6f7
RSP: 0018:ffff810147c9f9e0 EFLAGS: 00010217
RAX: 000000001526c311 RBX: ffff8100c2ce1d00 RCX: ffff810143cc6aa0
RDX: 0000000000000001 RSI: ffff810102b37b00 RDI: ffff810102b37b50
RBP: ffff810147c9fa50 R08: 000000000000004a R09: 0000000000000001
R10: 0000000000000b50 R11: 0000000000000001 R12: ffff81013a575700
R13: 0000000000000000 R14: ffff810143cc6400 R15: ffff81013a575750
FS: 0000000000000000(0000) GS:ffff810147c57140(0000) knlGS:0000000000000000
CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: 00002ad5d294b000 CR3: 00000000bd11b000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process swapper (pid: 0, threadinfo ffff810147c98000, task ffff810147c89040)
Stack: ffff810147c9fa00 ffffffff00000000 000005a843cc6400 ffff810143cc6400
ffff810147c9fa70 ffff8100c2ce1d50 ffff810143cc6590 ffff810143cc6aa0
1526542100000000 ffff810143cc6400 ffff810143cc6400 ffff81013a575700
Call Trace:
<IRQ> [<ffffffff804190c7>] tcp_retransmit_skb+0xd6/0x713
[<ffffffff804197d4>] tcp_xmit_retransmit_queue+0xd0/0x330
[<ffffffff8041209b>] tcp_fastretrans_alert+0xb92/0xbf2
[<ffffffff80413f30>] tcp_ack+0xdf3/0xfbe
[<ffffffff80417295>] tcp_rcv_established+0x66a/0x76d
[<ffffffff8041d285>] tcp_v4_do_rcv+0x37/0x3aa
[<ffffffff8041fb73>] tcp_v4_rcv+0x9a9/0xa76
[<ffffffff80402e4e>] ip_local_deliver_finish+0x161/0x23c
[<ffffffff80403363>] ip_local_deliver+0x72/0x77
[<ffffffff80402ca9>] ip_rcv_finish+0x371/0x3b5
[<ffffffff804032bd>] ip_rcv+0x292/0x2c6
[<ffffffff803e3dcc>] netif_receive_skb+0x267/0x340
[<ffffffff8806eff4>] :tg3:tg3_poll+0x5d2/0x89e
[<ffffffff803e639d>] net_rx_action+0xd5/0x1ad
[<ffffffff8023b605>] __do_softirq+0x5f/0xe3
[<ffffffff8020c86c>] call_softirq+0x1c/0x28
[<ffffffff8020e739>] do_softirq+0x39/0x9f
[<ffffffff8023b5a4>] irq_exit+0x4e/0x50
[<ffffffff8020e880>] do_IRQ+0xb7/0xd7
[<ffffffff8020a803>] mwait_idle+0x0/0x55
[<ffffffff8020bb66>] ret_from_intr+0x0/0xf
<EOI> [<ffffffff8024d623>] __atomic_notifier_call_chain+0x20/0x83
[<ffffffff8020a84b>] mwait_idle+0x48/0x55
[<ffffffff80209e79>] enter_idle+0x22/0x24
[<ffffffff8020a793>] cpu_idle+0xa1/0xc5
[<ffffffff8021dfd5>] start_secondary+0x3b9/0x3c5


Code: 0f 0b eb fe 48 85 f6 74 08 8b 46 6c 3b 41 68 75 55 48 8d 41
RIP [<ffffffff80418d93>] tcp_fragment+0x5ee/0x6f7
RSP <ffff810147c9f9e0>
Kernel panic - not syncing: Aiee, killing interrupt handler!

2007-12-13 23:00:36

by Ilpo Järvinen

[permalink] [raw]
Subject: Re: 2.6.24-rc4-mm1 - BUG in tcp_fragment

On Thu, 13 Dec 2007, Cedric Le Goater wrote:

> I got this one while compiling on NFS.
>
> C.
>
> kernel BUG at /home/legoater/linux/2.6.24-rc4-mm1/include/net/tcp.h:1480!

I'm not exactly sure what patches you have applied and which patches are
not, with rc4-mm1 there are two patches (first one was incomplete, I
assume you had at least that one based on your other mail) to really fix
the issues in (__|)tcp_reset_fack_counts(...). However, there seems to be
so much breakage that I have a bit trouble to decide where to start...
The situation seems bit scary :-).

So, I might soon prepare a revert patch for most of the questionable
TCP parts and ask Dave to apply it (and drop them fully during next
rebase) unless I suddently figure something out soon which explains
all/most of the problems, then return to drawing board. ...As it seems
that the cumulative ACK processing problem discovered later on (having
rather cumbersome solution with skbs only) will make part of the work
that's currently in net-2.6.25 quite useless/duplicate effort. But thanks
anyway for reporting these.


--
i.

2007-12-14 06:52:59

by Cédric Le Goater

[permalink] [raw]
Subject: Re: 2.6.24-rc4-mm1 - BUG in tcp_fragment

Ilpo J?rvinen wrote:
> On Thu, 13 Dec 2007, Cedric Le Goater wrote:
>
>> I got this one while compiling on NFS.
>>
>> C.
>>
>> kernel BUG at /home/legoater/linux/2.6.24-rc4-mm1/include/net/tcp.h:1480!
>
> I'm not exactly sure what patches you have applied and which patches are
> not, with rc4-mm1 there are two patches (first one was incomplete, I
> assume you had at least that one based on your other mail) to really fix
> the issues in (__|)tcp_reset_fack_counts(...).

Yes I only have the first patch you sent on lkml on top of 2.6.24-rc4-mm1.
attached below. I didn't see the second one on lkml ?

> However, there seems to be so much breakage that I have a bit trouble to
> decide where to start... The situation seems bit scary :-).

my n/w environment seems to reproduce these issues quite easily. if you
need some testing, just ping me.

Cheers,

C.

> So, I might soon prepare a revert patch for most of the questionable
> TCP parts and ask Dave to apply it (and drop them fully during next
> rebase) unless I suddently figure something out soon which explains
> all/most of the problems, then return to drawing board. ...As it seems
> that the cumulative ACK processing problem discovered later on (having
> rather cumbersome solution with skbs only) will make part of the work
> that's currently in net-2.6.25 quite useless/duplicate effort. But thanks
> anyway for reporting these.
>
>

Subject: [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 <[email protected]>
---
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

2007-12-14 20:14:48

by Ilpo Järvinen

[permalink] [raw]
Subject: [PATCH net-2.6.25] Revert recent TCP work

On Fri, 14 Dec 2007, Ilpo J?rvinen wrote:

> So, I might soon prepare a revert patch for most of the questionable
> TCP parts and ask Dave to apply it (and drop them fully during next
> rebase) unless I suddently figure something out soon which explains
> all/most of the problems, then return to drawing board. ...As it seems
> that the cumulative ACK processing problem discovered later on (having
> rather cumbersome solution with skbs only) will make part of the work
> that's currently in net-2.6.25 quite useless/duplicate effort. But thanks
> anyway for reporting these.

Hi Dave,

Could you either drop my recent patches (+one fix to them from Herbert
Xu == "[TCP]: Fix crash in tcp_advance_send_head"), all mine after "[TCP]:
Abstract tp->highest_sack accessing & point to next skb" from net-2.6.25
or just apply the revert from below and do the removal during next rebase.
I think it could even be automated by something like this (untested):
for i in $(cat commits | cut -d ' ' -f 1); do git-rebase --onto $i^ $i; done
(I've attached the commits list).

I'll resend small bits that are still useful but get removed in this kind
of straightforward operation (I guess it's easier for you to track this
way and makes conflicts a non-problem).

...It was buggy as well, I've tried to Cc all bug reporters that I've
noticed so far... Related bugs include at least these cases:

These are completely removed by this revert:
__tcp_rb_insert
(__|)tcp_reset_fack_counts
May still trigger later due to other, genuine bugs:
tcp_sacktag_one (I'll rework & resend this soon)
tcp_fastretrans_alert (fackets_out trap)
BUG_TRAP(packets <= tp->packets_out); in tcp_mark_head_lost

--
i.


[PATCH net-2.6.25] Revert recent TCP work

It was recently discovered that there's yet another processing
aspect to consider related to cumulative ACK processing. This
solution wasn't enough to handle that but "(arguably) complex"
and intrusive changes were still necessary in addition to the
complexity this already introduced. Another approach is on the
drawing board.

This was somehow buggy as well, a lot of reports against it
were filed already :-), but hunting the cause doesn't seem so
beneficial anymore.

Signed-off-by: Ilpo J?rvinen <[email protected]>
---
include/linux/skbuff.h | 3 -
include/linux/tcp.h | 4 -
include/net/tcp.h | 362 ++++------------------------------------------
net/ipv4/tcp_input.c | 341 ++++++++++++++++++++-----------------------
net/ipv4/tcp_ipv4.c | 1 -
net/ipv4/tcp_minisocks.c | 1 -
net/ipv4/tcp_output.c | 13 +-
net/ipv6/tcp_ipv6.c | 1 -
8 files changed, 196 insertions(+), 530 deletions(-)

diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index f21fee6..c618fbf 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -18,7 +18,6 @@
#include <linux/compiler.h>
#include <linux/time.h>
#include <linux/cache.h>
-#include <linux/rbtree.h>

#include <asm/atomic.h>
#include <asm/types.h>
@@ -254,8 +253,6 @@ struct sk_buff {
struct sk_buff *next;
struct sk_buff *prev;

- struct rb_node rb;
-
struct sock *sk;
ktime_t tstamp;
struct net_device *dev;
diff --git a/include/linux/tcp.h b/include/linux/tcp.h
index 56342c3..08027f1 100644
--- a/include/linux/tcp.h
+++ b/include/linux/tcp.h
@@ -174,7 +174,6 @@ struct tcp_md5sig {

#include <linux/skbuff.h>
#include <linux/dmaengine.h>
-#include <linux/rbtree.h>
#include <net/sock.h>
#include <net/inet_connection_sock.h>
#include <net/inet_timewait_sock.h>
@@ -321,9 +320,6 @@ struct tcp_sock {
u32 snd_cwnd_used;
u32 snd_cwnd_stamp;

- struct rb_root write_queue_rb;
- struct rb_root sacked_queue_rb;
- struct sk_buff_head sacked_queue;
struct sk_buff_head out_of_order_queue; /* Out of order segments go here */

u32 rcv_wnd; /* Current receiver window */
diff --git a/include/net/tcp.h b/include/net/tcp.h
index 5e6c433..5ec1cac 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -555,7 +555,6 @@ struct tcp_skb_cb {
__u32 seq; /* Starting sequence number */
__u32 end_seq; /* SEQ + FIN + SYN + datalen */
__u32 when; /* used to compute rtt's */
- unsigned int fack_count; /* speed up SACK processing */
__u8 flags; /* TCP header flags. */

/* NOTE: These must match up to the flags byte in a
@@ -1191,112 +1190,29 @@ static inline void tcp_put_md5sig_pool(void)
}

/* write queue abstraction */
-#define TCP_WQ_SACKED 1
-
-static inline struct sk_buff_head *__tcp_list_select(struct sock *sk, const int queue)
-{
- if (queue == TCP_WQ_SACKED)
- return &tcp_sk(sk)->sacked_queue;
- else
- return &sk->sk_write_queue;
-}
-
-static inline struct rb_root *__tcp_tree_select(struct sock *sk, const int tree)
-{
- if (tree == TCP_WQ_SACKED)
- return &tcp_sk(sk)->sacked_queue_rb;
- else
- return &tcp_sk(sk)->write_queue_rb;
-}
-
-/* All SACKed except S|R go to a separate skb space */
-static inline int __tcp_skb_queue_select(const struct sk_buff *skb)
-{
- if ((TCP_SKB_CB(skb)->sacked &
- (TCPCB_SACKED_ACKED|TCPCB_SACKED_RETRANS)) ==
- TCPCB_SACKED_ACKED)
- return TCP_WQ_SACKED;
- else
- return 0;
-}
-
-static inline void tcp_write_queue_init(struct sock *sk)
-{
- tcp_sk(sk)->write_queue_rb = RB_ROOT;
- tcp_sk(sk)->sacked_queue_rb = RB_ROOT;
- skb_queue_head_init(&tcp_sk(sk)->sacked_queue);
-}
-
-static inline void __tcp_write_queue_purge(struct sock *sk, int queue)
+static inline void tcp_write_queue_purge(struct sock *sk)
{
struct sk_buff *skb;

- while ((skb = __skb_dequeue(__tcp_list_select(sk, queue))) != NULL)
+ while ((skb = __skb_dequeue(&sk->sk_write_queue)) != NULL)
sk_stream_free_skb(sk, skb);
- *__tcp_tree_select(sk, queue) = RB_ROOT;
-}
-
-static inline void tcp_write_queue_purge(struct sock *sk)
-{
- __tcp_write_queue_purge(sk, 0);
- __tcp_write_queue_purge(sk, TCP_WQ_SACKED);
sk_stream_mem_reclaim(sk);
}

-static inline struct sk_buff *__tcp_write_queue_head(struct sock *sk, int queue)
-{
- struct sk_buff *skb = __tcp_list_select(sk, queue)->next;
- if (skb == (struct sk_buff *)__tcp_list_select(sk, queue))
- return NULL;
- return skb;
-}
-
static inline struct sk_buff *tcp_write_queue_head(struct sock *sk)
{
- return __tcp_write_queue_head(sk, 0);
-}
-
-/* FIXME, this should eventually vanish because callers likely benefit
- * from scanning the non-SACKed and SACKed spaces separately.
- */
-static inline struct sk_buff *tcp_real_queue_head(struct sock *sk)
-{
- struct sk_buff *skb, *sacked;
-
- skb = tcp_write_queue_head(sk);
- sacked = __tcp_write_queue_head(sk, TCP_WQ_SACKED);
-
- if (skb == NULL)
- return sacked;
- if (sacked == NULL)
- return skb;
-
- if (after(TCP_SKB_CB(skb)->seq, TCP_SKB_CB(sacked)->seq))
- return sacked;
- return skb;
-}
-
-static inline struct sk_buff *__tcp_write_queue_tail(struct sock *sk, int queue)
-{
- struct sk_buff *skb = __tcp_list_select(sk, queue)->prev;
- if (skb == (struct sk_buff *)__tcp_list_select(sk, queue))
+ struct sk_buff *skb = sk->sk_write_queue.next;
+ if (skb == (struct sk_buff *) &sk->sk_write_queue)
return NULL;
return skb;
}

static inline struct sk_buff *tcp_write_queue_tail(struct sock *sk)
{
- return __tcp_write_queue_tail(sk, 0);
-}
-
-static inline int __tcp_write_queue_empty(struct sock *sk, int queue)
-{
- return skb_queue_empty(__tcp_list_select(sk, queue));
-}
-
-static inline int tcp_write_queue_empty(struct sock *sk)
-{
- return __tcp_write_queue_empty(sk, 0);
+ struct sk_buff *skb = sk->sk_write_queue.prev;
+ if (skb == (struct sk_buff *) &sk->sk_write_queue)
+ return NULL;
+ return skb;
}

static inline struct sk_buff *tcp_write_queue_next(struct sock *sk, struct sk_buff *skb)
@@ -1304,29 +1220,18 @@ static inline struct sk_buff *tcp_write_queue_next(struct sock *sk, struct sk_bu
return skb->next;
}

-static inline struct sk_buff *tcp_write_queue_prev(struct sock *sk, struct sk_buff *skb)
-{
- return skb->prev;
-}
-
-static inline int tcp_skb_adjacent(struct sock *sk, struct sk_buff *skb,
- struct sk_buff *next)
-{
- return TCP_SKB_CB(skb)->end_seq == TCP_SKB_CB(next)->seq;
-}
-
-#define tcp_for_write_queue(skb, sk, queue) \
- for (skb = __tcp_list_select(sk, queue)->next; \
- (skb != (struct sk_buff *)__tcp_list_select(sk, queue));\
+#define tcp_for_write_queue(skb, sk) \
+ for (skb = (sk)->sk_write_queue.next; \
+ (skb != (struct sk_buff *)&(sk)->sk_write_queue); \
skb = skb->next)

-#define tcp_for_write_queue_from(skb, sk, queue) \
- for (; (skb != (struct sk_buff *)__tcp_list_select(sk, queue));\
+#define tcp_for_write_queue_from(skb, sk) \
+ for (; (skb != (struct sk_buff *)&(sk)->sk_write_queue);\
skb = skb->next)

-#define tcp_for_write_queue_from_safe(skb, tmp, sk, queue) \
+#define tcp_for_write_queue_from_safe(skb, tmp, sk) \
for (tmp = skb->next; \
- (skb != (struct sk_buff *)__tcp_list_select(sk, queue));\
+ (skb != (struct sk_buff *)&(sk)->sk_write_queue); \
skb = tmp, tmp = skb->next)

static inline struct sk_buff *tcp_send_head(struct sock *sk)
@@ -1336,23 +1241,7 @@ 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 == 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);
+ sk->sk_send_head = skb->next;
if (sk->sk_send_head == (struct sk_buff *)&sk->sk_write_queue)
sk->sk_send_head = NULL;
}
@@ -1368,78 +1257,9 @@ static inline void tcp_init_send_head(struct sock *sk)
sk->sk_send_head = NULL;
}

-static inline struct sk_buff *__tcp_write_queue_find(struct rb_node *rb_node,
- __u32 seq)
-{
- struct sk_buff *skb = NULL;
-
- while (rb_node) {
- struct sk_buff *tmp = rb_entry(rb_node,struct sk_buff,rb);
- if (after(TCP_SKB_CB(tmp)->end_seq, seq)) {
- skb = tmp;
- if (!after(TCP_SKB_CB(tmp)->seq, seq))
- break;
- rb_node = rb_node->rb_left;
- } else
- rb_node = rb_node->rb_right;
-
- }
- return skb;
-}
-
-static inline struct sk_buff *tcp_write_queue_find(struct sock *sk, __u32 seq, int tree)
-{
- return __tcp_write_queue_find(__tcp_tree_select(sk, tree)->rb_node, seq);
-}
-
-/* Inserts skb into RB-tree root, prev node (ie., the skb before the inserted
- * one) is returned, which is available as a side-effect from parent of the
- * last rb_right edge. If no rb_right edge is walked, NULL is returned (tree
- * does not contain a smaller node).
- */
-static struct sk_buff *__tcp_rb_insert(struct sk_buff *skb,
- struct rb_root *root)
-{
- struct rb_node **rb_link, *rb_parent;
- struct sk_buff *prev = NULL;
- __u32 seq = TCP_SKB_CB(skb)->seq;
-
- rb_link = &root->rb_node;
- rb_parent = NULL;
- while (*rb_link) {
- struct sk_buff *tmp;
-
- rb_parent = *rb_link;
- tmp = rb_entry(rb_parent,struct sk_buff,rb);
- if (after(TCP_SKB_CB(tmp)->end_seq, seq)) {
- BUG_ON(!after(TCP_SKB_CB(tmp)->seq, seq));
- rb_link = &rb_parent->rb_left;
- } else {
- rb_link = &rb_parent->rb_right;
- prev = tmp;
- }
- }
- rb_link_node(&skb->rb, rb_parent, rb_link);
- rb_insert_color(&skb->rb, root);
-
- return prev;
-}
-
-static inline void tcp_rb_insert(struct sk_buff *skb, struct rb_root *root)
-{
- __tcp_rb_insert(skb, root);
-}
-
-static inline void tcp_rb_unlink(struct sk_buff *skb, struct rb_root *root)
-{
- rb_erase(&skb->rb, root);
-}
-
static inline void __tcp_add_write_queue_tail(struct sock *sk, struct sk_buff *skb)
{
- TCP_SKB_CB(skb)->fack_count = 0;
__skb_queue_tail(&sk->sk_write_queue, skb);
- tcp_rb_insert(skb, &tcp_sk(sk)->write_queue_rb);
}

static inline void tcp_add_write_queue_tail(struct sock *sk, struct sk_buff *skb)
@@ -1455,90 +1275,9 @@ static inline void tcp_add_write_queue_tail(struct sock *sk, struct sk_buff *skb
}
}

-/* This is only used for tcp_send_synack(), so the write queue should
- * be empty. If that stops being true, the fack_count assignment
- * will need to be more elaborate.
- */
static inline void __tcp_add_write_queue_head(struct sock *sk, struct sk_buff *skb)
{
- BUG_ON(!skb_queue_empty(&sk->sk_write_queue));
__skb_queue_head(&sk->sk_write_queue, skb);
- TCP_SKB_CB(skb)->fack_count = 0;
- tcp_rb_insert(skb, &tcp_sk(sk)->write_queue_rb);
-}
-
-/* An insert into the middle of the write queue causes the fack
- * counts in subsequent packets to become invalid, fix them up.
- *
- * FIXME, this definately could be improved!
- */
-static inline void tcp_reset_fack_counts(struct sock *sk, struct sk_buff *inskb)
-{
- struct sk_buff *prev;
- struct sk_buff *skb[2] = {NULL, NULL};
- int queue;
- unsigned int fc = 0;
-
- if (!before(TCP_SKB_CB(inskb)->seq, tcp_sk(sk)->snd_nxt))
- return;
-
- queue = __tcp_skb_queue_select(inskb);
- skb[queue] = inskb;
-
- prev = inskb->prev;
- if (inskb == __tcp_write_queue_head(sk, queue))
- prev = NULL;
-
- if (((prev != NULL) && !tcp_skb_adjacent(sk, prev, inskb)) ||
- ((prev == NULL) && (TCP_SKB_CB(inskb)->seq != tcp_sk(sk)->snd_una))) {
- int otherq = queue ^ TCP_WQ_SACKED;
-
- BUG_ON (__tcp_write_queue_empty(sk, otherq));
- prev = tcp_write_queue_find(sk, TCP_SKB_CB(inskb)->seq - 1,
- otherq);
- BUG_ON (prev == NULL || prev == tcp_send_head(sk));
- skb[otherq] = prev->next;
- }
-
- if (prev != NULL)
- fc = TCP_SKB_CB(prev)->fack_count + tcp_skb_pcount(prev);
-
- while (skb[queue] != (struct sk_buff *)__tcp_list_select(sk, queue)) {
- /* Lazy find for the other queue */
- if (skb[queue] == NULL) {
- skb[queue] = tcp_write_queue_find(sk, TCP_SKB_CB(prev)->seq,
- queue);
- if (skb[queue] == NULL)
- break;
- }
-
- BUG_ON((prev != NULL) && !tcp_skb_adjacent(sk, prev, skb[queue]));
-
- tcp_for_write_queue_from(skb[queue], sk, queue) {
- if ((prev != NULL) && !tcp_skb_adjacent(sk, prev, skb[queue]))
- break;
-
- if (!before(TCP_SKB_CB(skb[queue])->seq, tcp_sk(sk)->snd_nxt) ||
- TCP_SKB_CB(skb[queue])->fack_count == fc)
- return;
-
- TCP_SKB_CB(skb[queue])->fack_count = fc;
- fc += tcp_skb_pcount(skb[queue]);
-
- prev = skb[queue];
- }
-
- queue ^= TCP_WQ_SACKED;
- }
-}
-
-static inline void __tcp_insert_write_queue_after(struct sk_buff *skb,
- struct sk_buff *buff,
- struct sock *sk,
- int queue)
-{
- __skb_append(skb, buff, __tcp_list_select(sk, queue));
- tcp_rb_insert(buff, __tcp_tree_select(sk, queue));
}

/* Insert buff after skb on the write queue of sk. */
@@ -1546,74 +1285,36 @@ static inline void tcp_insert_write_queue_after(struct sk_buff *skb,
struct sk_buff *buff,
struct sock *sk)
{
- __tcp_insert_write_queue_after(skb, buff, sk, __tcp_skb_queue_select(buff));
- tcp_reset_fack_counts(sk, buff);
+ __skb_append(skb, buff, &sk->sk_write_queue);
}

-/* Insert new before skb on the write queue of sk.
- *
- * This is only used for tcp_mtu_probe() new send_head injection. If that
- * stops being true, needs to consider fack_counts and TCP_WQ_SACKED.
- */
-static inline void __tcp_insert_write_queue_before(struct sk_buff *new,
- struct sk_buff *skb,
- struct sock *sk)
+/* Insert skb between prev and next on the write queue of sk. */
+static inline void tcp_insert_write_queue_before(struct sk_buff *new,
+ struct sk_buff *skb,
+ struct sock *sk)
{
- BUG_ON(sk->sk_send_head != skb);
-
__skb_insert(new, skb->prev, skb, &sk->sk_write_queue);
- tcp_rb_insert(new, &tcp_sk(sk)->write_queue_rb);
- sk->sk_send_head = new;
-}

-static inline void tcp_unlink_write_queue(struct sk_buff *skb, struct sock *sk)
-{
- int queue = __tcp_skb_queue_select(skb);
-
- __skb_unlink(skb, __tcp_list_select(sk, queue));
- tcp_rb_unlink(skb, __tcp_tree_select(sk, queue));
+ if (sk->sk_send_head == skb)
+ sk->sk_send_head = new;
}

-/* Moves skb to queue part of the skb space, a bit fragile, call must be made
- * prior (important) sacked changes (= ->S and &~R)
- */
-static inline void tcp_write_queue_requeue(struct sk_buff *skb,
- struct sock *sk, int queue)
+static inline void tcp_unlink_write_queue(struct sk_buff *skb, struct sock *sk)
{
- struct sk_buff *prev;
-
- /* FIXME, most of hints are to be dropped soon... */
- if (tcp_sk(sk)->scoreboard_skb_hint == skb)
- tcp_sk(sk)->scoreboard_skb_hint = skb->next;
- if (tcp_sk(sk)->forward_skb_hint == skb)
- tcp_sk(sk)->forward_skb_hint = skb->next;
- /* ...These have related cnt */
- if (tcp_sk(sk)->lost_skb_hint == skb)
- tcp_sk(sk)->lost_skb_hint = NULL;
- if (tcp_sk(sk)->retransmit_skb_hint == skb)
- tcp_sk(sk)->retransmit_skb_hint = NULL;
-
- /* S|R must not be in SACKed space because of mark_lost_retrans walk */
- if ((queue == TCP_WQ_SACKED) &&
- (TCP_SKB_CB(skb)->sacked & TCPCB_SACKED_RETRANS))
- return;
-
- tcp_unlink_write_queue(skb, sk);
-
- prev = __tcp_rb_insert(skb, __tcp_tree_select(sk, queue));
- if (prev == NULL)
- prev = (struct sk_buff *)__tcp_list_select(sk, queue);
- __skb_append(prev, skb, __tcp_list_select(sk, queue));
+ __skb_unlink(skb, &sk->sk_write_queue);
}

static inline int tcp_skb_is_last(const struct sock *sk,
const struct sk_buff *skb)
{
- BUG_ON(__tcp_skb_queue_select(skb) == TCP_WQ_SACKED);
-
return skb->next == (struct sk_buff *)&sk->sk_write_queue;
}

+static inline int tcp_write_queue_empty(struct sock *sk)
+{
+ return skb_queue_empty(&sk->sk_write_queue);
+}
+
/* Start sequence of the highest skb with SACKed bit, valid only if
* sacked > 0 or when the caller has ensured validity by itself.
*/
@@ -1628,9 +1329,6 @@ static inline u32 tcp_highest_sack_seq(struct tcp_sock *tp)
return TCP_SKB_CB(tp->highest_sack)->seq;
}

-/* This is somewhat dangerous now, because skb must still be in non-sacked
- * space
- */
static inline void tcp_advance_highest_sack(struct sock *sk, struct sk_buff *skb)
{
tcp_sk(sk)->highest_sack = tcp_skb_is_last(sk, skb) ? NULL :
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 218754b..616bbcb 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -1072,7 +1072,7 @@ static void tcp_update_reordering(struct sock *sk, const int metric,
* the exact amount is rather hard to quantify. However, tp->max_window can
* be used as an exaggerated estimate.
*/
-static int tcp_is_sackblock_valid(struct tcp_sock *tp,
+static int tcp_is_sackblock_valid(struct tcp_sock *tp, int is_dsack,
u32 start_seq, u32 end_seq)
{
/* Too far in future, or reversed (interpretation is ambiguous) */
@@ -1089,16 +1089,10 @@ static int tcp_is_sackblock_valid(struct tcp_sock *tp,
if (after(start_seq, tp->snd_una))
return 1;

- return 0;
-}
-
-static int tcp_is_past_dsack_useful(struct tcp_sock *tp,
- u32 start_seq, u32 end_seq)
-{
- if (!tp->undo_marker)
+ if (!is_dsack || !tp->undo_marker)
return 0;

- /* ...Past D-SACK must reside below snd_una completely */
+ /* ...Then it's D-SACK, and must reside below snd_una completely */
if (!after(end_seq, tp->snd_una))
return 0;

@@ -1138,7 +1132,7 @@ static void tcp_mark_lost_retrans(struct sock *sk)
icsk->icsk_ca_state != TCP_CA_Recovery)
return;

- tcp_for_write_queue(skb, sk, 0) {
+ tcp_for_write_queue(skb, sk) {
u32 ack_seq = TCP_SKB_CB(skb)->ack_seq;

if (skb == tcp_send_head(sk))
@@ -1155,10 +1149,6 @@ static void tcp_mark_lost_retrans(struct sock *sk)
(tcp_is_fack(tp) ||
!before(received_upto,
ack_seq + tp->reordering * tp->mss_cache))) {
-
- if (TCP_SKB_CB(skb)->sacked & TCPCB_SACKED_ACKED)
- tcp_write_queue_requeue(skb, sk, TCP_WQ_SACKED);
-
TCP_SKB_CB(skb)->sacked &= ~TCPCB_SACKED_RETRANS;
tp->retrans_out -= tcp_skb_pcount(skb);

@@ -1181,6 +1171,39 @@ static void tcp_mark_lost_retrans(struct sock *sk)
tp->lost_retrans_low = new_low_seq;
}

+static int tcp_check_dsack(struct tcp_sock *tp, struct sk_buff *ack_skb,
+ struct tcp_sack_block_wire *sp, int num_sacks,
+ u32 prior_snd_una)
+{
+ u32 start_seq_0 = ntohl(get_unaligned(&sp[0].start_seq));
+ u32 end_seq_0 = ntohl(get_unaligned(&sp[0].end_seq));
+ int dup_sack = 0;
+
+ if (before(start_seq_0, TCP_SKB_CB(ack_skb)->ack_seq)) {
+ dup_sack = 1;
+ tcp_dsack_seen(tp);
+ NET_INC_STATS_BH(LINUX_MIB_TCPDSACKRECV);
+ } else if (num_sacks > 1) {
+ u32 end_seq_1 = ntohl(get_unaligned(&sp[1].end_seq));
+ u32 start_seq_1 = ntohl(get_unaligned(&sp[1].start_seq));
+
+ if (!after(end_seq_0, end_seq_1) &&
+ !before(start_seq_0, start_seq_1)) {
+ dup_sack = 1;
+ tcp_dsack_seen(tp);
+ NET_INC_STATS_BH(LINUX_MIB_TCPDSACKOFORECV);
+ }
+ }
+
+ /* D-SACK for already forgotten data... Do dumb counting. */
+ if (dup_sack &&
+ !after(end_seq_0, prior_snd_una) &&
+ after(end_seq_0, tp->undo_marker))
+ tp->undo_retrans--;
+
+ return dup_sack;
+}
+
/* Check if skb is fully within the SACK block. In presence of GSO skbs,
* the incoming SACK may not exactly match but we can find smaller MSS
* aligned portion of it that matches. Therefore we might need to fragment
@@ -1214,15 +1237,11 @@ static int tcp_match_skb_to_sack(struct sock *sk, struct sk_buff *skb,
}

static int tcp_sacktag_one(struct sk_buff *skb, struct sock *sk,
- int *reord, int dup_sack)
+ int *reord, int dup_sack, int fack_count)
{
struct tcp_sock *tp = tcp_sk(sk);
u8 sacked = TCP_SKB_CB(skb)->sacked;
int flag = 0;
- int fack_count;
-
- fack_count = TCP_SKB_CB(skb)->fack_count -
- TCP_SKB_CB(tcp_write_queue_head(sk))->fack_count;

/* Account D-SACK for retransmitted packet. */
if (dup_sack && (sacked & TCPCB_RETRANS)) {
@@ -1274,28 +1293,23 @@ static int tcp_sacktag_one(struct sk_buff *skb, struct sock *sk,
}
}

- fack_count += tcp_skb_pcount(skb);
- if (!before(TCP_SKB_CB(skb)->seq, tcp_highest_sack_seq(tp))) {
- WARN_ON((fack_count <= tp->fackets_out) ||
- (fack_count > tp->packets_out));
-
- tcp_advance_highest_sack(sk, skb);
- tp->fackets_out = fack_count;
- } else
- WARN_ON(fack_count > tp->fackets_out);
-
- tcp_write_queue_requeue(skb, sk, TCP_WQ_SACKED);
-
TCP_SKB_CB(skb)->sacked |= TCPCB_SACKED_ACKED;
flag |= FLAG_DATA_SACKED;
tp->sacked_out += tcp_skb_pcount(skb);

+ fack_count += tcp_skb_pcount(skb);
+
/* Lost marker hint past SACKed? Tweak RFC3517 cnt */
if (!tcp_is_fack(tp) && (tp->lost_skb_hint != NULL) &&
before(TCP_SKB_CB(skb)->seq,
TCP_SKB_CB(tp->lost_skb_hint)->seq))
tp->lost_cnt_hint += tcp_skb_pcount(skb);

+ if (fack_count > tp->fackets_out)
+ tp->fackets_out = fack_count;
+
+ if (!before(TCP_SKB_CB(skb)->seq, tcp_highest_sack_seq(tp)))
+ tcp_advance_highest_sack(sk, skb);
}

/* D-SACK. We can detect redundant retransmission in S|R and plain R
@@ -1303,8 +1317,6 @@ static int tcp_sacktag_one(struct sk_buff *skb, struct sock *sk,
* are accounted above as well.
*/
if (dup_sack && (TCP_SKB_CB(skb)->sacked & TCPCB_SACKED_RETRANS)) {
- tcp_write_queue_requeue(skb, sk, TCP_WQ_SACKED);
-
TCP_SKB_CB(skb)->sacked &= ~TCPCB_SACKED_RETRANS;
tp->retrans_out -= tcp_skb_pcount(skb);
tp->retransmit_skb_hint = NULL;
@@ -1314,14 +1326,14 @@ static int tcp_sacktag_one(struct sk_buff *skb, struct sock *sk,
}

static struct sk_buff *tcp_sacktag_walk(struct sk_buff *skb, struct sock *sk,
+ struct tcp_sack_block *next_dup,
u32 start_seq, u32 end_seq,
- int dup_sack, int *reord, int *flag,
- int queue)
+ int dup_sack_in, int *fack_count,
+ int *reord, int *flag)
{
- struct sk_buff *next;
-
- tcp_for_write_queue_from_safe(skb, next, sk, queue) {
+ tcp_for_write_queue_from(skb, sk) {
int in_sack = 0;
+ int dup_sack = dup_sack_in;

if (skb == tcp_send_head(sk))
break;
@@ -1330,12 +1342,24 @@ static struct sk_buff *tcp_sacktag_walk(struct sk_buff *skb, struct sock *sk,
if (!before(TCP_SKB_CB(skb)->seq, end_seq))
break;

- in_sack = tcp_match_skb_to_sack(sk, skb, start_seq, end_seq);
+ if ((next_dup != NULL) &&
+ before(TCP_SKB_CB(skb)->seq, next_dup->end_seq)) {
+ in_sack = tcp_match_skb_to_sack(sk, skb,
+ next_dup->start_seq,
+ next_dup->end_seq);
+ if (in_sack > 0)
+ dup_sack = 1;
+ }
+
+ if (in_sack <= 0)
+ in_sack = tcp_match_skb_to_sack(sk, skb, start_seq, end_seq);
if (unlikely(in_sack < 0))
break;

if (in_sack)
- *flag |= tcp_sacktag_one(skb, sk, reord, dup_sack);
+ *flag |= tcp_sacktag_one(skb, sk, reord, dup_sack, *fack_count);
+
+ *fack_count += tcp_skb_pcount(skb);
}
return skb;
}
@@ -1343,72 +1367,37 @@ static struct sk_buff *tcp_sacktag_walk(struct sk_buff *skb, struct sock *sk,
/* Avoid all extra work that is being done by sacktag while walking in
* a normal way
*/
-static struct sk_buff *tcp_sacktag_skip(struct sock *sk, u32 skip_to_seq)
+static struct sk_buff *tcp_sacktag_skip(struct sk_buff *skb, struct sock *sk,
+ u32 skip_to_seq)
{
- struct sk_buff *skb;
+ tcp_for_write_queue_from(skb, sk) {
+ if (skb == tcp_send_head(sk))
+ break;

- skb = tcp_write_queue_find(sk, skip_to_seq, 0);
- if (skb == tcp_write_queue_head(sk))
- skb = NULL;
+ if (!before(TCP_SKB_CB(skb)->end_seq, skip_to_seq))
+ break;
+ }
return skb;
}

-static int tcp_handle_dsack(struct sock *sk, struct sk_buff *ack_skb,
- struct tcp_sack_block_wire *sp, u32 *reord,
- int num_sacks, u32 prior_snd_una)
+static struct sk_buff *tcp_maybe_skipping_dsack(struct sk_buff *skb,
+ struct sock *sk,
+ struct tcp_sack_block *next_dup,
+ u32 skip_to_seq,
+ int *fack_count, int *reord,
+ int *flag)
{
- struct tcp_sock *tp = tcp_sk(sk);
- struct sk_buff *skb;
- u32 start_seq_0 = ntohl(get_unaligned(&sp[0].start_seq));
- u32 end_seq_0 = ntohl(get_unaligned(&sp[0].end_seq));
- int flag = 0;
+ if (next_dup == NULL)
+ return skb;

- if (before(start_seq_0, TCP_SKB_CB(ack_skb)->ack_seq)) {
- flag |= FLAG_DSACKING_ACK;
- tcp_dsack_seen(tp);
- NET_INC_STATS_BH(LINUX_MIB_TCPDSACKRECV);
-
- if (!tcp_is_past_dsack_useful(tp, start_seq_0, end_seq_0)) {
- if (!tp->undo_marker)
- NET_INC_STATS_BH(LINUX_MIB_TCPDSACKIGNOREDNOUNDO);
- else
- NET_INC_STATS_BH(LINUX_MIB_TCPDSACKIGNOREDOLD);
-
- return flag;
- }
-
- /* D-SACK for already forgotten data... Do dumb counting. */
- if (!after(end_seq_0, prior_snd_una))
- tp->undo_retrans--;
-
- } else if (num_sacks > 1) {
- u32 end_seq_1 = ntohl(get_unaligned(&sp[1].end_seq));
- u32 start_seq_1 = ntohl(get_unaligned(&sp[1].start_seq));
-
- if (!after(end_seq_0, end_seq_1) &&
- !before(start_seq_0, start_seq_1)) {
- flag |= FLAG_DSACKING_ACK;
- tcp_dsack_seen(tp);
- NET_INC_STATS_BH(LINUX_MIB_TCPDSACKOFORECV);
- if (!tcp_is_sackblock_valid(tp, start_seq_0, end_seq_0)) {
- /* FIXME, reordering check like in the other place! */
- NET_INC_STATS_BH(LINUX_MIB_TCPSACKDISCARD);
- return flag;
- }
- }
+ if (before(next_dup->start_seq, skip_to_seq)) {
+ skb = tcp_sacktag_skip(skb, sk, next_dup->start_seq);
+ tcp_sacktag_walk(skb, sk, NULL,
+ next_dup->start_seq, next_dup->end_seq,
+ 1, fack_count, reord, flag);
}

- if ((flag & FLAG_DSACKING_ACK) && after(end_seq_0, prior_snd_una)) {
- skb = tcp_write_queue_find(sk, start_seq_0, TCP_WQ_SACKED);
- if (skb != NULL)
- tcp_sacktag_walk(skb, sk, start_seq_0, end_seq_0, 1, reord, &flag, TCP_WQ_SACKED);
-
- skb = tcp_write_queue_find(sk, start_seq_0, 0);
- if (skb != NULL)
- tcp_sacktag_walk(skb, sk, start_seq_0, end_seq_0, 1, reord, &flag, 0);
- }
-
- return flag;
+ return skb;
}

static int tcp_sack_cache_ok(struct tcp_sock *tp, struct tcp_sack_block *cache)
@@ -1431,7 +1420,10 @@ tcp_sacktag_write_queue(struct sock *sk, struct sk_buff *ack_skb, u32 prior_snd_
int used_sacks;
int reord = tp->packets_out;
int flag = 0;
+ int found_dup_sack = 0;
+ int fack_count;
int i, j;
+ int first_sack_index;

if (!tp->sacked_out) {
if (WARN_ON(tp->fackets_out))
@@ -1439,7 +1431,10 @@ tcp_sacktag_write_queue(struct sock *sk, struct sk_buff *ack_skb, u32 prior_snd_
tcp_highest_sack_reset(sk);
}

- flag |= tcp_handle_dsack(sk, ack_skb, sp_wire, &reord, num_sacks, prior_snd_una);
+ found_dup_sack = tcp_check_dsack(tp, ack_skb, sp_wire,
+ num_sacks, prior_snd_una);
+ if (found_dup_sack)
+ flag |= FLAG_DSACKING_ACK;

/* Eliminate too old ACKs, but take into
* account more or less fresh ones, they can
@@ -1452,17 +1447,30 @@ tcp_sacktag_write_queue(struct sock *sk, struct sk_buff *ack_skb, u32 prior_snd_
goto out;

used_sacks = 0;
- for (i = (flag & FLAG_DSACKING_ACK) ? 1 : 0; i < num_sacks; i++) {
+ first_sack_index = 0;
+ for (i = 0; i < num_sacks; i++) {
+ int dup_sack = !i && found_dup_sack;
+
sp[used_sacks].start_seq = ntohl(get_unaligned(&sp_wire[i].start_seq));
sp[used_sacks].end_seq = ntohl(get_unaligned(&sp_wire[i].end_seq));

- if (!tcp_is_sackblock_valid(tp, sp[used_sacks].start_seq,
+ if (!tcp_is_sackblock_valid(tp, dup_sack,
+ sp[used_sacks].start_seq,
sp[used_sacks].end_seq)) {
- /* Don't count olds caused by ACK reordering */
- if ((TCP_SKB_CB(ack_skb)->ack_seq != tp->snd_una) &&
- !after(sp[used_sacks].end_seq, tp->snd_una))
- continue;
- NET_INC_STATS_BH(LINUX_MIB_TCPSACKDISCARD);
+ if (dup_sack) {
+ if (!tp->undo_marker)
+ NET_INC_STATS_BH(LINUX_MIB_TCPDSACKIGNOREDNOUNDO);
+ else
+ NET_INC_STATS_BH(LINUX_MIB_TCPDSACKIGNOREDOLD);
+ } else {
+ /* Don't count olds caused by ACK reordering */
+ if ((TCP_SKB_CB(ack_skb)->ack_seq != tp->snd_una) &&
+ !after(sp[used_sacks].end_seq, tp->snd_una))
+ continue;
+ NET_INC_STATS_BH(LINUX_MIB_TCPSACKDISCARD);
+ }
+ if (i == 0)
+ first_sack_index = -1;
continue;
}

@@ -1482,11 +1490,16 @@ tcp_sacktag_write_queue(struct sock *sk, struct sk_buff *ack_skb, u32 prior_snd_
tmp = sp[j];
sp[j] = sp[j+1];
sp[j+1] = tmp;
+
+ /* Track where the first SACK block goes to */
+ if (j == first_sack_index)
+ first_sack_index = j+1;
}
}
}

skb = tcp_write_queue_head(sk);
+ fack_count = 0;
i = 0;

if (!tp->sacked_out) {
@@ -1503,6 +1516,11 @@ tcp_sacktag_write_queue(struct sock *sk, struct sk_buff *ack_skb, u32 prior_snd_
while (i < used_sacks) {
u32 start_seq = sp[i].start_seq;
u32 end_seq = sp[i].end_seq;
+ int dup_sack = (found_dup_sack && (i == first_sack_index));
+ struct tcp_sack_block *next_dup = NULL;
+
+ if (found_dup_sack && ((i + 1) == first_sack_index))
+ next_dup = &sp[i + 1];

/* Event "B" in the comment above. */
if (after(end_seq, tp->high_seq))
@@ -1514,36 +1532,36 @@ tcp_sacktag_write_queue(struct sock *sk, struct sk_buff *ack_skb, u32 prior_snd_
cache++;

/* Can skip some work by looking recv_sack_cache? */
- if (tcp_sack_cache_ok(tp, cache) &&
+ if (tcp_sack_cache_ok(tp, cache) && !dup_sack &&
after(end_seq, cache->start_seq)) {

/* Head todo? */
if (before(start_seq, cache->start_seq)) {
- skb = tcp_sacktag_skip(sk, start_seq);
- if (skb == NULL)
- break;
- skb = tcp_sacktag_walk(skb, sk, start_seq,
- cache->start_seq, 0,
- &reord, &flag, 0);
+ skb = tcp_sacktag_skip(skb, sk, start_seq);
+ skb = tcp_sacktag_walk(skb, sk, next_dup, start_seq,
+ cache->start_seq, dup_sack,
+ &fack_count, &reord, &flag);
}

/* Rest of the block already fully processed? */
if (!after(end_seq, cache->end_seq))
goto advance_sp;

+ skb = tcp_maybe_skipping_dsack(skb, sk, next_dup, cache->end_seq,
+ &fack_count, &reord, &flag);
+
/* ...tail remains todo... */
if (tcp_highest_sack_seq(tp) == cache->end_seq) {
/* ...but better entrypoint exists! */
skb = tcp_highest_sack(sk);
if (skb == NULL)
break;
+ fack_count = tp->fackets_out;
cache++;
goto walk;
}

- skb = tcp_sacktag_skip(sk, cache->end_seq);
- if (skb == NULL)
- break;
+ skb = tcp_sacktag_skip(skb, sk, cache->end_seq);
/* Check overlap against next cached too (past this one already) */
cache++;
continue;
@@ -1553,14 +1571,13 @@ tcp_sacktag_write_queue(struct sock *sk, struct sk_buff *ack_skb, u32 prior_snd_
skb = tcp_highest_sack(sk);
if (skb == NULL)
break;
+ fack_count = tp->fackets_out;
}
- skb = tcp_sacktag_skip(sk, start_seq);
- if (skb == NULL)
- break;
+ skb = tcp_sacktag_skip(skb, sk, start_seq);

walk:
- skb = tcp_sacktag_walk(skb, sk, start_seq, end_seq,
- 0, &reord, &flag, 0);
+ skb = tcp_sacktag_walk(skb, sk, next_dup, start_seq, end_seq,
+ dup_sack, &fack_count, &reord, &flag);

advance_sp:
/* SACK enhanced FRTO (RFC4138, Appendix B): Clearing correct
@@ -1657,7 +1674,6 @@ int tcp_use_frto(struct sock *sk)
{
const struct tcp_sock *tp = tcp_sk(sk);
struct sk_buff *skb;
- struct sk_buff *notsacked; /* Or S|R => deny basic F-RTO */

if (!sysctl_tcp_frto)
return 0;
@@ -1669,19 +1685,15 @@ int tcp_use_frto(struct sock *sk)
if (tp->retrans_out > 1)
return 0;

- notsacked = tcp_write_queue_head(sk);
- /* Not interested in head skb here because F-RTO is reentrable if only
- * head skb has been retransmitted (equals to multiple RTOs case)
- */
- notsacked = tcp_write_queue_next(sk, notsacked);
- if ((notsacked != NULL) && TCP_SKB_CB(notsacked)->sacked & TCPCB_RETRANS)
- return 0;
-
- tcp_for_write_queue(skb, sk, TCP_WQ_SACKED) {
+ skb = tcp_write_queue_head(sk);
+ skb = tcp_write_queue_next(sk, skb); /* Skips head */
+ tcp_for_write_queue_from(skb, sk) {
+ if (skb == tcp_send_head(sk))
+ break;
if (TCP_SKB_CB(skb)->sacked&TCPCB_RETRANS)
return 0;
- /* Short-circuit when past first non-SACKed skb */
- if (after(TCP_SKB_CB(skb)->seq, TCP_SKB_CB(notsacked)->seq))
+ /* Short-circuit when first non-SACKed skb has been checked */
+ if (!(TCP_SKB_CB(skb)->sacked&TCPCB_SACKED_ACKED))
break;
}
return 1;
@@ -1782,7 +1794,7 @@ static void tcp_enter_frto_loss(struct sock *sk, int allowed_segments, int flag)
if (tcp_is_reno(tp))
tcp_reset_reno_sack(tp);

- tcp_for_write_queue(skb, sk, 0) {
+ tcp_for_write_queue(skb, sk) {
if (skb == tcp_send_head(sk))
break;

@@ -1880,16 +1892,9 @@ void tcp_enter_loss(struct sock *sk, int how)
tp->sacked_out = 0;
tp->fackets_out = 0;
tcp_clear_all_retrans_hints(tp);
-
- tcp_for_write_queue(skb, sk, TCP_WQ_SACKED) {
- /* FIXME, this could be optimized by avoiding tree
- * deletes
- */
- tcp_write_queue_requeue(skb, sk, 0);
- }
}

- tcp_for_write_queue(skb, sk, 0) {
+ tcp_for_write_queue(skb, sk) {
if (skb == tcp_send_head(sk))
break;

@@ -1923,7 +1928,7 @@ static int tcp_check_sack_reneging(struct sock *sk)
* receiver _host_ is heavily congested (or buggy).
* Do processing similar to RTO timeout.
*/
- if ((skb = tcp_real_queue_head(sk)) != NULL &&
+ if ((skb = tcp_write_queue_head(sk)) != NULL &&
(TCP_SKB_CB(skb)->sacked & TCPCB_SACKED_ACKED)) {
struct inet_connection_sock *icsk = inet_csk(sk);
NET_INC_STATS_BH(LINUX_MIB_TCPSACKRENEGING);
@@ -2122,21 +2127,6 @@ static void tcp_verify_retransmit_hint(struct tcp_sock *tp,
tp->retransmit_skb_hint = NULL;
}

-/* Simple NewReno thing: Mark head LOST if it wasn't yet and it's below
- * high_seq, stop. That's all.
- */
-static void tcp_mark_head_lost_single(struct sock *sk)
-{
- struct tcp_sock *tp = tcp_sk(sk);
- struct sk_buff *skb = tcp_write_queue_head(sk);
-
- if (!(TCP_SKB_CB(skb)->sacked & TCPCB_LOST) &&
- before(tp->snd_una, tp->high_seq)) {
- TCP_SKB_CB(skb)->sacked |= TCPCB_LOST;
- tp->lost_out += tcp_skb_pcount(skb);
- }
-}
-
/* Mark head of queue up as lost. With RFC3517 SACK, the packets is
* is against sacked "cnt", otherwise it's against facked "cnt"
*/
@@ -2145,10 +2135,6 @@ static void tcp_mark_head_lost(struct sock *sk, int packets, int fast_rexmit)
struct tcp_sock *tp = tcp_sk(sk);
struct sk_buff *skb;
int cnt;
- unsigned int fc;
- unsigned int fack_count_base;
-
- fack_count_base = TCP_SKB_CB(tcp_write_queue_head(sk))->fack_count;

BUG_TRAP(packets <= tp->packets_out);
if (tp->lost_skb_hint) {
@@ -2159,7 +2145,7 @@ static void tcp_mark_head_lost(struct sock *sk, int packets, int fast_rexmit)
cnt = 0;
}

- tcp_for_write_queue_from(skb, sk, 0) {
+ tcp_for_write_queue_from(skb, sk) {
if (skb == tcp_send_head(sk))
break;
/* TODO: do this better */
@@ -2167,18 +2153,9 @@ static void tcp_mark_head_lost(struct sock *sk, int packets, int fast_rexmit)
tp->lost_skb_hint = skb;
tp->lost_cnt_hint = cnt;

- fc = TCP_SKB_CB(skb)->fack_count;
- if (tcp_is_fack(tp)) {
- cnt = fc - fack_count_base + tcp_skb_pcount(skb);
- } else {
- if (TCP_SKB_CB(skb)->sacked & TCPCB_SACKED_ACKED)
- cnt += tcp_skb_pcount(skb);
- /* Add SACK blocks between this and skb->prev */
- if ((skb != tcp_write_queue_head(sk)) &&
- !tcp_skb_adjacent(sk, skb->prev, skb))
- cnt += fc - TCP_SKB_CB(skb->prev)->fack_count -
- tcp_skb_pcount(skb->prev);
- }
+ if (tcp_is_fack(tp) ||
+ (TCP_SKB_CB(skb)->sacked & TCPCB_SACKED_ACKED))
+ cnt += tcp_skb_pcount(skb);

if (((!fast_rexmit || (tp->lost_out > 0)) && (cnt > packets)) ||
after(TCP_SKB_CB(skb)->end_seq, tp->high_seq))
@@ -2189,6 +2166,7 @@ static void tcp_mark_head_lost(struct sock *sk, int packets, int fast_rexmit)
tcp_verify_retransmit_hint(tp, skb);
}
}
+ tcp_verify_left_out(tp);
}

/* Account newly detected lost packet(s) */
@@ -2198,7 +2176,7 @@ static void tcp_update_scoreboard(struct sock *sk, int fast_rexmit)
struct tcp_sock *tp = tcp_sk(sk);

if (tcp_is_reno(tp)) {
- tcp_mark_head_lost_single(sk);
+ tcp_mark_head_lost(sk, 1, fast_rexmit);
} else if (tcp_is_fack(tp)) {
int lost = tp->fackets_out - tp->reordering;
if (lost <= 0)
@@ -2211,8 +2189,6 @@ static void tcp_update_scoreboard(struct sock *sk, int fast_rexmit)
tcp_mark_head_lost(sk, sacked_upto, fast_rexmit);
}

- tcp_verify_left_out(tp);
-
/* New heuristics: it is possible only after we switched
* to restart timer each time when something is ACKed.
* Hence, we can detect timed out packets during fast
@@ -2224,7 +2200,7 @@ static void tcp_update_scoreboard(struct sock *sk, int fast_rexmit)
skb = tp->scoreboard_skb_hint ? tp->scoreboard_skb_hint
: tcp_write_queue_head(sk);

- tcp_for_write_queue_from(skb, sk, 0) {
+ tcp_for_write_queue_from(skb, sk) {
if (skb == tcp_send_head(sk))
break;
if (!tcp_skb_timedout(sk, skb))
@@ -2422,7 +2398,7 @@ static int tcp_try_undo_loss(struct sock *sk)

if (tcp_may_undo(tp)) {
struct sk_buff *skb;
- tcp_for_write_queue(skb, sk, 0) {
+ tcp_for_write_queue(skb, sk) {
if (skb == tcp_send_head(sk))
break;
TCP_SKB_CB(skb)->sacked &= ~TCPCB_LOST;
@@ -2528,8 +2504,11 @@ tcp_fastretrans_alert(struct sock *sk, int pkts_acked, int flag)
(tcp_fackets_out(tp) > tp->reordering));
int fast_rexmit = 0;

- if (WARN_ON(!tp->packets_out && tp->sacked_out))
+ /* Some technical things:
+ * 1. Reno does not count dupacks (sacked_out) automatically. */
+ if (!tp->packets_out)
tp->sacked_out = 0;
+
if (WARN_ON(!tp->sacked_out && tp->fackets_out))
tp->fackets_out = 0;

@@ -2794,7 +2773,7 @@ static int tcp_clean_rtx_queue(struct sock *sk, s32 *seq_rtt_p,
s32 seq_rtt = -1;
ktime_t last_ackt = net_invalid_timestamp();

- while ((skb = tcp_real_queue_head(sk)) && skb != tcp_send_head(sk)) {
+ while ((skb = tcp_write_queue_head(sk)) && skb != tcp_send_head(sk)) {
struct tcp_skb_cb *scb = TCP_SKB_CB(skb);
u32 end_seq;
u32 acked_pcount;
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index 5a27e42..652c323 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -1849,7 +1849,6 @@ static int tcp_v4_init_sock(struct sock *sk)
struct inet_connection_sock *icsk = inet_csk(sk);
struct tcp_sock *tp = tcp_sk(sk);

- tcp_write_queue_init(sk);
skb_queue_head_init(&tp->out_of_order_queue);
tcp_init_xmit_timers(sk);
tcp_prequeue_init(tp);
diff --git a/net/ipv4/tcp_minisocks.c b/net/ipv4/tcp_minisocks.c
index e1a0e4a..b61b768 100644
--- a/net/ipv4/tcp_minisocks.c
+++ b/net/ipv4/tcp_minisocks.c
@@ -426,7 +426,6 @@ struct sock *tcp_create_openreq_child(struct sock *sk, struct request_sock *req,

tcp_set_ca_state(newsk, TCP_CA_Open);
tcp_init_xmit_timers(newsk);
- tcp_write_queue_init(newsk);
skb_queue_head_init(&newtp->out_of_order_queue);
newtp->write_seq = treq->snt_isn + 1;
newtp->pushed_seq = newtp->write_seq;
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 6110459..9a985b5 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -1207,7 +1207,7 @@ static int tso_fragment(struct sock *sk, struct sk_buff *skb, unsigned int len,

/* Link BUFF into the send queue. */
skb_header_release(buff);
- __tcp_insert_write_queue_after(skb, buff, sk, 0);
+ tcp_insert_write_queue_after(skb, buff, sk);

return 0;
}
@@ -1344,10 +1344,10 @@ static int tcp_mtu_probe(struct sock *sk)
nskb->csum = 0;
nskb->ip_summed = skb->ip_summed;

- __tcp_insert_write_queue_before(nskb, skb, sk);
+ tcp_insert_write_queue_before(nskb, skb, sk);

len = 0;
- tcp_for_write_queue_from_safe(skb, next, sk, 0) {
+ tcp_for_write_queue_from_safe(skb, next, sk) {
copy = min_t(int, skb->len, probe_size - len);
if (nskb->ip_summed)
skb_copy_bits(skb, 0, skb_put(nskb, copy), copy);
@@ -1760,7 +1760,7 @@ void tcp_simple_retransmit(struct sock *sk)
unsigned int mss = tcp_current_mss(sk, 0);
int lost = 0;

- tcp_for_write_queue(skb, sk, 0) {
+ tcp_for_write_queue(skb, sk) {
if (skb == tcp_send_head(sk))
break;
if (skb->len > mss &&
@@ -1848,7 +1848,6 @@ int tcp_retransmit_skb(struct sock *sk, struct sk_buff *skb)
(skb->len < (cur_mss >> 1)) &&
(tcp_write_queue_next(sk, skb) != tcp_send_head(sk)) &&
(!tcp_skb_is_last(sk, skb)) &&
- (tcp_skb_adjacent(sk, skb, tcp_write_queue_next(sk, skb))) &&
(skb_shinfo(skb)->nr_frags == 0 && skb_shinfo(tcp_write_queue_next(sk, skb))->nr_frags == 0) &&
(tcp_skb_pcount(skb) == 1 && tcp_skb_pcount(tcp_write_queue_next(sk, skb)) == 1) &&
(sysctl_tcp_retrans_collapse != 0))
@@ -1937,7 +1936,7 @@ void tcp_xmit_retransmit_queue(struct sock *sk)

/* First pass: retransmit lost packets. */
if (tp->lost_out) {
- tcp_for_write_queue_from(skb, sk, 0) {
+ tcp_for_write_queue_from(skb, sk) {
__u8 sacked = TCP_SKB_CB(skb)->sacked;

if (skb == tcp_send_head(sk))
@@ -2010,7 +2009,7 @@ void tcp_xmit_retransmit_queue(struct sock *sk)
else
skb = tcp_write_queue_head(sk);

- tcp_for_write_queue_from(skb, sk, 0) {
+ tcp_for_write_queue_from(skb, sk) {
if (skb == tcp_send_head(sk))
break;
tp->forward_skb_hint = skb;
diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c
index d576833..0ef9986 100644
--- a/net/ipv6/tcp_ipv6.c
+++ b/net/ipv6/tcp_ipv6.c
@@ -1886,7 +1886,6 @@ static int tcp_v6_init_sock(struct sock *sk)
struct inet_connection_sock *icsk = inet_csk(sk);
struct tcp_sock *tp = tcp_sk(sk);

- tcp_write_queue_init(sk);
skb_queue_head_init(&tp->out_of_order_queue);
tcp_init_xmit_timers(sk);
tcp_prequeue_init(tp);
--
1.5.0.6


Attachments:
commits (1.82 kB)

2007-12-16 22:22:17

by David Miller

[permalink] [raw]
Subject: Re: [PATCH net-2.6.25] Revert recent TCP work

From: "Ilpo_J?rvinen" <[email protected]>
Date: Fri, 14 Dec 2007 22:14:29 +0200 (EET)

> Could you either drop my recent patches (+one fix to them from Herbert
> Xu == "[TCP]: Fix crash in tcp_advance_send_head"), all mine after "[TCP]:
> Abstract tp->highest_sack accessing & point to next skb" from net-2.6.25
> or just apply the revert from below and do the removal during next rebase.
> I think it could even be automated by something like this (untested):
> for i in $(cat commits | cut -d ' ' -f 1); do git-rebase --onto $i^ $i; done
> (I've attached the commits list).

I'll take care of this when I rebase the net-2.6.25 tree later
today.

Thanks Ilpo.