* 2.6.4-mm2
@ 2004-03-15 1:28 Andrew Morton
2004-03-15 1:57 ` 2.6.4-mm2 Joshua Kwan
` (8 more replies)
0 siblings, 9 replies; 90+ messages in thread
From: Andrew Morton @ 2004-03-15 1:28 UTC (permalink / raw)
To: linux-kernel
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 <mochel@osdl.org>
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 <hawkes@babylon.engr.sgi.com>
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 <hawkes@babylon.engr.sgi.com>
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
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.4-mm2
2004-03-15 1:28 2.6.4-mm2 Andrew Morton
@ 2004-03-15 1:57 ` Joshua Kwan
2004-03-15 6:08 ` 2.6.4-mm2 Sam Ravnborg
2004-03-15 9:32 ` [patch] 2.6.4-mm2: ALSA au88x0.c doesn't compile with gcc 2.95 Adrian Bunk
` (7 subsequent siblings)
8 siblings, 1 reply; 90+ messages in thread
From: Joshua Kwan @ 2004-03-15 1:57 UTC (permalink / raw)
To: linux-kernel
On Sun, 14 Mar 2004 17:28:09 -0800, Andrew Morton wrote:
> +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:
--- linux/Makefile~ 2004-03-14 17:52:54.000000000 -0800
+++ linux/Makefile 2004-03-14 17:52:21.000000000 -0800
@@ -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)
--
Joshua Kwan
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.4-mm2
2004-03-15 1:57 ` 2.6.4-mm2 Joshua Kwan
@ 2004-03-15 6:08 ` Sam Ravnborg
0 siblings, 0 replies; 90+ messages in thread
From: Sam Ravnborg @ 2004-03-15 6:08 UTC (permalink / raw)
To: Joshua Kwan; +Cc: linux-kernel
On Sun, Mar 14, 2004 at 05:57:21PM -0800, Joshua Kwan wrote:
> On Sun, 14 Mar 2004 17:28:09 -0800, Andrew Morton wrote:
> > +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:
>
> --- linux/Makefile~ 2004-03-14 17:52:54.000000000 -0800
> +++ linux/Makefile 2004-03-14 17:52:21.000000000 -0800
> @@ -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
^ permalink raw reply [flat|nested] 90+ messages in thread
* [patch] 2.6.4-mm2: ALSA au88x0.c doesn't compile with gcc 2.95
2004-03-15 1:28 2.6.4-mm2 Andrew Morton
2004-03-15 1:57 ` 2.6.4-mm2 Joshua Kwan
@ 2004-03-15 9:32 ` Adrian Bunk
2004-03-15 9:36 ` 2.6.4-mm2: ALSA au88{1,2}0: multiply defined symbols Adrian Bunk
` (6 subsequent siblings)
8 siblings, 0 replies; 90+ messages in thread
From: Adrian Bunk @ 2004-03-15 9:32 UTC (permalink / raw)
To: Andrew Morton, mjander, perex; +Cc: linux-kernel, alsa-devel
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:
--- linux-2.6.4-mm2-full/sound/pci/au88x0/au88x0.c.old 2004-03-15 10:26:56.000000000 +0100
+++ linux-2.6.4-mm2-full/sound/pci/au88x0/au88x0.c 2004-03-15 10:27:32.000000000 +0100
@@ -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
--
"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
^ permalink raw reply [flat|nested] 90+ messages in thread
* 2.6.4-mm2: ALSA au88{1,2}0: multiply defined symbols
2004-03-15 1:28 2.6.4-mm2 Andrew Morton
2004-03-15 1:57 ` 2.6.4-mm2 Joshua Kwan
2004-03-15 9:32 ` [patch] 2.6.4-mm2: ALSA au88x0.c doesn't compile with gcc 2.95 Adrian Bunk
@ 2004-03-15 9:36 ` Adrian Bunk
2004-03-15 18:54 ` 2.6.4-mm2 Sam Ravnborg
` (5 subsequent siblings)
8 siblings, 0 replies; 90+ messages in thread
From: Adrian Bunk @ 2004-03-15 9:36 UTC (permalink / raw)
To: Andrew Morton, perex; +Cc: linux-kernel, alsa-devel
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
--
"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
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.4-mm2
2004-03-15 1:28 2.6.4-mm2 Andrew Morton
` (2 preceding siblings ...)
2004-03-15 9:36 ` 2.6.4-mm2: ALSA au88{1,2}0: multiply defined symbols Adrian Bunk
@ 2004-03-15 18:54 ` Sam Ravnborg
2004-03-20 22:50 ` 2.6.4-mm2 Olaf Hering
2004-03-15 19:18 ` 2.6.4-mm2 (compile stats) John Cherry
` (4 subsequent siblings)
8 siblings, 1 reply; 90+ messages in thread
From: Sam Ravnborg @ 2004-03-15 18:54 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
>
> +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
diff -Nru a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile
--- a/Documentation/DocBook/Makefile Mon Mar 15 19:51:20 2004
+++ b/Documentation/DocBook/Makefile Mon Mar 15 19:51:20 2004
@@ -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
diff -Nru a/Makefile b/Makefile
--- a/Makefile Mon Mar 15 19:51:20 2004
+++ b/Makefile Mon Mar 15 19:51:20 2004
@@ -304,17 +304,10 @@
# ===========================================================================
# Rules shared between *config targets and build targets
-# Helpers built in scripts/
-
-scripts/docproc scripts/split-include : scripts ;
-
-.PHONY: scripts scripts/fixdep
-scripts:
- $(Q)$(MAKE) $(build)=scripts
-
-scripts/fixdep:
- $(Q)$(MAKE) $(build)=scripts $@
-
+# Basic helpers built in scripts/
+.PHONY: scripts_basic
+scripts_basic:
+ $(Q)$(MAKE) $(build)=scripts/basic
# To make sure we do not include .config for any of the *config targets
# catch them early, and hand them over to scripts/kconfig/Makefile
@@ -358,9 +351,9 @@
# *config targets only - make sure prerequisites are updated, and descend
# in scripts/kconfig to make the *config target
-%config: scripts/fixdep FORCE
+config: scripts_basic FORCE
$(Q)$(MAKE) $(build)=scripts/kconfig $@
-config : scripts/fixdep FORCE
+%config: scripts_basic FORCE
$(Q)$(MAKE) $(build)=scripts/kconfig $@
else
@@ -368,6 +361,16 @@
# Build targets only - this includes vmlinux, arch specific targets, clean
# targets and others. In general all targets except *config targets.
+# Additional helpers built in scripts/
+# Carefully list dependencies so we do not try to build scripts twice
+# in parrallel
+.PHONY: scripts
+scripts: scripts_basic include/config/MARKER
+ $(Q)$(MAKE) $(build)=$(@)
+
+scripts_basic: include/linux/autoconf.h
+
+
# That's our default target when none is given on the command line
# Note that 'modules' will be added as a prerequisite as well,
# in the CONFIG_MODULES part below
@@ -400,7 +403,9 @@
# with it and forgot to run make oldconfig
include/linux/autoconf.h: .config
$(Q)$(MAKE) -f $(srctree)/Makefile silentoldconfig
-
+else
+# Dummy target needed, because used as prerequisite
+include/linux/autoconf.h: ;
endif
include $(srctree)/arch/$(ARCH)/Makefile
@@ -634,9 +639,9 @@
# Split autoconf.h into include/linux/config/*
-include/config/MARKER: scripts/split-include include/linux/autoconf.h
+include/config/MARKER: include/linux/autoconf.h
@echo ' SPLIT include/linux/autoconf.h -> include/config/*'
- @scripts/split-include include/linux/autoconf.h include/config
+ @scripts/basic/split-include include/linux/autoconf.h include/config
@touch $@
# Generate some files
@@ -930,7 +935,7 @@
# Documentation targets
# ---------------------------------------------------------------------------
-%docs: scripts/docproc FORCE
+%docs: scripts FORCE
$(Q)$(MAKE) $(build)=Documentation/DocBook $@
# Scripts to check various things for consistency
@@ -983,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)
diff -Nru a/scripts/Makefile b/scripts/Makefile
--- a/scripts/Makefile Mon Mar 15 19:51:20 2004
+++ b/scripts/Makefile Mon Mar 15 19:51:20 2004
@@ -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
diff -Nru a/scripts/Makefile.build b/scripts/Makefile.build
--- a/scripts/Makefile.build Mon Mar 15 19:51:20 2004
+++ b/scripts/Makefile.build Mon Mar 15 19:51:20 2004
@@ -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
diff -Nru a/scripts/Makefile.lib b/scripts/Makefile.lib
--- a/scripts/Makefile.lib Mon Mar 15 19:51:20 2004
+++ b/scripts/Makefile.lib Mon Mar 15 19:51:20 2004
@@ -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)
diff -Nru a/scripts/basic/Makefile b/scripts/basic/Makefile
--- /dev/null Wed Dec 31 16:00:00 1969
+++ b/scripts/basic/Makefile Mon Mar 15 19:51:20 2004
@@ -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
diff -Nru a/scripts/basic/docproc.c b/scripts/basic/docproc.c
--- /dev/null Wed Dec 31 16:00:00 1969
+++ b/scripts/basic/docproc.c Mon Mar 15 19:51:20 2004
@@ -0,0 +1,387 @@
+/*
+ * docproc is a simple preprocessor for the template files
+ * used as placeholders for the kernel internal documentation.
+ * docproc is used for documentation-frontend and
+ * dependency-generator.
+ * The two usages have in common that they require
+ * some knowledge of the .tmpl syntax, therefore they
+ * are kept together.
+ *
+ * documentation-frontend
+ * Scans the template file and call kernel-doc for
+ * all occurrences of ![EIF]file
+ * Beforehand each referenced file are scanned for
+ * any exported sympols "EXPORT_SYMBOL()" statements.
+ * This is used to create proper -function and
+ * -nofunction arguments in calls to kernel-doc.
+ * Usage: docproc doc file.tmpl
+ *
+ * dependency-generator:
+ * Scans the template file and list all files
+ * referenced in a format recognized by make.
+ * Usage: docproc depend file.tmpl
+ * Writes dependency information to stdout
+ * in the following format:
+ * file.tmpl src.c src2.c
+ * The filenames are obtained from the following constructs:
+ * !Efilename
+ * !Ifilename
+ * !Dfilename
+ * !Ffilename
+ *
+ */
+
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <ctype.h>
+#include <unistd.h>
+#include <limits.h>
+#include <sys/types.h>
+#include <sys/wait.h>
+
+/* exitstatus is used to keep track of any failing calls to kernel-doc,
+ * but execution continues. */
+int exitstatus = 0;
+
+typedef void DFL(char *);
+DFL *defaultline;
+
+typedef void FILEONLY(char * file);
+FILEONLY *internalfunctions;
+FILEONLY *externalfunctions;
+FILEONLY *symbolsonly;
+
+typedef void FILELINE(char * file, char * line);
+FILELINE * singlefunctions;
+FILELINE * entity_system;
+
+#define MAXLINESZ 2048
+#define MAXFILES 250
+#define KERNELDOCPATH "scripts/"
+#define KERNELDOC "kernel-doc"
+#define DOCBOOK "-docbook"
+#define FUNCTION "-function"
+#define NOFUNCTION "-nofunction"
+
+void usage (void)
+{
+ fprintf(stderr, "Usage: docproc {doc|depend} file\n");
+ fprintf(stderr, "Input is read from file.tmpl. Output is sent to stdout\n");
+ fprintf(stderr, "doc: frontend when generating kernel documentation\n");
+ fprintf(stderr, "depend: generate list of files referenced within file\n");
+}
+
+/*
+ * Execute kernel-doc with parameters givin in svec
+ */
+void exec_kernel_doc(char **svec)
+{
+ pid_t pid;
+ int ret;
+ /* Make sure output generated so far are flushed */
+ fflush(stdout);
+ switch(pid=fork()) {
+ case -1:
+ perror("fork");
+ exit(1);
+ case 0:
+ execvp(KERNELDOCPATH KERNELDOC, svec);
+ perror("exec " KERNELDOCPATH KERNELDOC);
+ exit(1);
+ default:
+ waitpid(pid, &ret ,0);
+ }
+ if (WIFEXITED(ret))
+ exitstatus |= WEXITSTATUS(ret);
+ else
+ exitstatus = 0xff;
+}
+
+/* Types used to create list of all exported symbols in a number of files */
+struct symbols
+{
+ char *name;
+};
+
+struct symfile
+{
+ char *filename;
+ struct symbols *symbollist;
+ int symbolcnt;
+};
+
+struct symfile symfilelist[MAXFILES];
+int symfilecnt = 0;
+
+void add_new_symbol(struct symfile *sym, char * symname)
+{
+ sym->symbollist =
+ realloc(sym->symbollist, (sym->symbolcnt + 1) * sizeof(char *));
+ sym->symbollist[sym->symbolcnt++].name = strdup(symname);
+}
+
+/* Add a filename to the list */
+struct symfile * add_new_file(char * filename)
+{
+ symfilelist[symfilecnt++].filename = strdup(filename);
+ return &symfilelist[symfilecnt - 1];
+}
+/* Check if file already are present in the list */
+struct symfile * filename_exist(char * filename)
+{
+ int i;
+ for (i=0; i < symfilecnt; i++)
+ if (strcmp(symfilelist[i].filename, filename) == 0)
+ return &symfilelist[i];
+ return NULL;
+}
+
+/*
+ * List all files referenced within the template file.
+ * Files are separated by tabs.
+ */
+void adddep(char * file) { printf("\t%s", file); }
+void adddep2(char * file, char * line) { line = line; adddep(file); }
+void noaction(char * line) { line = line; }
+void noaction2(char * file, char * line) { file = file; line = line; }
+
+/* Echo the line without further action */
+void printline(char * line) { printf("%s", line); }
+
+/*
+ * Find all symbols exported with EXPORT_SYMBOL and EXPORT_SYMBOL_GPL
+ * in filename.
+ * All symbols located are stored in symfilelist.
+ */
+void find_export_symbols(char * filename)
+{
+ FILE * fp;
+ struct symfile *sym;
+ char line[MAXLINESZ];
+ if (filename_exist(filename) == NULL) {
+ sym = add_new_file(filename);
+ fp = fopen(filename, "r");
+ if (fp == NULL)
+ {
+ fprintf(stderr, "docproc: ");
+ perror(filename);
+ }
+ while(fgets(line, MAXLINESZ, fp)) {
+ char *p;
+ char *e;
+ if (((p = strstr(line, "EXPORT_SYMBOL_GPL")) != 0) ||
+ ((p = strstr(line, "EXPORT_SYMBOL")) != 0)) {
+ /* Skip EXPORT_SYMBOL{_GPL} */
+ while (isalnum(*p) || *p == '_')
+ p++;
+ /* Remove paranteses and additional ws */
+ while (isspace(*p))
+ p++;
+ if (*p != '(')
+ continue; /* Syntax error? */
+ else
+ p++;
+ while (isspace(*p))
+ p++;
+ e = p;
+ while (isalnum(*e) || *e == '_')
+ e++;
+ *e = '\0';
+ add_new_symbol(sym, p);
+ }
+ }
+ fclose(fp);
+ }
+}
+
+/*
+ * Document all external or internal functions in a file.
+ * Call kernel-doc with following parameters:
+ * kernel-doc -docbook -nofunction function_name1 filename
+ * function names are obtained from all the the src files
+ * by find_export_symbols.
+ * intfunc uses -nofunction
+ * extfunc uses -function
+ */
+void docfunctions(char * filename, char * type)
+{
+ int i,j;
+ int symcnt = 0;
+ int idx = 0;
+ char **vec;
+
+ for (i=0; i <= symfilecnt; i++)
+ symcnt += symfilelist[i].symbolcnt;
+ vec = malloc((2 + 2 * symcnt + 2) * sizeof(char*));
+ if (vec == NULL) {
+ perror("docproc: ");
+ exit(1);
+ }
+ vec[idx++] = KERNELDOC;
+ vec[idx++] = DOCBOOK;
+ for (i=0; i < symfilecnt; i++) {
+ struct symfile * sym = &symfilelist[i];
+ for (j=0; j < sym->symbolcnt; j++) {
+ vec[idx++] = type;
+ vec[idx++] = sym->symbollist[j].name;
+ }
+ }
+ vec[idx++] = filename;
+ vec[idx] = NULL;
+ printf("<!-- %s -->\n", filename);
+ exec_kernel_doc(vec);
+ fflush(stdout);
+ free(vec);
+}
+void intfunc(char * filename) { docfunctions(filename, NOFUNCTION); }
+void extfunc(char * filename) { docfunctions(filename, FUNCTION); }
+
+/*
+ * Document spåecific function(s) in a file.
+ * Call kernel-doc with the following parameters:
+ * kernel-doc -docbook -function function1 [-function function2]
+ */
+void singfunc(char * filename, char * line)
+{
+ char *vec[200]; /* Enough for specific functions */
+ int i, idx = 0;
+ int startofsym = 1;
+ vec[idx++] = KERNELDOC;
+ vec[idx++] = DOCBOOK;
+
+ /* Split line up in individual parameters preceeded by FUNCTION */
+ for (i=0; line[i]; i++) {
+ if (isspace(line[i])) {
+ line[i] = '\0';
+ startofsym = 1;
+ continue;
+ }
+ if (startofsym) {
+ startofsym = 0;
+ vec[idx++] = FUNCTION;
+ vec[idx++] = &line[i];
+ }
+ }
+ vec[idx++] = filename;
+ vec[idx] = NULL;
+ exec_kernel_doc(vec);
+}
+
+/*
+ * Parse file, calling action specific functions for:
+ * 1) Lines containing !E
+ * 2) Lines containing !I
+ * 3) Lines containing !D
+ * 4) Lines containing !F
+ * 5) Default lines - lines not matching the above
+ */
+void parse_file(FILE *infile)
+{
+ char line[MAXLINESZ];
+ char * s;
+ while(fgets(line, MAXLINESZ, infile)) {
+ if (line[0] == '!') {
+ s = line + 2;
+ switch (line[1]) {
+ case 'E':
+ while (*s && !isspace(*s)) s++;
+ *s = '\0';
+ externalfunctions(line+2);
+ break;
+ case 'I':
+ while (*s && !isspace(*s)) s++;
+ *s = '\0';
+ internalfunctions(line+2);
+ break;
+ case 'D':
+ while (*s && !isspace(*s)) s++;
+ *s = '\0';
+ symbolsonly(line+2);
+ break;
+ case 'F':
+ /* filename */
+ while (*s && !isspace(*s)) s++;
+ *s++ = '\0';
+ /* function names */
+ while (isspace(*s))
+ s++;
+ singlefunctions(line +2, s);
+ break;
+ default:
+ defaultline(line);
+ }
+ }
+ else {
+ defaultline(line);
+ }
+ }
+ fflush(stdout);
+}
+
+
+int main(int argc, char *argv[])
+{
+ FILE * infile;
+ if (argc != 3) {
+ usage();
+ exit(1);
+ }
+ /* Open file, exit on error */
+ infile = fopen(argv[2], "r");
+ if (infile == NULL) {
+ fprintf(stderr, "docproc: ");
+ perror(argv[2]);
+ exit(2);
+ }
+
+ if (strcmp("doc", argv[1]) == 0)
+ {
+ /* Need to do this in two passes.
+ * First pass is used to collect all symbols exported
+ * in the various files.
+ * Second pass generate the documentation.
+ * This is required because function are declared
+ * and exported in different files :-((
+ */
+ /* Collect symbols */
+ defaultline = noaction;
+ internalfunctions = find_export_symbols;
+ externalfunctions = find_export_symbols;
+ symbolsonly = find_export_symbols;
+ singlefunctions = noaction2;
+ parse_file(infile);
+
+ /* Rewind to start from beginning of file again */
+ fseek(infile, 0, SEEK_SET);
+ defaultline = printline;
+ internalfunctions = intfunc;
+ externalfunctions = extfunc;
+ symbolsonly = printline;
+ singlefunctions = singfunc;
+
+ parse_file(infile);
+ }
+ else if (strcmp("depend", argv[1]) == 0)
+ {
+ /* Create first part of dependency chain
+ * file.tmpl */
+ printf("%s\t", argv[2]);
+ defaultline = noaction;
+ internalfunctions = adddep;
+ externalfunctions = adddep;
+ symbolsonly = adddep;
+ singlefunctions = adddep2;
+ parse_file(infile);
+ printf("\n");
+ }
+ else
+ {
+ fprintf(stderr, "Unknown option: %s\n", argv[1]);
+ exit(1);
+ }
+ fclose(infile);
+ fflush(stdout);
+ return exitstatus;
+}
+
diff -Nru a/scripts/basic/fixdep.c b/scripts/basic/fixdep.c
--- /dev/null Wed Dec 31 16:00:00 1969
+++ b/scripts/basic/fixdep.c Mon Mar 15 19:51:20 2004
@@ -0,0 +1,381 @@
+/*
+ * "Optimize" a list of dependencies as spit out by gcc -MD
+ * for the kernel build
+ * ===========================================================================
+ *
+ * Author Kai Germaschewski
+ * Copyright 2002 by Kai Germaschewski <kai.germaschewski@gmx.de>
+ *
+ * This software may be used and distributed according to the terms
+ * of the GNU General Public License, incorporated herein by reference.
+ *
+ *
+ * Introduction:
+ *
+ * gcc produces a very nice and correct list of dependencies which
+ * tells make when to remake a file.
+ *
+ * To use this list as-is however has the drawback that virtually
+ * every file in the kernel includes <linux/config.h> which then again
+ * includes <linux/autoconf.h>
+ *
+ * If the user re-runs make *config, linux/autoconf.h will be
+ * regenerated. make notices that and will rebuild every file which
+ * includes autoconf.h, i.e. basically all files. This is extremely
+ * annoying if the user just changed CONFIG_HIS_DRIVER from n to m.
+ *
+ * So we play the same trick that "mkdep" played before. We replace
+ * the dependency on linux/autoconf.h by a dependency on every config
+ * option which is mentioned in any of the listed prequisites.
+ *
+ * To be exact, split-include populates a tree in include/config/,
+ * e.g. include/config/his/driver.h, which contains the #define/#undef
+ * for the CONFIG_HIS_DRIVER option.
+ *
+ * So if the user changes his CONFIG_HIS_DRIVER option, only the objects
+ * which depend on "include/linux/config/his/driver.h" will be rebuilt,
+ * so most likely only his driver ;-)
+ *
+ * The idea above dates, by the way, back to Michael E Chastain, AFAIK.
+ *
+ * So to get dependencies right, there two issues:
+ * o if any of the files the compiler read changed, we need to rebuild
+ * o if the command line given to the compile the file changed, we
+ * better rebuild as well.
+ *
+ * The former is handled by using the -MD output, the later by saving
+ * the command line used to compile the old object and comparing it
+ * to the one we would now use.
+ *
+ * Again, also this idea is pretty old and has been discussed on
+ * kbuild-devel a long time ago. I don't have a sensibly working
+ * internet connection right now, so I rather don't mention names
+ * without double checking.
+ *
+ * This code here has been based partially based on mkdep.c, which
+ * says the following about its history:
+ *
+ * Copyright abandoned, Michael Chastain, <mailto:mec@shout.net>.
+ * This is a C version of syncdep.pl by Werner Almesberger.
+ *
+ *
+ * It is invoked as
+ *
+ * fixdep <depfile> <target> <cmdline>
+ *
+ * and will read the dependency file <depfile>
+ *
+ * The transformed dependency snipped is written to stdout.
+ *
+ * It first generates a line
+ *
+ * cmd_<target> = <cmdline>
+ *
+ * and then basically copies the .<target>.d file to stdout, in the
+ * process filtering out the dependency on linux/autoconf.h and adding
+ * dependencies on include/config/my/option.h for every
+ * CONFIG_MY_OPTION encountered in any of the prequisites.
+ *
+ * It will also filter out all the dependencies on *.ver. We need
+ * to make sure that the generated version checksum are globally up
+ * to date before even starting the recursive build, so it's too late
+ * at this point anyway.
+ *
+ * The algorithm to grep for "CONFIG_..." is bit unusual, but should
+ * be fast ;-) We don't even try to really parse the header files, but
+ * merely grep, i.e. if CONFIG_FOO is mentioned in a comment, it will
+ * be picked up as well. It's not a problem with respect to
+ * correctness, since that can only give too many dependencies, thus
+ * we cannot miss a rebuild. Since people tend to not mention totally
+ * unrelated CONFIG_ options all over the place, it's not an
+ * efficiency problem either.
+ *
+ * (Note: it'd be easy to port over the complete mkdep state machine,
+ * but I don't think the added complexity is worth it)
+ */
+
+#include <sys/types.h>
+#include <sys/stat.h>
+#include <sys/mman.h>
+#include <unistd.h>
+#include <fcntl.h>
+#include <string.h>
+#include <stdlib.h>
+#include <stdio.h>
+#include <limits.h>
+#include <ctype.h>
+#include <netinet/in.h>
+
+#define INT_CONF ntohl(0x434f4e46)
+#define INT_ONFI ntohl(0x4f4e4649)
+#define INT_NFIG ntohl(0x4e464947)
+#define INT_FIG_ ntohl(0x4649475f)
+
+char *target;
+char *depfile;
+char *cmdline;
+
+void usage(void)
+
+{
+ fprintf(stderr, "Usage: fixdep <depfile> <target> <cmdline>\n");
+ exit(1);
+}
+
+void print_cmdline(void)
+{
+ printf("cmd_%s := %s\n\n", target, cmdline);
+}
+
+char * str_config = NULL;
+int size_config = 0;
+int len_config = 0;
+
+/*
+ * Grow the configuration string to a desired length.
+ * Usually the first growth is plenty.
+ */
+void grow_config(int len)
+{
+ while (len_config + len > size_config) {
+ if (size_config == 0)
+ size_config = 2048;
+ str_config = realloc(str_config, size_config *= 2);
+ if (str_config == NULL)
+ { perror("fixdep:malloc"); exit(1); }
+ }
+}
+
+
+
+/*
+ * Lookup a value in the configuration string.
+ */
+int is_defined_config(const char * name, int len)
+{
+ const char * pconfig;
+ const char * plast = str_config + len_config - len;
+ for ( pconfig = str_config + 1; pconfig < plast; pconfig++ ) {
+ if (pconfig[ -1] == '\n'
+ && pconfig[len] == '\n'
+ && !memcmp(pconfig, name, len))
+ return 1;
+ }
+ return 0;
+}
+
+/*
+ * Add a new value to the configuration string.
+ */
+void define_config(const char * name, int len)
+{
+ grow_config(len + 1);
+
+ memcpy(str_config+len_config, name, len);
+ len_config += len;
+ str_config[len_config++] = '\n';
+}
+
+/*
+ * Clear the set of configuration strings.
+ */
+void clear_config(void)
+{
+ len_config = 0;
+ define_config("", 0);
+}
+
+/*
+ * Record the use of a CONFIG_* word.
+ */
+void use_config(char *m, int slen)
+{
+ char s[PATH_MAX];
+ char *p;
+
+ if (is_defined_config(m, slen))
+ return;
+
+ define_config(m, slen);
+
+ memcpy(s, m, slen); s[slen] = 0;
+
+ for (p = s; p < s + slen; p++) {
+ if (*p == '_')
+ *p = '/';
+ else
+ *p = tolower((unsigned char)*p);
+ }
+ printf(" $(wildcard include/config/%s.h) \\\n", s);
+}
+
+void parse_config_file(char *map, size_t len)
+{
+ int *end = (int *) (map + len);
+ /* start at +1, so that p can never be < map */
+ int *m = (int *) map + 1;
+ char *p, *q;
+
+ for (; m < end; m++) {
+ if (*m == INT_CONF) { p = (char *) m ; goto conf; }
+ if (*m == INT_ONFI) { p = (char *) m-1; goto conf; }
+ if (*m == INT_NFIG) { p = (char *) m-2; goto conf; }
+ if (*m == INT_FIG_) { p = (char *) m-3; goto conf; }
+ continue;
+ conf:
+ if (p > map + len - 7)
+ continue;
+ if (memcmp(p, "CONFIG_", 7))
+ continue;
+ for (q = p + 7; q < map + len; q++) {
+ if (!(isalnum(*q) || *q == '_'))
+ goto found;
+ }
+ continue;
+
+ found:
+ use_config(p+7, q-p-7);
+ }
+}
+
+/* test is s ends in sub */
+int strrcmp(char *s, char *sub)
+{
+ int slen = strlen(s);
+ int sublen = strlen(sub);
+
+ if (sublen > slen)
+ return 1;
+
+ return memcmp(s + slen - sublen, sub, sublen);
+}
+
+void do_config_file(char *filename)
+{
+ struct stat st;
+ int fd;
+ void *map;
+
+ fd = open(filename, O_RDONLY);
+ if (fd < 0) {
+ fprintf(stderr, "fixdep: ");
+ perror(filename);
+ exit(2);
+ }
+ fstat(fd, &st);
+ if (st.st_size == 0) {
+ close(fd);
+ return;
+ }
+ map = mmap(NULL, st.st_size, PROT_READ, MAP_PRIVATE, fd, 0);
+ if ((long) map == -1) {
+ perror("fixdep: mmap");
+ close(fd);
+ return;
+ }
+
+ parse_config_file(map, st.st_size);
+
+ munmap(map, st.st_size);
+
+ close(fd);
+}
+
+void parse_dep_file(void *map, size_t len)
+{
+ char *m = map;
+ char *end = m + len;
+ char *p;
+ char s[PATH_MAX];
+
+ p = strchr(m, ':');
+ if (!p) {
+ fprintf(stderr, "fixdep: parse error\n");
+ exit(1);
+ }
+ memcpy(s, m, p-m); s[p-m] = 0;
+ printf("deps_%s := \\\n", target);
+ m = p+1;
+
+ clear_config();
+
+ while (m < end) {
+ while (m < end && (*m == ' ' || *m == '\\' || *m == '\n'))
+ m++;
+ p = m;
+ while (p < end && *p != ' ') p++;
+ if (p == end) {
+ do p--; while (!isalnum(*p));
+ p++;
+ }
+ memcpy(s, m, p-m); s[p-m] = 0;
+ if (strrcmp(s, "include/linux/autoconf.h") &&
+ strrcmp(s, ".ver")) {
+ printf(" %s \\\n", s);
+ do_config_file(s);
+ }
+ m = p + 1;
+ }
+ printf("\n%s: $(deps_%s)\n\n", target, target);
+ printf("$(deps_%s):\n", target);
+}
+
+void print_deps(void)
+{
+ struct stat st;
+ int fd;
+ void *map;
+
+ fd = open(depfile, O_RDONLY);
+ if (fd < 0) {
+ fprintf(stderr, "fixdep: ");
+ perror(depfile);
+ exit(2);
+ }
+ fstat(fd, &st);
+ if (st.st_size == 0) {
+ fprintf(stderr,"fixdep: %s is empty\n",depfile);
+ close(fd);
+ return;
+ }
+ map = mmap(NULL, st.st_size, PROT_READ, MAP_PRIVATE, fd, 0);
+ if ((long) map == -1) {
+ perror("fixdep: mmap");
+ close(fd);
+ return;
+ }
+
+ parse_dep_file(map, st.st_size);
+
+ munmap(map, st.st_size);
+
+ close(fd);
+}
+
+void traps(void)
+{
+ static char test[] __attribute__((aligned(sizeof(int)))) = "CONF";
+
+ if (*(int *)test != INT_CONF) {
+ fprintf(stderr, "fixdep: sizeof(int) != 4 or wrong endianess? %#x\n",
+ *(int *)test);
+ exit(2);
+ }
+}
+
+int main(int argc, char *argv[])
+{
+ traps();
+
+ if (argc != 4)
+ usage();
+
+ depfile = argv[1];
+ target = argv[2];
+ cmdline = argv[3];
+
+ print_cmdline();
+ print_deps();
+
+ return 0;
+}
diff -Nru a/scripts/basic/split-include.c b/scripts/basic/split-include.c
--- /dev/null Wed Dec 31 16:00:00 1969
+++ b/scripts/basic/split-include.c Mon Mar 15 19:51:20 2004
@@ -0,0 +1,226 @@
+/*
+ * split-include.c
+ *
+ * Copyright abandoned, Michael Chastain, <mailto:mec@shout.net>.
+ * This is a C version of syncdep.pl by Werner Almesberger.
+ *
+ * This program takes autoconf.h as input and outputs a directory full
+ * of one-line include files, merging onto the old values.
+ *
+ * Think of the configuration options as key-value pairs. Then there
+ * are five cases:
+ *
+ * key old value new value action
+ *
+ * KEY-1 VALUE-1 VALUE-1 leave file alone
+ * KEY-2 VALUE-2A VALUE-2B write VALUE-2B into file
+ * KEY-3 - VALUE-3 write VALUE-3 into file
+ * KEY-4 VALUE-4 - write an empty file
+ * KEY-5 (empty) - leave old empty file alone
+ */
+
+#include <sys/stat.h>
+#include <sys/types.h>
+
+#include <ctype.h>
+#include <errno.h>
+#include <fcntl.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <unistd.h>
+
+#define ERROR_EXIT(strExit) \
+ { \
+ const int errnoSave = errno; \
+ fprintf(stderr, "%s: ", str_my_name); \
+ errno = errnoSave; \
+ perror((strExit)); \
+ exit(1); \
+ }
+
+
+
+int main(int argc, const char * argv [])
+{
+ const char * str_my_name;
+ const char * str_file_autoconf;
+ const char * str_dir_config;
+
+ FILE * fp_config;
+ FILE * fp_target;
+ FILE * fp_find;
+
+ int buffer_size;
+
+ char * line;
+ char * old_line;
+ char * list_target;
+ char * ptarget;
+
+ struct stat stat_buf;
+
+ /* Check arg count. */
+ if (argc != 3)
+ {
+ fprintf(stderr, "%s: wrong number of arguments.\n", argv[0]);
+ exit(1);
+ }
+
+ str_my_name = argv[0];
+ str_file_autoconf = argv[1];
+ str_dir_config = argv[2];
+
+ /* Find a buffer size. */
+ if (stat(str_file_autoconf, &stat_buf) != 0)
+ ERROR_EXIT(str_file_autoconf);
+ buffer_size = 2 * stat_buf.st_size + 4096;
+
+ /* Allocate buffers. */
+ if ( (line = malloc(buffer_size)) == NULL
+ || (old_line = malloc(buffer_size)) == NULL
+ || (list_target = malloc(buffer_size)) == NULL )
+ ERROR_EXIT(str_file_autoconf);
+
+ /* Open autoconfig file. */
+ if ((fp_config = fopen(str_file_autoconf, "r")) == NULL)
+ ERROR_EXIT(str_file_autoconf);
+
+ /* Make output directory if needed. */
+ if (stat(str_dir_config, &stat_buf) != 0)
+ {
+ if (mkdir(str_dir_config, 0755) != 0)
+ ERROR_EXIT(str_dir_config);
+ }
+
+ /* Change to output directory. */
+ if (chdir(str_dir_config) != 0)
+ ERROR_EXIT(str_dir_config);
+
+ /* Put initial separator into target list. */
+ ptarget = list_target;
+ *ptarget++ = '\n';
+
+ /* Read config lines. */
+ while (fgets(line, buffer_size, fp_config))
+ {
+ const char * str_config;
+ int is_same;
+ int itarget;
+
+ if (line[0] != '#')
+ continue;
+ if ((str_config = strstr(line, "CONFIG_")) == NULL)
+ continue;
+
+ /* Make the output file name. */
+ str_config += sizeof("CONFIG_") - 1;
+ for (itarget = 0; !isspace(str_config[itarget]); itarget++)
+ {
+ int c = (unsigned char) str_config[itarget];
+ if (isupper(c)) c = tolower(c);
+ if (c == '_') c = '/';
+ ptarget[itarget] = c;
+ }
+ ptarget[itarget++] = '.';
+ ptarget[itarget++] = 'h';
+ ptarget[itarget++] = '\0';
+
+ /* Check for existing file. */
+ is_same = 0;
+ if ((fp_target = fopen(ptarget, "r")) != NULL)
+ {
+ fgets(old_line, buffer_size, fp_target);
+ if (fclose(fp_target) != 0)
+ ERROR_EXIT(ptarget);
+ if (!strcmp(line, old_line))
+ is_same = 1;
+ }
+
+ if (!is_same)
+ {
+ /* Auto-create directories. */
+ int islash;
+ for (islash = 0; islash < itarget; islash++)
+ {
+ if (ptarget[islash] == '/')
+ {
+ ptarget[islash] = '\0';
+ if (stat(ptarget, &stat_buf) != 0
+ && mkdir(ptarget, 0755) != 0)
+ ERROR_EXIT( ptarget );
+ ptarget[islash] = '/';
+ }
+ }
+
+ /* Write the file. */
+ if ((fp_target = fopen(ptarget, "w" )) == NULL)
+ ERROR_EXIT(ptarget);
+ fputs(line, fp_target);
+ if (ferror(fp_target) || fclose(fp_target) != 0)
+ ERROR_EXIT(ptarget);
+ }
+
+ /* Update target list */
+ ptarget += itarget;
+ *(ptarget-1) = '\n';
+ }
+
+ /*
+ * Close autoconfig file.
+ * Terminate the target list.
+ */
+ if (fclose(fp_config) != 0)
+ ERROR_EXIT(str_file_autoconf);
+ *ptarget = '\0';
+
+ /*
+ * Fix up existing files which have no new value.
+ * This is Case 4 and Case 5.
+ *
+ * I re-read the tree and filter it against list_target.
+ * This is crude. But it avoids data copies. Also, list_target
+ * is compact and contiguous, so it easily fits into cache.
+ *
+ * Notice that list_target contains strings separated by \n,
+ * with a \n before the first string and after the last.
+ * fgets gives the incoming names a terminating \n.
+ * So by having an initial \n, strstr will find exact matches.
+ */
+
+ fp_find = popen("find * -type f -name \"*.h\" -print", "r");
+ if (fp_find == 0)
+ ERROR_EXIT( "find" );
+
+ line[0] = '\n';
+ while (fgets(line+1, buffer_size, fp_find))
+ {
+ if (strstr(list_target, line) == NULL)
+ {
+ /*
+ * This is an old file with no CONFIG_* flag in autoconf.h.
+ */
+
+ /* First strip the \n. */
+ line[strlen(line)-1] = '\0';
+
+ /* Grab size. */
+ if (stat(line+1, &stat_buf) != 0)
+ ERROR_EXIT(line);
+
+ /* If file is not empty, make it empty and give it a fresh date. */
+ if (stat_buf.st_size != 0)
+ {
+ if ((fp_target = fopen(line+1, "w")) == NULL)
+ ERROR_EXIT(line);
+ if (fclose(fp_target) != 0)
+ ERROR_EXIT(line);
+ }
+ }
+ }
+
+ if (pclose(fp_find) != 0)
+ ERROR_EXIT("find");
+
+ return 0;
+}
diff -Nru a/scripts/docproc.c b/scripts/docproc.c
--- a/scripts/docproc.c Mon Mar 15 19:51:20 2004
+++ /dev/null Wed Dec 31 16:00:00 1969
@@ -1,387 +0,0 @@
-/*
- * docproc is a simple preprocessor for the template files
- * used as placeholders for the kernel internal documentation.
- * docproc is used for documentation-frontend and
- * dependency-generator.
- * The two usages have in common that they require
- * some knowledge of the .tmpl syntax, therefore they
- * are kept together.
- *
- * documentation-frontend
- * Scans the template file and call kernel-doc for
- * all occurrences of ![EIF]file
- * Beforehand each referenced file are scanned for
- * any exported sympols "EXPORT_SYMBOL()" statements.
- * This is used to create proper -function and
- * -nofunction arguments in calls to kernel-doc.
- * Usage: docproc doc file.tmpl
- *
- * dependency-generator:
- * Scans the template file and list all files
- * referenced in a format recognized by make.
- * Usage: docproc depend file.tmpl
- * Writes dependency information to stdout
- * in the following format:
- * file.tmpl src.c src2.c
- * The filenames are obtained from the following constructs:
- * !Efilename
- * !Ifilename
- * !Dfilename
- * !Ffilename
- *
- */
-
-#include <stdio.h>
-#include <stdlib.h>
-#include <string.h>
-#include <ctype.h>
-#include <unistd.h>
-#include <limits.h>
-#include <sys/types.h>
-#include <sys/wait.h>
-
-/* exitstatus is used to keep track of any failing calls to kernel-doc,
- * but execution continues. */
-int exitstatus = 0;
-
-typedef void DFL(char *);
-DFL *defaultline;
-
-typedef void FILEONLY(char * file);
-FILEONLY *internalfunctions;
-FILEONLY *externalfunctions;
-FILEONLY *symbolsonly;
-
-typedef void FILELINE(char * file, char * line);
-FILELINE * singlefunctions;
-FILELINE * entity_system;
-
-#define MAXLINESZ 2048
-#define MAXFILES 250
-#define KERNELDOCPATH "scripts/"
-#define KERNELDOC "kernel-doc"
-#define DOCBOOK "-docbook"
-#define FUNCTION "-function"
-#define NOFUNCTION "-nofunction"
-
-void usage (void)
-{
- fprintf(stderr, "Usage: docproc {doc|depend} file\n");
- fprintf(stderr, "Input is read from file.tmpl. Output is sent to stdout\n");
- fprintf(stderr, "doc: frontend when generating kernel documentation\n");
- fprintf(stderr, "depend: generate list of files referenced within file\n");
-}
-
-/*
- * Execute kernel-doc with parameters givin in svec
- */
-void exec_kernel_doc(char **svec)
-{
- pid_t pid;
- int ret;
- /* Make sure output generated so far are flushed */
- fflush(stdout);
- switch(pid=fork()) {
- case -1:
- perror("fork");
- exit(1);
- case 0:
- execvp(KERNELDOCPATH KERNELDOC, svec);
- perror("exec " KERNELDOCPATH KERNELDOC);
- exit(1);
- default:
- waitpid(pid, &ret ,0);
- }
- if (WIFEXITED(ret))
- exitstatus |= WEXITSTATUS(ret);
- else
- exitstatus = 0xff;
-}
-
-/* Types used to create list of all exported symbols in a number of files */
-struct symbols
-{
- char *name;
-};
-
-struct symfile
-{
- char *filename;
- struct symbols *symbollist;
- int symbolcnt;
-};
-
-struct symfile symfilelist[MAXFILES];
-int symfilecnt = 0;
-
-void add_new_symbol(struct symfile *sym, char * symname)
-{
- sym->symbollist =
- realloc(sym->symbollist, (sym->symbolcnt + 1) * sizeof(char *));
- sym->symbollist[sym->symbolcnt++].name = strdup(symname);
-}
-
-/* Add a filename to the list */
-struct symfile * add_new_file(char * filename)
-{
- symfilelist[symfilecnt++].filename = strdup(filename);
- return &symfilelist[symfilecnt - 1];
-}
-/* Check if file already are present in the list */
-struct symfile * filename_exist(char * filename)
-{
- int i;
- for (i=0; i < symfilecnt; i++)
- if (strcmp(symfilelist[i].filename, filename) == 0)
- return &symfilelist[i];
- return NULL;
-}
-
-/*
- * List all files referenced within the template file.
- * Files are separated by tabs.
- */
-void adddep(char * file) { printf("\t%s", file); }
-void adddep2(char * file, char * line) { line = line; adddep(file); }
-void noaction(char * line) { line = line; }
-void noaction2(char * file, char * line) { file = file; line = line; }
-
-/* Echo the line without further action */
-void printline(char * line) { printf("%s", line); }
-
-/*
- * Find all symbols exported with EXPORT_SYMBOL and EXPORT_SYMBOL_GPL
- * in filename.
- * All symbols located are stored in symfilelist.
- */
-void find_export_symbols(char * filename)
-{
- FILE * fp;
- struct symfile *sym;
- char line[MAXLINESZ];
- if (filename_exist(filename) == NULL) {
- sym = add_new_file(filename);
- fp = fopen(filename, "r");
- if (fp == NULL)
- {
- fprintf(stderr, "docproc: ");
- perror(filename);
- }
- while(fgets(line, MAXLINESZ, fp)) {
- char *p;
- char *e;
- if (((p = strstr(line, "EXPORT_SYMBOL_GPL")) != 0) ||
- ((p = strstr(line, "EXPORT_SYMBOL")) != 0)) {
- /* Skip EXPORT_SYMBOL{_GPL} */
- while (isalnum(*p) || *p == '_')
- p++;
- /* Remove paranteses and additional ws */
- while (isspace(*p))
- p++;
- if (*p != '(')
- continue; /* Syntax error? */
- else
- p++;
- while (isspace(*p))
- p++;
- e = p;
- while (isalnum(*e) || *e == '_')
- e++;
- *e = '\0';
- add_new_symbol(sym, p);
- }
- }
- fclose(fp);
- }
-}
-
-/*
- * Document all external or internal functions in a file.
- * Call kernel-doc with following parameters:
- * kernel-doc -docbook -nofunction function_name1 filename
- * function names are obtained from all the the src files
- * by find_export_symbols.
- * intfunc uses -nofunction
- * extfunc uses -function
- */
-void docfunctions(char * filename, char * type)
-{
- int i,j;
- int symcnt = 0;
- int idx = 0;
- char **vec;
-
- for (i=0; i <= symfilecnt; i++)
- symcnt += symfilelist[i].symbolcnt;
- vec = malloc((2 + 2 * symcnt + 2) * sizeof(char*));
- if (vec == NULL) {
- perror("docproc: ");
- exit(1);
- }
- vec[idx++] = KERNELDOC;
- vec[idx++] = DOCBOOK;
- for (i=0; i < symfilecnt; i++) {
- struct symfile * sym = &symfilelist[i];
- for (j=0; j < sym->symbolcnt; j++) {
- vec[idx++] = type;
- vec[idx++] = sym->symbollist[j].name;
- }
- }
- vec[idx++] = filename;
- vec[idx] = NULL;
- printf("<!-- %s -->\n", filename);
- exec_kernel_doc(vec);
- fflush(stdout);
- free(vec);
-}
-void intfunc(char * filename) { docfunctions(filename, NOFUNCTION); }
-void extfunc(char * filename) { docfunctions(filename, FUNCTION); }
-
-/*
- * Document spåecific function(s) in a file.
- * Call kernel-doc with the following parameters:
- * kernel-doc -docbook -function function1 [-function function2]
- */
-void singfunc(char * filename, char * line)
-{
- char *vec[200]; /* Enough for specific functions */
- int i, idx = 0;
- int startofsym = 1;
- vec[idx++] = KERNELDOC;
- vec[idx++] = DOCBOOK;
-
- /* Split line up in individual parameters preceeded by FUNCTION */
- for (i=0; line[i]; i++) {
- if (isspace(line[i])) {
- line[i] = '\0';
- startofsym = 1;
- continue;
- }
- if (startofsym) {
- startofsym = 0;
- vec[idx++] = FUNCTION;
- vec[idx++] = &line[i];
- }
- }
- vec[idx++] = filename;
- vec[idx] = NULL;
- exec_kernel_doc(vec);
-}
-
-/*
- * Parse file, calling action specific functions for:
- * 1) Lines containing !E
- * 2) Lines containing !I
- * 3) Lines containing !D
- * 4) Lines containing !F
- * 5) Default lines - lines not matching the above
- */
-void parse_file(FILE *infile)
-{
- char line[MAXLINESZ];
- char * s;
- while(fgets(line, MAXLINESZ, infile)) {
- if (line[0] == '!') {
- s = line + 2;
- switch (line[1]) {
- case 'E':
- while (*s && !isspace(*s)) s++;
- *s = '\0';
- externalfunctions(line+2);
- break;
- case 'I':
- while (*s && !isspace(*s)) s++;
- *s = '\0';
- internalfunctions(line+2);
- break;
- case 'D':
- while (*s && !isspace(*s)) s++;
- *s = '\0';
- symbolsonly(line+2);
- break;
- case 'F':
- /* filename */
- while (*s && !isspace(*s)) s++;
- *s++ = '\0';
- /* function names */
- while (isspace(*s))
- s++;
- singlefunctions(line +2, s);
- break;
- default:
- defaultline(line);
- }
- }
- else {
- defaultline(line);
- }
- }
- fflush(stdout);
-}
-
-
-int main(int argc, char *argv[])
-{
- FILE * infile;
- if (argc != 3) {
- usage();
- exit(1);
- }
- /* Open file, exit on error */
- infile = fopen(argv[2], "r");
- if (infile == NULL) {
- fprintf(stderr, "docproc: ");
- perror(argv[2]);
- exit(2);
- }
-
- if (strcmp("doc", argv[1]) == 0)
- {
- /* Need to do this in two passes.
- * First pass is used to collect all symbols exported
- * in the various files.
- * Second pass generate the documentation.
- * This is required because function are declared
- * and exported in different files :-((
- */
- /* Collect symbols */
- defaultline = noaction;
- internalfunctions = find_export_symbols;
- externalfunctions = find_export_symbols;
- symbolsonly = find_export_symbols;
- singlefunctions = noaction2;
- parse_file(infile);
-
- /* Rewind to start from beginning of file again */
- fseek(infile, 0, SEEK_SET);
- defaultline = printline;
- internalfunctions = intfunc;
- externalfunctions = extfunc;
- symbolsonly = printline;
- singlefunctions = singfunc;
-
- parse_file(infile);
- }
- else if (strcmp("depend", argv[1]) == 0)
- {
- /* Create first part of dependency chain
- * file.tmpl */
- printf("%s\t", argv[2]);
- defaultline = noaction;
- internalfunctions = adddep;
- externalfunctions = adddep;
- symbolsonly = adddep;
- singlefunctions = adddep2;
- parse_file(infile);
- printf("\n");
- }
- else
- {
- fprintf(stderr, "Unknown option: %s\n", argv[1]);
- exit(1);
- }
- fclose(infile);
- fflush(stdout);
- return exitstatus;
-}
-
diff -Nru a/scripts/fixdep.c b/scripts/fixdep.c
--- a/scripts/fixdep.c Mon Mar 15 19:51:20 2004
+++ /dev/null Wed Dec 31 16:00:00 1969
@@ -1,381 +0,0 @@
-/*
- * "Optimize" a list of dependencies as spit out by gcc -MD
- * for the kernel build
- * ===========================================================================
- *
- * Author Kai Germaschewski
- * Copyright 2002 by Kai Germaschewski <kai.germaschewski@gmx.de>
- *
- * This software may be used and distributed according to the terms
- * of the GNU General Public License, incorporated herein by reference.
- *
- *
- * Introduction:
- *
- * gcc produces a very nice and correct list of dependencies which
- * tells make when to remake a file.
- *
- * To use this list as-is however has the drawback that virtually
- * every file in the kernel includes <linux/config.h> which then again
- * includes <linux/autoconf.h>
- *
- * If the user re-runs make *config, linux/autoconf.h will be
- * regenerated. make notices that and will rebuild every file which
- * includes autoconf.h, i.e. basically all files. This is extremely
- * annoying if the user just changed CONFIG_HIS_DRIVER from n to m.
- *
- * So we play the same trick that "mkdep" played before. We replace
- * the dependency on linux/autoconf.h by a dependency on every config
- * option which is mentioned in any of the listed prequisites.
- *
- * To be exact, split-include populates a tree in include/config/,
- * e.g. include/config/his/driver.h, which contains the #define/#undef
- * for the CONFIG_HIS_DRIVER option.
- *
- * So if the user changes his CONFIG_HIS_DRIVER option, only the objects
- * which depend on "include/linux/config/his/driver.h" will be rebuilt,
- * so most likely only his driver ;-)
- *
- * The idea above dates, by the way, back to Michael E Chastain, AFAIK.
- *
- * So to get dependencies right, there two issues:
- * o if any of the files the compiler read changed, we need to rebuild
- * o if the command line given to the compile the file changed, we
- * better rebuild as well.
- *
- * The former is handled by using the -MD output, the later by saving
- * the command line used to compile the old object and comparing it
- * to the one we would now use.
- *
- * Again, also this idea is pretty old and has been discussed on
- * kbuild-devel a long time ago. I don't have a sensibly working
- * internet connection right now, so I rather don't mention names
- * without double checking.
- *
- * This code here has been based partially based on mkdep.c, which
- * says the following about its history:
- *
- * Copyright abandoned, Michael Chastain, <mailto:mec@shout.net>.
- * This is a C version of syncdep.pl by Werner Almesberger.
- *
- *
- * It is invoked as
- *
- * fixdep <depfile> <target> <cmdline>
- *
- * and will read the dependency file <depfile>
- *
- * The transformed dependency snipped is written to stdout.
- *
- * It first generates a line
- *
- * cmd_<target> = <cmdline>
- *
- * and then basically copies the .<target>.d file to stdout, in the
- * process filtering out the dependency on linux/autoconf.h and adding
- * dependencies on include/config/my/option.h for every
- * CONFIG_MY_OPTION encountered in any of the prequisites.
- *
- * It will also filter out all the dependencies on *.ver. We need
- * to make sure that the generated version checksum are globally up
- * to date before even starting the recursive build, so it's too late
- * at this point anyway.
- *
- * The algorithm to grep for "CONFIG_..." is bit unusual, but should
- * be fast ;-) We don't even try to really parse the header files, but
- * merely grep, i.e. if CONFIG_FOO is mentioned in a comment, it will
- * be picked up as well. It's not a problem with respect to
- * correctness, since that can only give too many dependencies, thus
- * we cannot miss a rebuild. Since people tend to not mention totally
- * unrelated CONFIG_ options all over the place, it's not an
- * efficiency problem either.
- *
- * (Note: it'd be easy to port over the complete mkdep state machine,
- * but I don't think the added complexity is worth it)
- */
-
-#include <sys/types.h>
-#include <sys/stat.h>
-#include <sys/mman.h>
-#include <unistd.h>
-#include <fcntl.h>
-#include <string.h>
-#include <stdlib.h>
-#include <stdio.h>
-#include <limits.h>
-#include <ctype.h>
-#include <netinet/in.h>
-
-#define INT_CONF ntohl(0x434f4e46)
-#define INT_ONFI ntohl(0x4f4e4649)
-#define INT_NFIG ntohl(0x4e464947)
-#define INT_FIG_ ntohl(0x4649475f)
-
-char *target;
-char *depfile;
-char *cmdline;
-
-void usage(void)
-
-{
- fprintf(stderr, "Usage: fixdep <depfile> <target> <cmdline>\n");
- exit(1);
-}
-
-void print_cmdline(void)
-{
- printf("cmd_%s := %s\n\n", target, cmdline);
-}
-
-char * str_config = NULL;
-int size_config = 0;
-int len_config = 0;
-
-/*
- * Grow the configuration string to a desired length.
- * Usually the first growth is plenty.
- */
-void grow_config(int len)
-{
- while (len_config + len > size_config) {
- if (size_config == 0)
- size_config = 2048;
- str_config = realloc(str_config, size_config *= 2);
- if (str_config == NULL)
- { perror("fixdep:malloc"); exit(1); }
- }
-}
-
-
-
-/*
- * Lookup a value in the configuration string.
- */
-int is_defined_config(const char * name, int len)
-{
- const char * pconfig;
- const char * plast = str_config + len_config - len;
- for ( pconfig = str_config + 1; pconfig < plast; pconfig++ ) {
- if (pconfig[ -1] == '\n'
- && pconfig[len] == '\n'
- && !memcmp(pconfig, name, len))
- return 1;
- }
- return 0;
-}
-
-/*
- * Add a new value to the configuration string.
- */
-void define_config(const char * name, int len)
-{
- grow_config(len + 1);
-
- memcpy(str_config+len_config, name, len);
- len_config += len;
- str_config[len_config++] = '\n';
-}
-
-/*
- * Clear the set of configuration strings.
- */
-void clear_config(void)
-{
- len_config = 0;
- define_config("", 0);
-}
-
-/*
- * Record the use of a CONFIG_* word.
- */
-void use_config(char *m, int slen)
-{
- char s[PATH_MAX];
- char *p;
-
- if (is_defined_config(m, slen))
- return;
-
- define_config(m, slen);
-
- memcpy(s, m, slen); s[slen] = 0;
-
- for (p = s; p < s + slen; p++) {
- if (*p == '_')
- *p = '/';
- else
- *p = tolower((unsigned char)*p);
- }
- printf(" $(wildcard include/config/%s.h) \\\n", s);
-}
-
-void parse_config_file(char *map, size_t len)
-{
- int *end = (int *) (map + len);
- /* start at +1, so that p can never be < map */
- int *m = (int *) map + 1;
- char *p, *q;
-
- for (; m < end; m++) {
- if (*m == INT_CONF) { p = (char *) m ; goto conf; }
- if (*m == INT_ONFI) { p = (char *) m-1; goto conf; }
- if (*m == INT_NFIG) { p = (char *) m-2; goto conf; }
- if (*m == INT_FIG_) { p = (char *) m-3; goto conf; }
- continue;
- conf:
- if (p > map + len - 7)
- continue;
- if (memcmp(p, "CONFIG_", 7))
- continue;
- for (q = p + 7; q < map + len; q++) {
- if (!(isalnum(*q) || *q == '_'))
- goto found;
- }
- continue;
-
- found:
- use_config(p+7, q-p-7);
- }
-}
-
-/* test is s ends in sub */
-int strrcmp(char *s, char *sub)
-{
- int slen = strlen(s);
- int sublen = strlen(sub);
-
- if (sublen > slen)
- return 1;
-
- return memcmp(s + slen - sublen, sub, sublen);
-}
-
-void do_config_file(char *filename)
-{
- struct stat st;
- int fd;
- void *map;
-
- fd = open(filename, O_RDONLY);
- if (fd < 0) {
- fprintf(stderr, "fixdep: ");
- perror(filename);
- exit(2);
- }
- fstat(fd, &st);
- if (st.st_size == 0) {
- close(fd);
- return;
- }
- map = mmap(NULL, st.st_size, PROT_READ, MAP_PRIVATE, fd, 0);
- if ((long) map == -1) {
- perror("fixdep: mmap");
- close(fd);
- return;
- }
-
- parse_config_file(map, st.st_size);
-
- munmap(map, st.st_size);
-
- close(fd);
-}
-
-void parse_dep_file(void *map, size_t len)
-{
- char *m = map;
- char *end = m + len;
- char *p;
- char s[PATH_MAX];
-
- p = strchr(m, ':');
- if (!p) {
- fprintf(stderr, "fixdep: parse error\n");
- exit(1);
- }
- memcpy(s, m, p-m); s[p-m] = 0;
- printf("deps_%s := \\\n", target);
- m = p+1;
-
- clear_config();
-
- while (m < end) {
- while (m < end && (*m == ' ' || *m == '\\' || *m == '\n'))
- m++;
- p = m;
- while (p < end && *p != ' ') p++;
- if (p == end) {
- do p--; while (!isalnum(*p));
- p++;
- }
- memcpy(s, m, p-m); s[p-m] = 0;
- if (strrcmp(s, "include/linux/autoconf.h") &&
- strrcmp(s, ".ver")) {
- printf(" %s \\\n", s);
- do_config_file(s);
- }
- m = p + 1;
- }
- printf("\n%s: $(deps_%s)\n\n", target, target);
- printf("$(deps_%s):\n", target);
-}
-
-void print_deps(void)
-{
- struct stat st;
- int fd;
- void *map;
-
- fd = open(depfile, O_RDONLY);
- if (fd < 0) {
- fprintf(stderr, "fixdep: ");
- perror(depfile);
- exit(2);
- }
- fstat(fd, &st);
- if (st.st_size == 0) {
- fprintf(stderr,"fixdep: %s is empty\n",depfile);
- close(fd);
- return;
- }
- map = mmap(NULL, st.st_size, PROT_READ, MAP_PRIVATE, fd, 0);
- if ((long) map == -1) {
- perror("fixdep: mmap");
- close(fd);
- return;
- }
-
- parse_dep_file(map, st.st_size);
-
- munmap(map, st.st_size);
-
- close(fd);
-}
-
-void traps(void)
-{
- static char test[] __attribute__((aligned(sizeof(int)))) = "CONF";
-
- if (*(int *)test != INT_CONF) {
- fprintf(stderr, "fixdep: sizeof(int) != 4 or wrong endianess? %#x\n",
- *(int *)test);
- exit(2);
- }
-}
-
-int main(int argc, char *argv[])
-{
- traps();
-
- if (argc != 4)
- usage();
-
- depfile = argv[1];
- target = argv[2];
- cmdline = argv[3];
-
- print_cmdline();
- print_deps();
-
- return 0;
-}
diff -Nru a/scripts/split-include.c b/scripts/split-include.c
--- a/scripts/split-include.c Mon Mar 15 19:51:20 2004
+++ /dev/null Wed Dec 31 16:00:00 1969
@@ -1,226 +0,0 @@
-/*
- * split-include.c
- *
- * Copyright abandoned, Michael Chastain, <mailto:mec@shout.net>.
- * This is a C version of syncdep.pl by Werner Almesberger.
- *
- * This program takes autoconf.h as input and outputs a directory full
- * of one-line include files, merging onto the old values.
- *
- * Think of the configuration options as key-value pairs. Then there
- * are five cases:
- *
- * key old value new value action
- *
- * KEY-1 VALUE-1 VALUE-1 leave file alone
- * KEY-2 VALUE-2A VALUE-2B write VALUE-2B into file
- * KEY-3 - VALUE-3 write VALUE-3 into file
- * KEY-4 VALUE-4 - write an empty file
- * KEY-5 (empty) - leave old empty file alone
- */
-
-#include <sys/stat.h>
-#include <sys/types.h>
-
-#include <ctype.h>
-#include <errno.h>
-#include <fcntl.h>
-#include <stdio.h>
-#include <stdlib.h>
-#include <string.h>
-#include <unistd.h>
-
-#define ERROR_EXIT(strExit) \
- { \
- const int errnoSave = errno; \
- fprintf(stderr, "%s: ", str_my_name); \
- errno = errnoSave; \
- perror((strExit)); \
- exit(1); \
- }
-
-
-
-int main(int argc, const char * argv [])
-{
- const char * str_my_name;
- const char * str_file_autoconf;
- const char * str_dir_config;
-
- FILE * fp_config;
- FILE * fp_target;
- FILE * fp_find;
-
- int buffer_size;
-
- char * line;
- char * old_line;
- char * list_target;
- char * ptarget;
-
- struct stat stat_buf;
-
- /* Check arg count. */
- if (argc != 3)
- {
- fprintf(stderr, "%s: wrong number of arguments.\n", argv[0]);
- exit(1);
- }
-
- str_my_name = argv[0];
- str_file_autoconf = argv[1];
- str_dir_config = argv[2];
-
- /* Find a buffer size. */
- if (stat(str_file_autoconf, &stat_buf) != 0)
- ERROR_EXIT(str_file_autoconf);
- buffer_size = 2 * stat_buf.st_size + 4096;
-
- /* Allocate buffers. */
- if ( (line = malloc(buffer_size)) == NULL
- || (old_line = malloc(buffer_size)) == NULL
- || (list_target = malloc(buffer_size)) == NULL )
- ERROR_EXIT(str_file_autoconf);
-
- /* Open autoconfig file. */
- if ((fp_config = fopen(str_file_autoconf, "r")) == NULL)
- ERROR_EXIT(str_file_autoconf);
-
- /* Make output directory if needed. */
- if (stat(str_dir_config, &stat_buf) != 0)
- {
- if (mkdir(str_dir_config, 0755) != 0)
- ERROR_EXIT(str_dir_config);
- }
-
- /* Change to output directory. */
- if (chdir(str_dir_config) != 0)
- ERROR_EXIT(str_dir_config);
-
- /* Put initial separator into target list. */
- ptarget = list_target;
- *ptarget++ = '\n';
-
- /* Read config lines. */
- while (fgets(line, buffer_size, fp_config))
- {
- const char * str_config;
- int is_same;
- int itarget;
-
- if (line[0] != '#')
- continue;
- if ((str_config = strstr(line, "CONFIG_")) == NULL)
- continue;
-
- /* Make the output file name. */
- str_config += sizeof("CONFIG_") - 1;
- for (itarget = 0; !isspace(str_config[itarget]); itarget++)
- {
- int c = (unsigned char) str_config[itarget];
- if (isupper(c)) c = tolower(c);
- if (c == '_') c = '/';
- ptarget[itarget] = c;
- }
- ptarget[itarget++] = '.';
- ptarget[itarget++] = 'h';
- ptarget[itarget++] = '\0';
-
- /* Check for existing file. */
- is_same = 0;
- if ((fp_target = fopen(ptarget, "r")) != NULL)
- {
- fgets(old_line, buffer_size, fp_target);
- if (fclose(fp_target) != 0)
- ERROR_EXIT(ptarget);
- if (!strcmp(line, old_line))
- is_same = 1;
- }
-
- if (!is_same)
- {
- /* Auto-create directories. */
- int islash;
- for (islash = 0; islash < itarget; islash++)
- {
- if (ptarget[islash] == '/')
- {
- ptarget[islash] = '\0';
- if (stat(ptarget, &stat_buf) != 0
- && mkdir(ptarget, 0755) != 0)
- ERROR_EXIT( ptarget );
- ptarget[islash] = '/';
- }
- }
-
- /* Write the file. */
- if ((fp_target = fopen(ptarget, "w" )) == NULL)
- ERROR_EXIT(ptarget);
- fputs(line, fp_target);
- if (ferror(fp_target) || fclose(fp_target) != 0)
- ERROR_EXIT(ptarget);
- }
-
- /* Update target list */
- ptarget += itarget;
- *(ptarget-1) = '\n';
- }
-
- /*
- * Close autoconfig file.
- * Terminate the target list.
- */
- if (fclose(fp_config) != 0)
- ERROR_EXIT(str_file_autoconf);
- *ptarget = '\0';
-
- /*
- * Fix up existing files which have no new value.
- * This is Case 4 and Case 5.
- *
- * I re-read the tree and filter it against list_target.
- * This is crude. But it avoids data copies. Also, list_target
- * is compact and contiguous, so it easily fits into cache.
- *
- * Notice that list_target contains strings separated by \n,
- * with a \n before the first string and after the last.
- * fgets gives the incoming names a terminating \n.
- * So by having an initial \n, strstr will find exact matches.
- */
-
- fp_find = popen("find * -type f -name \"*.h\" -print", "r");
- if (fp_find == 0)
- ERROR_EXIT( "find" );
-
- line[0] = '\n';
- while (fgets(line+1, buffer_size, fp_find))
- {
- if (strstr(list_target, line) == NULL)
- {
- /*
- * This is an old file with no CONFIG_* flag in autoconf.h.
- */
-
- /* First strip the \n. */
- line[strlen(line)-1] = '\0';
-
- /* Grab size. */
- if (stat(line+1, &stat_buf) != 0)
- ERROR_EXIT(line);
-
- /* If file is not empty, make it empty and give it a fresh date. */
- if (stat_buf.st_size != 0)
- {
- if ((fp_target = fopen(line+1, "w")) == NULL)
- ERROR_EXIT(line);
- if (fclose(fp_target) != 0)
- ERROR_EXIT(line);
- }
- }
- }
-
- if (pclose(fp_find) != 0)
- ERROR_EXIT("find");
-
- return 0;
-}
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.4-mm2 (compile stats)
2004-03-15 1:28 2.6.4-mm2 Andrew Morton
` (3 preceding siblings ...)
2004-03-15 18:54 ` 2.6.4-mm2 Sam Ravnborg
@ 2004-03-15 19:18 ` John Cherry
2004-03-15 20:57 ` 2.6.4-mm2 Thomas Schlichter
` (3 subsequent siblings)
8 siblings, 0 replies; 90+ messages in thread
From: John Cherry @ 2004-03-15 19:18 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
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:
--- linux/Makefile~ 2004-03-14 17:52:54.000000000 -0800
+++ linux/Makefile 2004-03-14 17:52:21.000000000 -0800
@@ -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)
--
Joshua Kwan
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.4-mm2
2004-03-15 1:28 2.6.4-mm2 Andrew Morton
` (4 preceding siblings ...)
2004-03-15 19:18 ` 2.6.4-mm2 (compile stats) John Cherry
@ 2004-03-15 20:57 ` Thomas Schlichter
2004-03-15 21:08 ` 2.6.4-mm2 Thomas Schlichter
2004-03-15 21:18 ` 2.6.4-mm2 Andrew Morton
2004-03-15 22:11 ` 2.6.4-mm2 Jesse Barnes
` (2 subsequent siblings)
8 siblings, 2 replies; 90+ messages in thread
From: Thomas Schlichter @ 2004-03-15 20:57 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 1357 bytes --]
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
[-- Attachment #2: config-2.6.4-mm2 --]
[-- Type: text/plain, Size: 50541 bytes --]
#
# 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
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.4-mm2
2004-03-15 20:57 ` 2.6.4-mm2 Thomas Schlichter
@ 2004-03-15 21:08 ` Thomas Schlichter
2004-03-15 21:18 ` 2.6.4-mm2 Andrew Morton
1 sibling, 0 replies; 90+ messages in thread
From: Thomas Schlichter @ 2004-03-15 21:08 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
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.
>
> 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
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.4-mm2
2004-03-15 21:18 ` 2.6.4-mm2 Andrew Morton
@ 2004-03-15 21:18 ` Jens Axboe
2004-03-15 22:40 ` 2.6.4-mm2 Thomas Schlichter
1 sibling, 0 replies; 90+ messages in thread
From: Jens Axboe @ 2004-03-15 21:18 UTC (permalink / raw)
To: Andrew Morton; +Cc: Thomas Schlichter, linux-kernel
On Mon, Mar 15 2004, Andrew Morton wrote:
> Thomas Schlichter <thomas.schlichter@web.de> wrote:
> >
> > 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
>
> Someone got his bitmasks and bitshifts mixed up again ;)
Fudge, thanks Andrew.
--
Jens Axboe
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.4-mm2
2004-03-15 20:57 ` 2.6.4-mm2 Thomas Schlichter
2004-03-15 21:08 ` 2.6.4-mm2 Thomas Schlichter
@ 2004-03-15 21:18 ` Andrew Morton
2004-03-15 21:18 ` 2.6.4-mm2 Jens Axboe
2004-03-15 22:40 ` 2.6.4-mm2 Thomas Schlichter
1 sibling, 2 replies; 90+ messages in thread
From: Andrew Morton @ 2004-03-15 21:18 UTC (permalink / raw)
To: Thomas Schlichter; +Cc: linux-kernel, Jens Axboe
Thomas Schlichter <thomas.schlichter@web.de> wrote:
>
> 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
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
diff -puN include/linux/bio.h~per-backing_dev-unplugging-BIO_RW_SYNC-fix include/linux/bio.h
--- 25/include/linux/bio.h~per-backing_dev-unplugging-BIO_RW_SYNC-fix Mon Mar 15 13:13:06 2004
+++ 25-akpm/include/linux/bio.h Mon Mar 15 13:14:40 2004
@@ -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
diff -puN include/linux/fs.h~per-backing_dev-unplugging-BIO_RW_SYNC-fix include/linux/fs.h
--- 25/include/linux/fs.h~per-backing_dev-unplugging-BIO_RW_SYNC-fix Mon Mar 15 13:13:06 2004
+++ 25-akpm/include/linux/fs.h Mon Mar 15 13:15:11 2004
@@ -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
diff -puN kernel/power/pmdisk.c~per-backing_dev-unplugging-BIO_RW_SYNC-fix kernel/power/pmdisk.c
--- 25/kernel/power/pmdisk.c~per-backing_dev-unplugging-BIO_RW_SYNC-fix Mon Mar 15 13:13:06 2004
+++ 25-akpm/kernel/power/pmdisk.c Mon Mar 15 13:15:33 2004
@@ -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);
_
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.4-mm2
2004-03-15 1:28 2.6.4-mm2 Andrew Morton
` (5 preceding siblings ...)
2004-03-15 20:57 ` 2.6.4-mm2 Thomas Schlichter
@ 2004-03-15 22:11 ` Jesse Barnes
2004-03-16 18:32 ` 2.6.4-mm2 Daniel McNeil
2004-03-18 17:37 ` 2.6.4-mm2 markw
8 siblings, 0 replies; 90+ messages in thread
From: Jesse Barnes @ 2004-03-15 22:11 UTC (permalink / raw)
To: Andrew Morton, axboe; +Cc: linux-kernel
On Sun, Mar 14, 2004 at 05:28:09PM -0800, Andrew Morton wrote:
> - 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
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.4-mm2
2004-03-15 21:18 ` 2.6.4-mm2 Andrew Morton
2004-03-15 21:18 ` 2.6.4-mm2 Jens Axboe
@ 2004-03-15 22:40 ` Thomas Schlichter
1 sibling, 0 replies; 90+ messages in thread
From: Thomas Schlichter @ 2004-03-15 22:40 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, Jens Axboe
Am Montag, 15. März 2004 22:18 schrieb Andrew Morton:
> Thomas Schlichter <thomas.schlichter@web.de> wrote:
> > 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
>
> Someone got his bitmasks and bitshifts mixed up again ;)
[patch snipped]
Yeah, this fixes it...
Thanks!
Regards
Thomas
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.4-mm2
2004-03-15 1:28 2.6.4-mm2 Andrew Morton
` (6 preceding siblings ...)
2004-03-15 22:11 ` 2.6.4-mm2 Jesse Barnes
@ 2004-03-16 18:32 ` Daniel McNeil
2004-03-16 21:58 ` 2.6.4-mm2 Chris Mason
2004-03-18 17:37 ` 2.6.4-mm2 markw
8 siblings, 1 reply; 90+ messages in thread
From: Daniel McNeil @ 2004-03-16 18:32 UTC (permalink / raw)
To: Andrew Morton; +Cc: Linux Kernel Mailing List, linux-aio
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
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.4-mm2
2004-03-16 18:32 ` 2.6.4-mm2 Daniel McNeil
@ 2004-03-16 21:58 ` Chris Mason
2004-03-16 23:21 ` 2.6.4-mm2 Andrew Morton
0 siblings, 1 reply; 90+ messages in thread
From: Chris Mason @ 2004-03-16 21:58 UTC (permalink / raw)
To: Daniel McNeil; +Cc: Andrew Morton, Linux Kernel Mailing List, linux-aio
On Tue, 2004-03-16 at 13:32, Daniel McNeil wrote:
> 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
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.4-mm2
2004-03-16 21:58 ` 2.6.4-mm2 Chris Mason
@ 2004-03-16 23:21 ` Andrew Morton
2004-03-16 23:28 ` 2.6.4-mm2 Andrew Morton
0 siblings, 1 reply; 90+ messages in thread
From: Andrew Morton @ 2004-03-16 23:21 UTC (permalink / raw)
To: Chris Mason; +Cc: daniel, linux-kernel, linux-aio
Chris Mason <mason@suse.com> wrote:
>
> On Tue, 2004-03-16 at 13:32, Daniel McNeil wrote:
> > 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.
> 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.
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.4-mm2
2004-03-16 23:21 ` 2.6.4-mm2 Andrew Morton
@ 2004-03-16 23:28 ` Andrew Morton
2004-03-16 23:39 ` 2.6.4-mm2 Andrew Morton
0 siblings, 1 reply; 90+ messages in thread
From: Andrew Morton @ 2004-03-16 23:28 UTC (permalink / raw)
To: mason, daniel, linux-kernel, linux-aio
Andrew Morton <akpm@osdl.org> wrote:
>
> 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.
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.4-mm2
2004-03-16 23:28 ` 2.6.4-mm2 Andrew Morton
@ 2004-03-16 23:39 ` Andrew Morton
2004-03-17 0:10 ` 2.6.4-mm2 Daniel McNeil
[not found] ` <1079485055.4181.1115.camel@watt.suse.com>
0 siblings, 2 replies; 90+ messages in thread
From: Andrew Morton @ 2004-03-16 23:39 UTC (permalink / raw)
To: mason, daniel, linux-kernel, linux-aio
Andrew Morton <akpm@osdl.org> wrote:
>
> Andrew Morton <akpm@osdl.org> wrote:
> >
> > 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.
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.
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.4-mm2
2004-03-16 23:39 ` 2.6.4-mm2 Andrew Morton
@ 2004-03-17 0:10 ` Daniel McNeil
[not found] ` <1079485055.4181.1115.camel@watt.suse.com>
1 sibling, 0 replies; 90+ messages in thread
From: Daniel McNeil @ 2004-03-17 0:10 UTC (permalink / raw)
To: Andrew Morton; +Cc: mason, Linux Kernel Mailing List, linux-aio
On Tue, 2004-03-16 at 15:39, Andrew Morton wrote:
> Andrew Morton <akpm@osdl.org> wrote:
> >
> > Andrew Morton <akpm@osdl.org> wrote:
> > >
> > > 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.
>
> 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
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.4-mm2
[not found] ` <20040316180043.441e8150.akpm@osdl.org>
@ 2004-03-17 20:11 ` Chris Mason
2004-03-17 20:33 ` 2.6.4-mm2 Andrew Morton
0 siblings, 1 reply; 90+ messages in thread
From: Chris Mason @ 2004-03-17 20:11 UTC (permalink / raw)
To: Andrew Morton; +Cc: Daniel McNeil, linux-kernel, linux-aio
[ data not getting flushed ]
Ummm, this might help:
-chris
--- l/mm/filemap.c.1 2004-03-17 15:08:37.581083800 -0500
+++ l/mm/filemap.c 2004-03-17 15:08:47.105635848 -0500
@@ -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);
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.4-mm2
2004-03-17 20:11 ` 2.6.4-mm2 Chris Mason
@ 2004-03-17 20:33 ` Andrew Morton
2004-03-17 22:46 ` 2.6.4-mm2 Chris Mason
0 siblings, 1 reply; 90+ messages in thread
From: Andrew Morton @ 2004-03-17 20:33 UTC (permalink / raw)
To: Chris Mason; +Cc: daniel, linux-kernel, linux-aio
Chris Mason <mason@suse.com> wrote:
>
> [ 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...
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.4-mm2
2004-03-17 20:33 ` 2.6.4-mm2 Andrew Morton
@ 2004-03-17 22:46 ` Chris Mason
2004-03-17 23:09 ` 2.6.4-mm2 Andrew Morton
0 siblings, 1 reply; 90+ messages in thread
From: Chris Mason @ 2004-03-17 22:46 UTC (permalink / raw)
To: Andrew Morton; +Cc: daniel, linux-kernel, linux-aio
On Wed, 2004-03-17 at 15:33, Andrew Morton wrote:
> Chris Mason <mason@suse.com> wrote:
> >
> > [ 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
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.4-mm2
2004-03-17 22:46 ` 2.6.4-mm2 Chris Mason
@ 2004-03-17 23:09 ` Andrew Morton
2004-03-17 23:27 ` 2.6.4-mm2 Chris Mason
0 siblings, 1 reply; 90+ messages in thread
From: Andrew Morton @ 2004-03-17 23:09 UTC (permalink / raw)
To: Chris Mason; +Cc: daniel, linux-kernel, linux-aio
Chris Mason <mason@suse.com> wrote:
>
> 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?
--- 25/mm/filemap.c~stop-using-locked-pages-fix-2 2004-03-17 15:01:47.466260848 -0800
+++ 25-akpm/mm/filemap.c 2004-03-17 15:04:10.730481376 -0800
@@ -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++) {
_
> 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.
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.4-mm2
2004-03-17 23:09 ` 2.6.4-mm2 Andrew Morton
@ 2004-03-17 23:27 ` Chris Mason
2004-03-17 23:51 ` 2.6.4-mm2 Andrew Morton
0 siblings, 1 reply; 90+ messages in thread
From: Chris Mason @ 2004-03-17 23:27 UTC (permalink / raw)
To: Andrew Morton; +Cc: daniel, linux-kernel, linux-aio
On Wed, 2004-03-17 at 18:09, Andrew Morton wrote:
> Chris Mason <mason@suse.com> wrote:
> >
> > 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
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.4-mm2
2004-03-17 23:27 ` 2.6.4-mm2 Chris Mason
@ 2004-03-17 23:51 ` Andrew Morton
2004-03-18 0:06 ` 2.6.4-mm2 Chris Mason
0 siblings, 1 reply; 90+ messages in thread
From: Andrew Morton @ 2004-03-17 23:51 UTC (permalink / raw)
To: Chris Mason; +Cc: daniel, linux-kernel, linux-aio
Chris Mason <mason@suse.com> wrote:
>
> 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..
--- 25/mm/page-writeback.c~x 2004-03-17 15:43:40.102282112 -0800
+++ 25-akpm/mm/page-writeback.c 2004-03-17 15:43:52.317425128 -0800
@@ -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))
_
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.4-mm2
2004-03-17 23:51 ` 2.6.4-mm2 Andrew Morton
@ 2004-03-18 0:06 ` Chris Mason
2004-03-18 0:13 ` 2.6.4-mm2 Andrew Morton
0 siblings, 1 reply; 90+ messages in thread
From: Chris Mason @ 2004-03-18 0:06 UTC (permalink / raw)
To: Andrew Morton; +Cc: daniel, linux-kernel, linux-aio
On Wed, 2004-03-17 at 18:51, Andrew Morton wrote:
> Chris Mason <mason@suse.com> wrote:
> >
> > 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
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.4-mm2
2004-03-18 0:06 ` 2.6.4-mm2 Chris Mason
@ 2004-03-18 0:13 ` Andrew Morton
2004-03-18 0:31 ` 2.6.4-mm2 Chris Mason
0 siblings, 1 reply; 90+ messages in thread
From: Andrew Morton @ 2004-03-18 0:13 UTC (permalink / raw)
To: Chris Mason; +Cc: daniel, linux-kernel, linux-aio
Chris Mason <mason@suse.com> wrote:
>
> On Wed, 2004-03-17 at 18:51, Andrew Morton wrote:
> > Chris Mason <mason@suse.com> wrote:
> > >
> > > 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.
> 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();
}
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.4-mm2
2004-03-18 0:13 ` 2.6.4-mm2 Andrew Morton
@ 2004-03-18 0:31 ` Chris Mason
2004-03-18 0:33 ` 2.6.4-mm2 Andrew Morton
0 siblings, 1 reply; 90+ messages in thread
From: Chris Mason @ 2004-03-18 0:31 UTC (permalink / raw)
To: Andrew Morton; +Cc: daniel, linux-kernel, linux-aio
On Wed, 2004-03-17 at 19:13, Andrew Morton wrote:
> Chris Mason <mason@suse.com> wrote:
> >
> > On Wed, 2004-03-17 at 18:51, Andrew Morton wrote:
> > > Chris Mason <mason@suse.com> wrote:
> > > >
> > > > 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.
>
> > 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
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.4-mm2
2004-03-18 0:31 ` 2.6.4-mm2 Chris Mason
@ 2004-03-18 0:33 ` Andrew Morton
2004-03-18 0:41 ` 2.6.4-mm2 Chris Mason
2004-03-18 1:15 ` 2.6.4-mm2 Daniel McNeil
0 siblings, 2 replies; 90+ messages in thread
From: Andrew Morton @ 2004-03-18 0:33 UTC (permalink / raw)
To: Chris Mason; +Cc: daniel, linux-kernel, linux-aio
Chris Mason <mason@suse.com> wrote:
>
> 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.
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.4-mm2
2004-03-18 0:33 ` 2.6.4-mm2 Andrew Morton
@ 2004-03-18 0:41 ` Chris Mason
2004-03-18 1:15 ` 2.6.4-mm2 Daniel McNeil
1 sibling, 0 replies; 90+ messages in thread
From: Chris Mason @ 2004-03-18 0:41 UTC (permalink / raw)
To: Andrew Morton; +Cc: daniel, linux-kernel, linux-aio
On Wed, 2004-03-17 at 19:33, Andrew Morton wrote:
> Chris Mason <mason@suse.com> wrote:
> >
> > 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
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.4-mm2
2004-03-18 0:33 ` 2.6.4-mm2 Andrew Morton
2004-03-18 0:41 ` 2.6.4-mm2 Chris Mason
@ 2004-03-18 1:15 ` Daniel McNeil
2004-03-18 17:53 ` 2.6.4-mm2 Daniel McNeil
1 sibling, 1 reply; 90+ messages in thread
From: Daniel McNeil @ 2004-03-18 1:15 UTC (permalink / raw)
To: Andrew Morton; +Cc: Chris Mason, Linux Kernel Mailing List, linux-aio
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
On Wed, 2004-03-17 at 16:33, Andrew Morton wrote:
> Chris Mason <mason@suse.com> wrote:
> >
> > 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.
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.4-mm2
2004-03-15 1:28 2.6.4-mm2 Andrew Morton
` (7 preceding siblings ...)
2004-03-16 18:32 ` 2.6.4-mm2 Daniel McNeil
@ 2004-03-18 17:37 ` markw
2004-03-18 18:06 ` 2.6.4-mm2 Andrew Morton
8 siblings, 1 reply; 90+ messages in thread
From: markw @ 2004-03-18 17:37 UTC (permalink / raw)
To: akpm; +Cc: linux-kernel
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
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.4-mm2
2004-03-18 1:15 ` 2.6.4-mm2 Daniel McNeil
@ 2004-03-18 17:53 ` Daniel McNeil
2004-03-18 18:47 ` 2.6.4-mm2 Chris Mason
0 siblings, 1 reply; 90+ messages in thread
From: Daniel McNeil @ 2004-03-18 17:53 UTC (permalink / raw)
To: Andrew Morton; +Cc: Chris Mason, Linux Kernel Mailing List, linux-aio
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
On Wed, 2004-03-17 at 17:15, Daniel McNeil wrote:
> 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
> On Wed, 2004-03-17 at 16:33, Andrew Morton wrote:
> > Chris Mason <mason@suse.com> wrote:
> > >
> > > 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 majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.4-mm2
2004-03-18 17:37 ` 2.6.4-mm2 markw
@ 2004-03-18 18:06 ` Andrew Morton
2004-03-18 18:48 ` 2.6.4-mm2 markw
2004-03-18 19:27 ` 2.6.4-mm2 Jens Axboe
0 siblings, 2 replies; 90+ messages in thread
From: Andrew Morton @ 2004-03-18 18:06 UTC (permalink / raw)
To: markw; +Cc: linux-kernel
markw@osdl.org 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?
> 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.
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.
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.4-mm2
2004-03-18 17:53 ` 2.6.4-mm2 Daniel McNeil
@ 2004-03-18 18:47 ` Chris Mason
2004-03-18 19:10 ` 2.6.4-mm2 Daniel McNeil
0 siblings, 1 reply; 90+ messages in thread
From: Chris Mason @ 2004-03-18 18:47 UTC (permalink / raw)
To: Daniel McNeil; +Cc: Andrew Morton, Linux Kernel Mailing List, linux-aio
On Thu, 2004-03-18 at 12:53, Daniel McNeil wrote:
> 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
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.4-mm2
2004-03-18 18:06 ` 2.6.4-mm2 Andrew Morton
@ 2004-03-18 18:48 ` markw
2004-03-18 19:10 ` 2.6.4-mm2 Chris Mason
2004-03-18 19:27 ` 2.6.4-mm2 Jens Axboe
1 sibling, 1 reply; 90+ messages in thread
From: markw @ 2004-03-18 18:48 UTC (permalink / raw)
To: akpm; +Cc: linux-kernel
On 18 Mar, Andrew Morton wrote:
> markw@osdl.org 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.
>> 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.
>
> 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.
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.4-mm2
2004-03-18 18:47 ` 2.6.4-mm2 Chris Mason
@ 2004-03-18 19:10 ` Daniel McNeil
2004-03-19 16:49 ` 2.6.5-rc2-mm2 and direct_read_under Daniel McNeil
0 siblings, 1 reply; 90+ messages in thread
From: Daniel McNeil @ 2004-03-18 19:10 UTC (permalink / raw)
To: Chris Mason; +Cc: Andrew Morton, Linux Kernel Mailing List, linux-aio
On Thu, 2004-03-18 at 10:47, Chris Mason wrote:
> On Thu, 2004-03-18 at 12:53, Daniel McNeil wrote:
> > 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
>
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
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.4-mm2
2004-03-18 18:48 ` 2.6.4-mm2 markw
@ 2004-03-18 19:10 ` Chris Mason
0 siblings, 0 replies; 90+ messages in thread
From: Chris Mason @ 2004-03-18 19:10 UTC (permalink / raw)
To: markw; +Cc: akpm, linux-kernel
On Thu, 2004-03-18 at 13:48, markw@osdl.org wrote:
> On 18 Mar, Andrew Morton wrote:
> > markw@osdl.org 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.
>
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
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.4-mm2
2004-03-18 18:06 ` 2.6.4-mm2 Andrew Morton
2004-03-18 18:48 ` 2.6.4-mm2 markw
@ 2004-03-18 19:27 ` Jens Axboe
2004-03-18 23:38 ` 2.6.4-mm2 markw
2004-03-19 3:15 ` 2.6.4-mm2 Andrew Morton
1 sibling, 2 replies; 90+ messages in thread
From: Jens Axboe @ 2004-03-18 19:27 UTC (permalink / raw)
To: Andrew Morton; +Cc: markw, linux-kernel
On Thu, Mar 18 2004, Andrew Morton wrote:
> > 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.
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.
--- drivers/block/ll_rw_blk.c~ 2004-03-18 20:26:17.088531084 +0100
+++ drivers/block/ll_rw_blk.c 2004-03-18 20:26:44.773554953 +0100
@@ -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
--
Jens Axboe
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.4-mm2
2004-03-18 19:27 ` 2.6.4-mm2 Jens Axboe
@ 2004-03-18 23:38 ` markw
2004-03-19 7:39 ` 2.6.4-mm2 Jens Axboe
2004-03-19 3:15 ` 2.6.4-mm2 Andrew Morton
1 sibling, 1 reply; 90+ messages in thread
From: markw @ 2004-03-18 23:38 UTC (permalink / raw)
To: axboe; +Cc: akpm, linux-kernel
On 18 Mar, Jens Axboe wrote:
> On Thu, Mar 18 2004, Andrew Morton wrote:
>> > 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.
>
> 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.
>
> --- drivers/block/ll_rw_blk.c~ 2004-03-18 20:26:17.088531084 +0100
> +++ drivers/block/ll_rw_blk.c 2004-03-18 20:26:44.773554953 +0100
> @@ -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
>
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?
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.4-mm2
2004-03-18 19:27 ` 2.6.4-mm2 Jens Axboe
2004-03-18 23:38 ` 2.6.4-mm2 markw
@ 2004-03-19 3:15 ` Andrew Morton
2004-03-19 7:39 ` 2.6.4-mm2 Jens Axboe
[not found] ` <20040318194150.4de65049.akpm@osdl.org>
1 sibling, 2 replies; 90+ messages in thread
From: Andrew Morton @ 2004-03-19 3:15 UTC (permalink / raw)
To: Jens Axboe; +Cc: markw, linux-kernel
Jens Axboe <axboe@suse.de> wrote:
>
> On Thu, Mar 18 2004, Andrew Morton wrote:
> > > 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.
>
> 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:
--- 25/drivers/md/dm-table.c~a 2004-03-18 19:03:15.130004696 -0800
+++ 25-akpm/drivers/md/dm-table.c 2004-03-18 19:03:41.656971984 -0800
@@ -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.
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.4-mm2
2004-03-19 3:15 ` 2.6.4-mm2 Andrew Morton
@ 2004-03-19 7:39 ` Jens Axboe
2004-03-19 7:52 ` 2.6.4-mm2 Andrew Morton
[not found] ` <20040318194150.4de65049.akpm@osdl.org>
1 sibling, 1 reply; 90+ messages in thread
From: Jens Axboe @ 2004-03-19 7:39 UTC (permalink / raw)
To: Andrew Morton; +Cc: markw, linux-kernel
On Thu, Mar 18 2004, Andrew Morton wrote:
> Jens Axboe <axboe@suse.de> wrote:
> >
> > On Thu, Mar 18 2004, Andrew Morton wrote:
> > > > 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.
> >
> > 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:
>
> --- 25/drivers/md/dm-table.c~a 2004-03-18 19:03:15.130004696 -0800
> +++ 25-akpm/drivers/md/dm-table.c 2004-03-18 19:03:41.656971984 -0800
> @@ -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.
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.
--
Jens Axboe
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.4-mm2
2004-03-18 23:38 ` 2.6.4-mm2 markw
@ 2004-03-19 7:39 ` Jens Axboe
0 siblings, 0 replies; 90+ messages in thread
From: Jens Axboe @ 2004-03-19 7:39 UTC (permalink / raw)
To: markw; +Cc: akpm, linux-kernel
On Thu, Mar 18 2004, markw@osdl.org wrote:
> On 18 Mar, Jens Axboe wrote:
> > On Thu, Mar 18 2004, Andrew Morton wrote:
> >> > 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.
> >
> > 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.
> >
> > --- drivers/block/ll_rw_blk.c~ 2004-03-18 20:26:17.088531084 +0100
> > +++ drivers/block/ll_rw_blk.c 2004-03-18 20:26:44.773554953 +0100
> > @@ -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
> >
>
> 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?
Wait for a real patch first, I'll have one for you in an hour or two.
--
Jens Axboe
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.4-mm2
2004-03-19 7:39 ` 2.6.4-mm2 Jens Axboe
@ 2004-03-19 7:52 ` Andrew Morton
2004-03-19 7:57 ` 2.6.4-mm2 Jens Axboe
2004-03-19 9:56 ` 2.6.4-mm2 Miquel van Smoorenburg
0 siblings, 2 replies; 90+ messages in thread
From: Andrew Morton @ 2004-03-19 7:52 UTC (permalink / raw)
To: Jens Axboe; +Cc: markw, linux-kernel
Jens Axboe <axboe@suse.de> wrote:
>
> > --- 25/drivers/md/dm-table.c~a 2004-03-18 19:03:15.130004696 -0800
> > +++ 25-akpm/drivers/md/dm-table.c 2004-03-18 19:03:41.656971984 -0800
> > @@ -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.
>
> 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.
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?
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.4-mm2
2004-03-19 7:52 ` 2.6.4-mm2 Andrew Morton
@ 2004-03-19 7:57 ` Jens Axboe
2004-03-19 8:19 ` 2.6.4-mm2 Andrew Morton
2004-03-19 9:56 ` 2.6.4-mm2 Miquel van Smoorenburg
1 sibling, 1 reply; 90+ messages in thread
From: Jens Axboe @ 2004-03-19 7:57 UTC (permalink / raw)
To: Andrew Morton; +Cc: markw, linux-kernel
On Thu, Mar 18 2004, Andrew Morton wrote:
> Jens Axboe <axboe@suse.de> wrote:
> >
> > > --- 25/drivers/md/dm-table.c~a 2004-03-18 19:03:15.130004696 -0800
> > > +++ 25-akpm/drivers/md/dm-table.c 2004-03-18 19:03:41.656971984 -0800
> > > @@ -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.
> >
> > 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.
>
> 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.
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.
--
Jens Axboe
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.4-mm2
2004-03-19 7:57 ` 2.6.4-mm2 Jens Axboe
@ 2004-03-19 8:19 ` Andrew Morton
2004-03-19 8:31 ` 2.6.4-mm2 Jens Axboe
0 siblings, 1 reply; 90+ messages in thread
From: Andrew Morton @ 2004-03-19 8:19 UTC (permalink / raw)
To: Jens Axboe; +Cc: markw, linux-kernel
Jens Axboe <axboe@suse.de> wrote:
>
> > 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.
>
> 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.
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.4-mm2
2004-03-19 8:19 ` 2.6.4-mm2 Andrew Morton
@ 2004-03-19 8:31 ` Jens Axboe
2004-03-19 8:39 ` 2.6.4-mm2 Andrew Morton
0 siblings, 1 reply; 90+ messages in thread
From: Jens Axboe @ 2004-03-19 8:31 UTC (permalink / raw)
To: Andrew Morton; +Cc: markw, linux-kernel
On Fri, Mar 19 2004, Andrew Morton wrote:
> Jens Axboe <axboe@suse.de> wrote:
> >
> > > 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.
> >
> > 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...
> 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.
I guess that'd work ok, as far as I can see..
> 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.
--
Jens Axboe
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.4-mm2
2004-03-19 8:31 ` 2.6.4-mm2 Jens Axboe
@ 2004-03-19 8:39 ` Andrew Morton
2004-03-19 8:48 ` 2.6.4-mm2 Jens Axboe
0 siblings, 1 reply; 90+ messages in thread
From: Andrew Morton @ 2004-03-19 8:39 UTC (permalink / raw)
To: Jens Axboe; +Cc: markw, linux-kernel
Jens Axboe <axboe@suse.de> wrote:
>
> On Fri, Mar 19 2004, Andrew Morton wrote:
> > Jens Axboe <axboe@suse.de> wrote:
> > >
> > > > 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.
> > >
> > > 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.
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.
> > 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...
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.4-mm2
2004-03-19 8:39 ` 2.6.4-mm2 Andrew Morton
@ 2004-03-19 8:48 ` Jens Axboe
0 siblings, 0 replies; 90+ messages in thread
From: Jens Axboe @ 2004-03-19 8:48 UTC (permalink / raw)
To: Andrew Morton; +Cc: markw, linux-kernel
On Fri, Mar 19 2004, Andrew Morton wrote:
> Jens Axboe <axboe@suse.de> wrote:
> >
> > On Fri, Mar 19 2004, Andrew Morton wrote:
> > > Jens Axboe <axboe@suse.de> wrote:
> > > >
> > > > > 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.
> > > >
> > > > 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.
>
> 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.
--
Jens Axboe
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.4-mm2
2004-03-19 7:52 ` 2.6.4-mm2 Andrew Morton
2004-03-19 7:57 ` 2.6.4-mm2 Jens Axboe
@ 2004-03-19 9:56 ` Miquel van Smoorenburg
2004-03-19 10:00 ` 2.6.4-mm2 Jens Axboe
1 sibling, 1 reply; 90+ messages in thread
From: Miquel van Smoorenburg @ 2004-03-19 9:56 UTC (permalink / raw)
To: akpm; +Cc: Jens Axboe, linux-kernel
In article <20040318235200.25c376a9.akpm@osdl.org> you write:
>Jens Axboe <axboe@suse.de> wrote:
>> 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.
>
>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.
--
Netu, v qba'g yvxr gur cynvagrkg :)
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.4-mm2
2004-03-19 9:56 ` 2.6.4-mm2 Miquel van Smoorenburg
@ 2004-03-19 10:00 ` Jens Axboe
0 siblings, 0 replies; 90+ messages in thread
From: Jens Axboe @ 2004-03-19 10:00 UTC (permalink / raw)
To: Miquel van Smoorenburg; +Cc: akpm, linux-kernel
On Fri, Mar 19 2004, Miquel van Smoorenburg wrote:
> In article <20040318235200.25c376a9.akpm@osdl.org> you write:
> >Jens Axboe <axboe@suse.de> wrote:
> >> 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.
> >
> >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.
--
Jens Axboe
^ permalink raw reply [flat|nested] 90+ messages in thread
* 2.6.5-rc2-mm2 and direct_read_under
2004-03-18 19:10 ` 2.6.4-mm2 Daniel McNeil
@ 2004-03-19 16:49 ` Daniel McNeil
2004-03-19 17:05 ` 2.6.5-rc1-mm2 " Daniel McNeil
0 siblings, 1 reply; 90+ messages in thread
From: Daniel McNeil @ 2004-03-19 16:49 UTC (permalink / raw)
To: Chris Mason; +Cc: Andrew Morton, Linux Kernel Mailing List, linux-aio
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
On Thu, 2004-03-18 at 11:10, Daniel McNeil wrote:
> On Thu, 2004-03-18 at 10:47, Chris Mason wrote:
> > On Thu, 2004-03-18 at 12:53, Daniel McNeil wrote:
> > > 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
> >
>
> 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 majordomo@kvack.org. For more info on Linux AIO,
> see: http://www.kvack.org/aio/
> Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.5-rc1-mm2 and direct_read_under
2004-03-19 16:49 ` 2.6.5-rc2-mm2 and direct_read_under Daniel McNeil
@ 2004-03-19 17:05 ` Daniel McNeil
2004-03-21 14:36 ` Chris Mason
0 siblings, 1 reply; 90+ messages in thread
From: Daniel McNeil @ 2004-03-19 17:05 UTC (permalink / raw)
To: Chris Mason; +Cc: Andrew Morton, Linux Kernel Mailing List, linux-aio
Can't type this morning -- 2.6.5-rc1-mm2 is what I ran on.
=============
Daniel
On Fri, 2004-03-19 at 08:49, Daniel McNeil wrote:
> 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
>
> On Thu, 2004-03-18 at 11:10, Daniel McNeil wrote:
> > On Thu, 2004-03-18 at 10:47, Chris Mason wrote:
> > > On Thu, 2004-03-18 at 12:53, Daniel McNeil wrote:
> > > > 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
> > >
> >
> > 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 majordomo@kvack.org. For more info on Linux AIO,
> > see: http://www.kvack.org/aio/
> > Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-aio' in
> the body to majordomo@kvack.org. For more info on Linux AIO,
> see: http://www.kvack.org/aio/
> Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.4-mm2
[not found] ` <20040318194150.4de65049.akpm@osdl.org>
@ 2004-03-20 2:39 ` Mark Wong
2004-03-20 2:47 ` 2.6.4-mm2 Mark Wong
` (2 more replies)
0 siblings, 3 replies; 90+ messages in thread
From: Mark Wong @ 2004-03-20 2:39 UTC (permalink / raw)
To: Andrew Morton; +Cc: axboe, linux-kernel
On Thu, Mar 18, 2004 at 07:41:50PM -0800, Andrew Morton wrote:
> Andrew Morton <akpm@osdl.org> wrote:
> >
> > 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
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.4-mm2
2004-03-20 2:39 ` 2.6.4-mm2 Mark Wong
@ 2004-03-20 2:47 ` Mark Wong
2004-03-20 2:50 ` 2.6.4-mm2 Andrew Morton
2004-03-22 17:19 ` 2.6.4-mm2 Mary Edie Meredith
2 siblings, 0 replies; 90+ messages in thread
From: Mark Wong @ 2004-03-20 2:47 UTC (permalink / raw)
To: Andrew Morton, axboe, linux-kernel
On Fri, Mar 19, 2004 at 06:39:06PM -0800, Mark Wong wrote:
> On Thu, Mar 18, 2004 at 07:41:50PM -0800, Andrew Morton wrote:
> > Andrew Morton <akpm@osdl.org> wrote:
> > >
> > > 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
Meant to recopy the link too:
http://developer.osdl.org/markw/linux/2.6-pagecache.html
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.4-mm2
2004-03-20 2:39 ` 2.6.4-mm2 Mark Wong
2004-03-20 2:47 ` 2.6.4-mm2 Mark Wong
@ 2004-03-20 2:50 ` Andrew Morton
2004-03-20 2:53 ` 2.6.4-mm2 Mark Wong
2004-03-22 17:19 ` 2.6.4-mm2 Mary Edie Meredith
2 siblings, 1 reply; 90+ messages in thread
From: Andrew Morton @ 2004-03-20 2:50 UTC (permalink / raw)
To: Mark Wong; +Cc: axboe, linux-kernel
Mark Wong <markw@osdl.org> wrote:
>
> On Thu, Mar 18, 2004 at 07:41:50PM -0800, Andrew Morton wrote:
> > Andrew Morton <akpm@osdl.org> wrote:
> > >
> > > 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
Thanks, so it's the CPU scheduler changes. Is that machine hyperthreaded?
And do you have CONFIG_X86_HT enabled?
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.4-mm2
2004-03-20 2:50 ` 2.6.4-mm2 Andrew Morton
@ 2004-03-20 2:53 ` Mark Wong
2004-03-20 3:52 ` 2.6.4-mm2 Nick Piggin
0 siblings, 1 reply; 90+ messages in thread
From: Mark Wong @ 2004-03-20 2:53 UTC (permalink / raw)
To: Andrew Morton; +Cc: axboe, linux-kernel
On Fri, Mar 19, 2004 at 06:50:26PM -0800, Andrew Morton wrote:
> Mark Wong <markw@osdl.org> wrote:
> >
> > On Thu, Mar 18, 2004 at 07:41:50PM -0800, Andrew Morton wrote:
> > > Andrew Morton <akpm@osdl.org> wrote:
> > > >
> > > > 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
>
> 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.)
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.4-mm2
2004-03-20 2:53 ` 2.6.4-mm2 Mark Wong
@ 2004-03-20 3:52 ` Nick Piggin
2004-03-20 4:14 ` 2.6.4-mm2 Andrew Morton
0 siblings, 1 reply; 90+ messages in thread
From: Nick Piggin @ 2004-03-20 3:52 UTC (permalink / raw)
To: Mark Wong; +Cc: Andrew Morton, axboe, linux-kernel
Mark Wong wrote:
>On Fri, Mar 19, 2004 at 06:50:26PM -0800, Andrew Morton wrote:
>
>>Mark Wong <markw@osdl.org> wrote:
>>
>>>On Thu, Mar 18, 2004 at 07:41:50PM -0800, Andrew Morton wrote:
>>>
>>>>Andrew Morton <akpm@osdl.org> wrote:
>>>>
>>>>>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
>>>
>>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.
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.4-mm2
2004-03-20 3:52 ` 2.6.4-mm2 Nick Piggin
@ 2004-03-20 4:14 ` Andrew Morton
2004-03-20 4:24 ` 2.6.4-mm2 Nick Piggin
0 siblings, 1 reply; 90+ messages in thread
From: Andrew Morton @ 2004-03-20 4:14 UTC (permalink / raw)
To: Nick Piggin; +Cc: markw, axboe, linux-kernel
Nick Piggin <piggin@cyberone.com.au> wrote:
>
> >>>
> >>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?
Does the sched-domains patch break `acpi=off' or `noht'?
> 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.
> 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?
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.4-mm2
2004-03-20 4:14 ` 2.6.4-mm2 Andrew Morton
@ 2004-03-20 4:24 ` Nick Piggin
2004-03-20 4:26 ` 2.6.4-mm2 Nick Piggin
2004-03-20 21:17 ` 2.6.4-mm2 Martin J. Bligh
0 siblings, 2 replies; 90+ messages in thread
From: Nick Piggin @ 2004-03-20 4:24 UTC (permalink / raw)
To: Andrew Morton; +Cc: markw, axboe, linux-kernel
Andrew Morton wrote:
>Nick Piggin <piggin@cyberone.com.au> wrote:
>
>> >>>
>> >>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?
>>
>
>Does the sched-domains patch break `acpi=off' or `noht'?
>
>
Shouldnt.
>> 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.
>> 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?
>
>
I can't remember how much CPU reaim uses, I thought it was
quite a lot (ie. not IO bound).
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.4-mm2
2004-03-20 4:24 ` 2.6.4-mm2 Nick Piggin
@ 2004-03-20 4:26 ` Nick Piggin
2004-03-20 21:17 ` 2.6.4-mm2 Martin J. Bligh
1 sibling, 0 replies; 90+ messages in thread
From: Nick Piggin @ 2004-03-20 4:26 UTC (permalink / raw)
To: Nick Piggin; +Cc: Andrew Morton, markw, axboe, linux-kernel
Nick Piggin wrote:
>
>
> Andrew Morton wrote:
>
>> Nick Piggin <piggin@cyberone.com.au> wrote:
>>
>>>
>>> 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.
>
sched-sibling-map-to-cpumask.patch may. Sorry I don't have time to
check it right now. Got to go.
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.4-mm2
2004-03-20 4:24 ` 2.6.4-mm2 Nick Piggin
2004-03-20 4:26 ` 2.6.4-mm2 Nick Piggin
@ 2004-03-20 21:17 ` Martin J. Bligh
1 sibling, 0 replies; 90+ messages in thread
From: Martin J. Bligh @ 2004-03-20 21:17 UTC (permalink / raw)
To: Nick Piggin, Andrew Morton; +Cc: markw, axboe, linux-kernel
>> 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.
M.
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.4-mm2
2004-03-15 18:54 ` 2.6.4-mm2 Sam Ravnborg
@ 2004-03-20 22:50 ` Olaf Hering
0 siblings, 0 replies; 90+ messages in thread
From: Olaf Hering @ 2004-03-20 22:50 UTC (permalink / raw)
To: Sam Ravnborg, linux-kernel
On Mon, Mar 15, Sam Ravnborg wrote:
> >
> > +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
> --- a/scripts/Makefile Mon Mar 15 19:51:20 2004
> +++ b/scripts/Makefile Mon Mar 15 19:51:20 2004
> @@ -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
>
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?
--
USB is for mice, FireWire is for men!
sUse lINUX ag, nÜRNBERG
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.5-rc1-mm2 and direct_read_under
2004-03-19 17:05 ` 2.6.5-rc1-mm2 " Daniel McNeil
@ 2004-03-21 14:36 ` Chris Mason
2004-03-22 18:10 ` 2.6.5-rc1-mm2 and direct_read_under and wb Daniel McNeil
0 siblings, 1 reply; 90+ messages in thread
From: Chris Mason @ 2004-03-21 14:36 UTC (permalink / raw)
To: Daniel McNeil; +Cc: Andrew Morton, Linux Kernel Mailing List, linux-aio
On Fri, 2004-03-19 at 12:05, Daniel McNeil wrote:
> Can't type this morning -- 2.6.5-rc1-mm2 is what I ran on.
> =============
>
> Daniel
> On Fri, 2004-03-19 at 08:49, Daniel McNeil wrote:
> > 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 ]
> > >
> > > 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
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.4-mm2
2004-03-20 2:39 ` 2.6.4-mm2 Mark Wong
2004-03-20 2:47 ` 2.6.4-mm2 Mark Wong
2004-03-20 2:50 ` 2.6.4-mm2 Andrew Morton
@ 2004-03-22 17:19 ` Mary Edie Meredith
2004-03-23 0:27 ` 2.6.4-mm2 Andrew Morton
2 siblings, 1 reply; 90+ messages in thread
From: Mary Edie Meredith @ 2004-03-22 17:19 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, linux-mm
[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)
On Fri, 2004-03-19 at 18:39, Mark Wong wrote:
> On Thu, Mar 18, 2004 at 07:41:50PM -0800, Andrew Morton wrote:
> > Andrew Morton <akpm@osdl.org> wrote:
> > >
> > > 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 majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Mary Edie Meredith
maryedie@osdl.org
503-626-2455 x42
Open Source Development Labs
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.5-rc1-mm2 and direct_read_under and wb
2004-03-21 14:36 ` Chris Mason
@ 2004-03-22 18:10 ` Daniel McNeil
2004-03-22 18:23 ` Chris Mason
2004-03-22 18:35 ` Chris Mason
0 siblings, 2 replies; 90+ messages in thread
From: Daniel McNeil @ 2004-03-22 18:10 UTC (permalink / raw)
To: Chris Mason, Andrew Morton; +Cc: Linux Kernel Mailing List, linux-aio
[-- Attachment #1: Type: text/plain, Size: 1701 bytes --]
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
On Sun, 2004-03-21 at 06:36, Chris Mason wrote:
> On Fri, 2004-03-19 at 12:05, Daniel McNeil wrote:
> > Can't type this morning -- 2.6.5-rc1-mm2 is what I ran on.
> > =============
> >
> > Daniel
> > On Fri, 2004-03-19 at 08:49, Daniel McNeil wrote:
> > > 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 ]
>
> > > >
> > > > 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
>
[-- Attachment #2: 265-rc1-mm2.wb_rwsema.patch --]
[-- Type: text/x-patch, Size: 4706 bytes --]
diff -rup linux-2.6.5-rc1-mm2.orig/fs/buffer.c linux-2.6.5-rc1-mm2/fs/buffer.c
--- linux-2.6.5-rc1-mm2.orig/fs/buffer.c 2004-03-22 09:51:08.780141187 -0800
+++ linux-2.6.5-rc1-mm2/fs/buffer.c 2004-03-19 16:24:57.000000000 -0800
@@ -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;
}
}
diff -rup linux-2.6.5-rc1-mm2.orig/fs/fs-writeback.c linux-2.6.5-rc1-mm2/fs/fs-writeback.c
--- linux-2.6.5-rc1-mm2.orig/fs/fs-writeback.c 2004-03-22 09:51:36.444272668 -0800
+++ linux-2.6.5-rc1-mm2/fs/fs-writeback.c 2004-03-19 16:49:57.000000000 -0800
@@ -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 */
diff -rup linux-2.6.5-rc1-mm2.orig/fs/inode.c linux-2.6.5-rc1-mm2/fs/inode.c
--- linux-2.6.5-rc1-mm2.orig/fs/inode.c 2004-03-22 09:51:21.299937974 -0800
+++ linux-2.6.5-rc1-mm2/fs/inode.c 2004-03-19 16:25:42.000000000 -0800
@@ -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);
diff -rup linux-2.6.5-rc1-mm2.orig/include/linux/fs.h linux-2.6.5-rc1-mm2/include/linux/fs.h
--- linux-2.6.5-rc1-mm2.orig/include/linux/fs.h 2004-03-22 09:52:00.125104495 -0800
+++ linux-2.6.5-rc1-mm2/include/linux/fs.h 2004-03-19 16:26:30.000000000 -0800
@@ -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 {
diff -rup linux-2.6.5-rc1-mm2.orig/mm/filemap.c linux-2.6.5-rc1-mm2/mm/filemap.c
--- linux-2.6.5-rc1-mm2.orig/mm/filemap.c 2004-03-22 09:50:34.895103358 -0800
+++ linux-2.6.5-rc1-mm2/mm/filemap.c 2004-03-19 16:46:28.000000000 -0800
@@ -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;
}
diff -rup linux-2.6.5-rc1-mm2.orig/mm/swap_state.c linux-2.6.5-rc1-mm2/mm/swap_state.c
--- linux-2.6.5-rc1-mm2.orig/mm/swap_state.c 2004-03-22 09:50:49.363557747 -0800
+++ linux-2.6.5-rc1-mm2/mm/swap_state.c 2004-03-19 16:28:06.000000000 -0800
@@ -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)
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.5-rc1-mm2 and direct_read_under and wb
2004-03-22 18:10 ` 2.6.5-rc1-mm2 and direct_read_under and wb Daniel McNeil
@ 2004-03-22 18:23 ` Chris Mason
2004-03-22 18:27 ` Chris Mason
2004-03-22 18:35 ` Chris Mason
1 sibling, 1 reply; 90+ messages in thread
From: Chris Mason @ 2004-03-22 18:23 UTC (permalink / raw)
To: Daniel McNeil; +Cc: Andrew Morton, Linux Kernel Mailing List, linux-aio
On Mon, 2004-03-22 at 13:10, Daniel McNeil wrote:
> 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
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.5-rc1-mm2 and direct_read_under and wb
2004-03-22 18:23 ` Chris Mason
@ 2004-03-22 18:27 ` Chris Mason
0 siblings, 0 replies; 90+ messages in thread
From: Chris Mason @ 2004-03-22 18:27 UTC (permalink / raw)
To: Daniel McNeil; +Cc: Andrew Morton, Linux Kernel Mailing List, linux-aio
On Mon, 2004-03-22 at 13:23, Chris Mason wrote:
> On Mon, 2004-03-22 at 13:10, Daniel McNeil wrote:
> > 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.
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
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.5-rc1-mm2 and direct_read_under and wb
2004-03-22 18:10 ` 2.6.5-rc1-mm2 and direct_read_under and wb Daniel McNeil
2004-03-22 18:23 ` Chris Mason
@ 2004-03-22 18:35 ` Chris Mason
2004-03-22 18:51 ` Daniel McNeil
1 sibling, 1 reply; 90+ messages in thread
From: Chris Mason @ 2004-03-22 18:35 UTC (permalink / raw)
To: Daniel McNeil; +Cc: Andrew Morton, Linux Kernel Mailing List, linux-aio
On Mon, 2004-03-22 at 13:10, Daniel McNeil wrote:
> 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
--- linux-2.6.5-rc1-mm2.orig/fs/buffer.c 2004-03-22 09:51:08.780141187 -0800
+++ linux-2.6.5-rc1-mm2/fs/buffer.c 2004-03-19 16:24:57.000000000 -0800
@@ -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
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.5-rc1-mm2 and direct_read_under and wb
2004-03-22 18:35 ` Chris Mason
@ 2004-03-22 18:51 ` Daniel McNeil
2004-03-22 23:13 ` Andrew Morton
0 siblings, 1 reply; 90+ messages in thread
From: Daniel McNeil @ 2004-03-22 18:51 UTC (permalink / raw)
To: Chris Mason; +Cc: Andrew Morton, Linux Kernel Mailing List, linux-aio
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
On Mon, 2004-03-22 at 10:35, Chris Mason wrote:
> On Mon, 2004-03-22 at 13:10, Daniel McNeil wrote:
> > 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
> --- linux-2.6.5-rc1-mm2.orig/fs/buffer.c 2004-03-22 09:51:08.780141187 -0800
> +++ linux-2.6.5-rc1-mm2/fs/buffer.c 2004-03-19 16:24:57.000000000 -0800
> @@ -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
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.5-rc1-mm2 and direct_read_under and wb
2004-03-22 18:51 ` Daniel McNeil
@ 2004-03-22 23:13 ` Andrew Morton
2004-03-23 0:51 ` Daniel McNeil
0 siblings, 1 reply; 90+ messages in thread
From: Andrew Morton @ 2004-03-22 23:13 UTC (permalink / raw)
To: Daniel McNeil; +Cc: mason, linux-kernel, linux-aio
Daniel McNeil <daniel@osdl.org> wrote:
>
> 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.
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.4-mm2
2004-03-22 17:19 ` 2.6.4-mm2 Mary Edie Meredith
@ 2004-03-23 0:27 ` Andrew Morton
2004-03-23 19:21 ` 2.6.4-mm2 Mary Edie Meredith
0 siblings, 1 reply; 90+ messages in thread
From: Andrew Morton @ 2004-03-23 0:27 UTC (permalink / raw)
To: maryedie; +Cc: linux-kernel, linux-mm
Mary Edie Meredith <maryedie@osdl.org> wrote:
>
> [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%)
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.
>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.
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.5-rc1-mm2 and direct_read_under and wb
2004-03-22 23:13 ` Andrew Morton
@ 2004-03-23 0:51 ` Daniel McNeil
2004-03-23 9:25 ` Andrew Morton
0 siblings, 1 reply; 90+ messages in thread
From: Daniel McNeil @ 2004-03-23 0:51 UTC (permalink / raw)
To: Andrew Morton; +Cc: mason, Linux Kernel Mailing List, linux-aio
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
On Mon, 2004-03-22 at 15:13, Andrew Morton wrote:
> Daniel McNeil <daniel@osdl.org> wrote:
> >
> > 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 majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.5-rc1-mm2 and direct_read_under and wb
2004-03-23 0:51 ` Daniel McNeil
@ 2004-03-23 9:25 ` Andrew Morton
2004-03-23 17:05 ` Daniel McNeil
0 siblings, 1 reply; 90+ messages in thread
From: Andrew Morton @ 2004-03-23 9:25 UTC (permalink / raw)
To: Daniel McNeil; +Cc: mason, linux-kernel, linux-aio
Daniel McNeil <daniel@osdl.org> wrote:
>
> 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
--- 25/fs/buffer.c~block_write_full_page-redirty 2004-03-23 01:06:59.281253176 -0800
+++ 25-akpm/fs/buffer.c 2004-03-23 01:09:11.313181272 -0800
@@ -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))
_
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.5-rc1-mm2 and direct_read_under and wb
2004-03-23 9:25 ` Andrew Morton
@ 2004-03-23 17:05 ` Daniel McNeil
2004-03-23 17:59 ` Andrew Morton
0 siblings, 1 reply; 90+ messages in thread
From: Daniel McNeil @ 2004-03-23 17:05 UTC (permalink / raw)
To: Andrew Morton; +Cc: mason, Linux Kernel Mailing List, linux-aio
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
On Tue, 2004-03-23 at 01:25, Andrew Morton wrote:
> Daniel McNeil <daniel@osdl.org> wrote:
> >
> > 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
> --- 25/fs/buffer.c~block_write_full_page-redirty 2004-03-23 01:06:59.281253176 -0800
> +++ 25-akpm/fs/buffer.c 2004-03-23 01:09:11.313181272 -0800
> @@ -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 majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.5-rc1-mm2 and direct_read_under and wb
2004-03-23 17:05 ` Daniel McNeil
@ 2004-03-23 17:59 ` Andrew Morton
2004-03-23 21:38 ` Daniel McNeil
0 siblings, 1 reply; 90+ messages in thread
From: Andrew Morton @ 2004-03-23 17:59 UTC (permalink / raw)
To: Daniel McNeil; +Cc: mason, linux-kernel, linux-aio
Daniel McNeil <daniel@osdl.org> wrote:
>
> Andrew,
>
> Just to confirm my tests ran overnight without errors.
good.
> So the !wbc->nonblocking lowers the cpu utilization.
yup. It prevents balance_dirty_pages() callers from spinning over the same
pages again and again.
> 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.
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.4-mm2
2004-03-23 0:27 ` 2.6.4-mm2 Andrew Morton
@ 2004-03-23 19:21 ` Mary Edie Meredith
2004-03-23 19:32 ` 2.6.4-mm2 Andrew Morton
0 siblings, 1 reply; 90+ messages in thread
From: Mary Edie Meredith @ 2004-03-23 19:21 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, linux-mm
On Mon, 2004-03-22 at 16:27, Andrew Morton wrote:
> Mary Edie Meredith <maryedie@osdl.org> wrote:
> >
> > [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%)
>
> 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.
>
> >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?
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Mary Edie Meredith
maryedie@osdl.org
503-626-2455 x42
Open Source Development Labs
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.4-mm2
2004-03-23 19:21 ` 2.6.4-mm2 Mary Edie Meredith
@ 2004-03-23 19:32 ` Andrew Morton
2004-03-24 0:07 ` 2.6.4-mm2 Mary Edie Meredith
0 siblings, 1 reply; 90+ messages in thread
From: Andrew Morton @ 2004-03-23 19:32 UTC (permalink / raw)
To: maryedie; +Cc: linux-kernel, linux-mm
Mary Edie Meredith <maryedie@osdl.org> wrote:
>
> > 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.
> >
> > >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
There seems to be a large amount of idle time in the profiles and in the
vmstat trace.
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.5-rc1-mm2 and direct_read_under and wb
2004-03-23 17:59 ` Andrew Morton
@ 2004-03-23 21:38 ` Daniel McNeil
2004-03-23 21:47 ` Andrew Morton
0 siblings, 1 reply; 90+ messages in thread
From: Daniel McNeil @ 2004-03-23 21:38 UTC (permalink / raw)
To: Andrew Morton; +Cc: mason, Linux Kernel Mailing List, linux-aio
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
On Tue, 2004-03-23 at 09:59, Andrew Morton wrote:
> Daniel McNeil <daniel@osdl.org> wrote:
> >
> > Andrew,
> >
> > Just to confirm my tests ran overnight without errors.
>
> good.
>
> > So the !wbc->nonblocking lowers the cpu utilization.
>
> yup. It prevents balance_dirty_pages() callers from spinning over the same
> pages again and again.
>
> > 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.
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.5-rc1-mm2 and direct_read_under and wb
2004-03-23 21:38 ` Daniel McNeil
@ 2004-03-23 21:47 ` Andrew Morton
0 siblings, 0 replies; 90+ messages in thread
From: Andrew Morton @ 2004-03-23 21:47 UTC (permalink / raw)
To: Daniel McNeil; +Cc: mason, linux-kernel, linux-aio
Daniel McNeil <daniel@osdl.org> wrote:
>
> 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?
Correct, setting both WB_SYNC_ALL and nonblocking=1 doesn't make sense.
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.4-mm2
2004-03-23 19:32 ` 2.6.4-mm2 Andrew Morton
@ 2004-03-24 0:07 ` Mary Edie Meredith
2004-03-30 21:30 ` 2.6.4-mm2 Mary Edie Meredith
0 siblings, 1 reply; 90+ messages in thread
From: Mary Edie Meredith @ 2004-03-24 0:07 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, linux-mm
On Tue, 2004-03-23 at 11:32, Andrew Morton wrote:
> Mary Edie Meredith <maryedie@osdl.org> wrote:
> >
> > > 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.
> > >
> > > >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
>
> 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.
--
Mary Edie Meredith
maryedie@osdl.org
503-626-2455 x42
Open Source Development Labs
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.4-mm2
2004-03-24 0:07 ` 2.6.4-mm2 Mary Edie Meredith
@ 2004-03-30 21:30 ` Mary Edie Meredith
0 siblings, 0 replies; 90+ messages in thread
From: Mary Edie Meredith @ 2004-03-30 21:30 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, linux-mm
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.
On Tue, 2004-03-23 at 16:07, Mary Edie Meredith wrote:
> On Tue, 2004-03-23 at 11:32, Andrew Morton wrote:
> > Mary Edie Meredith <maryedie@osdl.org> wrote:
> > >
> > > > 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.
> > > >
> > > > >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
> >
> > 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.
--
Mary Edie Meredith
maryedie@osdl.org
503-626-2455 x42
Open Source Development Labs
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.4-mm2
2004-03-20 9:01 ` 2.6.4-mm2 Nick Piggin
@ 2004-03-22 16:24 ` markw
0 siblings, 0 replies; 90+ messages in thread
From: markw @ 2004-03-22 16:24 UTC (permalink / raw)
To: piggin; +Cc: len.brown, akpm, axboe, linux-kernel
On 20 Mar, Nick Piggin wrote:
>
>
> Len Brown wrote:
>
>>On Fri, 2004-03-19 at 23:19, Brown, Len wrote:
>>
>>>CONFIG_X86_HT=y does not enable HT.
>>>CONFIG_X86_HT=n does not disable HT.
>>>It only controls if the cpu_sibling_map[] etc. are initialized.
>>>
>>>acpi=off does not disable HT
>>>
>>
>>oops, that line incorrect.
>>we fixed "acpi=off" to _really_ mean ACPI off -- table parsing
>>and all, so it does disable HT, along w/ all the other stuff
>>that depends on ACPI.
>>
>>
>
> So how come oprofile seems to think there is a sibling?
> Can you verify both cases use physical only CPUs?
The sar output still only lists data for 4 individual CPUs. Is that a
good way to verify it?
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.4-mm2
2004-03-20 23:12 2.6.4-mm2 sam
@ 2004-03-20 23:41 ` Olaf Hering
0 siblings, 0 replies; 90+ messages in thread
From: Olaf Hering @ 2004-03-20 23:41 UTC (permalink / raw)
To: sam; +Cc: linux-kernel
On Sun, Mar 21, sam@ravnborg.org wrote:
> Date: Lør, 20 Mar 2004 23:50:30 +0100 skrev Olaf Hering <olh@suse.de> :
>
> >
> >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?
>
> There is a missing dependency on 'scripts' in the Makefile.
This patch is needed to fix the compile. Odd, make -jN works.
--- linux-2.6.4.um/arch/um/Makefile-i386~ 2004-03-20 21:13:52.000000000 +0100
+++ linux-2.6.4.um/arch/um/Makefile-i386 2004-03-20 21:16:14.000000000 +0100
@@ -30,7 +30,7 @@ filechk_$(SYS_DIR)/thread.h := $(SYS_UTI
$(SYS_DIR)/thread.h: $(SYS_UTIL_DIR)/mk_thread
$(call filechk,$@)
-$(SYS_UTIL_DIR)/mk_sc: scripts/fixdep include/config/MARKER FORCE ;
+$(SYS_UTIL_DIR)/mk_sc: scripts/basic/fixdep include/config/MARKER FORCE ;
$(Q)$(MAKE) $(build)=$(SYS_UTIL_DIR) $@
$(SYS_UTIL_DIR)/mk_thread: $(ARCH_SYMLINKS) $(GEN_HEADERS) sys_prepare FORCE ;
--- ./Makefile~ 2004-03-21 00:12:23.000000000 +0100
+++ ./Makefile 2004-03-21 00:22:28.000000000 +0100
@@ -568,7 +568,7 @@ $(sort $(vmlinux-objs)) arch/$(ARCH)/ker
# Handle descending into subdirectories listed in $(SUBDIRS)
.PHONY: $(SUBDIRS)
-$(SUBDIRS): prepare-all
+$(SUBDIRS): prepare-all scripts
$(Q)$(MAKE) $(build)=$@
# Things we need to do before we recursively start building the kernel
--
USB is for mice, FireWire is for men!
sUse lINUX ag, nÜRNBERG
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.4-mm2
@ 2004-03-20 23:12 sam
2004-03-20 23:41 ` 2.6.4-mm2 Olaf Hering
0 siblings, 1 reply; 90+ messages in thread
From: sam @ 2004-03-20 23:12 UTC (permalink / raw)
To: Olaf Hering; +Cc: Sam Ravnborg, linux-kernel
Date: Lør, 20 Mar 2004 23:50:30 +0100 skrev Olaf Hering <olh@suse.de> :
>
>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?
There is a missing dependency on 'scripts' in the Makefile.
Try add scripts as target on the line that says something like:
$(SUBDIRS): prepare-all scripts
^---- The scripts target you shall add.
$(Q)$(MAKE) $(build)=$@
Cannot test rigth now - not on my Linux machine.
Sam
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.4-mm2
2004-03-20 4:27 ` 2.6.4-mm2 Len Brown
@ 2004-03-20 9:01 ` Nick Piggin
2004-03-22 16:24 ` 2.6.4-mm2 markw
0 siblings, 1 reply; 90+ messages in thread
From: Nick Piggin @ 2004-03-20 9:01 UTC (permalink / raw)
To: Len Brown; +Cc: Mark Wong, Andrew Morton, axboe, linux-kernel
Len Brown wrote:
>On Fri, 2004-03-19 at 23:19, Brown, Len wrote:
>
>>CONFIG_X86_HT=y does not enable HT.
>>CONFIG_X86_HT=n does not disable HT.
>>It only controls if the cpu_sibling_map[] etc. are initialized.
>>
>>acpi=off does not disable HT
>>
>
>oops, that line incorrect.
>we fixed "acpi=off" to _really_ mean ACPI off -- table parsing
>and all, so it does disable HT, along w/ all the other stuff
>that depends on ACPI.
>
>
So how come oprofile seems to think there is a sibling?
Can you verify both cases use physical only CPUs?
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.4-mm2
2004-03-20 4:26 ` 2.6.4-mm2 Andrew Morton
@ 2004-03-20 4:32 ` Mark Wong
0 siblings, 0 replies; 90+ messages in thread
From: Mark Wong @ 2004-03-20 4:32 UTC (permalink / raw)
To: Andrew Morton; +Cc: Len Brown, axboe, linux-kernel
On Fri, Mar 19, 2004 at 08:26:16PM -0800, Andrew Morton wrote:
> Len Brown <len.brown@intel.com> wrote:
> >
> > On Fri, 2004-03-19 at 21:53, Mark Wong wrote:
> >
> > > > 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.)
> >
> > CONFIG_X86_HT=y does not enable HT.
> > CONFIG_X86_HT=n does not disable HT.
> > It only controls if the cpu_sibling_map[] etc. are initialized.
>
> Err, the question I meant to ask Mark was "do you have CONFIG_SCHED_SMT
> enabled?"
CONFIG_SCHED_SMT isn't set. :)
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.4-mm2
[not found] <A6974D8E5F98D511BB910002A50A6647615F5E2B@hdsmsx402.hd.intel.com>
@ 2004-03-20 4:27 ` Len Brown
2004-03-20 9:01 ` 2.6.4-mm2 Nick Piggin
0 siblings, 1 reply; 90+ messages in thread
From: Len Brown @ 2004-03-20 4:27 UTC (permalink / raw)
To: Mark Wong; +Cc: Andrew Morton, axboe, linux-kernel
On Fri, 2004-03-19 at 23:19, Brown, Len wrote:
> On Fri, 2004-03-19 at 21:53, Mark Wong wrote:
>
> > > 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.)
>
> CONFIG_X86_HT=y does not enable HT.
> CONFIG_X86_HT=n does not disable HT.
> It only controls if the cpu_sibling_map[] etc. are initialized.
>
> acpi=off does not disable HT
oops, that line incorrect.
we fixed "acpi=off" to _really_ mean ACPI off -- table parsing
and all, so it does disable HT, along w/ all the other stuff
that depends on ACPI.
> "noht" doesn't exist.
>
> Please see my message yesterday w/ subject "how to disable HT"
>
> cheers,
> -Len
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.4-mm2
2004-03-20 4:19 ` 2.6.4-mm2 Len Brown
@ 2004-03-20 4:26 ` Andrew Morton
2004-03-20 4:32 ` 2.6.4-mm2 Mark Wong
0 siblings, 1 reply; 90+ messages in thread
From: Andrew Morton @ 2004-03-20 4:26 UTC (permalink / raw)
To: Len Brown; +Cc: markw, axboe, linux-kernel
Len Brown <len.brown@intel.com> wrote:
>
> On Fri, 2004-03-19 at 21:53, Mark Wong wrote:
>
> > > 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.)
>
> CONFIG_X86_HT=y does not enable HT.
> CONFIG_X86_HT=n does not disable HT.
> It only controls if the cpu_sibling_map[] etc. are initialized.
Err, the question I meant to ask Mark was "do you have CONFIG_SCHED_SMT
enabled?"
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.4-mm2
[not found] <A6974D8E5F98D511BB910002A50A6647615F5E26@hdsmsx402.hd.intel.com>
@ 2004-03-20 4:19 ` Len Brown
2004-03-20 4:26 ` 2.6.4-mm2 Andrew Morton
0 siblings, 1 reply; 90+ messages in thread
From: Len Brown @ 2004-03-20 4:19 UTC (permalink / raw)
To: Mark Wong; +Cc: Andrew Morton, axboe, linux-kernel
On Fri, 2004-03-19 at 21:53, Mark Wong wrote:
> > 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.)
CONFIG_X86_HT=y does not enable HT.
CONFIG_X86_HT=n does not disable HT.
It only controls if the cpu_sibling_map[] etc. are initialized.
acpi=off does not disable HT
"noht" doesn't exist.
Please see my message yesterday w/ subject "how to disable HT"
cheers,
-Len
^ permalink raw reply [flat|nested] 90+ messages in thread
end of thread, other threads:[~2004-03-30 21:35 UTC | newest]
Thread overview: 90+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-03-15 1:28 2.6.4-mm2 Andrew Morton
2004-03-15 1:57 ` 2.6.4-mm2 Joshua Kwan
2004-03-15 6:08 ` 2.6.4-mm2 Sam Ravnborg
2004-03-15 9:32 ` [patch] 2.6.4-mm2: ALSA au88x0.c doesn't compile with gcc 2.95 Adrian Bunk
2004-03-15 9:36 ` 2.6.4-mm2: ALSA au88{1,2}0: multiply defined symbols Adrian Bunk
2004-03-15 18:54 ` 2.6.4-mm2 Sam Ravnborg
2004-03-20 22:50 ` 2.6.4-mm2 Olaf Hering
2004-03-15 19:18 ` 2.6.4-mm2 (compile stats) John Cherry
2004-03-15 20:57 ` 2.6.4-mm2 Thomas Schlichter
2004-03-15 21:08 ` 2.6.4-mm2 Thomas Schlichter
2004-03-15 21:18 ` 2.6.4-mm2 Andrew Morton
2004-03-15 21:18 ` 2.6.4-mm2 Jens Axboe
2004-03-15 22:40 ` 2.6.4-mm2 Thomas Schlichter
2004-03-15 22:11 ` 2.6.4-mm2 Jesse Barnes
2004-03-16 18:32 ` 2.6.4-mm2 Daniel McNeil
2004-03-16 21:58 ` 2.6.4-mm2 Chris Mason
2004-03-16 23:21 ` 2.6.4-mm2 Andrew Morton
2004-03-16 23:28 ` 2.6.4-mm2 Andrew Morton
2004-03-16 23:39 ` 2.6.4-mm2 Andrew Morton
2004-03-17 0:10 ` 2.6.4-mm2 Daniel McNeil
[not found] ` <1079485055.4181.1115.camel@watt.suse.com>
[not found] ` <1079487710.3100.22.camel@ibm-c.pdx.osdl.net>
[not found] ` <20040316180043.441e8150.akpm@osdl.org>
2004-03-17 20:11 ` 2.6.4-mm2 Chris Mason
2004-03-17 20:33 ` 2.6.4-mm2 Andrew Morton
2004-03-17 22:46 ` 2.6.4-mm2 Chris Mason
2004-03-17 23:09 ` 2.6.4-mm2 Andrew Morton
2004-03-17 23:27 ` 2.6.4-mm2 Chris Mason
2004-03-17 23:51 ` 2.6.4-mm2 Andrew Morton
2004-03-18 0:06 ` 2.6.4-mm2 Chris Mason
2004-03-18 0:13 ` 2.6.4-mm2 Andrew Morton
2004-03-18 0:31 ` 2.6.4-mm2 Chris Mason
2004-03-18 0:33 ` 2.6.4-mm2 Andrew Morton
2004-03-18 0:41 ` 2.6.4-mm2 Chris Mason
2004-03-18 1:15 ` 2.6.4-mm2 Daniel McNeil
2004-03-18 17:53 ` 2.6.4-mm2 Daniel McNeil
2004-03-18 18:47 ` 2.6.4-mm2 Chris Mason
2004-03-18 19:10 ` 2.6.4-mm2 Daniel McNeil
2004-03-19 16:49 ` 2.6.5-rc2-mm2 and direct_read_under Daniel McNeil
2004-03-19 17:05 ` 2.6.5-rc1-mm2 " Daniel McNeil
2004-03-21 14:36 ` Chris Mason
2004-03-22 18:10 ` 2.6.5-rc1-mm2 and direct_read_under and wb Daniel McNeil
2004-03-22 18:23 ` Chris Mason
2004-03-22 18:27 ` Chris Mason
2004-03-22 18:35 ` Chris Mason
2004-03-22 18:51 ` Daniel McNeil
2004-03-22 23:13 ` Andrew Morton
2004-03-23 0:51 ` Daniel McNeil
2004-03-23 9:25 ` Andrew Morton
2004-03-23 17:05 ` Daniel McNeil
2004-03-23 17:59 ` Andrew Morton
2004-03-23 21:38 ` Daniel McNeil
2004-03-23 21:47 ` Andrew Morton
2004-03-18 17:37 ` 2.6.4-mm2 markw
2004-03-18 18:06 ` 2.6.4-mm2 Andrew Morton
2004-03-18 18:48 ` 2.6.4-mm2 markw
2004-03-18 19:10 ` 2.6.4-mm2 Chris Mason
2004-03-18 19:27 ` 2.6.4-mm2 Jens Axboe
2004-03-18 23:38 ` 2.6.4-mm2 markw
2004-03-19 7:39 ` 2.6.4-mm2 Jens Axboe
2004-03-19 3:15 ` 2.6.4-mm2 Andrew Morton
2004-03-19 7:39 ` 2.6.4-mm2 Jens Axboe
2004-03-19 7:52 ` 2.6.4-mm2 Andrew Morton
2004-03-19 7:57 ` 2.6.4-mm2 Jens Axboe
2004-03-19 8:19 ` 2.6.4-mm2 Andrew Morton
2004-03-19 8:31 ` 2.6.4-mm2 Jens Axboe
2004-03-19 8:39 ` 2.6.4-mm2 Andrew Morton
2004-03-19 8:48 ` 2.6.4-mm2 Jens Axboe
2004-03-19 9:56 ` 2.6.4-mm2 Miquel van Smoorenburg
2004-03-19 10:00 ` 2.6.4-mm2 Jens Axboe
[not found] ` <20040318194150.4de65049.akpm@osdl.org>
2004-03-20 2:39 ` 2.6.4-mm2 Mark Wong
2004-03-20 2:47 ` 2.6.4-mm2 Mark Wong
2004-03-20 2:50 ` 2.6.4-mm2 Andrew Morton
2004-03-20 2:53 ` 2.6.4-mm2 Mark Wong
2004-03-20 3:52 ` 2.6.4-mm2 Nick Piggin
2004-03-20 4:14 ` 2.6.4-mm2 Andrew Morton
2004-03-20 4:24 ` 2.6.4-mm2 Nick Piggin
2004-03-20 4:26 ` 2.6.4-mm2 Nick Piggin
2004-03-20 21:17 ` 2.6.4-mm2 Martin J. Bligh
2004-03-22 17:19 ` 2.6.4-mm2 Mary Edie Meredith
2004-03-23 0:27 ` 2.6.4-mm2 Andrew Morton
2004-03-23 19:21 ` 2.6.4-mm2 Mary Edie Meredith
2004-03-23 19:32 ` 2.6.4-mm2 Andrew Morton
2004-03-24 0:07 ` 2.6.4-mm2 Mary Edie Meredith
2004-03-30 21:30 ` 2.6.4-mm2 Mary Edie Meredith
[not found] <A6974D8E5F98D511BB910002A50A6647615F5E26@hdsmsx402.hd.intel.com>
2004-03-20 4:19 ` 2.6.4-mm2 Len Brown
2004-03-20 4:26 ` 2.6.4-mm2 Andrew Morton
2004-03-20 4:32 ` 2.6.4-mm2 Mark Wong
[not found] <A6974D8E5F98D511BB910002A50A6647615F5E2B@hdsmsx402.hd.intel.com>
2004-03-20 4:27 ` 2.6.4-mm2 Len Brown
2004-03-20 9:01 ` 2.6.4-mm2 Nick Piggin
2004-03-22 16:24 ` 2.6.4-mm2 markw
2004-03-20 23:12 2.6.4-mm2 sam
2004-03-20 23:41 ` 2.6.4-mm2 Olaf Hering
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).