2.6.4-mm2

PATCH New Andrew Morton 16 participants 82 messages Mar 15, 2004 – Mar 30, 2004 4 messages not in the archive

Subsystems (11)

Memory management Documentation VFS Sound +7 more subsystems

lore

Share & tools

lore

Andrew Morton

author

2004-03-15 01:28 UTC #0 lore raw

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.4/2.6.4-mm2/

- Added the new per-address_space block unplugging code. This is designed to reduce the locking contention against the global plug list's lock and it also allows us to avoid unplugging all the queues in the machine when we want just a single queue to kick off its I/O.

- Reiserfs updates: mainly new features.

- Some significant NFS client enhancements: reads smaller than PAGE_SIZE are no longer synchronous, support for smaller-than-PAGE_SIZE reads, etc.

Changes since 2.6.4-mm1:

linus.patch
bk-driver-core.patch
bk-i2c.patch
bk-ieee1394.patch
bk-input.patch
bk-netdev.patch
bk-pci.patch
bk-pcmcia.patch
bk-usb.patch

Latest versions of external trees

-dma_sync_for_device-cpu.patch -bk-acpi-warning-fix.patch -x86_64-update.patch -move-dma_consistent_dma_mask.patch -move-dma_consistent_dma_mask-x86_64-fix.patch -move-dma_consistent_dma_mask-sn-fix.patch -print-kernel-version-in-oops.patch -ppc64-iseries-virtual-console-fix.patch -remove-sys_ioperm-stubs.patch -readdir-cleanups.patch -sched-stats-64-bit.patch
-nfs-31-attr.patch
-nfs-reconnect-fix.patch
-nfs-mount-fix.patch
-nfs-d_drop-lowmem.patch -nfs-avoid-i_size_write.patch -nfs_unlink-oops-fix.patch -nfs-remove-XID-spinlock.patch -nfs-misc-rpc-fixes.patch -nfs-improved-writeback-strategy.patch -nfs-simplify-config-options.patch -nfs-fix-msync.patch -nfs-mount-return-useful-errors.patch -nfs-misc-minor-fixes.patch -nfs-lockd-sync-01.patch -nfs-lockd-sync-02.patch -nfs-lockd-sync-03.patch -nfs-lockd-sync-04.patch -nfs-rpc-remove-redundant-memset.patch -nfs-tunable-rpc-slot-table.patch -nfs-short-read-fix.patch -nfs-server-in-root_server_path.patch -adaptive-lazy-readahead.patch -module_exit-deadlock-fix.patch -ufs2-01.patch
-fb_console_init-fix.patch -pcmcia-debugging-rework-1.patch -cs_err-compile-fix.patch -pcmcia-debugging-rework-2.patch -distribute-early-allocations-across-nodes.patch -time-interpolator-fix.patch -kmsg-nonblock.patch -remove-__io_virt_debug.patch -genrtc-cleanups.patch -i386-early-memory-cleanup.patch -modular-mce-handler.patch -remove-more-KERNEL_SYSCALLS.patch -dm-01-endio-method.patch -dm-03-list_for_each_entry-audit.patch -dm-04-default-queue-limits-fix.patch -dm-05-list-targets-command.patch -dm-06-stripe-width-fix.patch -use-wait_task_inactive-in-kthread_bind.patch -selinux-cleanup-binary-mount-data.patch -udffs-update.patch -kbuild-redundant-CFLAGS.patch -numa-aware-zonelist-builder.patch -remove-redundant-unplug_timer-deletion.patch -m68k-rename-sys_functions.patch -cdromaudio-use-dma.patch -md-use-schedule_timeout.patch -md-array-assembly-fix.patch -md-array-assembly-major-fix.patch -compiler_h-scope-fixes.patch -elf-mmap-fix.patch -kbuild-more-cleaning.patch -LOOP_CHANGE_FD.patch -loop-setup-race-fix.patch -handle-dot-o-paths.patch -acpi-asmlinkage-fix.patch -ipc-sem-extra-sem_unlock.patch -procfs-dangling-subdir-fix.patch -AMD-768MPX-bootmem-fix.patch -i810fb-on-x86_64.patch -ext23-remove-acl-limits.patch -watchdog-moduleparam-patches.patch -amd-elan-fix.patch
-fadvise-fixups.patch -validate_mm-fixes.patch -3c59x-xcvr-fix.patch -current_is_keventd-speedup.patch -root-ramdisk-fix.patch -cciss-per-device-queues.patch -blkdev-fix-final-page.patch -wavfront-needs-syscalls_h.patch -edd-legacy-parameters-fix.patch -cciss-section-fix.patch -pte_chain-nowarns.patch -macintosh-config-fix.patch -applicom-warning-fix.patch -CONFIG_NVRAM-dependencies.patch -kobject-module-request-64-bit-fix.patch -instrument-highmem-page-reclaim.patch -blk_congestion_wait-return-remaining.patch -blk-congestion-races.patch -vmscan-remove-priority.patch -kswapd-throttling-fixes.patch -vm-refill_inactive-preserve-referenced.patch -shrink_slab-precision-fix.patch -try_to_free_pages-shrink_slab-evenness.patch -vmscan-total_scanned-fix.patch -shrink_slab-for-all-zones-2.patch -zone-balancing-fix-2.patch -vmscan-control-by-nr_to_scan-only.patch -vmscan-balance-zone-scanning-rates.patch -vmscan-dont-throttle-if-zero-max_scan.patch -kswapd-avoid-higher-zones.patch -kswapd-avoid-higher-zones-reverse-direction.patch -kswapd-avoid-higher-zones-reverse-direction-fix.patch -vmscan-throttle-later.patch -vm-batch-inactive-scanning.patch -vm-batch-inactive-scanning-fix.patch -vm-balance-refill-rate.patch -vm-lrutopage-cleanup.patch -slab-no-higher-order.patch

Merged

+kbuild-fix-early-dependencies.patch
+kbuild-fix-early-dependencies-fix.patch

Parallel build fix

+scsi_transport_spi-build-fix.patch

Fix for gcc-2.95

+tty_io-warning-fix.patch

Warning fix

+x86_64-mem_map-shrinkage.patch

Smaller pageframes on x86_64

+svcauth_gss_accept-warning-fix.patch

Fix a printk warning for gcc-2.95

+ppc-bootloader-build-fix.patch
+ppc64-irq_stackwarn_reduction.patch
+ppc64-oldumount_fix.patch
+ppc64-remove_Hash.patch
+ppc64-dma-functions.patch
+ppc64-longbusy.patch
+ppc64-veth-use-longbusy.patch
+ppc64-exports.patch
+ppc64-multifunction-fix.patch
+ppc64-eeh_fixes.patch
+ppc64-irq-fixes.patch
+ppc64-vio-dma.patch
+ppc64-iseries-exports.patch
+ppc64-iseries_default.patch
+ppc64-bitops_exports.patch
+ppc64-ide_request_irq.patch
+ppc64-iseries_do_IRQ.patch
+ppc64-remove_pci_dma_exports.patch
+ppc64-rtas_set_power_level.patch
+ppc64-rtas_syscall_fix.patch
+ppc64-add_version_to_oops.patch
+ppc64-procfs-cleanup.patch
+ppc64-xmon_backtrace.patch
+ppc64-hvc-sleep_in_spinlock.patch
+ppc64-defconfig.patch

PPC64 stuff

+compat-signal-noarch-sparc64-fix.patch

Fix compat-signal-noarch-2004-01-29.patch for sparc64

+ext3-journalled-quotas-2-exports.patch

Expert a symbol needed by ext3-journalled-quotas-2.patch

+nfs-01-prepare_nfspage.patch
+nfs-02-small_rsize.patch
+nfs-03-small_wsize.patch
+nfs-04-congestion.patch
+nfs-05-unrace.patch
+nfs-06-rpc_throttle.patch
+nfs-07-rpc_fixes.patch
+nfs-08-short_rw.patch

NFS update

+sched-remove-unused-local.patch

Remove dead variable

+ppc64-sched-domain-support.patch

ppc64 support for the domain-based CPU scheduler

+sched-local-load.patch
+sched-no-cpu-in-rq.patch

Small cleanups

+lightweight-auditing-framework.patch

syscall auditing framework (this needs updating but I couldn't be bothered re-redoing all the succeeding patches).

+futex_wait-debug-fix.patch

Fix futex-wait-debug.patch so that it actually does something.

+per-backing_dev-unplugging.patch +per-backing_dev-unplugging-block_sync_page-fix.patch +swapper_space-unplug_fn.patch +shmem-unplug_fn.patch

Per-address-space block queue unplugging.

+move-job-control-stuff-tosignal_struct-s390-fix.patch +move-job-control-stuff-tosignal_struct-sx-fix.patch +move-job-control-stuff-tosignal_struct-sn-fix.patch

Move job control fields out of task_struct and into signal_struct.

+selinux-conditional-policy-extensions.patch

SELinux feature work

+devinet-ctl_table-fix.patch

Doesn't fix an oops - I'll drop this once I work out why we don't need it.

+cm206-check_region-fix.patch
+document-acpi_sleep-option.patch
+document-S3_swsusp-tricks.patch
+sjcd-check_region-fix.patch
+rename-acpi_disable.patch
+filemap-comment-fix.patch
+genhd-comment-fix.patch
+docbook-build-warning.patch
+cdu31c-check_region-fix-2.patch
+move-pcibios-help.patch
+modular-fbdev-fix.patch
+kbuild-modpost-fix.patch

Minor fixlets.

+fix-kallsyms-in-modules.patch

Make kallsyms work better when the symbols are in modules.

+ver_linux-binutils-version-fix.patch

Fix ver_linux's display of the binutils version

+module-aliases-for-char-devices.patch

More MODULE_ALIASes

+credits-updates.patch

Update email address

+idr-extra-features.patch

Extra features in the idr.c code.

+selinux-compute_av-fix.patch

SELinux fix

+flush_scheduled_work-deadlock-fix.patch
+flush_scheduled_work-recursion-detect.patch

Permit kevent to call flush_scheduled_work().

+page_referenced-no-mark_page_accessed.patch

Simplify page_referenced()

+fbdev-char-drawing-enhancement.patch

fbdev improvement

+sgml-build-fix.patch

kernel-doc build fix

+reiserfs-direct-tail.patch
+reiserfs-lock-lat.patch
+reiserfs-search-restart.patch
+reiserfs-should-end-jbegin.patch
+reiserfs-write-sched-bug.patch
+reiserfs-aio.patch

Reiserfs feature work.

+early-x86-cpu-detection.patch

Detect the x86 cacheline size earlier.

+do_write_mem-retval-check.patch

Fix return value checking in mem.c

+vsyscall-alignment-fix.patch

More robust alignment of the vsyscall pages

+smh-do_unmap-comments.patch

Add a comment explaining why the unchecked do_munmap()s in shm.c are OK.

+shm-do_munmap-check.patch

Add a check to find out if the above comment is true.

+slab-corruption-detector-fix.patch

Fix the output of the slab corruption detector.

+kthread-keeps-files-open.patch

Teach keventd to close /dev/console

+kill-INIT_THREAD_SIZE.patch
+stack-overflow-test-fix.patch
+init-task-alignment-fix.patch

Fix up some more places where we were assuming 8k stacks on x86

+remap-file-pages-prot-ia64-fix.patch
+remap-file-pages-prot-s390.patch
+remap-file-pages-prot-sparc64.patch

Implement the new per-page-permissions mode of remap_file_pages() for a few architectures.

+slab-alignment-rework.patch
+slab-alignment-rework-merge-fix.patch

Change slab to utilise the cache line size detection in early-x86-cpu-detection.patch, thus saving some memory.

All 243 patches:

linus.patch

bk-driver-core.patch

bk-i2c.patch

bk-ieee1394.patch

bk-input.patch

bk-netdev.patch

bk-pci.patch

bk-pcmcia.patch

bk-usb.patch

mm.patch
add -mmN to EXTRAVERSION

kbuild-fix-early-dependencies.patch
Fix early parallel make failures

kbuild-fix-early-dependencies-fix.patch

scsi_transport_spi-build-fix.patch
Fix scsi_transport_spi.c for gcc-2.95.3

tty_io-warning-fix.patch

x86_64-mem_map-shrinkage.patch
Save some memory in mem_map on x86-64

svcauth_gss_accept-warning-fix.patch
svcauth_gss_accept() printk warning fix

kgdb-ga.patch
kgdb stub for ia32 (George Anzinger's one)
kgdbL warning fix
kgdb buffer overflow fix
kgdbL warning fix
kgdb: CONFIG_DEBUG_INFO fix
x86_64 fixes
correct kgdb.txt Documentation link (against 2.6.1-rc1-mm2)

kgdb-ga-recent-gcc-fix.patch
kgdb: fix for recent gcc

kgdboe-netpoll.patch
kgdb-over-ethernet via netpoll

kgdboe-non-ia32-build-fix.patch

kgdb-warning-fixes.patch
kgdb warning fixes

kgdb-x86_64-support.patch
kgdb-x86_64-support.patch for 2.6.2-rc1-mm3

kgdb-THREAD_SIZE-fixes.patch
THREAD_SIZE fixes for kgdb

must-fix.patch
must fix lists update
must fix list update
mustfix update

must-fix-update-5.patch
must-fix update

ppc-bootloader-build-fix.patch
ppc32: fix bootloader build when DEBUG is defined

ppc64-irq_stackwarn_reduction.patch
Reduce stack overflow check to 4096 bytes

ppc64-oldumount_fix.patch
Remove bogus sys_oldumount sign extension code

ppc64-remove_Hash.patch
Remove some unused ppc64 variables

ppc64-dma-functions.patch
Make dma API handle PCI and VIO

ppc64-longbusy.patch
Add hypervisor busy return codes

ppc64-veth-use-longbusy.patch
Handle longbusy return codes in IBM VETH driver

ppc64-exports.patch
Add some missing EXPORT_SYMBOLs

ppc64-multifunction-fix.patch
Fix for hotplug of multifunction cards.

ppc64-eeh_fixes.patch
Fix multiple EEH-related bugs

ppc64-irq-fixes.patch
Fix xics IRQ affinity

ppc64-vio-dma.patch
Add some functions to make vio.h consistant with pci_dma.h and dma_mapping.h

ppc64-iseries-exports.patch
Move iSeries specific EXPORT_SYMBOLs out of ppc_ksyms.c

ppc64-iseries_default.patch
update iseries default target

ppc64-bitops_exports.patch
Export find_next_bit

ppc64-ide_request_irq.patch
Add slow path lookup in xics_get_irq

ppc64-iseries_do_IRQ.patch
Dont enable interrupts during interrupt processing on iseries

ppc64-remove_pci_dma_exports.patch
Remove pci DMA exports

ppc64-rtas_set_power_level.patch
Added rtas_set_power_level()

ppc64-rtas_syscall_fix.patch
Fixed NULL ptr deref in RTAS syscall ppc_rtas()

ppc64-add_version_to_oops.patch
Add kernel version to oops.

ppc64-procfs-cleanup.patch
Cleanup ppc64 procfs code

ppc64-xmon_backtrace.patch
Clean up xmon backtrace code.

ppc64-hvc-sleep_in_spinlock.patch
Fix hvc console sleep in spinlock bug

ppc64-defconfig.patch
ppc64 defconfig update

ppc64-reloc_hide.patch

compat-signal-noarch-2004-01-29.patch
Generic 32-bit compat for copy_siginfo_to_user

compat-signal-noarch-sparc64-fix.patch
compat-signal sparc64 fix

compat-generic-ipc-emulation.patch
generic 32 bit emulation for System-V IPC

ext3-journalled-quotas-2.patch
ext3: journalled quota

ext3-journalled-quotas-2-exports.patch
export needed symbols for new quota code

invalidate_inodes-speedup.patch
invalidate_inodes speedup
more invalidate_inodes speedup fixes

cfq-4.patch
CFQ io scheduler
CFQ fixes

config_spinline.patch
uninline spinlocks for profiling accuracy.

pdflush-diag.patch

get_user_pages-handle-VM_IO.patch
fix get_user_pages() against mappings of /dev/mem

pci_set_power_state-might-sleep.patch

CONFIG_STANDALONE-default-to-n.patch
Make CONFIG_STANDALONE default to N

extra-buffer-diags.patch

CONFIG_SYSFS.patch
From: Pat Mochel <[email protected]>
Subject: [PATCH] Add CONFIG_SYSFS

CONFIG_SYSFS-boot-from-disk-fix.patch

slab-leak-detector.patch
slab leak detector
mm/slab.c warning in cache_alloc_debugcheck_after

scale-nr_requests.patch
scale nr_requests with TCQ depth

truncate_inode_pages-check.patch

local_bh_enable-warning-fix.patch

nfs-01-prepare_nfspage.patch
Subject: [PATCH] Prepare NFS asynchronous read/write structures for rsize/wsize < PAGE_SIZE

nfs-02-small_rsize.patch
Subject: [PATCH] Add asynchronous read support for rsize<PAGE_SIZE

nfs-03-small_wsize.patch
Subject: [PATCH] Add asynchronous write support for wsize<PAGE_SIZE

nfs-04-congestion.patch
Subject: [PATCH] Throttle writes when memory pressure forces a flush

nfs-05-unrace.patch
Subject: [PATCH] Remove a couple of races in RPC layer...

nfs-06-rpc_throttle.patch
Subject: [PATCH] add fair queueing to the RPC scheduler.

nfs-07-rpc_fixes.patch
Subject: [PATCH] Close some potential scheduler races in rpciod.

nfs-08-short_rw.patch
Subject: [PATCH] Add support for short reads/writes (< rsize/wsize)

sched-find_busiest_node-resolution-fix.patch
sched: improved resolution in find_busiest_node

sched-domains.patch
sched: scheduler domain support
sched: fix for NR_CPUS > BITS_PER_LONG
sched: clarify find_busiest_group
sched: find_busiest_group arithmetic fix

sched-remove-unused-local.patch
sched: remove unused field

sched-domains-improvements.patch
sched domains kernbench improvements

sched-clock-fixes.patch
fix sched_clock()

sched-sibling-map-to-cpumask.patch
sched: cpu_sibling_map to cpu_mask
p4-clockmod sibling_map fix
p4-clockmod: handle more than two siblings

sched-domains-i386-ht.patch
sched: implement domains for i386 HT
sched: Fix CONFIG_SMT oops on UP
sched: fix SMT + NUMA bug
Change arch_init_sched_domains to use cpu_online_map Fix build with NR_CPUS > BITS_PER_LONG

sched-domain-tweak.patch
i386-sched-domain code consolidation

sched-no-drop-balance.patch
sched: handle inter-CPU jiffies skew

sched-directed-migration.patch
sched_balance_exec(): don't fiddle with the cpus_allowed mask

sched-domain-debugging.patch
sched_domain debugging

sched-domain-balancing-improvements.patch
scheduler domain balancing improvements

sched-group-power.patch
sched-group-power
sched-group-power warning fixes

sched-domains-use-cpu_possible_map.patch
sched_domains: use cpu_possible_map

sched-smt-nice-handling.patch
sched: SMT niceness handling

sched-smt-nice-optimisation.patch
sched: SMT-ice optimisation

ppc64-sched-domain-support.patch
ppc64: sched-domain support

sched-local-load.patch
sched: add local load metrics

sched-no-cpu-in-rq.patch
sched: remove cpu field gtom runqueue

fa311-mac-address-fix.patch
wrong mac address with netgear FA311 ethernet card

laptop-mode-2.patch
laptop-mode for 2.6, version 6
Documentation/laptop-mode.txt
laptop-mode documentation updates
Laptop mode documentation addition
laptop mode simplification

pid_max-fix.patch
Bug when setting pid_max > 32k

use-soft-float.patch
Use -msoft-float

DRM-cvs-update.patch
DRM cvs update

drm-include-fix.patch

process-migration-speedup.patch
Reduce TLB flushing during process migration

non-readable-binaries.patch
Handle non-readable binfmt_misc executables

binfmt_misc-credentials.patch
binfmt_misc: improve calaulation of interpreter's credentials

initramfs-search-for-init.patch
search for /init for initramfs boots

sysfs_remove_dir-race-fix.patch
sysfs_remove_dir-vs-dcache_readdir race fix

sysfs_remove_subdir-dentry-leak-fix.patch
Fix dentry refcounting in sysfs_remove_group()

lightweight-auditing-framework.patch
Light-weight Auditing Framework

per-node-rss-tracking.patch
Track per-node RSS for NUMA

aic7xxx-deadlock-fix.patch
aic7xxx deadlock fix

futex_wait-debug.patch
futex_wait debug

futex_wait-debug-fix.patch

selinux-inode-race-trap.patch
Try to diagnose Bug 2153

ide-scsi-error-handling-fixes.patch
ide-scsi error handling fixes

ide-scsi-error-handling-update.patch
ide-scsi error handler update

poll-select-longer-timeouts.patch
poll()/select(): support longer timeouts

poll-select-range-check-fix.patch
poll()/select() range checking fix

poll-select-handle-large-timeouts.patch
poll()/select(): handle long timeouts

mixart-build-fix.patch
CONFIG_SND_MIXART doesn't compile

add-a-slab-for-ethernet.patch
Add a kmalloc slab for ethernet packets

piix_ide_init-can-be-__init.patch
piix_ide_init can be __init

mq-01-codemove.patch
posix message queues: code move

mq-02-syscalls.patch
posix message queues: syscall stubs

mq-03-core.patch
posix message queues: implementation

mq-03-core-update.patch
posix message queues: update to core patch

mq-04-linuxext-poll.patch
posix message queues: linux-specific poll extension

mq-05-linuxext-mount.patch
posix message queues: made user mountable

mq-update-01.patch
posix message queue update

mq-security-fix.patch
security bugfix for mqueue

queue-congestion-callout.patch
Add queue congestion callout

queue-congestion-dm-implementation.patch
Implement queue congestion callout for device mapper

dm-maplock.patch
devicemapper: use rwlock for map alterations

dm-map-rwlock-ng.patch
Another DM maplock implementation

dm-remove-__dm_request.patch
dmL remove __dm_request

per-backing_dev-unplugging.patch
per-backing dev unplugging

per-backing_dev-unplugging-block_sync_page-fix.patch

swapper_space-unplug_fn.patch

shmem-unplug_fn.patch
more backing_dev unplug functions

HPFS1-hpfs2-RC4-rc1.patch

HPFS2-hpfs_namei-RC4-rc1.patch

queue_work_on_cpu.patch
Add queue_work_on_cpu() workqueue function

pdc202xx_new-update.patch
ide: update for pdc202xx_new driver

siimage-update.patch
ide: update for siimage driver

ide-cleanups-01.patch
ide: IDE cleanups

ide-cleanups-02.patch
ide: IDE cleanups

ide-cleanups-03.patch
ide: IDE cleanups

sysfs-pin-kobject.patch
sysfs: pin kobjects to fix use-after-free crashes

ATI-IXP-IDE-support.patch
ATI IXP IDE support

ipmi-updates-3.patch
IPMI driver updates

ipmi-socket-interface.patch
IPMI: socket interface

nmi_watchdog-local-apic-fix.patch
Fix nmi_watchdog=2 and P4 HT

nmi-1-hz.patch
set nmi_hz to 1 with nmi_watchdog=2 and SMP

pcmcia-netdev-ordering-fixes.patch
PCMCIA netdevice ordering issues

3ware-update.patch
3ware driver update

move-job-control-stuff-tosignal_struct.patch
moef job control fields from task_struct to signal_struct

move-job-control-stuff-tosignal_struct-s390-fix.patch
s390 fix for move-job-control-stuff-tosignal_struct.patch

move-job-control-stuff-tosignal_struct-sx-fix.patch

move-job-control-stuff-tosignal_struct-sn-fix.patch
From: John Hawkes <[email protected]>
Subject: [PATCH] 2.6.4-mm1 for ia64

module_h-attribute_used-fix.patch
module.h __attribute_used__ fix

sch_htb-fix.patch
net: fix sch_htb on 64-bit

selinux-conditional-policy-extensions.patch
selinux: Conditional policy extension and MLS detection support

devinet-ctl_table-fix.patch
devinet_ctl_table[] null termination

cm206-check_region-fix.patch
drivers_cdrom_cm206.c check_region() fix

document-acpi_sleep-option.patch
ACPI: document acpi_sleep option

document-S3_swsusp-tricks.patch
Document tricks to get S3_swsusp working

sjcd-check_region-fix.patch
drivers_cdrom_sjcd.c check_region() fix

rename-acpi_disable.patch
rename one of the acpi_disable() instances

filemap-comment-fix.patch
filemap.c comment fix

fix-kallsyms-in-modules.patch
fix for kallsyms module symbol resolution problem

ver_linux-binutils-version-fix.patch
Fix scripts/ver_linux

module-aliases-for-char-devices.patch
chardev module aliases

credits-updates.patch
minor credits updates

genhd-comment-fix.patch
Fix comment in drivers/block/genhd.c

docbook-build-warning.patch
add warning to DocBook/Makefile

cdu31c-check_region-fix-2.patch
drivers_cdrom_cdu31c.c check_region() fix

move-pcibios-help.patch
move PCIBIOS access help text

modular-fbdev-fix.patch
fix modular fb drivers

kbuild-modpost-fix.patch
kbuild: fix modpost when used with O=

idr-extra-features.patch
idr.c: extra features enhancements

selinux-compute_av-fix.patch
selinux: fix compute_av bug

flush_scheduled_work-deadlock-fix.patch
flush_scheduled_work() deadlock fix

flush_scheduled_work-recursion-detect.patch
flush_workqueue(): detect excessive nesting

page_referenced-no-mark_page_accessed.patch
page_referenced() simplification

fbdev-char-drawing-enhancement.patch
fbdev: character drawing enhancement.

sgml-build-fix.patch
kernel-doc build fix

reiserfs-direct-tail.patch
reiserfs: fix null pointer deref

reiserfs-lock-lat.patch
resierfs: scheduling latency improvements

reiserfs-search-restart.patch
reiserfs: search_by_key fix

reiserfs-should-end-jbegin.patch
reiserfs: fix transaction sizes

reiserfs-write-sched-bug.patch
reiserfs: atomicity fix

reiserfs-aio.patch
resierfs: AIO support

early-x86-cpu-detection.patch
Add early CPU detection to i386, export cache_line_size()

do_write_mem-retval-check.patch
do_write_mem() return value check

vsyscall-alignment-fix.patch
x86 vsyscall alignment fix

smh-do_unmap-comments.patch
document unchecked do_munmaps in ipc/shm.c

shm-do_munmap-check.patch

slab-corruption-detector-fix.patch
slab: fix display of object length in corruption detector

kthread-keeps-files-open.patch
kthreads hold files open

kill-INIT_THREAD_SIZE.patch
kill INIT_THREAD_SIZE

stack-overflow-test-fix.patch
Fix stack overflow test for non-8k stacks

init-task-alignment-fix.patch
proper alignment of init task in kernel image

O_DIRECT-race-fixes-rollup.patch
O_DIRECT data exposure fixes

O_DIRECT-ll_rw_block-vs-block_write_full_page-fix.patch
Fix race between ll_rw_block() and block_write_full_page()

blockdev-direct-io-speedup.patch
blockdev direct-io speedups

dio-aio-fixes.patch
direct-io AIO fixes

aio-fallback-bio_count-race-fix-2.patch
AIO+DIO bio_count race fix

aio-direct-io-oops-fix.patch
AIO/direct-io oops fix

radix-tree-tagging.patch
radix-tree tags for selective lookup

irq-safe-pagecache-lock.patch
make the pagecache lock irq-safe.

tag-dirty-pages.patch
tag dirty pages as such in the radix tree

tag-writeback-pages.patch
tag writeback pages as such in their radix tree

stop-using-dirty-pages.patch
stop using the address_space dirty_pages list

stop-using-io-pages.patch
remove address_space.io_pages

stop-using-locked-pages.patch
Stop using address_space.locked_pages

stop-using-clean-pages.patch
stop using address_space.clean_pages

unslabify-pgds-and-pmds.patch
revert the slabification of i386 pgd's and pmd's

slab-stop-using-page-list.patch
slab: stop using page.list

page_alloc-stop-using-page-list.patch
stop using page.list in the page allocator

hugetlb-stop-using-page-list.patch
stop using page->list in the hugetlbpage implementations

pageattr-stop-using-page-list.patch
stop using page.list in pageattr.c

readahead-stop-using-page-list.patch
stop using page.list in readahead

compound-pages-stop-using-lru.patch
stop using page->lru in compound pages

remove-page-list.patch
remove page.list

remap-file-pages-prot-2.6.4-rc1-mm1-A1.patch
per-page protections for remap_file_pages()

remap-file-pages-prot-ia64-2.6.4-rc2-mm1-A0.patch
remap_file_pages page-prot implementation for ia64

remap-file-pages-prot-ia64-fix.patch
From: John Hawkes <[email protected]>
Subject: [PATCH] 2.6.4-mm1 for ia64

remap-file-pages-prot-s390.patch
s390: remap-file-pages-prot support

remap-file-pages-prot-sparc64.patch
remap-file-pages-prot: sparc64 support

slab-alignment-rework.patch
slab: updates for per-arch alignments

slab-alignment-rework-merge-fix.patch
slab-alignment-rework merge fix

list_del-debug.patch
list_del debug check

oops-dump-preceding-code.patch
i386 oops output: dump preceding code

lockmeter.patch
lockmeter

lockmeter-ia64-fix.patch
ia64 CONFIG_LOCKMETER fix

4g-2.6.0-test2-mm2-A5.patch
4G/4G split patch
4G/4G: remove debug code
4g4g: pmd fix
4g/4g: fixes from Bill
4g4g: fpu emulation fix
4g/4g usercopy atomicity fix
4G/4G: remove debug code
4g4g: pmd fix
4g/4g: fixes from Bill
4g4g: fpu emulation fix
4g/4g usercopy atomicity fix
4G/4G preempt on vstack
4G/4G: even number of kmap types
4g4g: fix __get_user in slab
4g4g: Remove extra .data.idt section definition
4g/4g linker error (overlapping sections)
4G/4G: remove debug code
4g4g: pmd fix
4g/4g: fixes from Bill
4g4g: fpu emulation fix
4g4g: show_registers() fix
4g/4g usercopy atomicity fix
4g4g: debug flags fix
4g4g: Fix wrong asm-offsets entry
cyclone time fixmap fix
4G/4G preempt on vstack
4G/4G: even number of kmap types
4g4g: fix __get_user in slab
4g4g: Remove extra .data.idt section definition
4g/4g linker error (overlapping sections)
4G/4G: remove debug code
4g4g: pmd fix
4g/4g: fixes from Bill
4g4g: fpu emulation fix
4g4g: show_registers() fix
4g/4g usercopy atomicity fix
4g4g: debug flags fix
4g4g: Fix wrong asm-offsets entry
cyclone time fixmap fix
use direct_copy_{to,from}_user for kernel access in mm/usercopy.c 4G/4G might_sleep warning fix
4g/4g pagetable accounting fix
Fix 4G/4G and WP test lockup
4G/4G KERNEL_DS usercopy again
Fix 4G/4G X11/vm86 oops
Fix 4G/4G athlon triplefault
4g4g SEP fix
Fix 4G/4G split fix for pre-pentiumII machines
4g/4g PAE ACPI low mappings fix
zap_low_mappings() cannot be __init
4g/4g: remove printk at boot
4g4g: fix handle_BUG()
4g4g: acpi sleep fixes

4g4g-locked-userspace-copy.patch
Do a locked user-space copy for 4g/4g

ia32-4k-stacks.patch
ia32: 4Kb stacks (and irqstacks) patch

ia32-4k-stacks-build-fix.patch
4k stacks build fix

4k-stacks-in-modversions-magic.patch
Add 4k stacks to module version magic

ppc-fixes.patch
make mm4 compile on ppc

ppc-fixes-dependency-fix.patch
ppc-fixes dependency fix

Joshua Kwan

2004-03-15 01:57 UTC #1 lore raw

Review

Quoted 4 lines · Andrew Morton

(quoted diff) +2 -0

+kbuild-fix-early-dependencies.patch
+kbuild-fix-early-dependencies-fix.patch
 
 Parallel build fix

This set of patches requires the following fix to successfully link the kernel:

Makefile 2004-03-14 17:52:21.000000000 -0800 renamed from Makefile~ 2004-03-14 17:52:54.000000000 -0800 +1 -1

@@ -988,7 +988,7 @@
        @set -e; \
        $(if $($(quiet)cmd_$(1)),echo '  $(subst ','\'',$($(quiet)cmd_$(1)))';) \
        $(cmd_$(1)); \
-       scripts/fixdep $(depfile) $@ '$(subst $$,$$$$,$(subst ','\'',$(cmd_$(1))))' > $(@D)/.$(@F).tmp; \
+       scripts/basic/fixdep $(depfile) $@ '$(subst $$,$$$$,$(subst ','\'',$(cmd_$(1))))' > $(@D)/.$(@F).tmp; \
        rm -f $(depfile); \
        mv -f $(@D)/.$(@F).tmp $(@D)/.$(@F).cmd)

Signature · 1 line

Joshua Kwan

Sam Ravnborg

2004-03-15 06:08 UTC #2 lore raw

Quoted 12 lines · Joshua Kwan

Review
Quoted 4 lines · Andrew Morton
(quoted diff) +2 -0
+kbuild-fix-early-dependencies.patch
+kbuild-fix-early-dependencies-fix.patch
 
 Parallel build fix
This set of patches requires the following fix to successfully link the kernel:

Makefile 2004-03-14 17:52:21.000000000 -0800 line 993

Quoted 7 lines

Makefile 2004-03-14 17:52:21.000000000 -0800 renamed from Makefile~ 2004-03-14 17:52:54.000000000 -0800 +1 -1

@@ -988,7 +988,7 @@
        @set -e; \
        $(if $($(quiet)cmd_$(1)),echo '  $(subst ','\'',$($(quiet)cmd_$(1)))';) \
        $(cmd_$(1)); \
-       scripts/fixdep $(depfile) $@ '$(subst $$,$$$$,$(subst ','\'',$(cmd_$(1))))' > $(@D)/.$(@F).tmp; \
+       scripts/basic/fixdep $(depfile) $@ '$(subst $$,$$$$,$(subst ','\'',$(cmd_$(1))))' > $(@D)/.$(@F).tmp; \
        rm -f $(depfile); \
        mv -f $(@D)/.$(@F).tmp $(@D)/.$(@F).cmd)

Thanks, my bad.
Also I broke docbook. Next time I better delete the binaries in scripts before testing :-(
Updated patch will follow tonight.

Sam

Adrian Bunk

2004-03-15 09:33 UTC #3 lore raw

PATCH 1/1 2.6.4-mm2: ALSA au88x0.c doesn't compile with gcc 2.95

In reply to Andrew Morton

The following compile error with gcc 2.95 comes from Linus' tree:

<-- snip -->

...
CC sound/pci/au88x0/au8810.o
In file included from sound/pci/au88x0/au8810.c:17:
sound/pci/au88x0/au88x0.c: In function `snd_vortex_workaround':
sound/pci/au88x0/au88x0.c:89: parse error before int' sound/pci/au88x0/au88x0.c:93: rc' undeclared (first use in this function) sound/pci/au88x0/au88x0.c:93: (Each undeclared identifier is reported only once sound/pci/au88x0/au88x0.c:93: for each function it appears in.) make[3]: *** [sound/pci/au88x0/au8810.o] Error 1

<-- snip -->

gcc 2.95 doesn't allow declarations mixed with code.

The fix is simple:

sound/pci/au88x0/au88x0.c renamed from sound/pci/au88x0/au88x0.c.old +2 -2

@@ -71,6 +71,8 @@
 static void __devinit snd_vortex_workaround(struct pci_dev *vortex, int fix)
 {
 	struct pci_dev *via = NULL;
+	int rc;
+
 	/* autodetect if workarounds are required */
 	while ((via = pci_find_device(PCI_VENDOR_ID_VIA,
 				      PCI_DEVICE_ID_VIA_8365_1, via))) {

@@ -86,8 +88,6 @@
 	if (fix == 255)
 		return;
 
-	int rc;
-
 	/* fix vortex latency */
 	if (fix & 0x01) {
 		if (!(rc = pci_write_config_byte(vortex, 0x40, 0xff))) {

cu
Adrian

Signature · 4 lines

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Adrian Bunk

2004-03-15 09:36 UTC #4 lore raw

2.6.4-mm2: ALSA au88{1,2}0: multiply defined symbols

In reply to Andrew Morton

The following compile error in 2.6.4-mm2 comes from Linus' tree:

<-- snip -->

...
LD sound/pci/au88x0/built-in.o
sound/pci/au88x0/snd-au8820.o(.bss+0x20): multiple definition of `mchannels' sound/pci/au88x0/snd-au8810.o(.bss+0x20): first defined here
ld: Warning: size of symbol mchannels' changed from 128 in sound/pci/au88x0/snd-au8810.o to 64 in sound/pci/au88x0/snd-au8820.o sound/pci/au88x0/snd-au8820.o(.bss+0x60): multiple definition of rampchs' sound/pci/au88x0/snd-au8810.o(.bss+0xa0): first defined here
ld: Warning: size of symbol rampchs' changed from 128 in sound/pci/au88x0/snd-au8810.o to 64 in sound/pci/au88x0/snd-au8820.o sound/pci/au88x0/snd-au8830.o(.bss+0x20): multiple definition of mchannels' sound/pci/au88x0/snd-au8810.o(.bss+0x20): first defined here
ld: Warning: size of symbol mchannels' changed from 64 in sound/pci/au88x0/snd-au8810.o to 128 in sound/pci/au88x0/snd-au8830.o sound/pci/au88x0/snd-au8830.o(.bss+0xa0): multiple definition of rampchs' sound/pci/au88x0/snd-au8810.o(.bss+0xa0): first defined here
ld: Warning: size of symbol rampchs' changed from 64 in sound/pci/au88x0/snd-au8810.o to 128 in sound/pci/au88x0/snd-au8830.o sound/pci/au88x0/snd-au8830.o(.text+0x6970): In function Vort3DRend_Initialize':
: multiple definition of `Vort3DRend_Initialize' sound/pci/au88x0/snd-au8810.o(.text+0x58c0): first defined here make[3]: *** [sound/pci/au88x0/built-in.o] Error 1

<-- snip -->

cu
Adrian

Signature · 4 lines

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Sam Ravnborg

2004-03-15 18:57 UTC #5 lore raw

In reply to Andrew Morton

Review

Quoted 5 lines

(quoted diff) +2 -0

+kbuild-fix-early-dependencies.patch
+kbuild-fix-early-dependencies-fix.patch
 
 Parallel build fix

Hi Andrew - here is an update, that includes the posted fixes. It also fixes 'make sgmldocs', using correct path to docproc.

It replaces the above two patches, but description is still ok.

Sam

Documentation/DocBook/Makefile +1 -1

diff -Nru a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile
@@ -47,7 +47,7 @@
 ###
 #External programs used
 KERNELDOC = scripts/kernel-doc
-DOCPROC   = scripts/docproc
+DOCPROC   = scripts/basic/docproc
 SPLITMAN  = $(PERL) $(srctree)/scripts/split-man
 MAKEMAN   = $(PERL) $(srctree)/scripts/makeman

Makefile +23 ~~-18~~

85 lines not on this page · raw message

scripts/Makefile +2 -9

diff -Nru a/scripts/Makefile b/scripts/Makefile
@@ -2,14 +2,10 @@
 # scripts contains sources for various helper programs used throughout
 # the kernel for the build process.
 # ---------------------------------------------------------------------------
-# fix-dep: 	 Used to generate dependency information during build process
-# split-include: Divide all config symbols up in a number of files in
-#                include/config/...
 # docproc: 	 Preprocess .tmpl file in order to generate .sgml docs
 # conmakehash:	 Create arrays for initializing the kernel console tables
 
-host-progs	:= fixdep split-include conmakehash docproc kallsyms modpost \
-		   mk_elfconfig pnmtologo bin2c
+host-progs	:= conmakehash kallsyms modpost mk_elfconfig pnmtologo bin2c
 always		:= $(host-progs) empty.o
 
 modpost-objs	:= modpost.o file2alias.o sumversion.o

@@ -17,10 +13,7 @@
 subdir-$(CONFIG_MODVERSIONS)	+= genksyms
 
 # Let clean descend into subdirs
-subdir-	+= lxdialog kconfig
-
-# fixdep is needed to compile other host programs
-$(addprefix $(obj)/,$(filter-out fixdep,$(always)) $(subdir-y)): $(obj)/fixdep
+subdir-	+= basic lxdialog kconfig
 
 # dependencies on generated files need to be listed explicitly

scripts/Makefile.build +1 -1

diff -Nru a/scripts/Makefile.build b/scripts/Makefile.build
@@ -162,7 +162,7 @@
 	$(if $($(quiet)cmd_cc_o_c),echo '  $($(quiet)cmd_cc_o_c)';)	  \
 	$(cmd_cc_o_c);							  \
 	$(cmd_modversions)						  \
-	scripts/fixdep $(depfile) $@ '$(cmd_cc_o_c)' > $(@D)/.$(@F).tmp;  \
+	scripts/basic/fixdep $(depfile) $@ '$(cmd_cc_o_c)' > $(@D)/.$(@F).tmp;  \
 	rm -f $(depfile);						  \
 	mv -f $(@D)/.$(@F).tmp $(@D)/.$(@F).cmd
 endef

scripts/Makefile.lib +1 -1

diff -Nru a/scripts/Makefile.lib b/scripts/Makefile.lib
@@ -249,7 +249,7 @@
 	@set -e; \
 	$(if $($(quiet)cmd_$(1)),echo '  $(subst ','\'',$($(quiet)cmd_$(1)))';) \
 	$(cmd_$(1)); \
-	scripts/fixdep $(depfile) $@ '$(subst $$,$$$$,$(subst ','\'',$(cmd_$(1))))' > $(@D)/.$(@F).tmp; \
+	scripts/basic/fixdep $(depfile) $@ '$(subst $$,$$$$,$(subst ','\'',$(cmd_$(1))))' > $(@D)/.$(@F).tmp; \
 	rm -f $(depfile); \
 	mv -f $(@D)/.$(@F).tmp $(@D)/.$(@F).cmd)

scripts/basic/Makefile new file +18 -0

diff -Nru a/scripts/basic/Makefile b/scripts/basic/Makefile
@@ -0,0 +1,18 @@
+###
+# Makefile.basic list the most basic programs used during the build process.
+# The programs listed herein is what is needed to do the basic stuff,
+# such as splitting .config and fix dependency file.
+# This initial step is needed to avoid files to be recompiled
+# when kernel configuration changes (which is what happens when
+# .config is included by main Makefile.
+# ---------------------------------------------------------------------------
+# fixdep: 	 Used to generate dependency information during build process
+# split-include: Divide all config symbols up in a number of files in
+#                include/config/...
+# docproc:	 Used in Documentation/docbook 
+
+host-progs	:= fixdep split-include docproc
+always		:= $(host-progs)
+
+# fixdep is needed to compile other host programs
+$(addprefix $(obj)/,$(filter-out fixdep,$(always))): $(obj)/fixdep

scripts/basic/docproc.c new file +387 -0

387 lines not on this page · raw message

scripts/basic/fixdep.c new file +381 -0

381 lines not on this page · raw message

scripts/basic/split-include.c new file +226 -0

226 lines not on this page · raw message

scripts/docproc.c deleted +0 ~~-387~~

387 lines not on this page · raw message

scripts/fixdep.c deleted +0 ~~-381~~

381 lines not on this page · raw message

scripts/split-include.c deleted +0 ~~-226~~

226 lines not on this page · raw message

Olaf Hering

2004-03-20 22:50 UTC #6 lore raw

Quoted 17 lines · Sam Ravnborg

Review
Quoted 5 lines
(quoted diff) +2 -0
+kbuild-fix-early-dependencies.patch
+kbuild-fix-early-dependencies-fix.patch
 
 Parallel build fix
Hi Andrew - here is an update, that includes the posted fixes. It also fixes 'make sgmldocs', using correct path to docproc.
It replaces the above two patches, but description is still ok.
diff -Nru a/scripts/Makefile b/scripts/Makefile
scripts/Makefile +0 -0
@@ -17,10 +13,7 @@
 subdir-$(CONFIG_MODVERSIONS)	+= genksyms

scripts/Makefile line 19

Quoted 10 lines

scripts/Makefile +1 -4

 
 # Let clean descend into subdirs
-subdir-	+= lxdialog kconfig
-
-# fixdep is needed to compile other host programs
-$(addprefix $(obj)/,$(filter-out fixdep,$(always)) $(subdir-y)): $(obj)/fixdep
+subdir-	+= basic lxdialog kconfig
 
 # dependencies on generated files need to be listed explicitly

I think that one made it into rc2. It breaks uml compilation,

  CC      kernel/acct.o
  IKCFG   kernel/ikconfig.h
  GZIP    kernel/config_data.gz
  IKCFG   kernel/config_data.h

/bin/sh: line 1: scripts/bin2c: No such file or directory make[1]: *** [kernel/config_data.h] Error 1
make: *** [kernel] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.18419 (%build)

looks like IKCFG does not depend on scripts/bin2c anymore?

Signature · 3 lines

USB is for mice, FireWire is for men!

sUse lINUX ag, nÜRNBERG

John Cherry

2004-03-15 19:18 UTC #7 lore raw

Re: 2.6.4-mm2 (compile stats)

In reply to Andrew Morton

New errors in 2.6.4-mm2 should be fixed with Joshua Kwan's patch (attached to this email):

  LD      .tmp_vmlinux1
  KSYM    .tmp_kallsyms1.S
  AS      .tmp_kallsyms1.o
/bin/sh: line 1: scripts/fixdep: No such file or directory
make: [.tmp_kallsyms1.o] Error 1 (ignored)
  LD      .tmp_vmlinux2
  KSYM    .tmp_kallsyms2.S
  AS      .tmp_kallsyms2.o

/bin/sh: line 1: scripts/fixdep: No such file or directory
make: [.tmp_kallsyms2.o] Error 1 (ignored)

----------------------------------------------------------------------

Linux 2.6 (mm tree) Compile Statistics (gcc 3.2.2) Warnings/Errors Summary

Kernel bzImage bzImage bzImage modules bzImage modules
(defconfig) (allno) (allyes) (allyes) (allmod) (allmod)
--------------- ---------- -------- -------- -------- -------- --------

2.6.4-mm2         1w/2e     5w/2e   144w/10e   8w/0e   3w/2e    144w/0e
2.6.4-mm1         1w/0e     5w/0e   146w/ 5e   8w/0e   3w/0e    144w/0e
2.6.4-rc2-mm1     1w/0e     5w/0e   146w/12e  11w/0e   3w/0e    147w/2e
2.6.4-rc1-mm2     1w/0e     5w/0e   144w/ 0e  11w/0e   3w/0e    145w/0e
2.6.4-rc1-mm1     1w/0e     5w/0e   147w/ 5e  11w/0e   3w/0e    147w/0e
2.6.3-mm4         1w/0e     5w/0e   146w/ 0e   7w/0e   3w/0e    142w/0e
2.6.3-mm3         1w/2e     5w/2e   146w/15e   7w/0e   3w/2e    144w/5e
2.6.3-mm2         1w/8e     5w/0e   140w/ 0e   7w/0e   3w/0e    138w/0e
2.6.3-mm1         1w/0e     5w/0e   143w/ 5e   7w/0e   3w/0e    141w/0e
2.6.3-rc3-mm1     1w/0e     0w/0e   144w/13e   7w/0e   3w/0e    142w/3e
2.6.3-rc2-mm1     1w/0e     0w/265e 144w/ 5e   7w/0e   3w/0e    145w/0e
2.6.3-rc1-mm1     1w/0e     0w/265e 141w/ 5e   7w/0e   3w/0e    143w/0e
2.6.2-mm1         2w/0e     0w/264e 147w/ 5e   7w/0e   3w/0e    173w/0e
2.6.2-rc3-mm1     2w/0e     0w/265e 146w/ 5e   7w/0e   3w/0e    172w/0e
2.6.2-rc2-mm2     0w/0e     0w/264e 145w/ 5e   7w/0e   3w/0e    171w/0e
2.6.2-rc2-mm1     0w/0e     0w/264e 146w/ 5e   7w/0e   3w/0e    172w/0e
2.6.2-rc1-mm3     0w/0e     0w/265e 144w/ 8e   7w/0e   3w/0e    169w/0e
2.6.2-rc1-mm2     0w/0e     0w/264e 144w/ 5e  10w/0e   3w/0e    171w/0e
2.6.2-rc1-mm1     0w/0e     0w/264e 144w/ 5e  10w/0e   3w/0e    171w/0e
2.6.1-mm5         2w/5e     0w/264e 153w/11e  10w/0e   3w/0e    180w/0e
2.6.1-mm4         0w/821e   0w/264e 154w/ 5e   8w/1e   5w/0e    179w/0e
2.6.1-mm3         0w/0e     0w/0e   151w/ 5e  10w/0e   3w/0e    177w/0e
2.6.1-mm2         0w/0e     0w/0e   143w/ 5e  12w/0e   3w/0e    171w/0e
2.6.1-mm1         0w/0e     0w/0e   146w/ 9e  12w/0e   6w/0e    171w/0e
2.6.1-rc2-mm1     0w/0e     0w/0e   149w/ 0e  12w/0e   6w/0e    171w/4e
2.6.1-rc1-mm2     0w/0e     0w/0e   157w/15e  12w/0e   3w/0e    185w/4e
2.6.1-rc1-mm1     0w/0e     0w/0e   156w/10e  12w/0e   3w/0e    184w/2e
2.6.0-mm2         0w/0e     0w/0e   161w/ 0e  12w/0e   3w/0e    189w/0e
2.6.0-mm1         0w/0e     0w/0e   173w/ 0e  12w/0e   3w/0e    212w/0e

Web page with links to complete details:
http://developer.osdl.org/cherry/compile/

This set of patches requires the following fix to successfully link the kernel:

Makefile 2004-03-14 17:52:21.000000000 -0800 renamed from Makefile~ 2004-03-14 17:52:54.000000000 -0800 +0 -0

@@ -988,7 +988,7 @@
        @set -e; \
        $(if $($(quiet)cmd_$(1)),echo '  $(subst

','\'',$($(quiet)cmd_$(1)))';) \
        $(cmd_$(1)); \
-       scripts/fixdep $(depfile) $@ '$(subst $$,$$$$,$(subst
','\'',$(cmd_$(1))))' > $(@D)/.$(@F).tmp; \
+       scripts/basic/fixdep $(depfile) $@ '$(subst $$,$$$$,$(subst
','\'',$(cmd_$(1))))' > $(@D)/.$(@F).tmp; \
        rm -f $(depfile); \
        mv -f $(@D)/.$(@F).tmp $(@D)/.$(@F).cmd)

Signature · 1 line

Joshua Kwan

Thomas Schlichter

2004-03-15 21:00 UTC #8 lore raw

In reply to Andrew Morton

Hi,

with 2.6.4-mm2 I get following badness on boot:

Badness in as_insert_request at drivers/block/as-iosched.c:1513

Call Trace:
 [<c022e326>] as_insert_request+0x166/0x190
 [<c0225af8>] __elv_add_request+0x28/0x60
 [<c0228b9b>] __make_request+0x47b/0x540
 [<c0228d75>] generic_make_request+0x115/0x1d0
 [<c011efd0>] autoremove_wake_function+0x0/0x40
 [<c0228e80>] submit_bio+0x50/0xf0
 [<c0162f58>] __bio_add_page+0x88/0x110
 [<c016300c>] bio_add_page+0x2c/0x40
 [<c013be4f>] submit+0x9f/0xf0
 [<c03aa14a>] check_sig+0x1a/0x70
 [<c03aa4b6>] read_suspend_image+0x6/0x60
 [<c03aa565>] pmdisk_read+0x55/0x70
 [<c013b1a5>] pm_resume+0x15/0x90
 [<c039c7a3>] do_initcalls+0x23/0xc0
 [<c0103090>] init+0x0/0x150
 [<c01030c5>] init+0x35/0x150
 [<c0105288>] kernel_thread_helper+0x0/0x18
 [<c010528d>] kernel_thread_helper+0x5/0x18

After that one I get many badnesses in line 977 of the same file. I commented out that WARN_ON(..) to be able to capture the badness above. The message before the badness is:
PM: Reading pmdisk image.
After the badness following message is printed:
PM: Resume from disk failed.

So there seems to be a conflict between PM-resume (btw, I did not use suspend to disk) and as-iosched. There is no problem if I use "elevator=cfq", "elevator=deadline" or "elevator=noop".

My .config is attached...

Regards
Thomas Schlichter

#
# Automatically generated make config: don't edit
#
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_UID16=y
CONFIG_GENERIC_ISA_DMA=y

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_CLEAN_COMPILE=y
CONFIG_STANDALONE=y
CONFIG_BROKEN_ON_SMP=y

#
# General setup
#
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_SYSCTL=y
CONFIG_AUDIT=y
CONFIG_AUDITSYSCALL=y
CONFIG_LOG_BUF_SHIFT=14
CONFIG_HOTPLUG=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
# CONFIG_EMBEDDED is not set
CONFIG_KALLSYMS=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set

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

#
# Processor type and features
#
CONFIG_X86_PC=y
# CONFIG_X86_ELAN is not set
# CONFIG_X86_VOYAGER is not set
# CONFIG_X86_NUMAQ is not set
# CONFIG_X86_SUMMIT is not set
# CONFIG_X86_BIGSMP is not set
# CONFIG_X86_VISWS is not set
# CONFIG_X86_GENERICARCH is not set
# CONFIG_X86_ES7000 is not set
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMII is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUMM is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
CONFIG_MK7=y
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_X86_GENERIC is not set
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_L1_CACHE_SHIFT=6
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_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_4G is not set
# CONFIG_X86_SWITCH_PAGETABLES is not set
# CONFIG_X86_4G_VM_LAYOUT is not set
# CONFIG_X86_UACCESS_INDIRECT is not set
# CONFIG_X86_HIGH_ENTRY is not set
CONFIG_HPET_TIMER=y
# CONFIG_HPET_EMULATE_RTC is not set
# CONFIG_SMP is not set
CONFIG_PREEMPT=y
CONFIG_X86_UP_APIC=y
CONFIG_X86_UP_IOAPIC=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_TSC=y
CONFIG_X86_MCE=y
CONFIG_X86_MCE_NONFATAL=y
CONFIG_X86_MCE_P4THERMAL=y
CONFIG_TOSHIBA=m
CONFIG_I8K=m
CONFIG_MICROCODE=m
CONFIG_X86_MSR=m
CONFIG_X86_CPUID=m
CONFIG_EDD=y
CONFIG_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
# CONFIG_EFI is not set
CONFIG_HAVE_DEC_LOCK=y
CONFIG_REGPARM=y

#
# Power management options (ACPI, APM)
#
CONFIG_PM=y
CONFIG_SOFTWARE_SUSPEND=y
CONFIG_PM_DISK=y
CONFIG_PM_DISK_PARTITION="/dev/hda2"

#
# ACPI (Advanced Configuration and Power Interface) Support #
CONFIG_ACPI=y
CONFIG_ACPI_BOOT=y
CONFIG_ACPI_INTERPRETER=y
CONFIG_ACPI_SLEEP=y
CONFIG_ACPI_SLEEP_PROC_FS=y
CONFIG_ACPI_AC=m
CONFIG_ACPI_BATTERY=m
CONFIG_ACPI_BUTTON=m
CONFIG_ACPI_FAN=m
CONFIG_ACPI_PROCESSOR=m
CONFIG_ACPI_THERMAL=m
CONFIG_ACPI_ASUS=m
CONFIG_ACPI_TOSHIBA=m
# CONFIG_ACPI_DEBUG is not set
CONFIG_ACPI_BUS=y
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_PCI=y
CONFIG_ACPI_SYSTEM=y
CONFIG_X86_PM_TIMER=y

#
# APM (Advanced Power Management) BIOS Support
#
CONFIG_APM=y
# CONFIG_APM_IGNORE_USER_SUSPEND is not set
CONFIG_APM_DO_ENABLE=y
CONFIG_APM_CPU_IDLE=y
CONFIG_APM_DISPLAY_BLANK=y
# CONFIG_APM_RTC_IS_GMT is not set
# CONFIG_APM_ALLOW_INTS is not set
# CONFIG_APM_REAL_MODE_POWER_OFF is not set

#
# CPU Frequency scaling
#
CONFIG_CPU_FREQ=y CONFIG_CPU_FREQ_PROC_INTF=m CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y # CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set CONFIG_CPU_FREQ_GOV_PERFORMANCE=y CONFIG_CPU_FREQ_GOV_POWERSAVE=m CONFIG_CPU_FREQ_GOV_USERSPACE=m CONFIG_CPU_FREQ_24_API=y CONFIG_CPU_FREQ_TABLE=m

#
# CPUFreq processor drivers
#
CONFIG_X86_ACPI_CPUFREQ=m
CONFIG_X86_ACPI_CPUFREQ_PROC_INTF=y
CONFIG_X86_POWERNOW_K6=m
CONFIG_X86_POWERNOW_K7=m
CONFIG_X86_POWERNOW_K8=m
CONFIG_X86_GX_SUSPMOD=m
CONFIG_X86_SPEEDSTEP_CENTRINO=m
CONFIG_X86_SPEEDSTEP_ICH=m
CONFIG_X86_SPEEDSTEP_SMI=m
CONFIG_X86_P4_CLOCKMOD=m
CONFIG_X86_SPEEDSTEP_LIB=m
CONFIG_X86_LONGRUN=m
CONFIG_X86_LONGHAUL=m

#
# Bus options (PCI, PCMCIA, EISA, MCA, ISA)
#
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GOMMCONFIG is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_MMCONFIG=y
CONFIG_PCI_USE_VECTOR=y
CONFIG_PCI_LEGACY_PROC=y
CONFIG_PCI_NAMES=y
CONFIG_ISA=y
# CONFIG_EISA is not set
# CONFIG_MCA is not set
CONFIG_SCx200=m

#
# PCMCIA/CardBus support
#
CONFIG_PCMCIA=m
# CONFIG_PCMCIA_DEBUG is not set
CONFIG_YENTA=m
CONFIG_CARDBUS=y
CONFIG_I82092=m
CONFIG_I82365=m
CONFIG_TCIC=m
CONFIG_PCMCIA_PROBE=y

#
# PCI Hotplug Support
#
CONFIG_HOTPLUG_PCI=m
CONFIG_HOTPLUG_PCI_FAKE=m
CONFIG_HOTPLUG_PCI_COMPAQ=m
CONFIG_HOTPLUG_PCI_COMPAQ_NVRAM=y
CONFIG_HOTPLUG_PCI_IBM=m
CONFIG_HOTPLUG_PCI_ACPI=m
CONFIG_HOTPLUG_PCI_CPCI=y
CONFIG_HOTPLUG_PCI_CPCI_ZT5550=m
CONFIG_HOTPLUG_PCI_CPCI_GENERIC=m
CONFIG_HOTPLUG_PCI_PCIE=m
CONFIG_HOTPLUG_PCI_PCIE_POLL_EVENT_MODE=y
CONFIG_HOTPLUG_PCI_SHPC=m
CONFIG_HOTPLUG_PCI_SHPC_POLL_EVENT_MODE=y

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

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_FW_LOADER=m

#
# Memory Technology Devices (MTD)
#
CONFIG_MTD=m
# CONFIG_MTD_DEBUG is not set
CONFIG_MTD_PARTITIONS=m
CONFIG_MTD_CONCAT=m
CONFIG_MTD_REDBOOT_PARTS=m
CONFIG_MTD_CMDLINE_PARTS=m

#
# User Modules And Translation Layers
#
CONFIG_MTD_CHAR=m
CONFIG_MTD_BLOCK=m
CONFIG_MTD_BLOCK_RO=m
CONFIG_FTL=m
CONFIG_NFTL=m
CONFIG_NFTL_RW=y
CONFIG_INFTL=m

#
# RAM/ROM/Flash chip drivers
#
CONFIG_MTD_CFI=m
CONFIG_MTD_JEDECPROBE=m
CONFIG_MTD_GEN_PROBE=m
# CONFIG_MTD_CFI_ADV_OPTIONS is not set
CONFIG_MTD_CFI_INTELEXT=m
CONFIG_MTD_CFI_AMDSTD=m
CONFIG_MTD_CFI_STAA=m
CONFIG_MTD_RAM=m
CONFIG_MTD_ROM=m
CONFIG_MTD_ABSENT=m
CONFIG_MTD_OBSOLETE_CHIPS=y
CONFIG_MTD_AMDSTD=m
CONFIG_MTD_SHARP=m
CONFIG_MTD_JEDEC=m

#
# Mapping drivers for chip access
#
CONFIG_MTD_COMPLEX_MAPPINGS=y
CONFIG_MTD_PHYSMAP=m
CONFIG_MTD_PHYSMAP_START=0x8000000
CONFIG_MTD_PHYSMAP_LEN=0x4000000
CONFIG_MTD_PHYSMAP_BUSWIDTH=2
CONFIG_MTD_PNC2000=m
CONFIG_MTD_SC520CDP=m
CONFIG_MTD_NETSC520=m
CONFIG_MTD_SBC_GXX=m
CONFIG_MTD_ELAN_104NC=m
CONFIG_MTD_OCTAGON=m
CONFIG_MTD_VMAX=m
CONFIG_MTD_SCx200_DOCFLASH=m
CONFIG_MTD_AMD76XROM=m
CONFIG_MTD_ICH2ROM=m
CONFIG_MTD_SCB2_FLASH=m
CONFIG_MTD_NETtel=m
CONFIG_MTD_DILNETPC=m
CONFIG_MTD_DILNETPC_BOOTSIZE=0x80000
CONFIG_MTD_L440GX=m
CONFIG_MTD_PCI=m

#
# Self-contained MTD device drivers
#
CONFIG_MTD_PMC551=m
# CONFIG_MTD_PMC551_BUGFIX is not set
# CONFIG_MTD_PMC551_DEBUG is not set
CONFIG_MTD_SLRAM=m
CONFIG_MTD_MTDRAM=m
CONFIG_MTDRAM_TOTAL_SIZE=4096
CONFIG_MTDRAM_ERASE_SIZE=128
CONFIG_MTD_BLKMTD=m

#
# Disk-On-Chip Device Drivers
#
CONFIG_MTD_DOC2000=m
CONFIG_MTD_DOC2001=m
CONFIG_MTD_DOC2001PLUS=m
CONFIG_MTD_DOCPROBE=m
# CONFIG_MTD_DOCPROBE_ADVANCED is not set
CONFIG_MTD_DOCPROBE_ADDRESS=0

#
# NAND Flash Device Drivers
#
CONFIG_MTD_NAND=m
CONFIG_MTD_NAND_VERIFY_WRITE=y
CONFIG_MTD_NAND_IDS=m

#
# Parallel port support
#
CONFIG_PARPORT=m
CONFIG_PARPORT_PC=m
CONFIG_PARPORT_PC_CML1=m
CONFIG_PARPORT_SERIAL=m
CONFIG_PARPORT_PC_FIFO=y
CONFIG_PARPORT_PC_SUPERIO=y
CONFIG_PARPORT_PC_PCMCIA=m
# CONFIG_PARPORT_OTHER is not set
CONFIG_PARPORT_1284=y

#
# Plug and Play support
#
CONFIG_PNP=y
# CONFIG_PNP_DEBUG is not set

#
# Protocols
#
CONFIG_ISAPNP=y
CONFIG_PNPBIOS=y
CONFIG_PNPBIOS_PROC_FS=y

#
# Block devices
#
CONFIG_BLK_DEV_FD=m
CONFIG_BLK_DEV_XD=m
CONFIG_PARIDE=m
CONFIG_PARIDE_PARPORT=m

#
# Parallel IDE high-level drivers
#
CONFIG_PARIDE_PD=m
CONFIG_PARIDE_PCD=m
CONFIG_PARIDE_PF=m
CONFIG_PARIDE_PT=m
CONFIG_PARIDE_PG=m

#
# Parallel IDE protocol modules
#
CONFIG_PARIDE_ATEN=m
CONFIG_PARIDE_BPCK=m
CONFIG_PARIDE_BPCK6=m
CONFIG_PARIDE_COMM=m
CONFIG_PARIDE_DSTR=m
CONFIG_PARIDE_FIT2=m
CONFIG_PARIDE_FIT3=m
CONFIG_PARIDE_EPAT=m
CONFIG_PARIDE_EPATC8=y
CONFIG_PARIDE_EPIA=m
CONFIG_PARIDE_FRIQ=m
CONFIG_PARIDE_FRPW=m
CONFIG_PARIDE_KBIC=m
CONFIG_PARIDE_KTTI=m
CONFIG_PARIDE_ON20=m
CONFIG_PARIDE_ON26=m
CONFIG_BLK_CPQ_DA=m
CONFIG_BLK_CPQ_CISS_DA=m
CONFIG_CISS_SCSI_TAPE=y
CONFIG_BLK_DEV_DAC960=m
CONFIG_BLK_DEV_UMEM=m
CONFIG_BLK_DEV_LOOP=m
CONFIG_BLK_DEV_CRYPTOLOOP=m
CONFIG_BLK_DEV_NBD=m
CONFIG_BLK_DEV_CARMEL=m
CONFIG_BLK_DEV_RAM=m
CONFIG_BLK_DEV_RAM_SIZE=4096
CONFIG_LBD=y

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

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

#
# IDE chipset support/bugfixes
#
CONFIG_IDE_GENERIC=y
CONFIG_BLK_DEV_CMD640=y
CONFIG_BLK_DEV_CMD640_ENHANCED=y
CONFIG_BLK_DEV_IDEPNP=y
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
CONFIG_BLK_DEV_OFFBOARD=y
CONFIG_BLK_DEV_GENERIC=y
CONFIG_BLK_DEV_OPTI621=y
CONFIG_BLK_DEV_RZ1000=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
# CONFIG_BLK_DEV_IDEDMA_FORCED is not set
CONFIG_IDEDMA_PCI_AUTO=y
# CONFIG_IDEDMA_ONLYDISK is not set
CONFIG_BLK_DEV_ADMA=y
CONFIG_BLK_DEV_AEC62XX=y
CONFIG_BLK_DEV_ALI15X3=y
# CONFIG_WDC_ALI15X3 is not set
CONFIG_BLK_DEV_AMD74XX=y
CONFIG_BLK_DEV_ATIIXP=y
CONFIG_BLK_DEV_CMD64X=y
CONFIG_BLK_DEV_TRIFLEX=y
CONFIG_BLK_DEV_CY82C693=y
CONFIG_BLK_DEV_CS5520=y
CONFIG_BLK_DEV_CS5530=y
CONFIG_BLK_DEV_HPT34X=y
CONFIG_HPT34X_AUTODMA=y
CONFIG_BLK_DEV_HPT366=y
CONFIG_BLK_DEV_SC1200=y
CONFIG_BLK_DEV_PIIX=y
CONFIG_BLK_DEV_NS87415=y
CONFIG_BLK_DEV_PDC202XX_OLD=y
CONFIG_PDC202XX_BURST=y
CONFIG_BLK_DEV_PDC202XX_NEW=y
CONFIG_PDC202XX_FORCE=y
CONFIG_BLK_DEV_SVWKS=y
CONFIG_BLK_DEV_SIIMAGE=y
CONFIG_BLK_DEV_SIS5513=y
CONFIG_BLK_DEV_SLC90E66=y
CONFIG_BLK_DEV_TRM290=y
CONFIG_BLK_DEV_VIA82CXXX=y
# CONFIG_IDE_CHIPSETS is not set
CONFIG_BLK_DEV_IDEDMA=y
CONFIG_IDEDMA_IVB=y
CONFIG_IDEDMA_AUTO=y
# CONFIG_DMA_NONPCI is not set
# CONFIG_BLK_DEV_HD is not set

#
# SCSI device support
#
CONFIG_SCSI=m
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=m
CONFIG_BLK_DEV_SR=m
CONFIG_BLK_DEV_SR_VENDOR=y
CONFIG_CHR_DEV_SG=m

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

#
# SCSI Transport Attributes
#
CONFIG_SCSI_SPI_ATTRS=m
CONFIG_SCSI_FC_ATTRS=m

#
# SCSI low-level drivers
#
CONFIG_BLK_DEV_3W_XXXX_RAID=m
CONFIG_SCSI_7000FASST=m
CONFIG_SCSI_ACARD=m
CONFIG_SCSI_AHA152X=m
CONFIG_SCSI_AHA1542=m
CONFIG_SCSI_AACRAID=m
CONFIG_SCSI_AIC7XXX=m
CONFIG_AIC7XXX_CMDS_PER_DEVICE=32
CONFIG_AIC7XXX_RESET_DELAY_MS=15000
# CONFIG_AIC7XXX_BUILD_FIRMWARE is not set
# CONFIG_AIC7XXX_DEBUG_ENABLE is not set
CONFIG_AIC7XXX_DEBUG_MASK=0
CONFIG_AIC7XXX_REG_PRETTY_PRINT=y
CONFIG_SCSI_AIC7XXX_OLD=m
CONFIG_SCSI_AIC79XX=m
CONFIG_AIC79XX_CMDS_PER_DEVICE=32
CONFIG_AIC79XX_RESET_DELAY_MS=15000
# CONFIG_AIC79XX_BUILD_FIRMWARE is not set
# CONFIG_AIC79XX_ENABLE_RD_STRM is not set
# CONFIG_AIC79XX_DEBUG_ENABLE is not set
CONFIG_AIC79XX_DEBUG_MASK=0
CONFIG_AIC79XX_REG_PRETTY_PRINT=y
CONFIG_SCSI_ADVANSYS=m
CONFIG_SCSI_IN2000=m
CONFIG_SCSI_MEGARAID=m
CONFIG_SCSI_SATA=y
CONFIG_SCSI_SATA_SVW=m
CONFIG_SCSI_ATA_PIIX=m
CONFIG_SCSI_SATA_PROMISE=m
CONFIG_SCSI_SATA_VIA=m
CONFIG_SCSI_SATA_VITESSE=m
CONFIG_SCSI_BUSLOGIC=m
# CONFIG_SCSI_OMIT_FLASHPOINT is not set
CONFIG_SCSI_CPQFCTS=m
CONFIG_SCSI_DMX3191D=m
CONFIG_SCSI_DTC3280=m
CONFIG_SCSI_EATA=m
CONFIG_SCSI_EATA_TAGGED_QUEUE=y
CONFIG_SCSI_EATA_LINKED_COMMANDS=y
CONFIG_SCSI_EATA_MAX_TAGS=16
CONFIG_SCSI_EATA_PIO=m
CONFIG_SCSI_FUTURE_DOMAIN=m
CONFIG_SCSI_GDTH=m
CONFIG_SCSI_GENERIC_NCR5380=m
CONFIG_SCSI_GENERIC_NCR5380_MMIO=m
CONFIG_SCSI_GENERIC_NCR53C400=y
CONFIG_SCSI_IPS=m
CONFIG_SCSI_INIA100=m
CONFIG_SCSI_PPA=m
CONFIG_SCSI_IMM=m
# CONFIG_SCSI_IZIP_EPP16 is not set
# CONFIG_SCSI_IZIP_SLOW_CTR is not set
CONFIG_SCSI_NCR53C406A=m
CONFIG_SCSI_SYM53C8XX_2=m
CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=1
CONFIG_SCSI_SYM53C8XX_DEFAULT_TAGS=16
CONFIG_SCSI_SYM53C8XX_MAX_TAGS=64
# CONFIG_SCSI_SYM53C8XX_IOMAPPED is not set
CONFIG_SCSI_PAS16=m
CONFIG_SCSI_PSI240I=m
CONFIG_SCSI_QLOGIC_FAS=m
CONFIG_SCSI_QLOGIC_ISP=m
CONFIG_SCSI_QLOGIC_FC=m
CONFIG_SCSI_QLOGIC_FC_FIRMWARE=y
CONFIG_SCSI_QLOGIC_1280=m
CONFIG_SCSI_QLA2XXX=m
CONFIG_SCSI_QLA21XX=m
CONFIG_SCSI_QLA22XX=m
CONFIG_SCSI_QLA2300=m
CONFIG_SCSI_QLA2322=m
CONFIG_SCSI_QLA6312=m
CONFIG_SCSI_QLA6322=m
CONFIG_SCSI_SYM53C416=m
CONFIG_SCSI_DC395x=m
CONFIG_SCSI_DC390T=m
CONFIG_SCSI_T128=m
CONFIG_SCSI_U14_34F=m
CONFIG_SCSI_U14_34F_TAGGED_QUEUE=y
CONFIG_SCSI_U14_34F_LINKED_COMMANDS=y
CONFIG_SCSI_U14_34F_MAX_TAGS=8
CONFIG_SCSI_ULTRASTOR=m
CONFIG_SCSI_NSP32=m
CONFIG_SCSI_DEBUG=m

#
# PCMCIA SCSI adapter support
#
CONFIG_PCMCIA_AHA152X=m
CONFIG_PCMCIA_FDOMAIN=m
CONFIG_PCMCIA_NINJA_SCSI=m
CONFIG_PCMCIA_QLOGIC=m

#
# Old CD-ROM drivers (not SCSI, not IDE)
#
CONFIG_CD_NO_IDESCSI=y
CONFIG_AZTCD=m
CONFIG_GSCD=m
CONFIG_SBPCD=m
CONFIG_MCD=m
CONFIG_MCD_IRQ=11
CONFIG_MCD_BASE=0x300
CONFIG_MCDX=m
CONFIG_OPTCD=m
CONFIG_CM206=m
CONFIG_SJCD=m
CONFIG_ISP16_CDI=m
CONFIG_CDU31A=m
CONFIG_CDU535=m

#
# Multi-device support (RAID and LVM)
#
CONFIG_MD=y
CONFIG_BLK_DEV_MD=m
CONFIG_MD_LINEAR=m
CONFIG_MD_RAID0=m
CONFIG_MD_RAID1=m
CONFIG_MD_RAID5=m
CONFIG_MD_RAID6=m
CONFIG_MD_MULTIPATH=m
CONFIG_BLK_DEV_DM=m
CONFIG_DM_CRYPT=m

#
# Fusion MPT device support
#
CONFIG_FUSION=m
CONFIG_FUSION_MAX_SGE=40
CONFIG_FUSION_ISENSE=m
CONFIG_FUSION_CTL=m
CONFIG_FUSION_LAN=m

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

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

#
# Device Drivers
#
CONFIG_IEEE1394_PCILYNX=m
CONFIG_IEEE1394_OHCI1394=m

#
# Protocol Drivers
#
CONFIG_IEEE1394_VIDEO1394=m
CONFIG_IEEE1394_SBP2=m
CONFIG_IEEE1394_SBP2_PHYS_DMA=y
CONFIG_IEEE1394_ETH1394=m
CONFIG_IEEE1394_DV1394=m
CONFIG_IEEE1394_RAWIO=m
CONFIG_IEEE1394_CMP=m
CONFIG_IEEE1394_AMDTP=m

#
# I2O device support
#
CONFIG_I2O=m
CONFIG_I2O_PCI=m
CONFIG_I2O_BLOCK=m
CONFIG_I2O_SCSI=m
CONFIG_I2O_PROC=m

#
# Networking support
#
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=m
CONFIG_PACKET_MMAP=y
CONFIG_NETLINK_DEV=m
CONFIG_UNIX=m
CONFIG_IPMI_SOCKET=m
CONFIG_NET_KEY=m
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_ADVANCED_ROUTER=y
CONFIG_IP_MULTIPLE_TABLES=y
CONFIG_IP_ROUTE_FWMARK=y
CONFIG_IP_ROUTE_NAT=y
CONFIG_IP_ROUTE_MULTIPATH=y
CONFIG_IP_ROUTE_TOS=y
CONFIG_IP_ROUTE_VERBOSE=y
CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
CONFIG_IP_PNP_BOOTP=y
CONFIG_IP_PNP_RARP=y
CONFIG_NET_IPIP=m
CONFIG_NET_IPGRE=m
CONFIG_NET_IPGRE_BROADCAST=y
CONFIG_IP_MROUTE=y
CONFIG_IP_PIMSM_V1=y
CONFIG_IP_PIMSM_V2=y
CONFIG_ARPD=y
CONFIG_INET_ECN=y
CONFIG_SYN_COOKIES=y
CONFIG_INET_AH=m
CONFIG_INET_ESP=m
CONFIG_INET_IPCOMP=m

#
# IP: Virtual Server Configuration
#
CONFIG_IP_VS=m
# CONFIG_IP_VS_DEBUG is not set
CONFIG_IP_VS_TAB_BITS=12

#
# IPVS transport protocol load balancing support
#
CONFIG_IP_VS_PROTO_TCP=y
CONFIG_IP_VS_PROTO_UDP=y
CONFIG_IP_VS_PROTO_ESP=y
CONFIG_IP_VS_PROTO_AH=y

#
# IPVS scheduler
#
CONFIG_IP_VS_RR=m
CONFIG_IP_VS_WRR=m
CONFIG_IP_VS_LC=m
CONFIG_IP_VS_WLC=m
CONFIG_IP_VS_LBLC=m
CONFIG_IP_VS_LBLCR=m
CONFIG_IP_VS_DH=m
CONFIG_IP_VS_SH=m
CONFIG_IP_VS_SED=m
CONFIG_IP_VS_NQ=m

#
# IPVS application helper
#
CONFIG_IP_VS_FTP=m
CONFIG_IPV6=m
CONFIG_IPV6_PRIVACY=y
CONFIG_INET6_AH=m
CONFIG_INET6_ESP=m
CONFIG_INET6_IPCOMP=m
CONFIG_IPV6_TUNNEL=m
CONFIG_DECNET=m
# CONFIG_DECNET_SIOCGIFCONF is not set
CONFIG_DECNET_ROUTER=y
CONFIG_DECNET_ROUTE_FWMARK=y
CONFIG_BRIDGE=m
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
CONFIG_BRIDGE_NETFILTER=y

#
# IP: Netfilter Configuration
#
CONFIG_IP_NF_CONNTRACK=m
CONFIG_IP_NF_FTP=m
CONFIG_IP_NF_IRC=m
CONFIG_IP_NF_TFTP=m
CONFIG_IP_NF_AMANDA=m
CONFIG_IP_NF_QUEUE=m
CONFIG_IP_NF_IPTABLES=m
CONFIG_IP_NF_MATCH_LIMIT=m
CONFIG_IP_NF_MATCH_IPRANGE=m
CONFIG_IP_NF_MATCH_MAC=m
CONFIG_IP_NF_MATCH_PKTTYPE=m
CONFIG_IP_NF_MATCH_MARK=m
CONFIG_IP_NF_MATCH_MULTIPORT=m
CONFIG_IP_NF_MATCH_TOS=m
CONFIG_IP_NF_MATCH_RECENT=m
CONFIG_IP_NF_MATCH_ECN=m
CONFIG_IP_NF_MATCH_DSCP=m
CONFIG_IP_NF_MATCH_AH_ESP=m
CONFIG_IP_NF_MATCH_LENGTH=m
CONFIG_IP_NF_MATCH_TTL=m
CONFIG_IP_NF_MATCH_TCPMSS=m
CONFIG_IP_NF_MATCH_HELPER=m
CONFIG_IP_NF_MATCH_STATE=m
CONFIG_IP_NF_MATCH_CONNTRACK=m
CONFIG_IP_NF_MATCH_OWNER=m
CONFIG_IP_NF_MATCH_PHYSDEV=m
CONFIG_IP_NF_FILTER=m
CONFIG_IP_NF_TARGET_REJECT=m
CONFIG_IP_NF_NAT=m
CONFIG_IP_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=m
CONFIG_IP_NF_TARGET_REDIRECT=m
CONFIG_IP_NF_TARGET_NETMAP=m
CONFIG_IP_NF_TARGET_SAME=m
CONFIG_IP_NF_NAT_LOCAL=y
CONFIG_IP_NF_NAT_SNMP_BASIC=m
CONFIG_IP_NF_NAT_IRC=m
CONFIG_IP_NF_NAT_FTP=m
CONFIG_IP_NF_NAT_TFTP=m
CONFIG_IP_NF_NAT_AMANDA=m
CONFIG_IP_NF_MANGLE=m
CONFIG_IP_NF_TARGET_TOS=m
CONFIG_IP_NF_TARGET_ECN=m
CONFIG_IP_NF_TARGET_DSCP=m
CONFIG_IP_NF_TARGET_MARK=m
CONFIG_IP_NF_TARGET_CLASSIFY=m
CONFIG_IP_NF_TARGET_LOG=m
CONFIG_IP_NF_TARGET_ULOG=m
CONFIG_IP_NF_TARGET_TCPMSS=m
CONFIG_IP_NF_ARPTABLES=m
CONFIG_IP_NF_ARPFILTER=m
CONFIG_IP_NF_ARP_MANGLE=m
CONFIG_IP_NF_COMPAT_IPCHAINS=m
CONFIG_IP_NF_COMPAT_IPFWADM=m

#
# IPv6: Netfilter Configuration
#
CONFIG_IP6_NF_QUEUE=m
CONFIG_IP6_NF_IPTABLES=m
CONFIG_IP6_NF_MATCH_LIMIT=m
CONFIG_IP6_NF_MATCH_MAC=m
CONFIG_IP6_NF_MATCH_RT=m
CONFIG_IP6_NF_MATCH_OPTS=m
CONFIG_IP6_NF_MATCH_FRAG=m
CONFIG_IP6_NF_MATCH_HL=m
CONFIG_IP6_NF_MATCH_MULTIPORT=m
CONFIG_IP6_NF_MATCH_OWNER=m
CONFIG_IP6_NF_MATCH_MARK=m
CONFIG_IP6_NF_MATCH_IPV6HEADER=m
CONFIG_IP6_NF_MATCH_AHESP=m
CONFIG_IP6_NF_MATCH_LENGTH=m
CONFIG_IP6_NF_MATCH_EUI64=m
CONFIG_IP6_NF_FILTER=m
CONFIG_IP6_NF_TARGET_LOG=m
CONFIG_IP6_NF_MANGLE=m
CONFIG_IP6_NF_TARGET_MARK=m

#
# DECnet: Netfilter Configuration
#
CONFIG_DECNET_NF_GRABULATOR=m

#
# Bridge: Netfilter Configuration
#
CONFIG_BRIDGE_NF_EBTABLES=m
CONFIG_BRIDGE_EBT_BROUTE=m
CONFIG_BRIDGE_EBT_T_FILTER=m
CONFIG_BRIDGE_EBT_T_NAT=m
CONFIG_BRIDGE_EBT_802_3=m
CONFIG_BRIDGE_EBT_AMONG=m
CONFIG_BRIDGE_EBT_ARP=m
CONFIG_BRIDGE_EBT_IP=m
CONFIG_BRIDGE_EBT_LIMIT=m
CONFIG_BRIDGE_EBT_MARK=m
CONFIG_BRIDGE_EBT_PKTTYPE=m
CONFIG_BRIDGE_EBT_STP=m
CONFIG_BRIDGE_EBT_VLAN=m
CONFIG_BRIDGE_EBT_ARPREPLY=m
CONFIG_BRIDGE_EBT_DNAT=m
CONFIG_BRIDGE_EBT_MARK_T=m
CONFIG_BRIDGE_EBT_REDIRECT=m
CONFIG_BRIDGE_EBT_SNAT=m
CONFIG_BRIDGE_EBT_LOG=m
CONFIG_XFRM=y
CONFIG_XFRM_USER=m

#
# SCTP Configuration (EXPERIMENTAL)
#
CONFIG_IPV6_SCTP__=m
CONFIG_IP_SCTP=m
# CONFIG_SCTP_DBG_MSG is not set
# CONFIG_SCTP_DBG_OBJCNT is not set
# CONFIG_SCTP_HMAC_NONE is not set
# CONFIG_SCTP_HMAC_SHA1 is not set
CONFIG_SCTP_HMAC_MD5=y
CONFIG_ATM=m
CONFIG_ATM_CLIP=m
CONFIG_ATM_CLIP_NO_ICMP=y
CONFIG_ATM_LANE=m
CONFIG_ATM_MPOA=m
CONFIG_ATM_BR2684=m
# CONFIG_ATM_BR2684_IPFILTER is not set
CONFIG_VLAN_8021Q=m
CONFIG_LLC=y
CONFIG_LLC2=m
CONFIG_IPX=m
# CONFIG_IPX_INTERN is not set
CONFIG_ATALK=m
CONFIG_DEV_APPLETALK=y
CONFIG_LTPC=m
CONFIG_COPS=m
CONFIG_COPS_DAYNA=y
CONFIG_COPS_TANGENT=y
CONFIG_IPDDP=m
CONFIG_IPDDP_ENCAP=y
CONFIG_IPDDP_DECAP=y
CONFIG_X25=m
CONFIG_LAPB=m
CONFIG_NET_DIVERT=y
CONFIG_ECONET=m
CONFIG_ECONET_AUNUDP=y
CONFIG_ECONET_NATIVE=y
CONFIG_WAN_ROUTER=m
# CONFIG_NET_FASTROUTE is not set
# CONFIG_NET_HW_FLOWCONTROL is not set

#
# QoS and/or fair queueing
#
CONFIG_NET_SCHED=y
CONFIG_NET_SCH_CBQ=m
CONFIG_NET_SCH_HTB=m
CONFIG_NET_SCH_HFSC=m
CONFIG_NET_SCH_CSZ=m
CONFIG_NET_SCH_ATM=m
CONFIG_NET_SCH_PRIO=m
CONFIG_NET_SCH_RED=m
CONFIG_NET_SCH_SFQ=m
CONFIG_NET_SCH_TEQL=m
CONFIG_NET_SCH_TBF=m
CONFIG_NET_SCH_GRED=m
CONFIG_NET_SCH_DSMARK=m
CONFIG_NET_SCH_INGRESS=m
CONFIG_NET_QOS=y
CONFIG_NET_ESTIMATOR=y
CONFIG_NET_CLS=y
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_NET_CLS_RSVP=m
CONFIG_NET_CLS_RSVP6=m
CONFIG_NET_CLS_POLICE=y

#
# Network testing
#
CONFIG_NET_PKTGEN=m
CONFIG_NETDEVICES=y

#
# ARCnet devices
#
CONFIG_ARCNET=m
CONFIG_ARCNET_1201=m
CONFIG_ARCNET_1051=m
CONFIG_ARCNET_RAW=m
CONFIG_ARCNET_COM90xx=m
CONFIG_ARCNET_COM90xxIO=m
CONFIG_ARCNET_RIM_I=m
CONFIG_ARCNET_COM20020=m
CONFIG_ARCNET_COM20020_ISA=m
CONFIG_ARCNET_COM20020_PCI=m
CONFIG_DUMMY=m
CONFIG_BONDING=m
CONFIG_EQUALIZER=m
CONFIG_TUN=m
CONFIG_ETHERTAP=m
CONFIG_NET_SB1000=m

#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
CONFIG_MII=m
CONFIG_HAPPYMEAL=m
CONFIG_SUNGEM=m
CONFIG_NET_VENDOR_3COM=y
CONFIG_EL1=m
CONFIG_EL2=m
CONFIG_ELPLUS=m
CONFIG_EL16=m
CONFIG_EL3=m
CONFIG_3C515=m
CONFIG_VORTEX=m
CONFIG_TYPHOON=m
CONFIG_LANCE=m
CONFIG_NET_VENDOR_SMC=y
CONFIG_WD80x3=m
CONFIG_ULTRA=m
CONFIG_SMC9194=m
CONFIG_NET_VENDOR_RACAL=y
CONFIG_NI5010=m
CONFIG_NI52=m
CONFIG_NI65=m

#
# Tulip family network device support
#
CONFIG_NET_TULIP=y
CONFIG_DE2104X=m
CONFIG_TULIP=m
CONFIG_TULIP_MWI=y
CONFIG_TULIP_MMIO=y
CONFIG_TULIP_NAPI=y
CONFIG_TULIP_NAPI_HW_MITIGATION=y
CONFIG_DE4X5=m
CONFIG_WINBOND_840=m
CONFIG_DM9102=m
CONFIG_PCMCIA_XIRCOM=m
CONFIG_PCMCIA_XIRTULIP=m
CONFIG_AT1700=m
CONFIG_DEPCA=m
CONFIG_HP100=m
CONFIG_NET_ISA=y
CONFIG_E2100=m
CONFIG_EWRK3=m
CONFIG_EEXPRESS=m
CONFIG_EEXPRESS_PRO=m
CONFIG_HPLAN_PLUS=m
CONFIG_HPLAN=m
CONFIG_LP486E=m
CONFIG_ETH16I=m
CONFIG_NE2000=m
CONFIG_ZNET=m
CONFIG_SEEQ8005=m
CONFIG_NET_PCI=y
CONFIG_PCNET32=m
CONFIG_AMD8111_ETH=m
CONFIG_ADAPTEC_STARFIRE=m
CONFIG_ADAPTEC_STARFIRE_NAPI=y
CONFIG_AC3200=m
CONFIG_APRICOT=m
CONFIG_B44=m
CONFIG_FORCEDETH=m
CONFIG_CS89x0=m
CONFIG_DGRS=m
CONFIG_EEPRO100=m
# CONFIG_EEPRO100_PIO is not set
CONFIG_E100=m
CONFIG_E100_NAPI=y
CONFIG_FEALNX=m
CONFIG_NATSEMI=m
CONFIG_NE2K_PCI=m
CONFIG_8139CP=m
CONFIG_8139TOO=m
# CONFIG_8139TOO_PIO is not set
CONFIG_8139TOO_TUNE_TWISTER=y
CONFIG_8139TOO_8129=y
# CONFIG_8139_OLD_RX_RESET is not set
CONFIG_8139_RXBUF_IDX=2
CONFIG_SIS900=m
CONFIG_EPIC100=m
CONFIG_SUNDANCE=m
CONFIG_SUNDANCE_MMIO=y
CONFIG_TLAN=m
CONFIG_VIA_RHINE=m
CONFIG_VIA_RHINE_MMIO=y
CONFIG_NET_POCKET=y
CONFIG_ATP=m
CONFIG_DE600=m
CONFIG_DE620=m

#
# Ethernet (1000 Mbit)
#
CONFIG_ACENIC=m
# CONFIG_ACENIC_OMIT_TIGON_I is not set
CONFIG_DL2K=m
CONFIG_E1000=m
CONFIG_E1000_NAPI=y
CONFIG_NS83820=m
CONFIG_HAMACHI=m
CONFIG_YELLOWFIN=m
CONFIG_R8169=m
CONFIG_SIS190=m
CONFIG_SK98LIN=m
CONFIG_TIGON3=m

#
# Ethernet (10000 Mbit)
#
CONFIG_IXGB=m
CONFIG_IXGB_NAPI=y
CONFIG_FDDI=y
CONFIG_DEFXX=m
CONFIG_SKFP=m
CONFIG_HIPPI=y
CONFIG_ROADRUNNER=m
CONFIG_ROADRUNNER_LARGE_RINGS=y
CONFIG_PLIP=m
CONFIG_PPP=m
CONFIG_PPP_MULTILINK=y
CONFIG_PPP_FILTER=y
CONFIG_PPP_ASYNC=m
CONFIG_PPP_SYNC_TTY=m
CONFIG_PPP_DEFLATE=m
CONFIG_PPP_BSDCOMP=m
CONFIG_PPPOE=m
CONFIG_PPPOATM=m
CONFIG_SLIP=m
CONFIG_SLIP_COMPRESSED=y
CONFIG_SLIP_SMART=y
CONFIG_SLIP_MODE_SLIP6=y

#
# Wireless LAN (non-hamradio)
#
CONFIG_NET_RADIO=y

#
# Obsolete Wireless cards support (pre-802.11)
#
CONFIG_STRIP=m
CONFIG_ARLAN=m
CONFIG_WAVELAN=m
CONFIG_PCMCIA_WAVELAN=m
CONFIG_PCMCIA_NETWAVE=m

#
# Wireless 802.11 Frequency Hopping cards support
#
CONFIG_PCMCIA_RAYCS=m

#
# Wireless 802.11b ISA/PCI cards support
#
CONFIG_AIRO=m
CONFIG_HERMES=m
CONFIG_PLX_HERMES=m
CONFIG_TMD_HERMES=m
CONFIG_PCI_HERMES=m
CONFIG_ATMEL=m
CONFIG_PCI_ATMEL=m

#
# Wireless 802.11b Pcmcia/Cardbus cards support
#
CONFIG_PCMCIA_HERMES=m
CONFIG_AIRO_CS=m
CONFIG_PCMCIA_ATMEL=m
CONFIG_PCMCIA_WL3501=m

#
# Prism GT/Duette 802.11(a/b/g) PCI/PCMCIA support #
CONFIG_PRISM54=m
CONFIG_NET_WIRELESS=y

#
# Token Ring devices
#
CONFIG_TR=y
CONFIG_IBMTR=m
CONFIG_IBMOL=m
CONFIG_IBMLS=m
CONFIG_3C359=m
CONFIG_TMS380TR=m
CONFIG_TMSPCI=m
CONFIG_SKISA=m
CONFIG_PROTEON=m
CONFIG_ABYSS=m
CONFIG_SMCTR=m
CONFIG_NET_FC=y
CONFIG_RCPCI=m
CONFIG_SHAPER=m
CONFIG_NETCONSOLE=m

#
# Wan interfaces
#
CONFIG_WAN=y
CONFIG_HOSTESS_SV11=m
CONFIG_COSA=m
CONFIG_DSCC4=m
CONFIG_DSCC4_PCISYNC=y
CONFIG_DSCC4_PCI_RST=y
CONFIG_LANMEDIA=m
CONFIG_SEALEVEL_4021=m
CONFIG_SYNCLINK_SYNCPPP=m
CONFIG_HDLC=m
CONFIG_HDLC_RAW=y
CONFIG_HDLC_RAW_ETH=y
CONFIG_HDLC_CISCO=y
CONFIG_HDLC_FR=y
CONFIG_HDLC_PPP=y
CONFIG_HDLC_X25=y
CONFIG_PCI200SYN=m
CONFIG_WANXL=m
# CONFIG_WANXL_BUILD_FIRMWARE is not set
CONFIG_PC300=m
CONFIG_PC300_MLPPP=y
CONFIG_N2=m
CONFIG_C101=m
CONFIG_FARSYNC=m
CONFIG_DLCI=m
CONFIG_DLCI_COUNT=24
CONFIG_DLCI_MAX=8
CONFIG_SDLA=m
CONFIG_WAN_ROUTER_DRIVERS=y
CONFIG_CYCLADES_SYNC=m
CONFIG_CYCLOMX_X25=y
CONFIG_LAPBETHER=m
CONFIG_X25_ASY=m
CONFIG_SBNI=m
CONFIG_SBNI_MULTILINE=y

#
# PCMCIA network device support
#
CONFIG_NET_PCMCIA=y
CONFIG_PCMCIA_3C589=m
CONFIG_PCMCIA_3C574=m
CONFIG_PCMCIA_FMVJ18X=m
CONFIG_PCMCIA_PCNET=m
CONFIG_PCMCIA_NMCLAN=m
CONFIG_PCMCIA_SMC91C92=m
CONFIG_PCMCIA_XIRC2PS=m
CONFIG_PCMCIA_AXNET=m
CONFIG_ARCNET_COM20020_CS=m
CONFIG_PCMCIA_IBMTR=m

#
# ATM drivers
#
CONFIG_ATM_TCP=m
CONFIG_ATM_LANAI=m
CONFIG_ATM_ENI=m
# CONFIG_ATM_ENI_DEBUG is not set
# CONFIG_ATM_ENI_TUNE_BURST is not set
CONFIG_ATM_FIRESTREAM=m
CONFIG_ATM_ZATM=m
# CONFIG_ATM_ZATM_DEBUG is not set
CONFIG_ATM_NICSTAR=m
CONFIG_ATM_NICSTAR_USE_SUNI=y
CONFIG_ATM_NICSTAR_USE_IDT77105=y
CONFIG_ATM_IDT77252=m
# CONFIG_ATM_IDT77252_DEBUG is not set
# CONFIG_ATM_IDT77252_RCV_ALL is not set
CONFIG_ATM_IDT77252_USE_SUNI=y
CONFIG_ATM_AMBASSADOR=m
# CONFIG_ATM_AMBASSADOR_DEBUG is not set
CONFIG_ATM_HORIZON=m
# CONFIG_ATM_HORIZON_DEBUG is not set
CONFIG_ATM_IA=m
# CONFIG_ATM_IA_DEBUG is not set
CONFIG_ATM_FORE200E_MAYBE=m
CONFIG_ATM_FORE200E_PCA=y
CONFIG_ATM_FORE200E_PCA_DEFAULT_FW=y
CONFIG_ATM_FORE200E_TX_RETRY=16
CONFIG_ATM_FORE200E_DEBUG=0
CONFIG_ATM_FORE200E=m
CONFIG_ATM_HE=m
CONFIG_ATM_HE_USE_SUNI=y

#
# Amateur Radio support
#
CONFIG_HAMRADIO=y

#
# Packet Radio protocols
#
CONFIG_AX25=m
CONFIG_AX25_DAMA_SLAVE=y
CONFIG_NETROM=m
CONFIG_ROSE=m

#
# AX.25 network device drivers
#
CONFIG_MKISS=m
CONFIG_6PACK=m
CONFIG_BPQETHER=m
CONFIG_DMASCC=m
CONFIG_SCC=m
CONFIG_SCC_DELAY=y
CONFIG_SCC_TRXECHO=y
CONFIG_BAYCOM_SER_FDX=m
CONFIG_BAYCOM_SER_HDX=m
CONFIG_BAYCOM_PAR=m
CONFIG_BAYCOM_EPP=m
CONFIG_YAM=m

#
# IrDA (infrared) support
#
CONFIG_IRDA=m

#
# IrDA protocols
#
CONFIG_IRLAN=m
CONFIG_IRNET=m
CONFIG_IRCOMM=m
CONFIG_IRDA_ULTRA=y

#
# IrDA options
#
CONFIG_IRDA_CACHE_LAST_LSAP=y
CONFIG_IRDA_FAST_RR=y
# CONFIG_IRDA_DEBUG is not set

#
# Infrared-port device drivers
#

#
# SIR device drivers
#
CONFIG_IRTTY_SIR=m

#
# Dongle support
#
CONFIG_DONGLE=y
CONFIG_ESI_DONGLE=m
CONFIG_ACTISYS_DONGLE=m
CONFIG_TEKRAM_DONGLE=m
CONFIG_LITELINK_DONGLE=m
CONFIG_MA600_DONGLE=m
CONFIG_GIRBIL_DONGLE=m
CONFIG_MCP2120_DONGLE=m
CONFIG_OLD_BELKIN_DONGLE=m
CONFIG_ACT200L_DONGLE=m

#
# Old SIR device drivers
#
CONFIG_IRPORT_SIR=m

#
# Old Serial dongle support
#
CONFIG_DONGLE_OLD=y
CONFIG_ESI_DONGLE_OLD=m
CONFIG_ACTISYS_DONGLE_OLD=m
CONFIG_TEKRAM_DONGLE_OLD=m
CONFIG_GIRBIL_DONGLE_OLD=m
CONFIG_LITELINK_DONGLE_OLD=m
CONFIG_MCP2120_DONGLE_OLD=m
CONFIG_OLD_BELKIN_DONGLE_OLD=m
CONFIG_ACT200L_DONGLE_OLD=m
CONFIG_MA600_DONGLE_OLD=m

#
# FIR device drivers
#
CONFIG_USB_IRDA=m
CONFIG_SIGMATEL_FIR=m
CONFIG_NSC_FIR=m
CONFIG_WINBOND_FIR=m
CONFIG_TOSHIBA_FIR=m
CONFIG_SMC_IRCC_FIR=m
CONFIG_ALI_FIR=m
CONFIG_VLSI_FIR=m
CONFIG_VIA_FIR=m

#
# Bluetooth support
#
CONFIG_BT=m
CONFIG_BT_L2CAP=m
CONFIG_BT_SCO=m
CONFIG_BT_RFCOMM=m
CONFIG_BT_RFCOMM_TTY=y
CONFIG_BT_BNEP=m
CONFIG_BT_BNEP_MC_FILTER=y
CONFIG_BT_BNEP_PROTO_FILTER=y
CONFIG_BT_CMTP=m

#
# Bluetooth device drivers
#
CONFIG_BT_HCIUSB=m
CONFIG_BT_HCIUSB_SCO=y
CONFIG_BT_HCIUART=m
CONFIG_BT_HCIUART_H4=y
CONFIG_BT_HCIUART_BCSP=y
CONFIG_BT_HCIUART_BCSP_TXCRC=y
CONFIG_BT_HCIBCM203X=m
CONFIG_BT_HCIBFUSB=m
CONFIG_BT_HCIDTL1=m
CONFIG_BT_HCIBT3C=m
CONFIG_BT_HCIBLUECARD=m
CONFIG_BT_HCIBTUART=m
CONFIG_BT_HCIVHCI=m
# CONFIG_KGDBOE is not set
CONFIG_NETPOLL=y
# CONFIG_NETPOLL_RX is not set
# CONFIG_NETPOLL_TRAP is not set
CONFIG_NET_POLL_CONTROLLER=y

#
# ISDN subsystem
#
CONFIG_ISDN=m

#
# Old ISDN4Linux
#
# CONFIG_ISDN_I4L is not set

#
# CAPI subsystem
#
CONFIG_ISDN_CAPI=m
CONFIG_ISDN_DRV_AVMB1_VERBOSE_REASON=y
CONFIG_ISDN_CAPI_MIDDLEWARE=y
CONFIG_ISDN_CAPI_CAPI20=m
CONFIG_ISDN_CAPI_CAPIFS_BOOL=y
CONFIG_ISDN_CAPI_CAPIFS=m

#
# CAPI hardware drivers
#

#
# Active AVM cards
#
CONFIG_CAPI_AVM=y
CONFIG_ISDN_DRV_AVMB1_B1ISA=m
CONFIG_ISDN_DRV_AVMB1_B1PCI=m
CONFIG_ISDN_DRV_AVMB1_B1PCIV4=y
CONFIG_ISDN_DRV_AVMB1_T1ISA=m
CONFIG_ISDN_DRV_AVMB1_B1PCMCIA=m
CONFIG_ISDN_DRV_AVMB1_AVM_CS=m
CONFIG_ISDN_DRV_AVMB1_T1PCI=m
CONFIG_ISDN_DRV_AVMB1_C4=m

#
# Active Eicon DIVA Server cards
#
CONFIG_CAPI_EICON=y
CONFIG_ISDN_DIVAS=m
CONFIG_ISDN_DIVAS_BRIPCI=y
CONFIG_ISDN_DIVAS_PRIPCI=y
CONFIG_ISDN_DIVAS_DIVACAPI=m
CONFIG_ISDN_DIVAS_USERIDI=m
CONFIG_ISDN_DIVAS_MAINT=m

#
# Telephony Support
#
CONFIG_PHONE=m
CONFIG_PHONE_IXJ=m
CONFIG_PHONE_IXJ_PCMCIA=m

#
# Input device support
#
CONFIG_INPUT=y

#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_PSAUX=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
CONFIG_INPUT_JOYDEV=m
CONFIG_INPUT_TSDEV=m
CONFIG_INPUT_TSDEV_SCREEN_X=240
CONFIG_INPUT_TSDEV_SCREEN_Y=320
CONFIG_INPUT_EVDEV=m
CONFIG_INPUT_EVBUG=m

#
# Input I/O drivers
#
CONFIG_GAMEPORT=m
CONFIG_SOUND_GAMEPORT=m
CONFIG_GAMEPORT_NS558=m
CONFIG_GAMEPORT_L4=m
CONFIG_GAMEPORT_EMU10K1=m
CONFIG_GAMEPORT_VORTEX=m
CONFIG_GAMEPORT_FM801=m
CONFIG_GAMEPORT_CS461x=m
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
CONFIG_SERIO_SERPORT=m
CONFIG_SERIO_CT82C710=m
CONFIG_SERIO_PARKBD=m
CONFIG_SERIO_PCIPS2=m

#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
CONFIG_KEYBOARD_SUNKBD=m
CONFIG_KEYBOARD_LKKBD=m
CONFIG_KEYBOARD_XTKBD=m
CONFIG_KEYBOARD_NEWTON=m
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=m
CONFIG_MOUSE_SERIAL=m
CONFIG_MOUSE_INPORT=m
CONFIG_MOUSE_ATIXL=y
CONFIG_MOUSE_LOGIBM=m
CONFIG_MOUSE_PC110PAD=m
CONFIG_MOUSE_VSXXXAA=m
CONFIG_INPUT_JOYSTICK=y
CONFIG_JOYSTICK_ANALOG=m
CONFIG_JOYSTICK_A3D=m
CONFIG_JOYSTICK_ADI=m
CONFIG_JOYSTICK_COBRA=m
CONFIG_JOYSTICK_GF2K=m
CONFIG_JOYSTICK_GRIP=m
CONFIG_JOYSTICK_GRIP_MP=m
CONFIG_JOYSTICK_GUILLEMOT=m
CONFIG_JOYSTICK_INTERACT=m
CONFIG_JOYSTICK_SIDEWINDER=m
CONFIG_JOYSTICK_TMDC=m
CONFIG_JOYSTICK_IFORCE=m
CONFIG_JOYSTICK_IFORCE_USB=y
CONFIG_JOYSTICK_IFORCE_232=y
CONFIG_JOYSTICK_WARRIOR=m
CONFIG_JOYSTICK_MAGELLAN=m
CONFIG_JOYSTICK_SPACEORB=m
CONFIG_JOYSTICK_SPACEBALL=m
CONFIG_JOYSTICK_STINGER=m
CONFIG_JOYSTICK_TWIDDLER=m
CONFIG_JOYSTICK_DB9=m
CONFIG_JOYSTICK_GAMECON=m
CONFIG_JOYSTICK_TURBOGRAFX=m
CONFIG_INPUT_JOYDUMP=m
CONFIG_INPUT_TOUCHSCREEN=y
CONFIG_TOUCHSCREEN_GUNZE=m
CONFIG_INPUT_MISC=y
CONFIG_INPUT_PCSPKR=y
CONFIG_INPUT_UINPUT=m

#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
CONFIG_SERIAL_NONSTANDARD=y
CONFIG_COMPUTONE=m
CONFIG_ROCKETPORT=m
CONFIG_CYCLADES=m
CONFIG_CYZ_INTR=y
CONFIG_DIGIEPCA=m
CONFIG_ESPSERIAL=m
CONFIG_MOXA_INTELLIO=m
CONFIG_MOXA_SMARTIO=m
CONFIG_ISI=m
CONFIG_SYNCLINK=m
CONFIG_SYNCLINKMP=m
CONFIG_N_HDLC=m
CONFIG_RISCOM8=m
CONFIG_SPECIALIX=m
# CONFIG_SPECIALIX_RTSCTS is not set
CONFIG_SX=m
CONFIG_RIO=m
CONFIG_RIO_OLDPCI=y
CONFIG_STALDRV=y
CONFIG_STALLION=m
CONFIG_ISTALLION=m

#
# Serial drivers
#
CONFIG_SERIAL_8250=m
CONFIG_SERIAL_8250_CS=m
CONFIG_SERIAL_8250_ACPI=y
CONFIG_SERIAL_8250_NR_UARTS=4
CONFIG_SERIAL_8250_EXTENDED=y
CONFIG_SERIAL_8250_MANY_PORTS=y
CONFIG_SERIAL_8250_SHARE_IRQ=y
CONFIG_SERIAL_8250_DETECT_IRQ=y
CONFIG_SERIAL_8250_MULTIPORT=y
CONFIG_SERIAL_8250_RSA=y

#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=m
CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256
CONFIG_PRINTER=m
CONFIG_LP_CONSOLE=y
CONFIG_PPDEV=m
CONFIG_TIPAR=m
CONFIG_QIC02_TAPE=m
CONFIG_QIC02_DYNCONF=y

#
# Setting runtime QIC-02 configuration is done with qic02conf #

# from the tpqic02-support package.  It is available at
#

# metalab.unc.edu or ftp://titus.cfw.com/pub/Linux/util/
#

#
# IPMI
#
CONFIG_IPMI_HANDLER=m
CONFIG_IPMI_PANIC_EVENT=y
CONFIG_IPMI_PANIC_STRING=y
CONFIG_IPMI_DEVICE_INTERFACE=m
CONFIG_IPMI_SI=m
CONFIG_IPMI_SMB=m
CONFIG_IPMI_WATCHDOG=m

#
# Watchdog Cards
#
CONFIG_WATCHDOG=y
# CONFIG_WATCHDOG_NOWAYOUT is not set

#
# Watchdog Device Drivers
#
CONFIG_SOFT_WATCHDOG=m
CONFIG_ACQUIRE_WDT=m
CONFIG_ADVANTECH_WDT=m
CONFIG_ALIM1535_WDT=m
CONFIG_ALIM7101_WDT=m
CONFIG_AMD7XX_TCO=m
CONFIG_SC520_WDT=m
CONFIG_EUROTECH_WDT=m
CONFIG_IB700_WDT=m
CONFIG_WAFER_WDT=m
CONFIG_I8XX_TCO=m
CONFIG_SC1200_WDT=m
CONFIG_SCx200_WDT=m
CONFIG_60XX_WDT=m
CONFIG_CPU5_WDT=m
CONFIG_W83627HF_WDT=m
CONFIG_W83877F_WDT=m
CONFIG_MACHZ_WDT=m

#
# ISA-based Watchdog Cards
#
CONFIG_PCWATCHDOG=m
CONFIG_MIXCOMWD=m
CONFIG_WDT=m
CONFIG_WDT_501=y
CONFIG_WDT_501_FAN=y

#
# PCI-based Watchdog Cards
#
CONFIG_PCIPCWATCHDOG=m
CONFIG_WDTPCI=m
CONFIG_WDT_501_PCI=y

#
# USB-based Watchdog Cards
#
CONFIG_USBPCWATCHDOG=m
CONFIG_HW_RANDOM=m
CONFIG_NVRAM=m
CONFIG_RTC=m
CONFIG_GEN_RTC=m
CONFIG_GEN_RTC_X=y
CONFIG_DTLK=m
CONFIG_R3964=m
CONFIG_APPLICOM=m
CONFIG_SONYPI=m

#
# Ftape, the floppy tape device driver
#
CONFIG_FTAPE=m
CONFIG_ZFTAPE=m
CONFIG_ZFT_DFLT_BLK_SZ=10240

#
# The compressor will be built as a module only!
#
CONFIG_ZFT_COMPRESSOR=m
CONFIG_FT_NR_BUFFERS=3
CONFIG_FT_PROC_FS=y
CONFIG_FT_NORMAL_DEBUG=y
# CONFIG_FT_FULL_DEBUG is not set
# CONFIG_FT_NO_TRACE is not set
# CONFIG_FT_NO_TRACE_AT_ALL is not set

#
# Hardware configuration
#
CONFIG_FT_STD_FDC=y
# CONFIG_FT_MACH2 is not set
# CONFIG_FT_PROBE_FC10 is not set
# CONFIG_FT_ALT_FDC is not set
CONFIG_FT_FDC_THR=8
CONFIG_FT_FDC_MAX_RATE=2000
CONFIG_FT_ALPHA_CLOCK=0
CONFIG_AGP=m
CONFIG_AGP_ALI=m
CONFIG_AGP_ATI=m
CONFIG_AGP_AMD=m
CONFIG_AGP_AMD64=m
CONFIG_AGP_INTEL=m
CONFIG_AGP_NVIDIA=m
CONFIG_AGP_SIS=m
CONFIG_AGP_SWORKS=m
CONFIG_AGP_VIA=m
CONFIG_AGP_EFFICEON=m
CONFIG_DRM=y
CONFIG_DRM_TDFX=m
CONFIG_DRM_GAMMA=m
CONFIG_DRM_R128=m
CONFIG_DRM_RADEON=m
CONFIG_DRM_I810=m
CONFIG_DRM_I830=m
CONFIG_DRM_MGA=m
CONFIG_DRM_SIS=m

#
# PCMCIA character devices
#
CONFIG_SYNCLINK_CS=m
CONFIG_MWAVE=m
CONFIG_SCx200_GPIO=m
CONFIG_RAW_DRIVER=m
CONFIG_MAX_RAW_DEVS=256
CONFIG_HANGCHECK_TIMER=m

#
# I2C support
#
CONFIG_I2C=m
CONFIG_I2C_CHARDEV=m

#
# I2C Algorithms
#
CONFIG_I2C_ALGOBIT=m
CONFIG_I2C_ALGOPCF=m

#
# I2C Hardware Bus support
#
CONFIG_I2C_ALI1535=m
CONFIG_I2C_ALI15X3=m
CONFIG_I2C_AMD756=m
CONFIG_I2C_AMD8111=m
CONFIG_I2C_ELEKTOR=m
CONFIG_I2C_ELV=m
CONFIG_I2C_I801=m
CONFIG_I2C_I810=m
CONFIG_I2C_ISA=m
CONFIG_I2C_NFORCE2=m
CONFIG_I2C_PHILIPSPAR=m
CONFIG_I2C_PARPORT=m
CONFIG_I2C_PARPORT_LIGHT=m
CONFIG_I2C_PIIX4=m
CONFIG_I2C_PROSAVAGE=m
CONFIG_I2C_SAVAGE4=m
CONFIG_SCx200_I2C=m
CONFIG_SCx200_I2C_SCL=12
CONFIG_SCx200_I2C_SDA=13
CONFIG_SCx200_ACB=m
CONFIG_I2C_SIS5595=m
CONFIG_I2C_SIS630=m
CONFIG_I2C_SIS96X=m
CONFIG_I2C_VELLEMAN=m
CONFIG_I2C_VIA=m
CONFIG_I2C_VIAPRO=m
CONFIG_I2C_VOODOO3=m

#
# Hardware Sensors Chip support
#
CONFIG_I2C_SENSOR=m
CONFIG_SENSORS_ADM1021=m
CONFIG_SENSORS_ASB100=m
CONFIG_SENSORS_FSCHER=m
CONFIG_SENSORS_GL518SM=m
CONFIG_SENSORS_IT87=m
CONFIG_SENSORS_LM75=m
CONFIG_SENSORS_LM78=m
CONFIG_SENSORS_LM80=m
CONFIG_SENSORS_LM83=m
CONFIG_SENSORS_LM85=m
CONFIG_SENSORS_LM90=m
CONFIG_SENSORS_VIA686A=m
CONFIG_SENSORS_W83781D=m
CONFIG_SENSORS_W83L785TS=m
CONFIG_SENSORS_W83627HF=m

#
# Other I2C Chip support
#
CONFIG_SENSORS_EEPROM=m
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_BUS is not set
# CONFIG_I2C_DEBUG_CHIP is not set

#
# Misc devices
#
CONFIG_IBM_ASM=m

#
# Multimedia devices
#
CONFIG_VIDEO_DEV=m

#
# Video For Linux
#

#
# Video Adapters
#
CONFIG_VIDEO_BT848=m
CONFIG_VIDEO_PMS=m
CONFIG_VIDEO_BWQCAM=m
CONFIG_VIDEO_CQCAM=m
CONFIG_VIDEO_W9966=m
CONFIG_VIDEO_CPIA=m
CONFIG_VIDEO_CPIA_PP=m
CONFIG_VIDEO_CPIA_USB=m
CONFIG_VIDEO_SAA5246A=m
CONFIG_VIDEO_SAA5249=m
CONFIG_TUNER_3036=m
CONFIG_VIDEO_STRADIS=m
CONFIG_VIDEO_ZORAN=m
CONFIG_VIDEO_ZORAN_BUZ=m
CONFIG_VIDEO_ZORAN_DC10=m
CONFIG_VIDEO_ZORAN_DC30=m
CONFIG_VIDEO_ZORAN_LML33=m
CONFIG_VIDEO_ZORAN_LML33R10=m
CONFIG_VIDEO_MEYE=m
CONFIG_VIDEO_SAA7134=m
CONFIG_VIDEO_MXB=m
CONFIG_VIDEO_DPC=m
CONFIG_VIDEO_HEXIUM_ORION=m
CONFIG_VIDEO_HEXIUM_GEMINI=m
CONFIG_VIDEO_CX88=m

#
# Radio Adapters
#
CONFIG_RADIO_CADET=m
CONFIG_RADIO_RTRACK=m
CONFIG_RADIO_RTRACK2=m
CONFIG_RADIO_AZTECH=m
CONFIG_RADIO_GEMTEK=m
CONFIG_RADIO_GEMTEK_PCI=m
CONFIG_RADIO_MAXIRADIO=m
CONFIG_RADIO_MAESTRO=m
CONFIG_RADIO_MIROPCM20=m
CONFIG_RADIO_MIROPCM20_RDS=m
CONFIG_RADIO_SF16FMI=m
CONFIG_RADIO_SF16FMR2=m
CONFIG_RADIO_TERRATEC=m
CONFIG_RADIO_TRUST=m
CONFIG_RADIO_TYPHOON=m
CONFIG_RADIO_TYPHOON_PROC_FS=y
CONFIG_RADIO_ZOLTRIX=m

#
# Digital Video Broadcasting Devices
#
CONFIG_DVB=y
CONFIG_DVB_CORE=m

#
# Supported Frontend Modules
#
CONFIG_DVB_TWINHAN_DST=m
CONFIG_DVB_STV0299=m
# CONFIG_DVB_SP887X is not set
CONFIG_DVB_ALPS_TDLB7=m
CONFIG_DVB_ALPS_TDMB7=m
CONFIG_DVB_ATMEL_AT76C651=m
CONFIG_DVB_CX24110=m
CONFIG_DVB_GRUNDIG_29504_491=m
CONFIG_DVB_GRUNDIG_29504_401=m
CONFIG_DVB_MT312=m
CONFIG_DVB_VES1820=m
CONFIG_DVB_VES1X93=m
# CONFIG_DVB_TDA1004X is not set
CONFIG_DVB_NXT6000=m

#
# Supported SAA7146 based PCI Adapters
#
CONFIG_DVB_AV7110=m
CONFIG_DVB_AV7110_OSD=y
CONFIG_DVB_BUDGET=m
CONFIG_DVB_BUDGET_CI=m
CONFIG_DVB_BUDGET_AV=m
CONFIG_DVB_BUDGET_PATCH=m

#
# Supported USB Adapters
#
CONFIG_DVB_TTUSB_BUDGET=m
CONFIG_DVB_TTUSB_DEC=m

#
# Supported FlexCopII (B2C2) Adapters
#
CONFIG_DVB_B2C2_SKYSTAR=m

#
# Supported BT878 Adapters
#
CONFIG_DVB_BT8XX=m
CONFIG_VIDEO_SAA7146=m
CONFIG_VIDEO_SAA7146_VV=m
CONFIG_VIDEO_VIDEOBUF=m
CONFIG_VIDEO_TUNER=m
CONFIG_VIDEO_BUF=m
CONFIG_VIDEO_BTCX=m
CONFIG_VIDEO_IR=m

#
# Graphics support
#
CONFIG_FB=y
CONFIG_FB_PM2=m
CONFIG_FB_PM2_FIFO_DISCONNECT=y
CONFIG_FB_CYBER2000=m
# CONFIG_FB_IMSTT is not set
CONFIG_FB_VGA16=m
CONFIG_FB_VESA=y
CONFIG_VIDEO_SELECT=y
CONFIG_FB_HGA=m
CONFIG_FB_RIVA=m
CONFIG_FB_I810=m
# CONFIG_FB_I810_GTF is not set
CONFIG_FB_MATROX=m
CONFIG_FB_MATROX_MILLENIUM=y
CONFIG_FB_MATROX_MYSTIQUE=y
CONFIG_FB_MATROX_G450=y
CONFIG_FB_MATROX_G100=y
CONFIG_FB_MATROX_I2C=m
CONFIG_FB_MATROX_MAVEN=m
CONFIG_FB_MATROX_MULTIHEAD=y
CONFIG_FB_RADEON_OLD=m
CONFIG_FB_RADEON=m
CONFIG_FB_RADEON_I2C=y
# CONFIG_FB_RADEON_DEBUG is not set
CONFIG_FB_ATY128=m
CONFIG_FB_ATY=m
CONFIG_FB_ATY_CT=y
CONFIG_FB_ATY_GX=y
CONFIG_FB_ATY_XL_INIT=y
CONFIG_FB_SIS=m
CONFIG_FB_SIS_300=y
CONFIG_FB_SIS_315=y
CONFIG_FB_NEOMAGIC=m
CONFIG_FB_KYRO=m
CONFIG_FB_3DFX=m
CONFIG_FB_VOODOO1=m
CONFIG_FB_TRIDENT=m
CONFIG_FB_VIRTUAL=m

#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
CONFIG_MDA_CONSOLE=m
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_PCI_CONSOLE=y
# CONFIG_FONTS is not set
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y

#
# Logo configuration
#
CONFIG_LOGO=y
CONFIG_LOGO_LINUX_MONO=y
CONFIG_LOGO_LINUX_VGA16=y
CONFIG_LOGO_LINUX_CLUT224=y

#
# 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=m
CONFIG_SND_OSSEMUL=y
CONFIG_SND_MIXER_OSS=m
CONFIG_SND_PCM_OSS=m
CONFIG_SND_SEQUENCER_OSS=y
CONFIG_SND_RTCTIMER=m
# CONFIG_SND_VERBOSE_PRINTK is not set
# CONFIG_SND_DEBUG is not set

#
# Generic devices
#
CONFIG_SND_MPU401_UART=m
CONFIG_SND_OPL3_LIB=m
CONFIG_SND_OPL4_LIB=m
CONFIG_SND_VX_LIB=m
CONFIG_SND_DUMMY=m
CONFIG_SND_VIRMIDI=m
CONFIG_SND_MTPAV=m
CONFIG_SND_SERIAL_U16550=m
CONFIG_SND_MPU401=m

#
# ISA devices
#
CONFIG_SND_AD1816A=m
CONFIG_SND_AD1848=m
CONFIG_SND_CS4231=m
CONFIG_SND_CS4232=m
CONFIG_SND_CS4236=m
CONFIG_SND_ES968=m
CONFIG_SND_ES1688=m
CONFIG_SND_ES18XX=m
CONFIG_SND_GUSCLASSIC=m
CONFIG_SND_GUSEXTREME=m
CONFIG_SND_GUSMAX=m
CONFIG_SND_INTERWAVE=m
CONFIG_SND_INTERWAVE_STB=m
CONFIG_SND_OPTI92X_AD1848=m
CONFIG_SND_OPTI92X_CS4231=m
CONFIG_SND_OPTI93X=m
CONFIG_SND_SB8=m
CONFIG_SND_SB16=m
CONFIG_SND_SBAWE=m
CONFIG_SND_SB16_CSP=y
CONFIG_SND_WAVEFRONT=m
CONFIG_SND_ALS100=m
CONFIG_SND_AZT2320=m
CONFIG_SND_CMI8330=m
CONFIG_SND_DT019X=m
CONFIG_SND_OPL3SA2=m
CONFIG_SND_SGALAXY=m
CONFIG_SND_SSCAPE=m

#
# PCI devices
#
CONFIG_SND_AC97_CODEC=m
CONFIG_SND_ALI5451=m
CONFIG_SND_ATIIXP=m
CONFIG_SND_AU8810=m
CONFIG_SND_AU8820=m
CONFIG_SND_AU8830=m
CONFIG_SND_AZT3328=m
CONFIG_SND_BT87X=m
CONFIG_SND_CS46XX=m
CONFIG_SND_CS46XX_NEW_DSP=y
CONFIG_SND_CS4281=m
CONFIG_SND_EMU10K1=m
CONFIG_SND_KORG1212=m
CONFIG_SND_MIXART=m
CONFIG_SND_NM256=m
CONFIG_SND_RME32=m
CONFIG_SND_RME96=m
CONFIG_SND_RME9652=m
CONFIG_SND_HDSP=m
CONFIG_SND_TRIDENT=m
CONFIG_SND_YMFPCI=m
CONFIG_SND_ALS4000=m
CONFIG_SND_CMIPCI=m
CONFIG_SND_ENS1370=m
CONFIG_SND_ENS1371=m
CONFIG_SND_ES1938=m
CONFIG_SND_ES1968=m
CONFIG_SND_MAESTRO3=m
CONFIG_SND_FM801=m
CONFIG_SND_FM801_TEA575X=m
CONFIG_SND_ICE1712=m
CONFIG_SND_ICE1724=m
CONFIG_SND_INTEL8X0=m
CONFIG_SND_INTEL8X0M=m
CONFIG_SND_SONICVIBES=m
CONFIG_SND_VIA82XX=m
CONFIG_SND_VX222=m

#
# ALSA USB devices
#
CONFIG_SND_USB_AUDIO=m

#
# PCMCIA devices
#
CONFIG_SND_VXPOCKET=m
CONFIG_SND_VXP440=m
CONFIG_SND_PDAUDIOCF=m

#
# Open Sound System
#
CONFIG_SOUND_PRIME=m
CONFIG_SOUND_BT878=m
CONFIG_SOUND_CMPCI=m
CONFIG_SOUND_CMPCI_FM=y
CONFIG_SOUND_CMPCI_FMIO=0x388
CONFIG_SOUND_CMPCI_MIDI=y
CONFIG_SOUND_CMPCI_MPUIO=0x330
CONFIG_SOUND_CMPCI_JOYSTICK=y
CONFIG_SOUND_CMPCI_CM8738=y
CONFIG_SOUND_CMPCI_SPDIFINVERSE=y
CONFIG_SOUND_CMPCI_SPDIFLOOP=y
CONFIG_SOUND_CMPCI_SPEAKERS=2
CONFIG_SOUND_EMU10K1=m
CONFIG_MIDI_EMU10K1=y
CONFIG_SOUND_FUSION=m
CONFIG_SOUND_CS4281=m
CONFIG_SOUND_ES1370=m
CONFIG_SOUND_ES1371=m
CONFIG_SOUND_ESSSOLO1=m
CONFIG_SOUND_MAESTRO=m
CONFIG_SOUND_MAESTRO3=m
CONFIG_SOUND_ICH=m
CONFIG_SOUND_SONICVIBES=m
CONFIG_SOUND_TRIDENT=m
# CONFIG_SOUND_MSNDCLAS is not set
# CONFIG_SOUND_MSNDPIN is not set
CONFIG_SOUND_VIA82CXXX=m
CONFIG_MIDI_VIA82CXXX=y
CONFIG_SOUND_OSS=m
# CONFIG_SOUND_TRACEINIT is not set
# CONFIG_SOUND_DMAP is not set
CONFIG_SOUND_AD1816=m
CONFIG_SOUND_AD1889=m
CONFIG_SOUND_SGALAXY=m
CONFIG_SOUND_ADLIB=m
CONFIG_SOUND_ACI_MIXER=m
CONFIG_SOUND_CS4232=m
CONFIG_SOUND_SSCAPE=m
CONFIG_SOUND_GUS=m
CONFIG_SOUND_GUS16=y
CONFIG_SOUND_GUSMAX=y
CONFIG_SOUND_VMIDI=m
CONFIG_SOUND_TRIX=m
CONFIG_SOUND_MSS=m
CONFIG_SOUND_MPU401=m
CONFIG_SOUND_NM256=m
CONFIG_SOUND_MAD16=m
CONFIG_MAD16_OLDCARD=y
CONFIG_SOUND_PAS=m
CONFIG_SOUND_PSS=m
CONFIG_PSS_MIXER=y
CONFIG_SOUND_SB=m
CONFIG_SOUND_AWE32_SYNTH=m
CONFIG_SOUND_WAVEFRONT=m
CONFIG_SOUND_MAUI=m
CONFIG_SOUND_YM3812=m
CONFIG_SOUND_OPL3SA1=m
CONFIG_SOUND_OPL3SA2=m
CONFIG_SOUND_YMFPCI=m
CONFIG_SOUND_YMFPCI_LEGACY=y
CONFIG_SOUND_UART6850=m
CONFIG_SOUND_AEDSP16=m
CONFIG_SC6600=y
CONFIG_SC6600_JOY=y
CONFIG_SC6600_CDROM=4
CONFIG_SC6600_CDROMBASE=0x0
# CONFIG_AEDSP16_MSS is not set
CONFIG_AEDSP16_SBPRO=y
CONFIG_AEDSP16_MPU401=y
CONFIG_SOUND_TVMIXER=m
CONFIG_SOUND_KAHLUA=m
CONFIG_SOUND_ALI5455=m
CONFIG_SOUND_FORTE=m
CONFIG_SOUND_RME96XX=m
CONFIG_SOUND_AD1980=m

#
# USB support
#
CONFIG_USB=m
# CONFIG_USB_DEBUG is not set

#
# Miscellaneous USB options
#
CONFIG_USB_DEVICEFS=y
CONFIG_USB_BANDWIDTH=y
CONFIG_USB_DYNAMIC_MINORS=y

#
# USB Host Controller Drivers
#
CONFIG_USB_EHCI_HCD=m
CONFIG_USB_EHCI_SPLIT_ISO=y
CONFIG_USB_OHCI_HCD=m
CONFIG_USB_UHCI_HCD=m

#
# USB Device Class drivers
#
CONFIG_USB_AUDIO=m

#
# USB Bluetooth TTY can only be used with disabled Bluetooth subsystem #
CONFIG_USB_MIDI=m
CONFIG_USB_ACM=m
CONFIG_USB_PRINTER=m
CONFIG_USB_STORAGE=m
# CONFIG_USB_STORAGE_DEBUG is not set CONFIG_USB_STORAGE_DATAFAB=y
CONFIG_USB_STORAGE_FREECOM=y
CONFIG_USB_STORAGE_ISD200=y
CONFIG_USB_STORAGE_DPCM=y
CONFIG_USB_STORAGE_HP8200e=y
CONFIG_USB_STORAGE_SDDR09=y
CONFIG_USB_STORAGE_SDDR55=y
CONFIG_USB_STORAGE_JUMPSHOT=y

#
# USB Human Interface Devices (HID)
#
CONFIG_USB_HID=m
CONFIG_USB_HIDINPUT=y
CONFIG_HID_FF=y
CONFIG_HID_PID=y
CONFIG_LOGITECH_FF=y
CONFIG_THRUSTMASTER_FF=y
CONFIG_USB_HIDDEV=y

#
# USB HID Boot Protocol drivers
#
CONFIG_USB_KBD=m
CONFIG_USB_MOUSE=m
CONFIG_USB_AIPTEK=m
CONFIG_USB_WACOM=m
CONFIG_USB_KBTAB=m
CONFIG_USB_POWERMATE=m
CONFIG_USB_MTOUCH=m
CONFIG_USB_XPAD=m
CONFIG_USB_ATI_REMOTE=m

#
# USB Imaging devices
#
CONFIG_USB_MDC800=m
CONFIG_USB_MICROTEK=m
CONFIG_USB_HPUSBSCSI=m

#
# USB Multimedia devices
#
CONFIG_USB_DABUSB=m
CONFIG_USB_VICAM=m
CONFIG_USB_DSBR=m
CONFIG_USB_IBMCAM=m
CONFIG_USB_KONICAWC=m
CONFIG_USB_OV511=m
CONFIG_USB_PWC=m
CONFIG_USB_SE401=m
CONFIG_USB_STV680=m
CONFIG_USB_W9968CF=m

#
# USB Network adaptors
#
CONFIG_USB_CATC=m
CONFIG_USB_KAWETH=m
CONFIG_USB_PEGASUS=m
CONFIG_USB_RTL8150=m
CONFIG_USB_USBNET=m

#
# USB Host-to-Host Cables
#
CONFIG_USB_ALI_M5632=y
CONFIG_USB_AN2720=y
CONFIG_USB_BELKIN=y
CONFIG_USB_GENESYS=y
CONFIG_USB_NET1080=y
CONFIG_USB_PL2301=y

#
# Intelligent USB Devices/Gadgets
#
CONFIG_USB_ARMLINUX=y
CONFIG_USB_EPSON2888=y
CONFIG_USB_ZAURUS=y
CONFIG_USB_CDCETHER=y

#
# USB Network Adapters
#
CONFIG_USB_AX8817X=y

#
# USB port drivers
#
CONFIG_USB_USS720=m

#
# USB Serial Converter support
#
CONFIG_USB_SERIAL=m
CONFIG_USB_SERIAL_GENERIC=y
CONFIG_USB_SERIAL_BELKIN=m
CONFIG_USB_SERIAL_WHITEHEAT=m
CONFIG_USB_SERIAL_DIGI_ACCELEPORT=m
CONFIG_USB_SERIAL_EMPEG=m
CONFIG_USB_SERIAL_FTDI_SIO=m
CONFIG_USB_SERIAL_VISOR=m
CONFIG_USB_SERIAL_IPAQ=m
CONFIG_USB_SERIAL_IR=m
CONFIG_USB_SERIAL_EDGEPORT=m
CONFIG_USB_SERIAL_EDGEPORT_TI=m
CONFIG_USB_SERIAL_KEYSPAN_PDA=m
CONFIG_USB_SERIAL_KEYSPAN=m
CONFIG_USB_SERIAL_KEYSPAN_MPR=y
CONFIG_USB_SERIAL_KEYSPAN_USA28=y
CONFIG_USB_SERIAL_KEYSPAN_USA28X=y
CONFIG_USB_SERIAL_KEYSPAN_USA28XA=y
CONFIG_USB_SERIAL_KEYSPAN_USA28XB=y
CONFIG_USB_SERIAL_KEYSPAN_USA19=y
CONFIG_USB_SERIAL_KEYSPAN_USA18X=y
CONFIG_USB_SERIAL_KEYSPAN_USA19W=y
CONFIG_USB_SERIAL_KEYSPAN_USA19QW=y
CONFIG_USB_SERIAL_KEYSPAN_USA19QI=y
CONFIG_USB_SERIAL_KEYSPAN_USA49W=y
CONFIG_USB_SERIAL_KEYSPAN_USA49WLC=y
CONFIG_USB_SERIAL_KLSI=m
CONFIG_USB_SERIAL_KOBIL_SCT=m
CONFIG_USB_SERIAL_MCT_U232=m
CONFIG_USB_SERIAL_PL2303=m
CONFIG_USB_SERIAL_SAFE=m
CONFIG_USB_SERIAL_SAFE_PADDED=y
CONFIG_USB_SERIAL_CYBERJACK=m
CONFIG_USB_SERIAL_XIRCOM=m
CONFIG_USB_SERIAL_OMNINET=m
CONFIG_USB_EZUSB=y

#
# USB Miscellaneous drivers
#
CONFIG_USB_EMI62=m
CONFIG_USB_EMI26=m
CONFIG_USB_TIGL=m
CONFIG_USB_AUERSWALD=m
CONFIG_USB_RIO500=m
CONFIG_USB_LEGOTOWER=m
CONFIG_USB_LCD=m
CONFIG_USB_LED=m
CONFIG_USB_SPEEDTOUCH=m
CONFIG_USB_TEST=m

#
# USB Gadget Support
#
CONFIG_USB_GADGET=m
CONFIG_USB_GADGET_NET2280=y
CONFIG_USB_NET2280=m
# CONFIG_USB_GADGET_PXA2XX is not set
# CONFIG_USB_GADGET_GOKU is not set
# CONFIG_USB_GADGET_SA1100 is not set
CONFIG_USB_GADGET_DUALSPEED=y
CONFIG_USB_ZERO=m
CONFIG_USB_ETH=m
CONFIG_USB_GADGETFS=m
CONFIG_USB_FILE_STORAGE=m
# CONFIG_USB_FILE_STORAGE_TEST is not set
CONFIG_USB_G_SERIAL=m

#
# File systems
#
CONFIG_EXT2_FS=m
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
CONFIG_EXT2_FS_SECURITY=y
CONFIG_EXT3_FS=m
CONFIG_EXT3_FS_XATTR=y
CONFIG_EXT3_FS_POSIX_ACL=y
CONFIG_EXT3_FS_SECURITY=y
CONFIG_JBD=m
# CONFIG_JBD_DEBUG is not set
CONFIG_FS_MBCACHE=m
CONFIG_REISERFS_FS=y
# CONFIG_REISERFS_CHECK is not set
CONFIG_REISERFS_PROC_INFO=y
CONFIG_JFS_FS=m
CONFIG_JFS_POSIX_ACL=y
# CONFIG_JFS_DEBUG is not set
CONFIG_JFS_STATISTICS=y
CONFIG_FS_POSIX_ACL=y
CONFIG_XFS_FS=m
CONFIG_XFS_RT=y
CONFIG_XFS_QUOTA=y
CONFIG_XFS_SECURITY=y
CONFIG_XFS_POSIX_ACL=y
CONFIG_MINIX_FS=m
CONFIG_ROMFS_FS=m
CONFIG_QUOTA=y
CONFIG_QFMT_V1=m
CONFIG_QFMT_V2=m
CONFIG_QUOTACTL=y
CONFIG_AUTOFS_FS=m
CONFIG_AUTOFS4_FS=m

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

#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=m
CONFIG_MSDOS_FS=m
CONFIG_VFAT_FS=m
CONFIG_NTFS_FS=m
# CONFIG_NTFS_DEBUG is not set
CONFIG_NTFS_RW=y

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_SYSFS=y
# CONFIG_DEVFS_FS is not set
CONFIG_DEVPTS_FS_XATTR=y
CONFIG_DEVPTS_FS_SECURITY=y
CONFIG_TMPFS=y
CONFIG_HUGETLBFS=y
CONFIG_HUGETLB_PAGE=y
CONFIG_RAMFS=y

#
# Miscellaneous filesystems
#
CONFIG_ADFS_FS=m
# CONFIG_ADFS_FS_RW is not set
CONFIG_AFFS_FS=m
CONFIG_HFS_FS=m
CONFIG_HFSPLUS_FS=m
CONFIG_BEFS_FS=m
# CONFIG_BEFS_DEBUG is not set
CONFIG_BFS_FS=m
CONFIG_EFS_FS=m
CONFIG_JFFS_FS=m
CONFIG_JFFS_FS_VERBOSE=0
CONFIG_JFFS2_FS=m
CONFIG_JFFS2_FS_DEBUG=0
CONFIG_JFFS2_FS_NAND=y
CONFIG_CRAMFS=m
CONFIG_VXFS_FS=m
CONFIG_HPFS_FS=m
CONFIG_QNX4FS_FS=m
# CONFIG_QNX4FS_RW is not set
CONFIG_SYSV_FS=m
CONFIG_UFS_FS=m
# CONFIG_UFS_FS_WRITE is not set

#
# Network File Systems
#
CONFIG_NFS_FS=m
CONFIG_NFS_V3=y
CONFIG_NFS_V4=y
CONFIG_NFS_DIRECTIO=y
CONFIG_NFSD=m
CONFIG_NFSD_V3=y
CONFIG_NFSD_V4=y
CONFIG_NFSD_TCP=y
CONFIG_LOCKD=m
CONFIG_LOCKD_V4=y
CONFIG_EXPORTFS=m
CONFIG_SUNRPC=m
CONFIG_SUNRPC_GSS=m
CONFIG_RPCSEC_GSS_KRB5=m
CONFIG_SMB_FS=m
CONFIG_SMB_NLS_DEFAULT=y
CONFIG_SMB_NLS_REMOTE="cp850"
CONFIG_CIFS=m
CONFIG_NCP_FS=m
CONFIG_NCPFS_PACKET_SIGNING=y
CONFIG_NCPFS_IOCTL_LOCKING=y
CONFIG_NCPFS_STRONG=y
CONFIG_NCPFS_NFS_NS=y
CONFIG_NCPFS_OS2_NS=y
CONFIG_NCPFS_SMALLDOS=y
CONFIG_NCPFS_NLS=y
CONFIG_NCPFS_EXTRAS=y
CONFIG_CODA_FS=m
# CONFIG_CODA_FS_OLD_API is not set
CONFIG_AFS_FS=m
CONFIG_RXRPC=m

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

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

#
# Profiling support
#
CONFIG_PROFILING=y
CONFIG_OPROFILE=m

#
# Kernel hacking
#
# CONFIG_DEBUG_KERNEL is not set
CONFIG_EARLY_PRINTK=y
CONFIG_DEBUG_SPINLOCK_SLEEP=y
# CONFIG_FRAME_POINTER is not set
# CONFIG_4KSTACKS is not set
CONFIG_X86_FIND_SMP_CONFIG=y
CONFIG_X86_MPPARSE=y

#
# Security options
#
CONFIG_SECURITY=y
CONFIG_SECURITY_NETWORK=y
CONFIG_SECURITY_CAPABILITIES=m
CONFIG_SECURITY_ROOTPLUG=m
CONFIG_SECURITY_SELINUX=y
CONFIG_SECURITY_SELINUX_BOOTPARAM=y
CONFIG_SECURITY_SELINUX_DEVELOP=y
CONFIG_SECURITY_SELINUX_MLS=y

#
# Cryptographic options
#
CONFIG_CRYPTO=y
CONFIG_CRYPTO_HMAC=y
CONFIG_CRYPTO_NULL=m
CONFIG_CRYPTO_MD4=m
CONFIG_CRYPTO_MD5=y
CONFIG_CRYPTO_SHA1=m
CONFIG_CRYPTO_SHA256=m
CONFIG_CRYPTO_SHA512=m
CONFIG_CRYPTO_DES=m
CONFIG_CRYPTO_BLOWFISH=m
CONFIG_CRYPTO_TWOFISH=m
CONFIG_CRYPTO_SERPENT=m
CONFIG_CRYPTO_AES=m
CONFIG_CRYPTO_CAST5=m
CONFIG_CRYPTO_CAST6=m
CONFIG_CRYPTO_ARC4=m
CONFIG_CRYPTO_DEFLATE=m
CONFIG_CRYPTO_TEST=m

#
# Library routines
#
CONFIG_CRC32=m
CONFIG_ZLIB_INFLATE=m
CONFIG_ZLIB_DEFLATE=m
CONFIG_X86_BIOS_REBOOT=y
CONFIG_PC=y

Thomas Schlichter

2004-03-15 21:09 UTC #9 lore raw

Quoted 32 lines · On Monday, March 15. 2004 21:57, I wrote:

Hi,
with 2.6.4-mm2 I get following badness on boot:
Badness in as_insert_request at drivers/block/as-iosched.c:1513
Call Trace:
 [<c022e326>] as_insert_request+0x166/0x190
 [<c0225af8>] __elv_add_request+0x28/0x60
 [<c0228b9b>] __make_request+0x47b/0x540
 [<c0228d75>] generic_make_request+0x115/0x1d0
 [<c011efd0>] autoremove_wake_function+0x0/0x40
 [<c0228e80>] submit_bio+0x50/0xf0
 [<c0162f58>] __bio_add_page+0x88/0x110
 [<c016300c>] bio_add_page+0x2c/0x40
 [<c013be4f>] submit+0x9f/0xf0
 [<c03aa14a>] check_sig+0x1a/0x70
 [<c03aa4b6>] read_suspend_image+0x6/0x60
 [<c03aa565>] pmdisk_read+0x55/0x70
 [<c013b1a5>] pm_resume+0x15/0x90
 [<c039c7a3>] do_initcalls+0x23/0xc0
 [<c0103090>] init+0x0/0x150
 [<c01030c5>] init+0x35/0x150
 [<c0105288>] kernel_thread_helper+0x0/0x18
 [<c010528d>] kernel_thread_helper+0x5/0x18
After that one I get many badnesses in line 977 of the same file. I commented out that WARN_ON(..) to be able to capture the badness above. The message before the badness is:
PM: Reading pmdisk image.
After the badness following message is printed:
PM: Resume from disk failed.

Quoted 3 lines

So there seems to be a conflict between PM-resume (btw, I did not use suspend to disk) and as-iosched. There is no problem if I use "elevator=cfq", "elevator=deadline" or "elevator=noop".

Now I verified that "pmdisk=off" also removes the badnesses...

Regards
Thomas

Andrew Morton

author

2004-03-15 21:17 UTC #10 lore raw

In reply to Thomas Schlichter

Quoted 4 lines · Thomas Schlichter

ith 2.6.4-mm2 I get following badness on boot:
Badness in as_insert_request at drivers/block/as-iosched.c:1513

Quoted 8 lines

Call Trace:
 [<c022e326>] as_insert_request+0x166/0x190
 [<c0225af8>] __elv_add_request+0x28/0x60
 [<c0228b9b>] __make_request+0x47b/0x540
 [<c0228d75>] generic_make_request+0x115/0x1d0
 [<c011efd0>] autoremove_wake_function+0x0/0x40
 [<c0228e80>] submit_bio+0x50/0xf0
 [<c0162f58>] __bio_add_page+0x88/0x110

Someone got his bitmasks and bitshifts mixed up again ;)

 25-akpm/include/linux/bio.h   |    1 +
 25-akpm/include/linux/fs.h    |    4 ++--
 25-akpm/kernel/power/pmdisk.c |    2 +-
 drivers/md/md.c               |    0 
 4 files changed, 4 insertions(+), 3 deletions(-)

diff -puN drivers/md/md.c~per-backing_dev-unplugging-BIO_RW_SYNC-fix drivers/md/md.c

include/linux/bio.h renamed from include/linux/bio.h~per-backing_dev-unplugging-BIO_RW_SYNC-fix +1 -0

diff -puN include/linux/bio.h~per-backing_dev-unplugging-BIO_RW_SYNC-fix include/linux/bio.h
@@ -119,6 +119,7 @@ struct bio {
  * bit 1 -- rw-ahead when set
  * bit 2 -- barrier
  * bit 3 -- fail fast, don't want low level driver retries
+ * bit 4 -- synchronous I/O hint: the block layer will unplug immediately
  */
 #define BIO_RW		0
 #define BIO_RW_AHEAD	1

include/linux/fs.h renamed from include/linux/fs.h~per-backing_dev-unplugging-BIO_RW_SYNC-fix +2 -2

diff -puN include/linux/fs.h~per-backing_dev-unplugging-BIO_RW_SYNC-fix include/linux/fs.h
@@ -83,8 +83,8 @@ extern int leases_enable, dir_notify_ena
 #define WRITE 1
 #define READA 2		/* read-ahead  - don't block if no resources */
 #define SPECIAL 4	/* For non-blockdevice requests in request queue */
-#define READ_SYNC	(READ | BIO_RW_SYNC)
-#define WRITE_SYNC	(WRITE | BIO_RW_SYNC)
+#define READ_SYNC	(READ | (1 << BIO_RW_SYNC))
+#define WRITE_SYNC	(WRITE | (1 << BIO_RW_SYNC))
 
 #define SEL_IN		1
 #define SEL_OUT		2

kernel/power/pmdisk.c renamed from kernel/power/pmdisk.c~per-backing_dev-unplugging-BIO_RW_SYNC-fix +1 -1

diff -puN kernel/power/pmdisk.c~per-backing_dev-unplugging-BIO_RW_SYNC-fix kernel/power/pmdisk.c
@@ -897,7 +897,7 @@ static int submit(int rw, pgoff_t page_o
 	if (rw == WRITE)
 		bio_set_pages_dirty(bio);
 	start_io();
-	submit_bio(rw|BIO_RW_SYNC,bio);
+	submit_bio(rw | (1 << BIO_RW_SYNC), bio);
 	wait_io();
  Done:
 	bio_put(bio);

Jens Axboe

2004-03-15 21:19 UTC #11 lore raw

Quoted 14 lines · Andrew Morton

Quoted 4 lines · Thomas Schlichter
ith 2.6.4-mm2 I get following badness on boot:
Badness in as_insert_request at drivers/block/as-iosched.c:1513
Quoted 8 lines
Call Trace:
 [<c022e326>] as_insert_request+0x166/0x190
 [<c0225af8>] __elv_add_request+0x28/0x60
 [<c0228b9b>] __make_request+0x47b/0x540
 [<c0228d75>] generic_make_request+0x115/0x1d0
 [<c011efd0>] autoremove_wake_function+0x0/0x40
 [<c0228e80>] submit_bio+0x50/0xf0
 [<c0162f58>] __bio_add_page+0x88/0x110

Quoted 1 line

Someone got his bitmasks and bitshifts mixed up again ;)

Fudge, thanks Andrew.

Signature · 1 line

Jens Axboe

Thomas Schlichter

2004-03-15 22:41 UTC #12 lore raw

In reply to Andrew Morton

Am Montag, 15. März 2004 22:18 schrieb Andrew Morton:

Quoted 13 lines

Quoted 11 lines · Thomas Schlichter
ith 2.6.4-mm2 I get following badness on boot:
Badness in as_insert_request at drivers/block/as-iosched.c:1513
Call Trace:
 [<c022e326>] as_insert_request+0x166/0x190
 [<c0225af8>] __elv_add_request+0x28/0x60
 [<c0228b9b>] __make_request+0x47b/0x540
 [<c0228d75>] generic_make_request+0x115/0x1d0
 [<c011efd0>] autoremove_wake_function+0x0/0x40
 [<c0228e80>] submit_bio+0x50/0xf0
 [<c0162f58>] __bio_add_page+0x88/0x110

Quoted 1 line

Someone got his bitmasks and bitshifts mixed up again ;)

[patch snipped]

Yeah, this fixes it...
Thanks!

Regards
Thomas

Jesse Barnes

2004-03-15 22:14 UTC #13 lore raw

In reply to Andrew Morton

Quoted 4 lines · Andrew Morton

- Added the new per-address_space block unplugging code. This is designed to reduce the locking contention against the global plug list's lock and it also allows us to avoid unplugging all the queues in the machine when we want just a single queue to kick off its I/O.

Looks pretty good, same benchmark as last time (though hopefully the profiles look a little nicer--sorry David, I wasn't able to get qprof working today).

10 qla2200 fc controllers, 64 cpus, 112 disks

-------------------------------------
2.6.4 ~43252 I/Os per second

[root@revenue sio]# readprofile -p /root/profile.out -m /root/System.map | sort -nr | head -20
926930 total 0.1601

508304 snidle                                   1323.7083
170017 cpu_idle                                 354.2021
148308 default_idle                             4634.6250
 21765 blk_run_queues                            37.7865
 16914 __make_request                             4.6775
 16897 scsi_request_fn                            8.9497
  6478 scsi_end_request                          11.9081
  6111 schedule                                   1.1233
  4750 dio_bio_end_io                            12.3698
  3749 qla2x00_start_scsi                         1.5215
  3475 qla2x00_queuecommand                       0.8484
  3062 sn_dma_flush                               4.5565
  1313 scsi_dispatch_cmd                          0.9118
   997 scsi_device_unbusy                         2.3966
   917 dio_await_one                              1.5920
   910 get_request                                0.5687
   890 __end_that_request_first                   0.8428
   873 mempool_alloc                              0.9094
   834 __mod_timer                                0.8145

vmstat:
procs memory swap io system cpu

 r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id wa
 4 113      0 252927360  12112   4288    0    0 14649     0 73289 56926  0  7 45 48
 3 114      0 252927424  12112   4288    0    0 23187     1 75524 91055  0 13  1 85
 5 111      0 252927424  12112   4288    0    0 23142     0 75440 90893  0 13  0 87
 5 112      0 252927552  12112   4288    0    0 23581     0 75750 92907  0 12  0 88
 9 108      0 252927552  12112   4288    0    0 23224     0 75698 91226  0 14  0 86
 3 114      0 252927680  12112   4288    0    0 23474     0 75912 92509  0 12  1 87
 2 114      0 252927680  12112   4288    0    0 22651     0 75092 88730  0 15  0 85
 7 114      0 252927872  12112   4288    0    0 22915     0 75298 89525  0 15  0 84
 4 112      0 252927872  12112   4288    0    0 23106     0 75348 90598  0 15  0 85

0 0 0 252951488 12112 20688 0 0 21193 0 89210 85060 0 17 5 79

-------------------------------------
2.6.4-mm2 ~46655 I/Os per second

[root@revenue sio]# readprofile -p /root/profile.out -m /root/System.map | sort -nr | head -20
935122 total 0.1656

543734 snidle                                   1415.9740
182199 cpu_idle                                 379.5813
158268 default_idle                             4945.8750
  6850 scsi_request_fn                            3.6282
  6067 scsi_end_request                          11.1526
  4695 __make_request                             1.3338
  4347 dio_bio_end_io                            12.3494
  3782 schedule                                   0.6677
  3323 sn_dma_flush                               4.9449
  3314 pci_cacheline_size                         4.5027
  1753 sd_rw_intr                                 1.5652
  1313 dio_await_one                              1.7840
  1259 scsi_device_unbusy                         3.0264
  1201 scsi_dispatch_cmd                          0.8340
   847 sd_open                                    1.2031
   671 __mod_timer                                0.5825
   661 __end_that_request_first                   0.6259
   593 mempool_free                               1.1582
   568 scsi_io_completion                         0.2863

vmstat:
procs memory swap io system cpu

 r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id wa
 2 112      0 253452832  12128  69872    0    0  7703    17 77455 25398  0  2 94  4
 4 112      0 253452640  12128  69872    0    0 24694     0 76935 84163  0  8 79 13
 2 114      0 253452512  12128  69872    0    0 24744     8 76523 86890  0  8 71 21
 6 110      0 253452512  12128  69872    0    0 24614     0 76418 86889  0  8 70 22
 3 113      0 253452448  12128  69872    0    0 24652     0 76427 87022  0  8 68 24
 4 112      0 253452640  12128  69872    0    0 24504     0 76552 87179  0  8 67 25
 2 114      0 253452640  12128  69872    0    0 24540     0 76559 86955  0  8 66 27
 5 111      0 253452640  12128  69872    0    0 24525    17 76521 87415  0  8 66 26
 7 109      0 253452640  12128  69872    0    0 24528     0 76526 87092  0  8 66 27
 2 114      0 253452768  12128  69872    0    0 24488     0 76619 87209  0  8 66 27

0 0 0 253498848 12128 69872 0 0 5789 0 84614 21581 0 2 91 6

Daniel McNeil

2004-03-16 18:32 UTC #14 lore raw

In reply to Andrew Morton

Andrew,

I re-ran six copies of the direct_read_under test on an 8-proc machine last night. All six tests saw uninitialized data.

Daniel

Chris Mason

2004-03-16 21:56 UTC #15 lore raw

Quoted 4 lines · Daniel McNeil

Andrew,
I re-ran six copies of the direct_read_under test on an 8-proc machine last night. All six tests saw uninitialized data.

It is possible to trigger mpage_writepages twice at the same time, right? Say once from sync_sb_inodes and once from filemap_fdatawrite? I'm assuming Daniel is hitting the same bug he reported before, a race between ll_rw_block from ext3 data=ordered and sychronous writeback from fsync or O_DIRECT.

Picture one proc in mpage_writepages with wbc->sync_mode == WBC_SYNC_NONE, and a second proc with sync_mod = WBC_SYNC_ALL. The file in question has one dirty page and that one page is being written by kjournald in a data=ordered flush.

The sync none proc gets to a page with a locked buffer being written by ll_rw_block. It locks the page, calls test_clear_page_dirty, and then calls writepage.

The sync all proc now calls pagevec_lookup_tag(PAGECACHE_TAG_DIRTY), no pages are returned, so it returns.

The sync none proc gets to the buffer_locked check in __block_write_full_page and properly retags the page with PAGECACHE_TAG_DIRTY, but it's too late. The sync all proc has already skipped the page.

That's my theory anyway...

-chris

Andrew Morton

author

2004-03-16 23:19 UTC #16 lore raw

Quoted 9 lines · Chris Mason

Quoted 4 lines · Daniel McNeil
Andrew,
I re-ran six copies of the direct_read_under test on an 8-proc machine last night. All six tests saw uninitialized data.
It is possible to trigger mpage_writepages twice at the same time, right?

Yes.

Quoted 4 lines

Say once from sync_sb_inodes and once from filemap_fdatawrite?
I'm assuming Daniel is hitting the same bug he reported before, a race between ll_rw_block from ext3 data=ordered and sychronous writeback from fsync or O_DIRECT.

OK, that can happen. Daniel had a fixlet for that and I assume he's retrying that.

Not only can it happen with ext3, but also with any random filesystem which does ll_rw_blk() of a random metadata block. sync_blockdev() can miss the associated page. Conceivably this could leave I/O in flight after umount.

I'm thinking that the right thing to do here is to change submit_bh() callers and ll_rw_block() to run set_page_writeback(bh->b_page) when they start the buffer writeout and to do the run-around-the-buffer_heads thing at I/O completion. Ho hum, that'll take a bit of work but at least it kills off some exceptionalities.

Andrew Morton

author

2004-03-16 23:26 UTC #17 lore raw

Quoted 5 lines · Andrew Morton

I'm thinking that the right thing to do here is to change submit_bh() callers and ll_rw_block() to run set_page_writeback(bh->b_page) when they start the buffer writeout and to do the run-around-the-buffer_heads thing at I/O completion.

A page may have a mix of writeback and dirty+non-writeback buffers. It appears that the page-level writeback code will handle this correctly. But it requires that the page lock be held when we run set_page_writeback(), so that tears that. hmm.

Andrew Morton

author

2004-03-16 23:37 UTC #18 lore raw

Quoted 8 lines · Andrew Morton

Quoted 5 lines · Andrew Morton
I'm thinking that the right thing to do here is to change submit_bh() callers and ll_rw_block() to run set_page_writeback(bh->b_page) when they start the buffer writeout and to do the run-around-the-buffer_heads thing at I/O completion.

Quoted 4 lines

A page may have a mix of writeback and dirty+non-writeback buffers. It appears that the page-level writeback code will handle this correctly. But it requires that the page lock be held when we run set_page_writeback(), so that tears that. hmm.

I'll work this out yet.

We change the PageWriteback() predicate to go in and see if any of the buffer_heads are under I/O too. And we change wait_on_page_writeback() to also wait on any buffer_heads.

That means two new silly address_space ops. Or a new page flag which means "the thing at ->private is buffer_heads". Probably the latter.

Daniel McNeil

2004-03-17 00:10 UTC #19 lore raw

Quoted 14 lines · Andrew Morton

Quoted 8 lines · Andrew Morton
Quoted 5 lines · Andrew Morton
I'm thinking that the right thing to do here is to change submit_bh() callers and ll_rw_block() to run set_page_writeback(bh->b_page) when they start the buffer writeout and to do the run-around-the-buffer_heads thing at I/O completion.
Quoted 4 lines
A page may have a mix of writeback and dirty+non-writeback buffers. It appears that the page-level writeback code will handle this correctly. But it requires that the page lock be held when we run set_page_writeback(), so that tears that. hmm.

Quoted 8 lines

I'll work this out yet.
We change the PageWriteback() predicate to go in and see if any of the buffer_heads are under I/O too. And we change wait_on_page_writeback() to also wait on any buffer_heads.
That means two new silly address_space ops. Or a new page flag which means "the thing at ->private is buffer_heads". Probably the latter.

If buffer_heads are in flight and a SYNC_NONE writeback happens, will checking the buffer_heads cause to writeback to block?

Daniel

A message that is not in the archive (sent off-list or not yet received): [email protected]

Chris Mason

2004-03-17 20:09 UTC #23 lore raw

[ data not getting flushed ]

Ummm, this might help:

-chris

mm/filemap.c renamed from mm/filemap.c.1 +1 -1

@@ -180,7 +180,7 @@ static int wait_on_page_writeback_range(
 	int ret = 0;
 	pgoff_t index;
 
-	if (end > start)
+	if (end < start)
 		return 0;
 
 	pagevec_init(&pvec, 0);

Andrew Morton

author

2004-03-17 20:31 UTC #24 lore raw

Quoted 4 lines · Chris Mason

[ data not getting flushed ]
Ummm, this might help:

Pedant.

Now I have to work out why I saw longer runtimes with O_SYNC. Metadata I guess...

Chris Mason

2004-03-17 22:43 UTC #25 lore raw

Quoted 8 lines · Andrew Morton

Quoted 4 lines · Chris Mason
[ data not getting flushed ]
Ummm, this might help:
Pedant.

;-)

wait_on_page_writeback_range() does a pagevec_lookup_tag on min(end - index + 1, (pgoff_t)PAGEVEC_SIZE)

Which translates to: (unsigned long)-1 - 0 + 1, which is 0.

It doesn't look like anyone is using the range feature of this function, can we make it just wait on all the writeback pages?

-chris

Andrew Morton

author

2004-03-17 23:14 UTC #26 lore raw

Quoted 5 lines · Chris Mason

wait_on_page_writeback_range() does a pagevec_lookup_tag on
min(end - index + 1, (pgoff_t)PAGEVEC_SIZE)
Which translates to: (unsigned long)-1 - 0 + 1, which is 0.

I made a mental note to test that code.

How's this look?

mm/filemap.c renamed from mm/filemap.c~stop-using-locked-pages-fix-2 +2 -2

@@ -186,8 +186,8 @@ static int wait_on_page_writeback_range(
 	pagevec_init(&pvec, 0);
 	index = start;
 	while ((nr_pages = pagevec_lookup_tag(&pvec, mapping, &index,
-				PAGECACHE_TAG_WRITEBACK,
-				min(end - index + 1, (pgoff_t)PAGEVEC_SIZE)))) {
+			PAGECACHE_TAG_WRITEBACK,
+			min(end - index, (pgoff_t)PAGEVEC_SIZE-1) + 1))) {
 		unsigned i;
 
 		for (i = 0; i < nr_pages; i++) {

Quoted 2 lines

It doesn't look like anyone is using the range feature of this function, can we make it just wait on all the writeback pages?

We could, but there are the dreaded "future plans". In several places we're syncing the whole file unnecessarily. Most notably, O_SYNC writes. I'd like to get us to the stage where an O_SYNC write writes and waits upon just the pages which are within the range of the caller's write(), without holding i_sem.

Chris Mason

2004-03-17 23:25 UTC #27 lore raw

Quoted 11 lines · Andrew Morton

Quoted 5 lines · Chris Mason
wait_on_page_writeback_range() does a pagevec_lookup_tag on
min(end - index + 1, (pgoff_t)PAGEVEC_SIZE)
Which translates to: (unsigned long)-1 - 0 + 1, which is 0.
I made a mental note to test that code.
How's this look?

Looks good, but I'm still having problems convincing pagevec_lookup_tag to return anything other than 0 when called from wait_on_page_writeback_range (ext2, ext3, reiserfs). Any ideas?

I'm running with all the fixes discussed so far, including clear_page_dirty_for_io(page)

-chris

Andrew Morton

author

2004-03-17 23:51 UTC #28 lore raw

Quoted 4 lines · Chris Mason

Looks good, but I'm still having problems convincing pagevec_lookup_tag to return anything other than 0 when called from wait_on_page_writeback_range (ext2, ext3, reiserfs). Any ideas?

This might help. I'm testing this path now, so there may be more changes..

mm/page-writeback.c renamed from mm/page-writeback.c~x +1 -1

@@ -702,7 +702,7 @@ int test_set_page_writeback(struct page 
 
 		spin_lock_irqsave(&mapping->tree_lock, flags);
 		ret = TestSetPageWriteback(page);
-		if (ret)
+		if (!ret)
 			radix_tree_tag_set(&mapping->page_tree, page->index,
 						PAGECACHE_TAG_WRITEBACK);
 		if (!PageDirty(page))

Chris Mason

2004-03-18 00:04 UTC #29 lore raw

Quoted 8 lines · Andrew Morton

Quoted 4 lines · Chris Mason
Looks good, but I'm still having problems convincing pagevec_lookup_tag to return anything other than 0 when called from wait_on_page_writeback_range (ext2, ext3, reiserfs). Any ideas?
This might help. I'm testing this path now, so there may be more changes..

Well, that's certainly a lot slower ;-) I've got a direct_read_under round going. While you're at it, there's one more bug.

The wbc struct used by filemap_fdatawrite doesn't initialize wbc.nonblocking to zero. stack magic might give us a 1 there, leading to an early exit from mpage_writepages even when doing a WB_SYNC_ALL.

-chris

Andrew Morton

author

2004-03-18 00:13 UTC #30 lore raw

Quoted 4 lines · Chris Mason

Quoted 2 lines · Andrew Morton
Quoted 1 line · Chris Mason

Quoted 8 lines

Quoted 6 lines
Quoted 3 lines
Looks good, but I'm still having problems convincing pagevec_lookup_tag to return anything other than 0 when called from wait_on_page_writeback_range (ext2, ext3, reiserfs). Any ideas?
This might help. I'm testing this path now, so there may be more changes..
Well, that's certainly a lot slower ;-)

For once, that's good.

Quoted 6 lines

I've got a direct_read_under
round going. While you're at it, there's one more bug.
The wbc struct used by filemap_fdatawrite doesn't initialize wbc.nonblocking to zero. stack magic might give us a 1 there, leading to an early exit from mpage_writepages even when doing a WB_SYNC_ALL.

I hope not.

static int __filemap_fdatawrite(struct address_space *mapping, int sync_mode)

{
	int ret;
	struct writeback_control wbc = {
		.sync_mode = sync_mode,
		.nr_to_write = mapping->nrpages * 2,
	};

When you initialise some of the structure in this way the compiler will zero out all the other fields.

(gets worried)

yup.

struct thing {
	int a;
	int b[1000];
};

foo()

{
	int a[1000];

	memset(a, 1, sizeof(a));
}

bar()

{
	struct thing t = {
		.a = 1
	};
	int i;

	for (i = 0; i < 1000; i++) {
		if (t.b[i]) {
			printf("bad\n");
			return;
		}
	}
}

zot()

{
	struct thing t;
	int i;

	for (i = 0; i < 1000; i++) {
		if (t.b[i]) {
			printf("good\n");
			return;
		}
	}
}

main()

{
	foo();
	bar();
	foo();
	zot();
}

Chris Mason

2004-03-18 00:28 UTC #31 lore raw

Quoted 16 lines · Andrew Morton

Quoted 4 lines · Chris Mason
Quoted 2 lines · Andrew Morton
Quoted 1 line · Chris Mason
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
Looks good, but I'm still having problems convincing pagevec_lookup_tag to return anything other than 0 when called from wait_on_page_writeback_range (ext2, ext3, reiserfs). Any ideas?
This might help. I'm testing this path now, so there may be more changes..
Well, that's certainly a lot slower ;-)
For once, that's good.

Quoted 9 lines

Quoted 6 lines
I've got a direct_read_under
round going. While you're at it, there's one more bug.
The wbc struct used by filemap_fdatawrite doesn't initialize wbc.nonblocking to zero. stack magic might give us a 1 there, leading to an early exit from mpage_writepages even when doing a WB_SYNC_ALL.
I hope not.

Yes, my brain wandered off for a bit. Seems like it's break time for chris...good news is that direct_read_under is still running without problems here.

-chris

Andrew Morton

author

2004-03-18 00:33 UTC #32 lore raw

Quoted 3 lines · Chris Mason

good news is that direct_read_under is still running without
problems here.

Here also, but _without_ clear_page_dirty_for_io.patch, so it should break.

Maybe it takes a long time.

Chris Mason

2004-03-18 00:39 UTC #33 lore raw

Quoted 8 lines · Andrew Morton

Quoted 3 lines · Chris Mason
good news is that direct_read_under is still running without
problems here.
Here also, but _without_ clear_page_dirty_for_io.patch, so it should break.
Maybe it takes a long time.

It was very irregular for me. A run might die in pass3 or last for 30 minutes before I got bored and hit ctrl-c

-chris

Daniel McNeil

2004-03-18 01:15 UTC #34 lore raw

In reply to Andrew Morton

I'm running without clear_page_dirty_for_io.patch on an 8-proc with 6 direct_read_under tests on ext3.

2 failed in less than 5 minutes. The 4 others are still running and it's been over 30 minutes.

I'll run overnight wth clear_page_dirty_for_io.patch added in.

Daniel

Quoted 8 lines · Andrew Morton

Quoted 3 lines · Chris Mason
good news is that direct_read_under is still running without
problems here.
Here also, but _without_ clear_page_dirty_for_io.patch, so it should break.
Maybe it takes a long time.

Daniel McNeil

2004-03-18 17:54 UTC #35 lore raw

I'm ran 2.6.4-mm2 plus the 2 wait_on_page_range() patches, the test_set_page_writeback() patch and clear_page_dirty_for_io patch overnight.

6 copies of direct_read_under test on 8-cpu system on 1 ext3 file system in 1 directory on a scsi disk.
(http://developer.osdl.org/daniel/AIO/TESTS/direct_read_under.c)

5 of the 6 tests saw uninitialized data within 2 hours. The sixth test ran overnight.

Daniel

Quoted 24 lines · Daniel McNeil

I'm running without clear_page_dirty_for_io.patch on an 8-proc with 6 direct_read_under tests on ext3.
2 failed in less than 5 minutes. The 4 others are still running and it's been over 30 minutes.
I'll run overnight wth clear_page_dirty_for_io.patch added in.
Daniel
Quoted 8 lines · Andrew Morton
Quoted 3 lines · Chris Mason
good news is that direct_read_under is still running without
problems here.
Here also, but _without_ clear_page_dirty_for_io.patch, so it should break.
Maybe it takes a long time.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Chris Mason

2004-03-18 18:46 UTC #36 lore raw

Quoted 10 lines · Daniel McNeil

I'm ran 2.6.4-mm2 plus the 2 wait_on_page_range() patches, the test_set_page_writeback() patch and clear_page_dirty_for_io patch overnight.
6 copies of direct_read_under test on 8-cpu system on 1 ext3 file system in 1 directory on a scsi disk.
(http://developer.osdl.org/daniel/AIO/TESTS/direct_read_under.c)
5 of the 6 tests saw uninitialized data within 2 hours. The sixth test ran overnight.

Do you still have the errors generated? I wondering how big the range of uninitialized data was. When I was bug hunting yesterday, I saw ranges from 64k to 32mb in size, which was why I decided writes weren't getting to the disk at all.

It might be interesting to try with data=writeback, or on ext2. Things might be easier to track if we're not worried about ll_rw_block.

It might also be interesting to significantly lower the size of the reads and writes done by direct_read_under, or anything else you can think of to get the reproduce time down to something smaller than 2 hours...

It's probably a good idea to upgrade to 2.6.5-rc1-mm2, just so we're all staring at the same code.

-chris

Daniel McNeil

2004-03-18 19:10 UTC #37 lore raw

Quoted 25 lines · Chris Mason

Quoted 10 lines · Daniel McNeil
I'm ran 2.6.4-mm2 plus the 2 wait_on_page_range() patches, the test_set_page_writeback() patch and clear_page_dirty_for_io patch overnight.
6 copies of direct_read_under test on 8-cpu system on 1 ext3 file system in 1 directory on a scsi disk.
(http://developer.osdl.org/daniel/AIO/TESTS/direct_read_under.c)
5 of the 6 tests saw uninitialized data within 2 hours. The sixth test ran overnight.
Do you still have the errors generated? I wondering how big the range of uninitialized data was. When I was bug hunting yesterday, I saw ranges from 64k to 32mb in size, which was why I decided writes weren't getting to the disk at all.
It might be interesting to try with data=writeback, or on ext2. Things might be easier to track if we're not worried about ll_rw_block.
It might also be interesting to significantly lower the size of the reads and writes done by direct_read_under, or anything else you can think of to get the reproduce time down to something smaller than 2 hours...

Quoted 5 lines

It's probably a good idea to upgrade to 2.6.5-rc1-mm2, just so we're all staring at the same code.
-chris

Chris,

Still have the data:

		 63 pages (258048 bytes)
		 90 pages (368640 bytes)
		139 pages (569344 bytes)
		 30 pages (122880 bytes)
		 87 pages (356352 bytes)

I'm rebooting to 2.6.5-rc1-mm2 and will re-run. I have do have versions of direct_read_under that do smaller i/o and also 1 that does forks off and does 'sync' calls every few seconds.

I'll give ext2 and try as well.

Daniel

Daniel McNeil

2004-03-19 16:50 UTC #38 lore raw

2.6.5-rc2-mm2 and direct_read_under

I re-ran direct_read_under test (6 copies) on 2.6.4-rc2-mm2:

ext3 failed within 2 hours.

ext2 ran overnight without errors.

Daniel

Quoted 55 lines · Daniel McNeil

Quoted 25 lines · Chris Mason
Quoted 10 lines · Daniel McNeil
I'm ran 2.6.4-mm2 plus the 2 wait_on_page_range() patches, the test_set_page_writeback() patch and clear_page_dirty_for_io patch overnight.
6 copies of direct_read_under test on 8-cpu system on 1 ext3 file system in 1 directory on a scsi disk.
(http://developer.osdl.org/daniel/AIO/TESTS/direct_read_under.c)
5 of the 6 tests saw uninitialized data within 2 hours. The sixth test ran overnight.
Do you still have the errors generated? I wondering how big the range of uninitialized data was. When I was bug hunting yesterday, I saw ranges from 64k to 32mb in size, which was why I decided writes weren't getting to the disk at all.
It might be interesting to try with data=writeback, or on ext2. Things might be easier to track if we're not worried about ll_rw_block.
It might also be interesting to significantly lower the size of the reads and writes done by direct_read_under, or anything else you can think of to get the reproduce time down to something smaller than 2 hours...
Quoted 5 lines
It's probably a good idea to upgrade to 2.6.5-rc1-mm2, just so we're all staring at the same code.
-chris
Chris,
Still have the data:
		 63 pages (258048 bytes)
		 90 pages (368640 bytes)
		139 pages (569344 bytes)
		 30 pages (122880 bytes)
		 87 pages (356352 bytes)
I'm rebooting to 2.6.5-rc1-mm2 and will re-run. I have do have versions of direct_read_under that do smaller i/o and also 1 that does forks off and does 'sync' calls every few seconds.
I'll give ext2 and try as well.
Daniel
--
To unsubscribe, send a message with 'unsubscribe linux-aio' in the body to [email protected]. For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"[email protected]">[email protected]</a>

Daniel McNeil

2004-03-19 17:05 UTC #39 lore raw

Re: 2.6.5-rc1-mm2 and direct_read_under

Can't type this morning -- 2.6.5-rc1-mm2 is what I ran on.

                           =============

Daniel

Quoted 70 lines · Daniel McNeil

I re-ran direct_read_under test (6 copies) on 2.6.4-rc1-mm2:
ext3 failed within 2 hours.
ext2 ran overnight without errors.
Daniel
Quoted 48 lines · Daniel McNeil
Quoted 25 lines · Chris Mason
Quoted 10 lines · Daniel McNeil
I'm ran 2.6.4-mm2 plus the 2 wait_on_page_range() patches, the test_set_page_writeback() patch and clear_page_dirty_for_io patch overnight.
6 copies of direct_read_under test on 8-cpu system on 1 ext3 file system in 1 directory on a scsi disk.
(http://developer.osdl.org/daniel/AIO/TESTS/direct_read_under.c)
5 of the 6 tests saw uninitialized data within 2 hours. The sixth test ran overnight.
Do you still have the errors generated? I wondering how big the range of uninitialized data was. When I was bug hunting yesterday, I saw ranges from 64k to 32mb in size, which was why I decided writes weren't getting to the disk at all.
It might be interesting to try with data=writeback, or on ext2. Things might be easier to track if we're not worried about ll_rw_block.
It might also be interesting to significantly lower the size of the reads and writes done by direct_read_under, or anything else you can think of to get the reproduce time down to something smaller than 2 hours...
Quoted 5 lines
It's probably a good idea to upgrade to 2.6.5-rc1-mm2, just so we're all staring at the same code.
-chris
Chris,
Still have the data:
		 63 pages (258048 bytes)
		 90 pages (368640 bytes)
		139 pages (569344 bytes)
		 30 pages (122880 bytes)
		 87 pages (356352 bytes)
I'm rebooting to 2.6.5-rc1-mm2 and will re-run. I have do have versions of direct_read_under that do smaller i/o and also 1 that does forks off and does 'sync' calls every few seconds.
I'll give ext2 and try as well.
Quoted 7 lines
Daniel
--
To unsubscribe, send a message with 'unsubscribe linux-aio' in the body to [email protected]. For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"[email protected]">[email protected]</a>
--
To unsubscribe, send a message with 'unsubscribe linux-aio' in the body to [email protected]. For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"[email protected]">[email protected]</a>

Chris Mason

2004-03-21 14:34 UTC #40 lore raw

Re: 2.6.5-rc1-mm2 and direct_read_under

Quoted 11 lines · Daniel McNeil

Can't type this morning -- 2.6.5-rc1-mm2 is what I ran on.
                           =============
Daniel
Quoted 6 lines · Daniel McNeil
I re-ran direct_read_under test (6 copies) on 2.6.4-rc1-mm2:
ext3 failed within 2 hours.
ext2 ran overnight without errors.

[ ... a slightly different kernel, but numbers are probably good ]

Quoted 9 lines

Quoted 8 lines

Still have the data:

		 63 pages (258048 bytes)
		 90 pages (368640 bytes)
		139 pages (569344 bytes)
		 30 pages (122880 bytes)
		 87 pages (356352 bytes)

That seems like a lot of pages for a small race, it feels like we have a bigger problem. If nobody else has ideas, and you've got an available disk for mkreiserfs, could I talk you into trying with reiserfs data=ordered?

ftp.suse.com/pub/people/mason/patches/data-logging/experimental/2.6.4

(use series.mm for a list of files to apply to 2.6.5-rc-mm)

data=ordered is the default with those patches, so just mkreiserfs and mount. reiserfs is using a different writepage and different code to submit the ordered buffers, so you'll be using completely different code paths.

I'll try to get some time on an 8way here for some tests as well.

-chris

Daniel McNeil

2004-03-22 18:10 UTC #41 lore raw

Re: 2.6.5-rc1-mm2 and direct_read_under and wb

Andrew and Chris,

I re-ran the direct_read_under tests over the weekend on ext3 with the attached wb_rwsema patch and ran without errors.

It looks like the same thing as before -- async writebacks are causing the sync writebacks to miss pages.

Thoughts?

Daniel

Quoted 33 lines · Chris Mason

Quoted 11 lines · Daniel McNeil
Can't type this morning -- 2.6.5-rc1-mm2 is what I ran on.
                           =============
Daniel
Quoted 6 lines · Daniel McNeil
I re-ran direct_read_under test (6 copies) on 2.6.4-rc1-mm2:
ext3 failed within 2 hours.
ext2 ran overnight without errors.
[ ... a slightly different kernel, but numbers are probably good ]
Quoted 9 lines
Quoted 9 lines
Quoted 8 lines
Still have the data:
		 63 pages (258048 bytes)
		 90 pages (368640 bytes)
		139 pages (569344 bytes)
		 30 pages (122880 bytes)
		 87 pages (356352 bytes)
That seems like a lot of pages for a small race, it feels like we have a bigger problem. If nobody else has ideas, and you've got an available disk for mkreiserfs, could I talk you into trying with reiserfs data=ordered?
ftp.suse.com/pub/people/mason/patches/data-logging/experimental/2.6.4
(use series.mm for a list of files to apply to 2.6.5-rc-mm)

Quoted 9 lines

data=ordered is the default with those patches, so just mkreiserfs and mount. reiserfs is using a different writepage and different code to submit the ordered buffers, so you'll be using completely different code paths.
I'll try to get some time on an 8way here for some tests as well.
-chris

fs/buffer.c +1 -2

diff -rup linux-2.6.5-rc1-mm2.orig/fs/buffer.c linux-2.6.5-rc1-mm2/fs/buffer.c
@@ -1814,8 +1814,7 @@ static int __block_write_full_page(struc
 			lock_buffer(bh);
 		} else {
 			if (test_set_buffer_locked(bh)) {
-				if (buffer_dirty(bh))
-					__set_page_dirty_nobuffers(page);
+				__set_page_dirty_nobuffers(page);
 				continue;
 			}
 		}

fs/fs-writeback.c +25 -1

diff -rup linux-2.6.5-rc1-mm2.orig/fs/fs-writeback.c linux-2.6.5-rc1-mm2/fs/fs-writeback.c
@@ -132,6 +132,7 @@ __sync_single_inode(struct inode *inode,
 	struct address_space *mapping = inode->i_mapping;
 	struct super_block *sb = inode->i_sb;
 	int wait = wbc->sync_mode == WB_SYNC_ALL;
+	int blkdev = inode->i_sb == blockdev_superblock;
 
 	BUG_ON(inode->i_state & I_LOCK);

@@ -148,8 +149,26 @@ __sync_single_inode(struct inode *inode,
 
 	spin_unlock(&inode_lock);
 
+	if (!blkdev) {
+		if (wait) {
+			down_write(&mapping->wb_rwsema);
+		} else {
+			if (!down_read_trylock(&mapping->wb_rwsema)) {
+				wbc->encountered_congestion = 1;
+				goto skip_writeback;
+			}
+		}
+	}
+
 	do_writepages(mapping, wbc);
 
+	if (!blkdev) {
+		if (wait)
+			up_write(&mapping->wb_rwsema);
+		else
+			up_read(&mapping->wb_rwsema);
+	}
+skip_writeback:
 	/* Don't write the inode if only I_DIRTY_PAGES was set */
 	if (dirty & (I_DIRTY_SYNC | I_DIRTY_DATASYNC))
 		write_inode(inode, wait);

@@ -263,7 +282,12 @@ sync_sb_inodes(struct super_block *sb, s
 			break;
 		}
 
-		if (wbc->nonblocking && bdi_write_congested(bdi)) {
+		/*
+		 * wbc->encountered_congestion is set if we cannot get
+		 * the wb_rwsema.
+		 */
+		if (wbc->nonblocking &&
+		    (bdi_write_congested(bdi) || wbc->encountered_congestion)) {
 			wbc->encountered_congestion = 1;
 			if (sb != blockdev_superblock)
 				break;		/* Skip a congested fs */

fs/inode.c +1 -0

diff -rup linux-2.6.5-rc1-mm2.orig/fs/inode.c linux-2.6.5-rc1-mm2/fs/inode.c
@@ -190,6 +190,7 @@ void inode_init_once(struct inode *inode
 	INIT_LIST_HEAD(&inode->i_data.i_mmap_shared);
 	spin_lock_init(&inode->i_lock);
 	i_size_ordered_init(inode);
+	init_rwsem(&inode->i_data.wb_rwsema);
 }
 
 EXPORT_SYMBOL(inode_init_once);

include/linux/fs.h +1 -0

diff -rup linux-2.6.5-rc1-mm2.orig/include/linux/fs.h linux-2.6.5-rc1-mm2/include/linux/fs.h
@@ -338,6 +338,7 @@ struct address_space {
 	spinlock_t		private_lock;	/* for use by the address_space */
 	struct list_head	private_list;	/* ditto */
 	struct address_space	*assoc_mapping;	/* ditto */
+	struct rw_semaphore	wb_rwsema;	/* serialize SYNC writebacks */
 };
 
 struct block_device {

mm/filemap.c +16 -0

diff -rup linux-2.6.5-rc1-mm2.orig/mm/filemap.c linux-2.6.5-rc1-mm2/mm/filemap.c
@@ -140,16 +140,32 @@ static inline int sync_page(struct page 
  */
 static int __filemap_fdatawrite(struct address_space *mapping, int sync_mode)
 {
+	extern struct super_block *blockdev_superblock;
 	int ret;
 	struct writeback_control wbc = {
 		.sync_mode = sync_mode,
 		.nr_to_write = mapping->nrpages * 2,
 	};
+	int blkdev = mapping->host->i_sb == blockdev_superblock;
 
 	if (mapping->backing_dev_info->memory_backed)
 		return 0;
 
+	if (!blkdev) {
+		if (sync_mode == WB_SYNC_NONE) {
+			if (!down_read_trylock(&mapping->wb_rwsema))
+				return 0;
+		} else {
+			down_write(&mapping->wb_rwsema);
+		}
+	}
 	ret = do_writepages(mapping, &wbc);
+	if (!blkdev) {
+		if (sync_mode == WB_SYNC_NONE)
+			up_read(&mapping->wb_rwsema);
+		else
+			up_write(&mapping->wb_rwsema);
+	}
 	return ret;
 }

mm/swap_state.c +1 -0

diff -rup linux-2.6.5-rc1-mm2.orig/mm/swap_state.c linux-2.6.5-rc1-mm2/mm/swap_state.c
@@ -35,6 +35,7 @@ struct address_space swapper_space = {
 	.truncate_count  = ATOMIC_INIT(0),
 	.private_lock	= SPIN_LOCK_UNLOCKED,
 	.private_list	= LIST_HEAD_INIT(swapper_space.private_list),
+	.wb_rwsema	= __RWSEM_INITIALIZER(swapper_space.wb_rwsema)
 };
 
 #define INC_CACHE_INFO(x)	do { swap_cache_info.x++; } while (0)

Chris Mason

2004-03-22 18:21 UTC #42 lore raw

Re: 2.6.5-rc1-mm2 and direct_read_under and wb

Quoted 9 lines · Daniel McNeil

Andrew and Chris,
I re-ran the direct_read_under tests over the weekend on ext3 with the attached wb_rwsema patch and ran without errors.
It looks like the same thing as before -- async writebacks are causing the sync writebacks to miss pages.
Thoughts?

It does seem clear that's what is happening, but the part I don't understand is exactly where they are racing.

-chris

Chris Mason

2004-03-22 18:25 UTC #43 lore raw

Re: 2.6.5-rc1-mm2 and direct_read_under and wb

Quoted 6 lines · Chris Mason

Quoted 5 lines · Daniel McNeil
Andrew and Chris,
I re-ran the direct_read_under tests over the weekend on ext3 with the attached wb_rwsema patch and ran without errors.

Quoted 7 lines

Quoted 4 lines
It looks like the same thing as before -- async writebacks are causing the sync writebacks to miss pages.
Thoughts?
It does seem clear that's what is happening, but the part I don't understand is exactly where they are racing.

Wait, maybe I do see it.

In __block_write_full_page, if the buffers are locked by ll_rw_block and under io, they are clean. The page is only redirtied in this case because the buffers are clean.

So we set_page_writeback and nr_underway == 0. Then, in the if (nr_underway == 0) code, we clear page writeback even though the buffers are still locked and under io.

-chris

Chris Mason

2004-03-22 18:32 UTC #44 lore raw

Re: 2.6.5-rc1-mm2 and direct_read_under and wb

In reply to Daniel McNeil

Quoted 10 lines · Daniel McNeil

Andrew and Chris,
I re-ran the direct_read_under tests over the weekend on ext3 with the attached wb_rwsema patch and ran without errors.
It looks like the same thing as before -- async writebacks are causing the sync writebacks to miss pages.
Thoughts?

This hunk alone should be enough to force the sync writers to find a page with locked but clean buffers.

fs/buffer.c 2004-03-19 16:24:57.000000000 -0800 renamed from fs/buffer.c 2004-03-22 09:51:08.780141187 -0800 +1 -2

diff -rup linux-2.6.5-rc1-mm2.orig/fs/buffer.c linux-2.6.5-rc1-mm2/fs/buffer.c
@@ -1814,8 +1814,7 @@ static int __block_write_full_page(struc
                        lock_buffer(bh);
                } else {
                        if (test_set_buffer_locked(bh)) {
-                               if (buffer_dirty(bh))
-                                       __set_page_dirty_nobuffers(page);
+                               __set_page_dirty_nobuffers(page);
                                continue;
                        }
                }

-chris

Daniel McNeil

2004-03-22 18:51 UTC #45 lore raw

Re: 2.6.5-rc1-mm2 and direct_read_under and wb

I was thinking about this also, since this is included in the patch. As long as the page stays dirty in radix tree so the sync writer can find it, then the sync writer can wait on the locked buffers.

I am giving it a try and will let you know.

Daniel

Quoted 30 lines · Chris Mason

Quoted 10 lines · Daniel McNeil
Andrew and Chris,
I re-ran the direct_read_under tests over the weekend on ext3 with the attached wb_rwsema patch and ran without errors.
It looks like the same thing as before -- async writebacks are causing the sync writebacks to miss pages.
Thoughts?
This hunk alone should be enough to force the sync writers to find a page with locked but clean buffers.
diff -rup linux-2.6.5-rc1-mm2.orig/fs/buffer.c linux-2.6.5-rc1-mm2/fs/buffer.c
fs/buffer.c 2004-03-19 16:24:57.000000000 -0800 renamed from fs/buffer.c 2004-03-22 09:51:08.780141187 -0800 +1 -3
@@ -1814,8 +1814,7 @@ static int __block_write_full_page(struc
                        lock_buffer(bh);
                } else {
                        if (test_set_buffer_locked(bh)) {
-                               if (buffer_dirty(bh))
-                                       __set_page_dirty_nobuffers(page);
+                               __set_page_dirty_nobuffers(page);
                                continue;
                        }
                }
 
 
-chris

Andrew Morton

author

2004-03-22 23:11 UTC #46 lore raw

Re: 2.6.5-rc1-mm2 and direct_read_under and wb

Quoted 6 lines · Daniel McNeil

I was thinking about this also, since this is included in the patch. As long as the page stays dirty in radix tree so the sync writer can find it, then the sync writer can wait on the locked buffers.
I am giving it a try and will let you know.

Please do.

Redirtyng the pages in this manner does mean that background_writeout() could get stuck in a loop trying to write the same batch of pages over and over again, until the I/O completes.

I'll take another look at marking the pages which back the ll_rw_blk buffers as being under writeback.

Daniel McNeil

2004-03-23 00:51 UTC #47 lore raw

Re: 2.6.5-rc1-mm2 and direct_read_under and wb

Andrew,

The test has been running over 5 hours now without seeing uninitialized data. I'll let it run overnight, but it looks like the small __block_write_full_page patch fixes the problem.

Daniel

Quoted 22 lines · Andrew Morton

Quoted 6 lines · Daniel McNeil
I was thinking about this also, since this is included in the patch. As long as the page stays dirty in radix tree so the sync writer can find it, then the sync writer can wait on the locked buffers.
I am giving it a try and will let you know.
Please do.
Redirtyng the pages in this manner does mean that background_writeout() could get stuck in a loop trying to write the same batch of pages over and over again, until the I/O completes.
I'll take another look at marking the pages which back the ll_rw_blk buffers as being under writeback.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Andrew Morton

author

2004-03-23 09:25 UTC #48 lore raw

Re: 2.6.5-rc1-mm2 and direct_read_under and wb

Quoted 4 lines · Daniel McNeil

The test has been running over 5 hours now without seeing uninitialized
data. I'll let it run overnight, but it looks like the small __block_write_full_page patch fixes the problem.

OK, thanks. It does cause gargantuan amounts of CPU consumption as expected. The below version fixes that up. I'm not 100% happy with it, but it seems OK on the profiles.

fs/buffer.c renamed from fs/buffer.c~block_write_full_page-redirty +11 -7

diff -puN fs/buffer.c~block_write_full_page-redirty fs/buffer.c
@@ -1810,14 +1810,18 @@ static int __block_write_full_page(struc
 		get_bh(bh);
 		if (!buffer_mapped(bh))
 			continue;
-		if (wbc->sync_mode != WB_SYNC_NONE) {
+		/*
+		 * If it's a fully non-blocking write attempt and we cannot
+		 * lock the buffer then redirty the page.  Note that this can
+		 * potentially cause a busy-wait loop from pdflush and kswapd
+		 * activity, but those code paths have their own higher-level
+		 * throttling.
+		 */
+		if (wbc->sync_mode != WB_SYNC_NONE || !wbc->nonblocking) {
 			lock_buffer(bh);
-		} else {
-			if (test_set_buffer_locked(bh)) {
-				if (buffer_dirty(bh))
-					__set_page_dirty_nobuffers(page);
-				continue;
-			}
+		} else if (test_set_buffer_locked(bh)) {
+			__set_page_dirty_nobuffers(page);
+			continue;
 		}
 		if (test_clear_buffer_dirty(bh)) {
 			if (!buffer_uptodate(bh))

Daniel McNeil

2004-03-23 17:05 UTC #49 lore raw

Re: 2.6.5-rc1-mm2 and direct_read_under and wb

Andrew,

Just to confirm my tests ran overnight without errors.

So the !wbc->nonblocking lowers the cpu utilization. What does sync_mode=WB_SYNC_ALL and nonblocking=1 mean?

Daniel

Quoted 48 lines · Andrew Morton

Quoted 4 lines · Daniel McNeil
The test has been running over 5 hours now without seeing uninitialized
data. I'll let it run overnight, but it looks like the small __block_write_full_page patch fixes the problem.
OK, thanks. It does cause gargantuan amounts of CPU consumption as expected. The below version fixes that up. I'm not 100% happy with it, but it seems OK on the profiles.
diff -puN fs/buffer.c~block_write_full_page-redirty fs/buffer.c
fs/buffer.c renamed from fs/buffer.c~block_write_full_page-redirty +11 -7
@@ -1810,14 +1810,18 @@ static int __block_write_full_page(struc
 		get_bh(bh);
 		if (!buffer_mapped(bh))
 			continue;
-		if (wbc->sync_mode != WB_SYNC_NONE) {
+		/*
+		 * If it's a fully non-blocking write attempt and we cannot
+		 * lock the buffer then redirty the page.  Note that this can
+		 * potentially cause a busy-wait loop from pdflush and kswapd
+		 * activity, but those code paths have their own higher-level
+		 * throttling.
+		 */
+		if (wbc->sync_mode != WB_SYNC_NONE || !wbc->nonblocking) {
 			lock_buffer(bh);
-		} else {
-			if (test_set_buffer_locked(bh)) {
-				if (buffer_dirty(bh))
-					__set_page_dirty_nobuffers(page);
-				continue;
-			}
+		} else if (test_set_buffer_locked(bh)) {
+			__set_page_dirty_nobuffers(page);
+			continue;
 		}
 		if (test_clear_buffer_dirty(bh)) {
 			if (!buffer_uptodate(bh))
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Andrew Morton

author

2004-03-23 18:01 UTC #50 lore raw

Re: 2.6.5-rc1-mm2 and direct_read_under and wb

Quoted 4 lines · Daniel McNeil

Andrew,
Just to confirm my tests ran overnight without errors.

good.

Quoted 1 line

So the !wbc->nonblocking lowers the cpu utilization.

yup. It prevents balance_dirty_pages() callers from spinning over the same pages again and again.

Quoted 1 line

What does sync_mode=WB_SYNC_ALL and nonblocking=1 mean?

WB_SYNC_ALL means "we're performing this writeout for data-integrity purposes, as opposed to for a regular dirty memory flush". The code paths for these two things are deep, and are almost identical, so we pass it up and down in a flag.

->nonblocking means "try to avoid blocking on request queues or locked pages". pdflush and kswapd set this because those processes must serve many queues and cannot accord to get stuck on any one queue. But regular write() callers do not set ->nonblocking because we _want_ these guys to throttle.

It's only OK to let pdflush avoid blocking on the buffer because pdflush will take an explicit nap in background_writeout(). hm, but only if the queue is congested - we may still have a problem there.

Daniel McNeil

2004-03-23 21:38 UTC #51 lore raw

Re: 2.6.5-rc1-mm2 and direct_read_under and wb

It looks like every place wbc->nonblocking is set to 1, sync_mode is set to WB_SYNC_NONE, but there are places where WB_SYNC_NONE is used and nonblocking is NOT set:

	balance_dirty_pages()
	try_to_unuse()

So your patch makes balance_dirty_pages() do the lock_buffer() in __block_write_full_page() instead of skipping and redirtying the page.

I just making sure I understand.
So, WB_SYNC_ALL and nonblocking=1 should never be used?

Daniel

Quoted 29 lines · Andrew Morton

Quoted 4 lines · Daniel McNeil
Andrew,
Just to confirm my tests ran overnight without errors.
good.
Quoted 1 line
So the !wbc->nonblocking lowers the cpu utilization.
yup. It prevents balance_dirty_pages() callers from spinning over the same pages again and again.
Quoted 1 line
What does sync_mode=WB_SYNC_ALL and nonblocking=1 mean?
WB_SYNC_ALL means "we're performing this writeout for data-integrity purposes, as opposed to for a regular dirty memory flush". The code paths for these two things are deep, and are almost identical, so we pass it up and down in a flag.
->nonblocking means "try to avoid blocking on request queues or locked pages". pdflush and kswapd set this because those processes must serve many queues and cannot accord to get stuck on any one queue. But regular write() callers do not set ->nonblocking because we _want_ these guys to throttle.
It's only OK to let pdflush avoid blocking on the buffer because pdflush will take an explicit nap in background_writeout(). hm, but only if the queue is congested - we may still have a problem there.

Andrew Morton

author

2004-03-23 21:47 UTC #52 lore raw

Re: 2.6.5-rc1-mm2 and direct_read_under and wb

Review

Quoted 13 lines · Daniel McNeil

It looks like every place wbc->nonblocking is set to 1, sync_mode is set to WB_SYNC_NONE, but there are places where WB_SYNC_NONE is used and nonblocking is NOT set:
(quoted diff) +0 -0
 	balance_dirty_pages()
 	try_to_unuse()
 
 So your patch makes balance_dirty_pages() do the lock_buffer()
 in __block_write_full_page() instead of skipping and redirtying
 the page.
 
 I just making sure I understand.
 So, WB_SYNC_ALL and nonblocking=1 should never be used?

Correct, setting both WB_SYNC_ALL and nonblocking=1 doesn't make sense.

[email protected]

2004-03-18 17:37 UTC #53 lore raw

In reply to Andrew Morton

Sorry I'm falling behind... I see about a 10% decrease in throughput with our dbt2 workload when comparing 2.6.4-mm2 to 2.6.3. I'm wondering if this might be a result of the changes to the pagecache, radix-tree and writeback code since you mentioned it could affect i/o scheduling in 2.6.4-mm1.

PostgreSQL is using 8KB blocks and the characteristics of the i/o should be that one lvm2 volume is experiencing mostly sequential writes, while another has random reading and writing. Both these volumes are using ext2. I'll summarize the throughput results here, with the lvm2 stripe width varying across the columns:

kernel          16 kb   32 kb   64 kb   128 kb  256 kb  512 kb
2.6.3                           2308    2335    2348    2334
2.6.4-mm2       2028    2048    2074    2096    2082    2078

Here's a page with links to profile, oprofile, etc of each result:
http://developer.osdl.org/markw/linux/2.6-pagecache.html

Comparing one pair of readprofile results, I find it curious that dm_table_unplug_all and dm_table_any_congested show up near the top of a 2.6.4-mm2 profile when they haven't shown up before in 2.6.3.

Mark

Andrew Morton

author

2004-03-18 18:06 UTC #54 lore raw

Quoted 6 lines · [email protected] wrote:

Sorry I'm falling behind... I see about a 10% decrease in throughput with our dbt2 workload when comparing 2.6.4-mm2 to 2.6.3. I'm wondering if this might be a result of the changes to the pagecache, radix-tree and writeback code since you mentioned it could affect i/o scheduling in 2.6.4-mm1.

Could be. Have you run tests without LVM in the picture?

Quoted 10 lines

PostgreSQL is using 8KB blocks and the characteristics of the i/o should be that one lvm2 volume is experiencing mostly sequential writes, while another has random reading and writing. Both these volumes are using ext2. I'll summarize the throughput results here, with the lvm2 stripe width varying across the columns:
kernel          16 kb   32 kb   64 kb   128 kb  256 kb  512 kb
2.6.3                           2308    2335    2348    2334
2.6.4-mm2       2028    2048    2074    2096    2082    2078

Quoted 6 lines

Here's a page with links to profile, oprofile, etc of each result:
http://developer.osdl.org/markw/linux/2.6-pagecache.html
Comparing one pair of readprofile results, I find it curious that dm_table_unplug_all and dm_table_any_congested show up near the top of a 2.6.4-mm2 profile when they haven't shown up before in 2.6.3.

14015190 poll_idle 241641.2069

175162 generic_unplug_device                    1317.0075
165480 __copy_from_user_ll                      1272.9231
161151 __copy_to_user_ll                        1342.9250

152106 schedule 85.0705
142395 DAC960_LP_InterruptHandler 761.4706
113677 dm_table_unplug_all 1386.3049
65420 __make_request 45.5571
64832 dm_table_any_congested 697.1183
37913 try_to_wake_up 32.2939

That's broken. How many disks are involve in the DM stack?

The relevant code was reworked subsequent to 2.6.4-mm2. Maybe we fixed this, but I cannot immediately explain what you're seeing here.

[email protected]

2004-03-18 18:49 UTC #55 lore raw

Quoted 9 lines · Andrew Morton

Quoted 6 lines · [email protected] wrote:
Sorry I'm falling behind... I see about a 10% decrease in throughput with our dbt2 workload when comparing 2.6.4-mm2 to 2.6.3. I'm wondering if this might be a result of the changes to the pagecache, radix-tree and writeback code since you mentioned it could affect i/o scheduling in 2.6.4-mm1.
Could be. Have you run tests without LVM in the picture?

No I haven't and I'm hesitant to. I have 52 single drives in one volume and 14 single drives the other. Because it's PostgreSQL, my options are to either run on a single drive (and not be able to drive the system as hard) or to reconfigure my drives using hardware raid. I could do the latter if you think it'll help. It's just a bit time consuming.

Quoted 32 lines

Quoted 10 lines
PostgreSQL is using 8KB blocks and the characteristics of the i/o should be that one lvm2 volume is experiencing mostly sequential writes, while another has random reading and writing. Both these volumes are using ext2. I'll summarize the throughput results here, with the lvm2 stripe width varying across the columns:
kernel          16 kb   32 kb   64 kb   128 kb  256 kb  512 kb
2.6.3                           2308    2335    2348    2334
2.6.4-mm2       2028    2048    2074    2096    2082    2078
Quoted 6 lines
Here's a page with links to profile, oprofile, etc of each result:
http://developer.osdl.org/markw/linux/2.6-pagecache.html
Comparing one pair of readprofile results, I find it curious that dm_table_unplug_all and dm_table_any_congested show up near the top of a 2.6.4-mm2 profile when they haven't shown up before in 2.6.3.
14015190 poll_idle 241641.2069
175162 generic_unplug_device                    1317.0075
165480 __copy_from_user_ll                      1272.9231
161151 __copy_to_user_ll                        1342.9250
152106 schedule 85.0705
142395 DAC960_LP_InterruptHandler 761.4706
113677 dm_table_unplug_all 1386.3049
65420 __make_request 45.5571
64832 dm_table_any_congested 697.1183
37913 try_to_wake_up 32.2939
That's broken. How many disks are involve in the DM stack?
The relevant code was reworked subsequent to 2.6.4-mm2. Maybe we fixed this, but I cannot immediately explain what you're seeing here.

Chris Mason

2004-03-18 19:08 UTC #56 lore raw

Quoted 9 lines · On Thu, 2004-03-18 at 13:48, [email protected] wrote:

Quoted 8 lines · Andrew Morton
Quoted 6 lines · [email protected] wrote:
Sorry I'm falling behind... I see about a 10% decrease in throughput with our dbt2 workload when comparing 2.6.4-mm2 to 2.6.3. I'm wondering if this might be a result of the changes to the pagecache, radix-tree and writeback code since you mentioned it could affect i/o scheduling in 2.6.4-mm1.

Quoted 8 lines

Quoted 1 line
Could be. Have you run tests without LVM in the picture?
No I haven't and I'm hesitant to. I have 52 single drives in one volume and 14 single drives the other. Because it's PostgreSQL, my options are to either run on a single drive (and not be able to drive the system as hard) or to reconfigure my drives using hardware raid. I could do the latter if you think it'll help. It's just a bit time consuming.

It might be more valuable to retest on 2.6.5-rc1-mm2. I'm assuming postgres was doing synchronous writes, and 2.6.4-mm2 doesn't really wait correctly.

-chris

Jens Axboe

2004-03-18 19:27 UTC #57 lore raw

In reply to Andrew Morton

Quoted 15 lines · Andrew Morton

Quoted 3 lines
Comparing one pair of readprofile results, I find it curious that dm_table_unplug_all and dm_table_any_congested show up near the top of a 2.6.4-mm2 profile when they haven't shown up before in 2.6.3.
14015190 poll_idle 241641.2069
175162 generic_unplug_device                    1317.0075
165480 __copy_from_user_ll                      1272.9231
161151 __copy_to_user_ll                        1342.9250
152106 schedule 85.0705
142395 DAC960_LP_InterruptHandler 761.4706
113677 dm_table_unplug_all 1386.3049
65420 __make_request 45.5571
64832 dm_table_any_congested 697.1183
37913 try_to_wake_up 32.2939

Quoted 4 lines

That's broken. How many disks are involve in the DM stack?
The relevant code was reworked subsequent to 2.6.4-mm2. Maybe we fixed this, but I cannot immediately explain what you're seeing here.

Ugh that looks really bad, I wonder how it could possibly ever be this bad. Mark, please do do a run with 2.6.5-rc1-mm2, I'd very much like to see the profile there. If things get this bad, I need to think some more about how to best handle the 'when to invoke request_fn on unplug calls' logic again.

Actually, please also do a run with 2.6.5-rc1-mm2 + inlined patch. For non-stacked dm on dm it should work and could make a lot of difference for you.

block/ll_rw_blk.c renamed from block/ll_rw_blk.c~ +2 -5

@@ -1134,11 +1134,8 @@
 	if (test_bit(QUEUE_FLAG_STOPPED, &q->queue_flags))
 		return;
 
-	/*
-	 * always call down, since we can race now with setting the plugged
-	 * bit outside of the queue lock
-	 */
-	blk_remove_plug(q);
+	if (!blk_remove_plug(q))
+		return;
 
 	/*
 	 * was plugged, fire request_fn if queue has stuff to do

Signature · 1 line

Jens Axboe

[email protected]

2004-03-19 00:22 UTC #58 lore raw

Quoted 38 lines · Jens Axboe

Quoted 15 lines · Andrew Morton
Quoted 3 lines
Comparing one pair of readprofile results, I find it curious that dm_table_unplug_all and dm_table_any_congested show up near the top of a 2.6.4-mm2 profile when they haven't shown up before in 2.6.3.
14015190 poll_idle 241641.2069
175162 generic_unplug_device                    1317.0075
165480 __copy_from_user_ll                      1272.9231
161151 __copy_to_user_ll                        1342.9250
152106 schedule 85.0705
142395 DAC960_LP_InterruptHandler 761.4706
113677 dm_table_unplug_all 1386.3049
65420 __make_request 45.5571
64832 dm_table_any_congested 697.1183
37913 try_to_wake_up 32.2939
Quoted 4 lines
That's broken. How many disks are involve in the DM stack?
The relevant code was reworked subsequent to 2.6.4-mm2. Maybe we fixed this, but I cannot immediately explain what you're seeing here.
Ugh that looks really bad, I wonder how it could possibly ever be this bad. Mark, please do do a run with 2.6.5-rc1-mm2, I'd very much like to see the profile there. If things get this bad, I need to think some more about how to best handle the 'when to invoke request_fn on unplug calls' logic again.
Actually, please also do a run with 2.6.5-rc1-mm2 + inlined patch. For non-stacked dm on dm it should work and could make a lot of difference for you.
block/ll_rw_blk.c renamed from block/ll_rw_blk.c~ +0 -0
@@ -1134,11 +1134,8 @@
 	if (test_bit(QUEUE_FLAG_STOPPED, &q->queue_flags))
 		return;
 

block/ll_rw_blk.c line 1141

Quoted 10 lines

block/ll_rw_blk.c renamed from block/ll_rw_blk.c~ +2 -5

-	/*
-	 * always call down, since we can race now with setting the plugged
-	 * bit outside of the queue lock
-	 */
-	blk_remove_plug(q);
+	if (!blk_remove_plug(q))
+		return;
 
 	/*
 	 * was plugged, fire request_fn if queue has stuff to do

http://developer.osdl.org/markw/dbt2-pgsql/409/

There are the results with 2.6.5-rc1-mm2 with your patch with a 512kb stripe width. The throughput didn't improve but it did cut the ticks for dm_table_unplug_all in half. Should I continue with smaller stripe widths?

Jens Axboe

2004-03-19 07:41 UTC #59 lore raw

Quoted 52 lines · On Thu, Mar 18 2004, [email protected] wrote:

Quoted 38 lines · Jens Axboe
Quoted 15 lines · Andrew Morton
Quoted 3 lines
Comparing one pair of readprofile results, I find it curious that dm_table_unplug_all and dm_table_any_congested show up near the top of a 2.6.4-mm2 profile when they haven't shown up before in 2.6.3.
14015190 poll_idle 241641.2069
175162 generic_unplug_device                    1317.0075
165480 __copy_from_user_ll                      1272.9231
161151 __copy_to_user_ll                        1342.9250
152106 schedule 85.0705
142395 DAC960_LP_InterruptHandler 761.4706
113677 dm_table_unplug_all 1386.3049
65420 __make_request 45.5571
64832 dm_table_any_congested 697.1183
37913 try_to_wake_up 32.2939
Quoted 4 lines
That's broken. How many disks are involve in the DM stack?
The relevant code was reworked subsequent to 2.6.4-mm2. Maybe we fixed this, but I cannot immediately explain what you're seeing here.
Ugh that looks really bad, I wonder how it could possibly ever be this bad. Mark, please do do a run with 2.6.5-rc1-mm2, I'd very much like to see the profile there. If things get this bad, I need to think some more about how to best handle the 'when to invoke request_fn on unplug calls' logic again.
Actually, please also do a run with 2.6.5-rc1-mm2 + inlined patch. For non-stacked dm on dm it should work and could make a lot of difference for you.
block/ll_rw_blk.c renamed from block/ll_rw_blk.c~ +0 -0
@@ -1134,11 +1134,8 @@
 	if (test_bit(QUEUE_FLAG_STOPPED, &q->queue_flags))
 		return;
 
block/ll_rw_blk.c line 1141
Quoted 10 lines
block/ll_rw_blk.c renamed from block/ll_rw_blk.c~ +2 -5
-	/*
-	 * always call down, since we can race now with setting the plugged
-	 * bit outside of the queue lock
-	 */
-	blk_remove_plug(q);
+	if (!blk_remove_plug(q))
+		return;
 
 	/*
 	 * was plugged, fire request_fn if queue has stuff to do
http://developer.osdl.org/markw/dbt2-pgsql/409/

Quoted 4 lines

There are the results with 2.6.5-rc1-mm2 with your patch with a 512kb stripe width. The throughput didn't improve but it did cut the ticks for dm_table_unplug_all in half. Should I continue with smaller stripe widths?

Wait for a real patch first, I'll have one for you in an hour or two.

Signature · 1 line

Jens Axboe

Andrew Morton

author

2004-03-19 03:15 UTC #60 lore raw

In reply to Jens Axboe

Quoted 17 lines · Jens Axboe

Quoted 15 lines · Andrew Morton
Quoted 3 lines
Comparing one pair of readprofile results, I find it curious that dm_table_unplug_all and dm_table_any_congested show up near the top of a 2.6.4-mm2 profile when they haven't shown up before in 2.6.3.
14015190 poll_idle 241641.2069
175162 generic_unplug_device                    1317.0075
165480 __copy_from_user_ll                      1272.9231
161151 __copy_to_user_ll                        1342.9250
152106 schedule 85.0705
142395 DAC960_LP_InterruptHandler 761.4706
113677 dm_table_unplug_all 1386.3049
65420 __make_request 45.5571
64832 dm_table_any_congested 697.1183
37913 try_to_wake_up 32.2939

Quoted 7 lines

Quoted 4 lines
That's broken. How many disks are involve in the DM stack?
The relevant code was reworked subsequent to 2.6.4-mm2. Maybe we fixed this, but I cannot immediately explain what you're seeing here.
Ugh that looks really bad, I wonder how it could possibly ever be this bad.

generic_unplug_device() is only sucking 0.5% of total CPU capacity, so perhaps we need to be looking elsewhere for the source of the slowdown.

I suggest we do something like this:

drivers/md/dm-table.c renamed from drivers/md/dm-table.c~a +1 -1

@@ -893,7 +893,7 @@ void dm_table_unplug_all(struct dm_table
 		struct dm_dev *dd = list_entry(d, struct dm_dev, list);
 		request_queue_t *q = bdev_get_queue(dd->bdev);
 
-		if (q->unplug_fn)
+		if (q->unplug_fn && queue_needs_unplug(q)))
 			q->unplug_fn(q);
 	}
 }

to reduce the computational expense of dm_table_unplug_all() a bit.

But we're barking up the wrong tree here. Mark, if it's OK I'll run up some kernels for you to test.

Jens Axboe

2004-03-19 07:39 UTC #61 lore raw

Quoted 44 lines · Andrew Morton

Quoted 17 lines · Jens Axboe
Quoted 15 lines · Andrew Morton
Quoted 3 lines
Comparing one pair of readprofile results, I find it curious that dm_table_unplug_all and dm_table_any_congested show up near the top of a 2.6.4-mm2 profile when they haven't shown up before in 2.6.3.
14015190 poll_idle 241641.2069
175162 generic_unplug_device                    1317.0075
165480 __copy_from_user_ll                      1272.9231
161151 __copy_to_user_ll                        1342.9250
152106 schedule 85.0705
142395 DAC960_LP_InterruptHandler 761.4706
113677 dm_table_unplug_all 1386.3049
65420 __make_request 45.5571
64832 dm_table_any_congested 697.1183
37913 try_to_wake_up 32.2939
Quoted 7 lines
Quoted 4 lines
That's broken. How many disks are involve in the DM stack?
The relevant code was reworked subsequent to 2.6.4-mm2. Maybe we fixed this, but I cannot immediately explain what you're seeing here.
Ugh that looks really bad, I wonder how it could possibly ever be this bad.
generic_unplug_device() is only sucking 0.5% of total CPU capacity, so perhaps we need to be looking elsewhere for the source of the slowdown.
I suggest we do something like this:
drivers/md/dm-table.c renamed from drivers/md/dm-table.c~a +1 -1
@@ -893,7 +893,7 @@ void dm_table_unplug_all(struct dm_table
 		struct dm_dev *dd = list_entry(d, struct dm_dev, list);
 		request_queue_t *q = bdev_get_queue(dd->bdev);
 
-		if (q->unplug_fn)
+		if (q->unplug_fn && queue_needs_unplug(q)))
 			q->unplug_fn(q);
 	}
 }

Quoted 4 lines

to reduce the computational expense of dm_table_unplug_all() a bit.
But we're barking up the wrong tree here. Mark, if it's OK I'll run up some kernels for you to test.

I thought about this last night, and I have a better idea that gets the same accomplished. The problem right now is indeed that we aren't tracking who needs to be unplugged, like we used to. The solution is to do the exact same style plugging (with block helpers) that we used to, except the plug_list is maintained in the driver. So when you do dm_unplug(), it doesn't _have_ to iterate the full device list, only those that do need kicking.

I'll produce a patch to fix this this morning. First coffee.

Signature · 1 line

Jens Axboe

Andrew Morton

author

2004-03-19 07:52 UTC #62 lore raw

Quoted 27 lines · Jens Axboe

Quoted 14 lines
drivers/md/dm-table.c renamed from drivers/md/dm-table.c~a +1 -1
@@ -893,7 +893,7 @@ void dm_table_unplug_all(struct dm_table
 		struct dm_dev *dd = list_entry(d, struct dm_dev, list);
 		request_queue_t *q = bdev_get_queue(dd->bdev);
 
-		if (q->unplug_fn)
+		if (q->unplug_fn && queue_needs_unplug(q)))
 			q->unplug_fn(q);
 	}
 }
Quoted 4 lines
to reduce the computational expense of dm_table_unplug_all() a bit.
But we're barking up the wrong tree here. Mark, if it's OK I'll run up some kernels for you to test.
I thought about this last night, and I have a better idea that gets the same accomplished. The problem right now is indeed that we aren't tracking who needs to be unplugged, like we used to. The solution is to do the exact same style plugging (with block helpers) that we used to, except the plug_list is maintained in the driver. So when you do dm_unplug(), it doesn't _have_ to iterate the full device list, only those that do need kicking.

Quoted 1 line

I'll produce a patch to fix this this morning. First coffee.

Yes, it would be nice but I fear that it gets complicated.

Is it not the case that two dm maps can refer to the same queue? Say, one map uses /dev/hda1 and another map uses /dev/hda2?

If so, then when the /dev/hda queue is plugged we need to tell both the higher-level maps that this queue needs an unplug. So blk_plug_device() and the various unplug functions need to perform upcalls to an arbitrary number of higher-level drivers, and those drivers need to keep track of the currently-plugged queues without adding data structures to the request_queue structure.

It can be done of course, but could get messy.

Or am I missing something?

Jens Axboe

2004-03-19 07:57 UTC #63 lore raw

Quoted 35 lines · Andrew Morton

Quoted 27 lines · Jens Axboe
Quoted 14 lines
drivers/md/dm-table.c renamed from drivers/md/dm-table.c~a +1 -1
@@ -893,7 +893,7 @@ void dm_table_unplug_all(struct dm_table
 		struct dm_dev *dd = list_entry(d, struct dm_dev, list);
 		request_queue_t *q = bdev_get_queue(dd->bdev);
 
-		if (q->unplug_fn)
+		if (q->unplug_fn && queue_needs_unplug(q)))
 			q->unplug_fn(q);
 	}
 }
Quoted 4 lines
to reduce the computational expense of dm_table_unplug_all() a bit.
But we're barking up the wrong tree here. Mark, if it's OK I'll run up some kernels for you to test.
I thought about this last night, and I have a better idea that gets the same accomplished. The problem right now is indeed that we aren't tracking who needs to be unplugged, like we used to. The solution is to do the exact same style plugging (with block helpers) that we used to, except the plug_list is maintained in the driver. So when you do dm_unplug(), it doesn't _have_ to iterate the full device list, only those that do need kicking.
Quoted 1 line
I'll produce a patch to fix this this morning. First coffee.
Yes, it would be nice but I fear that it gets complicated.
Is it not the case that two dm maps can refer to the same queue? Say, one map uses /dev/hda1 and another map uses /dev/hda2?

Quoted 8 lines

If so, then when the /dev/hda queue is plugged we need to tell both the higher-level maps that this queue needs an unplug. So blk_plug_device() and the various unplug functions need to perform upcalls to an arbitrary number of higher-level drivers, and those drivers need to keep track of the currently-plugged queues without adding data structures to the request_queue structure.
It can be done of course, but could get messy.

That would get nasty, it's much more natural to track it from the other end. I view it as a dm (or whatever problem) that they need to track who has pending io on their behalf, which is pretty easy to to from eg __map_bio().

The only addition is putting the old q->plug_list back, but using it on stacking drivers like dm. dm then maintains a per-dm plugged list that it can use when dm_unplug() runs.

Signature · 1 line

Jens Axboe

Andrew Morton

author

2004-03-19 08:19 UTC #64 lore raw

Quoted 11 lines · Jens Axboe

Quoted 11 lines
Is it not the case that two dm maps can refer to the same queue? Say, one map uses /dev/hda1 and another map uses /dev/hda2?
If so, then when the /dev/hda queue is plugged we need to tell both the higher-level maps that this queue needs an unplug. So blk_plug_device() and the various unplug functions need to perform upcalls to an arbitrary number of higher-level drivers, and those drivers need to keep track of the currently-plugged queues without adding data structures to the request_queue structure.

Quoted 6 lines

Quoted 1 line
It can be done of course, but could get messy.
That would get nasty, it's much more natural to track it from the other end. I view it as a dm (or whatever problem) that they need to track who has pending io on their behalf, which is pretty easy to to from eg __map_bio().

But dm doesn't know enough. Suppose it is managing a map which includes /dev/hda1 and I do some I/O against /dev/hda2 which plugs the queue. dm needs to know about that plug.

Actually the data structure isn't toooo complex.

- In the request_queue add a list_head of "interested drivers"

- In a dm map, add:

	struct interested_driver {
		list_head list;
		void (*plug_upcall)(struct request_queue *q, void *private);
		void (*unplug_upcall)(struct request_queue *q, void *private);
		void *private;
	}

and when setting up a map, dm does:

blk_register_interested_driver(struct request_queue *q,
struct interested_driver *d)

  {
	list_add(&d->list, q->interested_driver_list);

}

- In blk_device_plug():

     list_for_each_entry(d, q->interested_driver_list, list) {
	(*d->plug_upcall)(q, d->private);
     }

- Similar in the unplug functions.

And in dm, maintain a dynamically allocated array of request_queue*'s:

dm_plug_upcall(struct request_queue *q, void *private)

  {
	map = private;

	map->plugged_queues[map->nr_plugged_queues++] = q;

}

dm_unplug_upcall(struct request_queue *q, void *private)

  {
	map = private;

 	for (i = 0; i < map->nr_plugged_queues; i++) {
		if (map->plugged_queues[i] == q) {
			memcpy(&map->plugged_queues[i],
				&map->plugged_queues[i+1],
				<whatever>
		}
	}

}

unplug_upcall is a bit sucky, but they're much less frequent than the current unplug downcalls.

Frankly, I wouldn't bother. 0.5% CPU when hammering the crap out of a 56-disk LVM isn't too bad. I'd suggest you first try to simply reduce the number of cache misses in the inner loop, see what that leaves us with.

Jens Axboe

2004-03-19 08:31 UTC #65 lore raw

Quoted 14 lines · Andrew Morton

Quoted 13 lines · Jens Axboe
Quoted 12 lines
Is it not the case that two dm maps can refer to the same queue? Say, one map uses /dev/hda1 and another map uses /dev/hda2?
If so, then when the /dev/hda queue is plugged we need to tell both the higher-level maps that this queue needs an unplug. So blk_plug_device() and the various unplug functions need to perform upcalls to an arbitrary number of higher-level drivers, and those drivers need to keep track of the currently-plugged queues without adding data structures to the request_queue structure.
It can be done of course, but could get messy.

Quoted 8 lines

Quoted 4 lines
That would get nasty, it's much more natural to track it from the other end. I view it as a dm (or whatever problem) that they need to track who has pending io on their behalf, which is pretty easy to to from eg __map_bio().
But dm doesn't know enough. Suppose it is managing a map which includes /dev/hda1 and I do some I/O against /dev/hda2 which plugs the queue. dm needs to know about that plug.

I don't follow at all. If dm initiates io against /dev/hda2, it's part of that mapped device and it can trigger and note the unplug just fine. If io goes through a 2nd level of dm maps that isn't an issue either, the 2nd level dm device will maintain the state needed to unplug that device automagically.

But it does get a bit hairy, and I'm getting lost in dm data structures...

Quoted 50 lines

Actually the data structure isn't toooo complex.
- In the request_queue add a list_head of "interested drivers"
- In a dm map, add:
	struct interested_driver {
		list_head list;
		void (*plug_upcall)(struct request_queue *q, void *private);
		void (*unplug_upcall)(struct request_queue *q, void *private);
		void *private;
	}
and when setting up a map, dm does:
blk_register_interested_driver(struct request_queue *q,
struct interested_driver *d)
  {
	list_add(&d->list, q->interested_driver_list);
}
- In blk_device_plug():
     list_for_each_entry(d, q->interested_driver_list, list) {
	(*d->plug_upcall)(q, d->private);
     }
- Similar in the unplug functions.
And in dm, maintain a dynamically allocated array of request_queue*'s:
dm_plug_upcall(struct request_queue *q, void *private)
  {
	map = private;

	map->plugged_queues[map->nr_plugged_queues++] = q;
}
dm_unplug_upcall(struct request_queue *q, void *private)
  {
	map = private;
 	for (i = 0; i < map->nr_plugged_queues; i++) {
		if (map->plugged_queues[i] == q) {
			memcpy(&map->plugged_queues[i],
				&map->plugged_queues[i+1],
				<whatever>
		}
	}

Quoted 4 lines

}
unplug_upcall is a bit sucky, but they're much less frequent than the current unplug downcalls.

I guess that'd work ok, as far as I can see..

Quoted 3 lines

Frankly, I wouldn't bother. 0.5% CPU when hammering the crap out of a 56-disk LVM isn't too bad. I'd suggest you first try to simply reduce the number of cache misses in the inner loop, see what that leaves us with.

Yeah I guess you are right, probably not a worry. At least not now, and the dm folks can always play with the above if they want.

I'll send you a small update for -mm with the unconditional unplug killed (at least it cuts it in half) and analyzed the loop.

Signature · 1 line

Jens Axboe

Andrew Morton

author

2004-03-19 08:39 UTC #66 lore raw

Quoted 21 lines · Jens Axboe

Quoted 19 lines · Andrew Morton
Quoted 17 lines · Jens Axboe
Quoted 4 lines
Is it not the case that two dm maps can refer to the same queue? Say, one map uses /dev/hda1 and another map uses /dev/hda2?
Quoted 8 lines
If so, then when the /dev/hda queue is plugged we need to tell both the higher-level maps that this queue needs an unplug. So blk_plug_device() and the various unplug functions need to perform upcalls to an arbitrary number of higher-level drivers, and those drivers need to keep track of the currently-plugged queues without adding data structures to the request_queue structure.
It can be done of course, but could get messy.
That would get nasty, it's much more natural to track it from the other end. I view it as a dm (or whatever problem) that they need to track who has pending io on their behalf, which is pretty easy to to from eg __map_bio().

Quoted 6 lines

Quoted 3 lines
But dm doesn't know enough. Suppose it is managing a map which includes /dev/hda1 and I do some I/O against /dev/hda2 which plugs the queue. dm needs to know about that plug.
I don't follow at all. If dm initiates io against /dev/hda2, it's part of that mapped device and it can trigger and note the unplug just fine.

Right. But suppose I have a plain old ext2 fs mounted on /dev/hda1. I do some I/O against /dev/hda1, and that causes the /dev/hda queue to be plugged. Device mapper doesn't know that the queue is currently plugged, because it was some totally unrelated piece of code which caused the plug.

Quoted 9 lines

Quoted 3 lines
Frankly, I wouldn't bother. 0.5% CPU when hammering the crap out of a 56-disk LVM isn't too bad. I'd suggest you first try to simply reduce the number of cache misses in the inner loop, see what that leaves us with.
Yeah I guess you are right, probably not a worry. At least not now, and the dm folks can always play with the above if they want.
I'll send you a small update for -mm with the unconditional unplug killed (at least it cuts it in half) and analyzed the loop.

OK...

Jens Axboe

2004-03-19 08:48 UTC #67 lore raw

Quoted 26 lines · Andrew Morton

Quoted 25 lines · Jens Axboe
Quoted 22 lines · Andrew Morton
Quoted 11 lines · Jens Axboe
Quoted 11 lines
Is it not the case that two dm maps can refer to the same queue? Say, one map uses /dev/hda1 and another map uses /dev/hda2?
If so, then when the /dev/hda queue is plugged we need to tell both the higher-level maps that this queue needs an unplug. So blk_plug_device() and the various unplug functions need to perform upcalls to an arbitrary number of higher-level drivers, and those drivers need to keep track of the currently-plugged queues without adding data structures to the request_queue structure.
Quoted 6 lines
Quoted 1 line
It can be done of course, but could get messy.
That would get nasty, it's much more natural to track it from the other end. I view it as a dm (or whatever problem) that they need to track who has pending io on their behalf, which is pretty easy to to from eg __map_bio().
But dm doesn't know enough. Suppose it is managing a map which includes /dev/hda1 and I do some I/O against /dev/hda2 which plugs the queue. dm needs to know about that plug.

Quoted 7 lines

Quoted 2 lines
I don't follow at all. If dm initiates io against /dev/hda2, it's part of that mapped device and it can trigger and note the unplug just fine.
Right. But suppose I have a plain old ext2 fs mounted on /dev/hda1. I do some I/O against /dev/hda1, and that causes the /dev/hda queue to be plugged. Device mapper doesn't know that the queue is currently plugged, because it was some totally unrelated piece of code which caused the plug.

You are right, that breaks. No good.

Signature · 1 line

Jens Axboe

Miquel van Smoorenburg

2004-03-19 09:56 UTC #68 lore raw

In reply to Andrew Morton

In article <[email protected]> you write:

Quoted 14 lines

Quoted 7 lines · Jens Axboe
I thought about this last night, and I have a better idea that gets the same accomplished. The problem right now is indeed that we aren't tracking who needs to be unplugged, like we used to. The solution is to do the exact same style plugging (with block helpers) that we used to, except the plug_list is maintained in the driver. So when you do dm_unplug(), it doesn't _have_ to iterate the full device list, only those that do need kicking.
Yes, it would be nice but I fear that it gets complicated.
Is it not the case that two dm maps can refer to the same queue? Say, one map uses /dev/hda1 and another map uses /dev/hda2?

Quoted 8 lines

If so, then when the /dev/hda queue is plugged we need to tell both the higher-level maps that this queue needs an unplug. So blk_plug_device() and the various unplug functions need to perform upcalls to an arbitrary number of higher-level drivers, and those drivers need to keep track of the currently-plugged queues without adding data structures to the request_queue structure.
It can be done of course, but could get messy.

I implemented exactly this for the congestion stuff. It isn't perfect, but perhaps it is of some use:

https://www.redhat.com/archives/linux-lvm/2004-February/msg00215.html

It got shot down because it was too complicated..

Mike.

Signature · 1 line

Netu, v qba'g yvxr gur cynvagrkg :)

Jens Axboe

2004-03-19 10:00 UTC #69 lore raw

Quoted 22 lines · Miquel van Smoorenburg

In article <[email protected]> you write:
Quoted 21 lines
Quoted 7 lines · Jens Axboe
I thought about this last night, and I have a better idea that gets the same accomplished. The problem right now is indeed that we aren't tracking who needs to be unplugged, like we used to. The solution is to do the exact same style plugging (with block helpers) that we used to, except the plug_list is maintained in the driver. So when you do dm_unplug(), it doesn't _have_ to iterate the full device list, only those that do need kicking.
Yes, it would be nice but I fear that it gets complicated.
Is it not the case that two dm maps can refer to the same queue? Say, one map uses /dev/hda1 and another map uses /dev/hda2?
If so, then when the /dev/hda queue is plugged we need to tell both the higher-level maps that this queue needs an unplug. So blk_plug_device() and the various unplug functions need to perform upcalls to an arbitrary number of higher-level drivers, and those drivers need to keep track of the currently-plugged queues without adding data structures to the request_queue structure.

Quoted 8 lines

Quoted 1 line
It can be done of course, but could get messy.
I implemented exactly this for the congestion stuff. It isn't perfect, but perhaps it is of some use:
https://www.redhat.com/archives/linux-lvm/2004-February/msg00215.html
It got shot down because it was too complicated..

It is, at least the profiles so far don't even warrant it. It's worth to keep in mind, though.

Signature · 1 line

Jens Axboe

A message that is not in the archive (sent off-list or not yet received): [email protected]

Mark Wong

2004-03-20 02:39 UTC #71 lore raw

Quoted 7 lines · Andrew Morton

Quoted 2 lines · Andrew Morton
Mark, if it's OK I'll run up some kernels for you to test.
At
http://www.zip.com.au/~akpm/linux/patches/markw/

Ok, looks like I take the first hit with the 02 patch. Here's re-summary:

kernel          16 kb   32 kb   64 kb   128 kb  256 kb  512 kb
2.6.3                           2308    2335    2348    2334
2.6.4-mm2       2028    2048    2074    2096    2082    2078
2.6.5-rc1-01                                            2394
2.6.5-rc1-02                                            2117
2.6.5-rc1-mm2                                           2036

Mark Wong

2004-03-20 02:47 UTC #72 lore raw

Quoted 9 lines · Mark Wong

Quoted 7 lines · Andrew Morton
Quoted 2 lines · Andrew Morton
Mark, if it's OK I'll run up some kernels for you to test.
At
http://www.zip.com.au/~akpm/linux/patches/markw/

Quoted 8 lines

Ok, looks like I take the first hit with the 02 patch. Here's re-summary:

kernel          16 kb   32 kb   64 kb   128 kb  256 kb  512 kb
2.6.3                           2308    2335    2348    2334
2.6.4-mm2       2028    2048    2074    2096    2082    2078
2.6.5-rc1-01                                            2394
2.6.5-rc1-02                                            2117
2.6.5-rc1-mm2                                           2036

Meant to recopy the link too:
http://developer.osdl.org/markw/linux/2.6-pagecache.html

Andrew Morton

author

2004-03-20 02:50 UTC #73 lore raw

In reply to Mark Wong

Quoted 10 lines · Mark Wong

Quoted 7 lines · Andrew Morton
Quoted 2 lines · Andrew Morton
Mark, if it's OK I'll run up some kernels for you to test.
At
http://www.zip.com.au/~akpm/linux/patches/markw/

Quoted 8 lines

Ok, looks like I take the first hit with the 02 patch. Here's re-summary:

kernel          16 kb   32 kb   64 kb   128 kb  256 kb  512 kb
2.6.3                           2308    2335    2348    2334
2.6.4-mm2       2028    2048    2074    2096    2082    2078
2.6.5-rc1-01                                            2394
2.6.5-rc1-02                                            2117
2.6.5-rc1-mm2                                           2036

Thanks, so it's the CPU scheduler changes. Is that machine hyperthreaded? And do you have CONFIG_X86_HT enabled?

Mark Wong

2004-03-20 02:53 UTC #74 lore raw

Quoted 20 lines · Andrew Morton

Quoted 10 lines · Mark Wong
Quoted 7 lines · Andrew Morton
Quoted 2 lines · Andrew Morton
Mark, if it's OK I'll run up some kernels for you to test.
At
http://www.zip.com.au/~akpm/linux/patches/markw/
Quoted 8 lines
Ok, looks like I take the first hit with the 02 patch. Here's re-summary:
kernel          16 kb   32 kb   64 kb   128 kb  256 kb  512 kb
2.6.3                           2308    2335    2348    2334
2.6.4-mm2       2028    2048    2074    2096    2082    2078
2.6.5-rc1-01                                            2394
2.6.5-rc1-02                                            2117
2.6.5-rc1-mm2                                           2036

Quoted 2 lines

Thanks, so it's the CPU scheduler changes. Is that machine hyperthreaded? And do you have CONFIG_X86_HT enabled?

Yes and CONFIG_X86_HT is enabled but I have hyperthreading disabled with 'acpi=off noht' (whichever one does it.)

Nick Piggin

2004-03-20 03:52 UTC #75 lore raw

Quoted 23 lines · Mark Wong

Quoted 21 lines · Andrew Morton
Quoted 19 lines · Mark Wong
Quoted 8 lines · Andrew Morton
Quoted 2 lines · Andrew Morton
Mark, if it's OK I'll run up some kernels for you to test.
At
http://www.zip.com.au/~akpm/linux/patches/markw/
Ok, looks like I take the first hit with the 02 patch. Here's re-summary:
kernel          16 kb   32 kb   64 kb   128 kb  256 kb  512 kb
2.6.3                           2308    2335    2348    2334
2.6.4-mm2       2028    2048    2074    2096    2082    2078
2.6.5-rc1-01                                            2394
2.6.5-rc1-02                                            2117
2.6.5-rc1-mm2                                           2036

Quoted 6 lines

Quoted 2 lines
Thanks, so it's the CPU scheduler changes. Is that machine hyperthreaded? And do you have CONFIG_X86_HT enabled?
Yes and CONFIG_X86_HT is enabled but I have hyperthreading disabled with 'acpi=off noht' (whichever one does it.)

The oprofile for the 01 kernel says
CPU: P4 / Xeon, speed 1497.76 MHz (estimated)
while the 02 kernel says
CPU: P4 / Xeon with 2 hyper-threads, speed 1497.57 MHz (estimated) What's going on there?

Other than that, nothing in the kernel profile jumps out at me:
schedule, __copy_from_user_ll and __copy_to_user_ll are all significantly lower *after* the CPU scheduler changes, which is an indicator that cache behaviour is better.

Sar says average context switches/second were 9064 and 6567 before and after.

The only thing I can see is the CPU utilisation averages show the scheduler patches have more of a tendancy to load up one CPU more before moving to another. This actually should be good behaviour, generally but I wonder if it is hurting at all. I would be really surprised if it was that significant.

Andrew Morton

author

2004-03-20 04:14 UTC #76 lore raw

Quoted 11 lines · Nick Piggin

Quoted 9 lines
Quoted 5 lines
Quoted 2 lines
Thanks, so it's the CPU scheduler changes. Is that machine hyperthreaded? And do you have CONFIG_X86_HT enabled?
Yes and CONFIG_X86_HT is enabled but I have hyperthreading disabled with 'acpi=off noht' (whichever one does it.)

Quoted 5 lines

The oprofile for the 01 kernel says
CPU: P4 / Xeon, speed 1497.76 MHz (estimated)
while the 02 kernel says
CPU: P4 / Xeon with 2 hyper-threads, speed 1497.57 MHz (estimated) What's going on there?

Does the sched-domains patch break acpi=off' or noht'?

Quoted 4 lines

Other than that, nothing in the kernel profile jumps out at me:
schedule, __copy_from_user_ll and __copy_to_user_ll are all significantly lower *after* the CPU scheduler changes, which is an indicator that cache behaviour is better.

No, it indicates that the kernel is getting less work done.

Quoted 8 lines

Sar says average context switches/second were 9064 and 6567 before and after.
The only thing I can see is the CPU utilisation averages show the scheduler patches have more of a tendancy to load up one CPU more before moving to another. This actually should be good behaviour, generally but I wonder if it is hurting at all. I would be really surprised if it was that significant.

This machine is I/O-bound, the CPUs are mostly idle. It would appear to be some interaction between the I/O system and the CPU scheduler. Haven't we seen that with reaim also?

Nick Piggin

2004-03-20 04:28 UTC #77 lore raw

Quoted 11 lines · Andrew Morton

Quoted 9 lines · Nick Piggin
Quoted 7 lines
Quoted 3 lines
Quoted 1 line
Thanks, so it's the CPU scheduler changes. Is that machine hyperthreaded? And do you have CONFIG_X86_HT enabled?
Yes and CONFIG_X86_HT is enabled but I have hyperthreading disabled with 'acpi=off noht' (whichever one does it.)

Quoted 10 lines

Quoted 6 lines
The oprofile for the 01 kernel says
CPU: P4 / Xeon, speed 1497.76 MHz (estimated)
while the 02 kernel says
CPU: P4 / Xeon with 2 hyper-threads, speed 1497.57 MHz (estimated) What's going on there?
Does the sched-domains patch break acpi=off' or noht'?

Shouldnt.

Quoted 9 lines

Quoted 5 lines
Other than that, nothing in the kernel profile jumps out at me:
schedule, __copy_from_user_ll and __copy_to_user_ll are all significantly lower *after* the CPU scheduler changes, which is an indicator that cache behaviour is better.
No, it indicates that the kernel is getting less work done.

If you are measuring the same period of time, yes. If you are measuring the same amount of work, no. I assumed the latter. Maybe I'm wrong.

Quoted 10 lines

Quoted 9 lines
Sar says average context switches/second were 9064 and 6567 before and after.
The only thing I can see is the CPU utilisation averages show the scheduler patches have more of a tendancy to load up one CPU more before moving to another. This actually should be good behaviour, generally but I wonder if it is hurting at all. I would be really surprised if it was that significant.

Quoted 5 lines

This machine is I/O-bound, the CPUs are mostly idle. It would appear to be some interaction between the I/O system and the CPU scheduler. Haven't we seen that with reaim also?

I can't remember how much CPU reaim uses, I thought it was quite a lot (ie. not IO bound).

Nick Piggin

2004-03-20 04:30 UTC #78 lore raw

Quoted 14 lines · Nick Piggin

Quoted 10 lines · Andrew Morton
Quoted 7 lines · Nick Piggin
The oprofile for the 01 kernel says
CPU: P4 / Xeon, speed 1497.76 MHz (estimated)
while the 02 kernel says
CPU: P4 / Xeon with 2 hyper-threads, speed 1497.57 MHz (estimated) What's going on there?

Quoted 6 lines

Quoted 3 lines
Does the sched-domains patch break acpi=off' or noht'?
Shouldnt.

sched-sibling-map-to-cpumask.patch may. Sorry I don't have time to check it right now. Got to go.

Martin J. Bligh

2004-03-20 21:18 UTC #79 lore raw

In reply to Nick Piggin

Quoted 6 lines

Quoted 3 lines
This machine is I/O-bound, the CPUs are mostly idle. It would appear to be some interaction between the I/O system and the CPU scheduler. Haven't we seen that with reaim also?
I can't remember how much CPU reaim uses, I thought it was quite a lot (ie. not IO bound).

aim / reaim supports multiple different workloads (including custom ones) - whether it's IO bound or CPU bound depends on which you pick.

Mary Edie Meredith

2004-03-22 17:19 UTC #80 lore raw

In reply to Mark Wong

[was "Poor DBT-3 pgsql 8way numbers on recent 2.6 mm kernels" on linux-mm]

Andrew,

This same patch (02) applied in STP (plm 2780) when run against dbt3-pgsql DSS workload displays the performance problem with the throughput numbers that I reported on linux-mm on our 8way systems, where the previous patch (plm 2777 -01) does not.

Here is the data (patches applied to 2.6.5-rc1)

PLM.....CPUs.Runid..Thruput Metric (bigger is better)

2777(01)  8  290298  138.22  (base  )
2779(02)  8  290304  88.57   (-35.9%)

The 8way is a 700MHz (1024k processor cache) with 8GB of memory.

Original message on linux-mm:
http://marc.theaimsgroup.com/?l=linux-mm&m=107913089923436&w=2

Results from runid 290298 (the good result);
http://khack.osdl.org/stp/290298/ (top level)

Results from runid 290304 (the bad result):
http://khack.osdl.org/stp/290305/ (top level)
For sar results see "Raw data" section everything labeled as
"thruput.sar."
http://khack.osdl.org/stp/290305/profile/after_throughput_test_1-tick.top20 (profile of throughput phase of the test)
http://khack.osdl.org/stp/290305/results/plot/thuput.vmstat.txt
(vmstat of thoughput phase of the test)

Quoted 22 lines · Mark Wong

Quoted 7 lines · Andrew Morton
Quoted 2 lines · Andrew Morton
Mark, if it's OK I'll run up some kernels for you to test.
At
http://www.zip.com.au/~akpm/linux/patches/markw/
Ok, looks like I take the first hit with the 02 patch. Here's re-summary:
kernel          16 kb   32 kb   64 kb   128 kb  256 kb  512 kb
2.6.3                           2308    2335    2348    2334
2.6.4-mm2       2028    2048    2074    2096    2082    2078
2.6.5-rc1-01                                            2394
2.6.5-rc1-02                                            2117
2.6.5-rc1-mm2                                           2036
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Signature · 10 lines

Mary Edie Meredith 
[email protected]
503-626-2455 x42
Open Source Development Labs

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

Andrew Morton

author

2004-03-23 00:25 UTC #81 lore raw

Quoted 11 lines · Mary Edie Meredith

[was "Poor DBT-3 pgsql 8way numbers on recent 2.6 mm kernels" on linux-mm]
Andrew,
This same patch (02) applied in STP (plm 2780) when run against dbt3-pgsql DSS workload displays the performance problem with the throughput numbers that I reported on linux-mm on our 8way systems, where the previous patch (plm 2777 -01) does not.

Quoted 5 lines

Here is the data (patches applied to 2.6.5-rc1)
PLM.....CPUs.Runid..Thruput Metric (bigger is better)
2777(01)  8  290298  138.22  (base  )
2779(02)  8  290304  88.57   (-35.9%)

36% regression due to the CPU scheduler changes? ow.

And that machine is a PIII, so presumably the setting of CONFIG_SCHED_SMT makes no difference.

Quoted 1 line

From a quick look at the material you have there it appears that this

workload also is very I/O bound. It's a little surprising that the CPU scheduler could make so much difference.

Mary Edie Meredith

2004-03-23 19:21 UTC #82 lore raw

Quoted 18 lines · Andrew Morton

Quoted 11 lines · Mary Edie Meredith
[was "Poor DBT-3 pgsql 8way numbers on recent 2.6 mm kernels" on linux-mm]
Andrew,
This same patch (02) applied in STP (plm 2780) when run against dbt3-pgsql DSS workload displays the performance problem with the throughput numbers that I reported on linux-mm on our 8way systems, where the previous patch (plm 2777 -01) does not.
Quoted 5 lines
Here is the data (patches applied to 2.6.5-rc1)
PLM.....CPUs.Runid..Thruput Metric (bigger is better)
2777(01)  8  290298  138.22  (base  )
2779(02)  8  290304  88.57   (-35.9%)

Quoted 8 lines

36% regression due to the CPU scheduler changes? ow.
And that machine is a PIII, so presumably the setting of CONFIG_SCHED_SMT makes no difference.
Quoted 1 line
From a quick look at the material you have there it appears that this
workload also is very I/O bound. It's a little surprising that the CPU scheduler could make so much difference.

I'm not sure why you think this is IO bound. For the throughput phase of the test (from which the metric above is taken) there is very little physical IO except at the start when the updates occur. They finish in a few minutes, after which there is very little.

http://khack.osdl.org/stp/290304/results/plot/thuput.vmstat_io.png
http://khack.osdl.org/stp/290304/results/plot/thuput.vmstat.txt
Perhaps you were looking at the start or at some other part of the test?

The power test (single stream phase) does not display any performance hit at all compared to the baseline. The throughput test runs eight streams (processes) and does display the problem. Furthermore the problem is worse on 8 ways than on 4 ways. It seems reasonable to me that this could be due to a task schedule issue.

Am I missing something?

Quoted 6 lines

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

Signature · 10 lines

Mary Edie Meredith 
[email protected]
503-626-2455 x42
Open Source Development Labs

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

Andrew Morton

author

2004-03-23 19:32 UTC #83 lore raw

Quoted 16 lines · Mary Edie Meredith

Quoted 9 lines
36% regression due to the CPU scheduler changes? ow.
And that machine is a PIII, so presumably the setting of CONFIG_SCHED_SMT makes no difference.
Quoted 1 line
From a quick look at the material you have there it appears that this
workload also is very I/O bound. It's a little surprising that the CPU scheduler could make so much difference.
I'm not sure why you think this is IO bound. For the throughput phase of the test (from which the metric above is taken) there is very little physical IO except at the start when the updates occur. They finish in a few minutes, after which there is very little.

Quoted 2 lines

http://khack.osdl.org/stp/290304/results/plot/thuput.vmstat_io.png
http://khack.osdl.org/stp/290304/results/plot/thuput.vmstat.txt

There seems to be a large amount of idle time in the profiles and in the vmstat trace.

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

Mary Edie Meredith

2004-03-24 00:07 UTC #84 lore raw

Quoted 17 lines · Andrew Morton

Quoted 16 lines · Mary Edie Meredith
Quoted 9 lines
36% regression due to the CPU scheduler changes? ow.
And that machine is a PIII, so presumably the setting of CONFIG_SCHED_SMT makes no difference.
Quoted 1 line
From a quick look at the material you have there it appears that this
workload also is very I/O bound. It's a little surprising that the CPU scheduler could make so much difference.
I'm not sure why you think this is IO bound. For the throughput phase of the test (from which the metric above is taken) there is very little physical IO except at the start when the updates occur. They finish in a few minutes, after which there is very little.

Quoted 5 lines

Quoted 2 lines
http://khack.osdl.org/stp/290304/results/plot/thuput.vmstat_io.png
http://khack.osdl.org/stp/290304/results/plot/thuput.vmstat.txt
There seems to be a large amount of idle time in the profiles and in the vmstat trace.

Yes. There is considerably more idle time in the bad run:
Good one:
http://khack.osdl.org/stp/290298/results/plot/thuput.sar_cpu_all.png
Bad one:
http://khack.osdl.org/stp/290304/results/plot/thuput.sar_cpu_all.png

I am concerned with the drop in CPU utilization relative to the other run.

Signature · 10 lines

Mary Edie Meredith 
[email protected]
503-626-2455 x42
Open Source Development Labs

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

Mary Edie Meredith

2004-03-30 21:30 UTC #85 lore raw

The 2.6.5-rc2-mm5 kernel has vastly improved the performance issue with dbt3-pgsql throughput numbers (bigger is better):

Runid...Metric.PLM..Kernel........diff%
290357 141.84 2788 2.6.5-rc2..... base
290576 91.18 2814 2.6.5-rc2-mm2 -35.72
290856 60.02 2842 2.6.5-rc2-mm4 -57.68
290953 134.10 2849 2.6.5-rc2-mm5 -5.46 <-------

Thanks to Nick and Ingo.

Quoted 31 lines · Mary Edie Meredith

Quoted 17 lines · Andrew Morton
Quoted 16 lines · Mary Edie Meredith
Quoted 9 lines
36% regression due to the CPU scheduler changes? ow.
And that machine is a PIII, so presumably the setting of CONFIG_SCHED_SMT makes no difference.
Quoted 1 line
From a quick look at the material you have there it appears that this
workload also is very I/O bound. It's a little surprising that the CPU scheduler could make so much difference.
I'm not sure why you think this is IO bound. For the throughput phase of the test (from which the metric above is taken) there is very little physical IO except at the start when the updates occur. They finish in a few minutes, after which there is very little.
Quoted 5 lines
Quoted 2 lines
http://khack.osdl.org/stp/290304/results/plot/thuput.vmstat_io.png
http://khack.osdl.org/stp/290304/results/plot/thuput.vmstat.txt
There seems to be a large amount of idle time in the profiles and in the vmstat trace.
Yes. There is considerably more idle time in the bad run:
Good one:
http://khack.osdl.org/stp/290298/results/plot/thuput.sar_cpu_all.png
Bad one:
http://khack.osdl.org/stp/290304/results/plot/thuput.sar_cpu_all.png
I am concerned with the drop in CPU utilization relative to the other run.

Signature · 10 lines

Mary Edie Meredith 
[email protected]
503-626-2455 x42
Open Source Development Labs

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