2003-06-07 22:01:13

by Andrew Morton

[permalink] [raw]
Subject: 2.5.70-mm6


ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.5/2.5.70/2.5.70-mm6/

. Numerous little fixes and additional work against additional patches.

. Waaay too many "cleanups". These are taking significant amounts of
effort and it is time to start learning to live with dirty code.

. -mm kernels will be running at HZ=100 for a while. This is because
the anticipatory scheduler's behaviour may be altered by the lower
resolution. Some architectures continue to use 100Hz and we need the
testing coverage which x86 provides.




Changes since 2.5.70-mm5:


linus.patch

Latest drop from Linus

-kmalloc_percpu-interface-change.patch
-kmalloc_percpu-interface-change-warning-fix.patch
-DEFINE_PERCPU-in-modules.patch
-irq-check-rate-limit.patch
-irq_desc-others.patch
-force_successful_syscall_return.patch
-proc-stat-btime-fix.patch
-console-blanking-fix.patch
-console-privacy.patch
-fix-tty-driver-mess.patch
-misc3.patch
-cs423x-fixes.patch
-remove-get_current_user.patch
-de_thread-BUG-fix.patch
-sched_best_cpu-fix-01.patch
-sched_best_cpu-fix-02.patch
-sched_best_cpu-fix-03.patch
-hweight64-warning-fix.patch
-dac960-negotiation-fix.patch
-min_free_kbytes.patch

Merged

+HZ-100.patch

Set HZ to 100

+kallsyms-build-fix.patch

Fix the build for !CONFIG_KALLSYMS

+ppc64-sk_family-fix.patch

Fix ppc64 for the socket field renaming

+x86_64-fixes.patch

Stuff from Andi

+non-CONFIG_PROC_FS-fix.patch

Build fix for !CONFIG_PROC_FS

-eat-keys-on-panic.patch

Dropped, needs rethinking.

+remove_proc_entry-fix.patch

Fix iaaa1394_core.c (at least) for !CONFIG_PROC_FS

+procfs-jffs-fix.patch

Another !CONFIG_PROC_FS fix

+fix-numaq-apic-handling.patch

NUMAQ fix

+cleanup-summit-subarch.patch

Summit cleanup

+summit-bus-to-node-mapping.patch

Summit fix

+rocket-devfs-fix.patch

rocket.c cleanup

+alloc_bootmem_core-BUG-fix.patch

Init ordering fix

+discontig-empty-node-fix.patch

dicontigmem fix for nodes which have no memory

+TARGET_CPUS-cleanup-fix.patch

More gratuitous cleanups

+show_stack-cleanup.patch

Rationalise show_stack(), show_task(), etc, etc.

+ppc64-show_stack.patch

Fix it for ppc64

-statfs64-fix.patch
-statfs-overflow-fix.patch
-statfs64-leftovers.patch

Folded into statfs64.patch

+statfs64-x86_64-fixes.patch
+ppc64-statfs-fix.patch
+xfs-statfs-warning-fix.patch

More statfs64() fixes

+as-autotune-write-batches.patch

Anticipatory scheduler tuning.




All 153 patches

linus.patch

mm.patch
add -mmN to EXTRAVERSION

kgdb-ga.patch
kgdb stub for ia32 (George Anzinger's one)

kgdb-use-ggdb.patch

HZ-100.patch

kallsyms-build-fix.patch
Fix build for CONFIG_KALLSYMS=n

config_spinline.patch
uninline spinlocks for profiling accuracy.

ppc64-fixup.patch
ppc64 fixup

ppc64-ioctl-pci-update.patch
From: Anton Blanchard <[email protected]>
Subject: ppc64 stuff

ppc64-reloc_hide.patch

ppc64-semaphore-reimplementation.patch
ppc64: use the ia32 semaphore implementation

ppc64-sk_family-fix.patch
ppc64: fixup for family/sk_family rename

sym-do-160.patch
make the SYM driver do 160 MB/sec

x86_64-fixes.patch
x86_64 fixes

non-CONFIG_PROC_FS-fix.patch
Fix the build with !CONFIG_PROC_FS

irqreturn-snd-via-fix.patch
via sound irqreturn fix

irq_cpustat-cleanup.patch
irq_cpustat cleanup

config-PAGE_OFFSET.patch
Configurable kenrel/user memory split

common-ioctl32.patch
common 32-bit ioctl code

ioctl32-cleanup-sparc64.patch
ioctl32 cleanup: sparc64

ioctl32-cleanup-x86_64.patch
x86_64: use common ioctl code

lru_cache_add-check.patch
lru_cache_add debug check

remove_proc_entry-fix.patch
remove_proc_entry() fix

procfs-jffs-fix.patch
JFFS_PROC_FS must depend on JFFS_FS

fix-numaq-apic-handling.patch
fix apic handling for NUMA-Q

cleanup-summit-subarch.patch
cleanup conditionals in summit subarch

summit-bus-to-node-mapping.patch
Subject: [PATCH] provide bus to node mapping for Summit

rocket-devfs-fix.patch
rocket.c: devfs fix

alloc_bootmem_core-BUG-fix.patch
add bootmem failure warning

discontig-empty-node-fix.patch
fix discontig with 0-sized nodes

mem_driver_cleanup.patch
driver/char/mem.c cleanup

eventpoll-use-after-free-fix.patch
eventpoll: fix possible use-after-free

TARGET_CPUS-cleanup-fix.patch
fix TARGET_CPUS inconsistency

fb-image-depth-fix.patch
fbdev image depth fix

buffer-debug.patch
buffer.c debugging

show_stack-cleanup.patch
show_stack() portability and cleanup patch

ppc64-show_stack.patch

statfs64.patch
Add system calls statfs64 and fstatfs64
statfs64: handle overflows
statfs64: remaining filesystems

statfs64-x86_64-fixes.patch
statfs64 fixes for x86_64

ppc64-statfs-fix.patch

xfs-statfs-warning-fix.patch

VM_RESERVED-check.patch
VM_RESERVED check

rcu-stats.patch
RCU statistics reporting

ide_setting_sem-fix.patch

reslabify-pgds-and-pmds.patch
re-slabify i386 pgd's and pmd's

linux-isp.patch

isp-update-1.patch

list_del-debug.patch
list_del debug check

airo-schedule-fix.patch
airo.c: don't sleep in atomic regions

synaptics-mouse-support.patch
Add Synaptics touchpad tweaking to psmouse driver

resurrect-batch_requests.patch
bring back the batch_requests function

kblockd.patch
Create `kblockd' workqueue

cfq-infrastructure.patch

elevator-completion-api.patch
elevator completion API

as-iosched.patch
anticipatory I/O scheduler

as-proc-read-write.patch
AS: pgbench improvement

as-discrete-read-fifo-batches.patch
AS: discrete read fifo batches

as-sync-async.patch
AS sync/async batches

as-hash-removal-fix.patch
AS: hash removal fix

as-jumbo-patch-for-scsi.patch
AS jumbo patch (for SCSI and TCQ)

as-stupid.patch
AS: fix stupid thinko

as-no-batch-antic-limit.patch
AS: no batch-antic-limit

as-autotune-write-batches.patch
AS: autotune write batches

unplug-use-kblockd.patch
Use kblockd for running request queues

cfq-2.patch
CFQ scheduler, #2
CFQ: update to rq-dyn API

cfq-hash-removal-fix.patch
CFQ: hash removal fix

cfq-list_del-fix.patch
CFQ: empty the queuelist

per-queue-nr_requests.patch
per queue nr_requests

blk-invert-watermarks.patch
blk_congestion_wait threshold cleanup

blk-fair-batches.patch
blk-fair-batches

blk-as-hint.patch
blk-as-hint

get_request_wait-oom-fix.patch
handle OOM in get_request_wait().

unmap-page-debugging-2.patch
debug patch: unmap unused kernel pages

unmap-page-debugging-2-fix.patch

slab-poisoning-fix.patch
slab poisoning fix

print-build-options-on-oops.patch
print a few config options on oops

mmap-prefault.patch
prefault of executable mmaps

bio-debug-trap.patch
BIO debugging patch

sound-irq-hack.patch

show_task-free-stack-fix.patch
show_task() fix and cleanup

put_task_struct-debug.patch

ia32-mknod64.patch
mknod64 for ia32

ext2-64-bit-special-inodes.patch
ext2: support for 64-bit device nodes

ext3-64-bit-special-inodes.patch
ext3: support for 64-bit device nodes

64-bit-dev_t-kdev_t.patch
64-bit dev_t and kdev_t

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

lockmeter.patch

ext3-no-bkl.patch

journal_get_write_access-speedup.patch
JBD: journal_get_write_access() speedup

ext3-concurrent-block-inode-allocation.patch
ext3: concurrent block/inode allocation
Fix orlov allocator boundary case

ext3-concurrent-block-allocation-hashed.patch
ext3: scalable counters and locks
fix ext3 inode allocator race

jbd-010-b_committed_data-race-fix.patch
JBD: fix race over access to b_committed_data

jbd-020-locking-schema.patch
JBD: plan JBD locking schema

jbd-030-remove-splice_lock.patch
JBD: remove jh_splice_lock

jbd-040-journal_add_journal_head-locking.patch
JBD: fine-grain journal_add_journal_head locking

jbd-045-rename-journal_unlock_journal_head.patch
JBD: rename journal_unlock_journal_head to journal_put_journal_head

jbd-050-b_frozen_data-locking.patch
JBD: Finish protection of journal_head.b_frozen_data

jbd-060-b_committed_data-locking.patch
JBD: implement b_committed_data locking

jbd-070-b_transaction-locking.patch
JBD: implement b_transaction locking rules

jbd-080-b_next_transaction-locking.patch
JBD: Implement b_next_transaction locking rules

jbd-090-b_tnext-locking.patch
JBD: b_tnext locking

jbd-100-remove-journal_datalist_lock.patch
JBD: remove journal_datalist_lock

jbd-110-t_nr_buffers-locking.patch
JBD: t_nr_buffers locking

jbd-120-t_updates-locking.patch
JBD: t_updates locking

jbd-130-t_outstanding_credits-locking.patch
JBD: implement t_outstanding_credits locking

jbd-140-t_jcb-locking.patch
JBD: implement t_jcb locking

jbd-150-j_barrier_count-locking.patch
JBD: implement j_barrier_count locking

jbd-160-j_running_transaction-locking.patch
JBD: implement j_running_transaction locking

jbd-170-j_committing_transaction-locking.patch
JBD: implement j_committing_transaction locking

jbd-180-j_checkpoint_transactions.patch
JBD: implement j_checkpoint_transactions locking

jbd-190-j_head-locking.patch
JBD: implement journal->j_head locking

jbd-200-j_tail-locking.patch
JBD: implement journal->j_tail locking

jbd-210-j_free-locking.patch
JBD: implement journal->j_free locking

jbd-220-j_commit_sequence-locking.patch
JBD: implement journal->j_commit_sequence locking

jbd-230-j_commit_request-locking.patch
JBD: implement j_commit_request locking

jbd-240-dual-revoke-tables.patch
JBD: implement dual revoke tables.

jbd-250-remove-sleep_on.patch
JBD: remove remaining sleep_on()s

jbd-300-remove-lock_kernel.patch
JBD: remove lock_kernel()

jbd-400-remove-lock_journal.patch
JBD: remove lock_journal()

jbd-510-h_credits-fix.patch
JBD: journal_release_buffer: handle credits fix

jbd-520-journal_unmap_buffer-race.patch
JBD: journal_unmap_buffer race fix

jbd-530-walk_page_buffers-race-fix.patch
ext3: ext3_writepage race fix

jbd-540-journal_try_to_free_buffers-race-fix.patch
JBD: buffer freeing non-race comment

jbd-550-locking-checks.patch
JBD: add some locking assertions

jbd-570-transaction-state-locking.patch
JBD: additional transaction shutdown locking

jbd-580-log_start_commit-race-fix.patch
JBD: fix log_start_commit race

jbd-590-do_get_write_access-speedup.patch
JBD: do_get_write_access() speedup

ext3-010-fix-journalled-data.patch
ext3: fix data=journal mode

ext3-035-journal_try_to_free_buffers-race-fix.patch

ext3-040-recursive-ext3_write_inode-check.patch
ext3: add a dump_stack()

ext3-050-ioctl-transaction-leak.patch
ext3: fix error-path handle leak

ext3-070-xattr-clone-leak-fix.patch
Fix leak in ext3_acl_chmod()

ext3-080-remove-block-inode-count-message.patch
ext3: remove mount-time diagnostic messages

jbd-600-journal_dirty_metadata-speedup.patch
JBD: journal_dirty_metadata() speedup

jbd-610-journal_dirty_metadata-diags.patch
JBD: journal_dirty_metadata diagnostics

jbd-620-commit-vs-start-race-fix.patch
JBD: fix race between journal_commit_transaction and start_this_handle

invalidate_mmap_range.patch
Interface to invalidate regions of mmaps

aio-01-retry.patch
AIO: Core retry infrastructure

aio-02-lockpage_wq.patch
AIO: Async page wait

aio-03-fs_read.patch
AIO: Filesystem aio read

aio-04-buffer_wq.patch
AIO: Async buffer wait

aio-05-fs_write.patch
AIO: Filesystem aio write

aio-05-fs_write-fix.patch

aio-06-bread_wq.patch
AIO: Async block read

aio-06-bread_wq-fix.patch

aio-07-ext2getblk_wq.patch
AIO: Async get block for ext2

aio-poll.patch
aio_poll
aio-poll: don't put extern decls in .c!

O_SYNC-speedup-2.patch
speed up O_SYNC writes

aio-09-o_sync.patch
aio O_SYNC

vfsmount_lock.patch
From: Maneesh Soni <[email protected]>
Subject: [patch 1/2] vfsmount_lock

syncppp-locking-fix.patch
syncppp locking fix

s390-dirty-bit-cleaning.patch
dirty bit clearing on s390.

sched-hot-balancing-fix.patch
fix for CPU scheduler load distribution




2003-06-08 00:23:34

by Alexander Hoogerhuis

[permalink] [raw]
Subject: Re: 2.5.70-mm6

Andrew Morton <[email protected]> writes:
>
> [SNIP]
>

It builds nicely here and runs nicely so far, but my USB-drive still
blows up after a few gigs and I have this one when plugging it in:

Attached scsi generic sg0 at scsi0, channel 0, id 0, lun 0, type 0
spurious 8259A interrupt: IRQ7.
SCSI device sda: 490232832 512-byte hdwr sectors (250999 MB)
sda: cache data unavailable
sda: assuming drive cache: write through
/dev/scsi/host0/bus0/target0/lun0: p1
devfs_mk_dir(scsi/host0/bus0/target0/lun0): could not append to dir: ea549820 "target0"
Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
kjournald starting. Commit interval 5 seconds
EXT3 FS 2.4-0.9.16, 02 Dec 2001 on sda1, internal journal
EXT3-fs: recovery complete.
EXT3-fs: mounted filesystem with ordered data mode.

mvh,
A
--
Alexander Hoogerhuis | [email protected]
CCNP - CCDP - MCNE - CCSE | +47 908 21 485
"You have zero privacy anyway. Get over it." --Scott McNealy

2003-06-08 00:43:06

by Andrew Morton

[permalink] [raw]
Subject: Re: 2.5.70-mm6

Alexander Hoogerhuis <[email protected]> wrote:
>
> Andrew Morton <[email protected]> writes:
> >
> > [SNIP]
> >
>
> It builds nicely here and runs nicely so far, but my USB-drive still
> blows up after a few gigs

Is that usb-storage? There seem to have been a few reports of
erratic behaviour lately.

> and I have this one when plugging it in:
>
> Attached scsi generic sg0 at scsi0, channel 0, id 0, lun 0, type 0
> spurious 8259A interrupt: IRQ7.
> SCSI device sda: 490232832 512-byte hdwr sectors (250999 MB)
> sda: cache data unavailable
> sda: assuming drive cache: write through
> /dev/scsi/host0/bus0/target0/lun0: p1
> devfs_mk_dir(scsi/host0/bus0/target0/lun0): could not append to dir: ea549820 "target0"

Maybe Christph can decode this one for us.


2003-06-08 01:00:11

by Alexander Hoogerhuis

[permalink] [raw]
Subject: Re: 2.5.70-mm6

Andrew Morton <[email protected]> writes:

> Alexander Hoogerhuis <[email protected]> wrote:
> >
> > Andrew Morton <[email protected]> writes:
> > >
> > > [SNIP]
> > >
> >
> > It builds nicely here and runs nicely so far, but my USB-drive still
> > blows up after a few gigs
>
> Is that usb-storage? There seem to have been a few reports of
> erratic behaviour lately.
>

Indeed. Lots of the noise is from me :) You CC'ed Matthew Dharm on a
mail about it, so I tucked him in the CC here too.

mvh,
A
--
Alexander Hoogerhuis | [email protected]
CCNP - CCDP - MCNE - CCSE | +47 908 21 485
"You have zero privacy anyway. Get over it." --Scott McNealy

2003-06-08 11:56:47

by Felipe Alfaro Solana

[permalink] [raw]
Subject: Re: 2.5.70-mm6

On Sun, 2003-06-08 at 00:14, Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.5/2.5.70/2.5.70-mm6/
>
> . Numerous little fixes and additional work against additional patches.
>
> . Waaay too many "cleanups". These are taking significant amounts of
> effort and it is time to start learning to live with dirty code.
>
> . -mm kernels will be running at HZ=100 for a while. This is because
> the anticipatory scheduler's behaviour may be altered by the lower
> resolution. Some architectures continue to use 100Hz and we need the
> testing coverage which x86 provides.

Testing it right now... It compiles nicely with gcc 3.3 (remember the
problems I had with snd-ymfpci when using gcc 3.2), boots and seems
functional.


2003-06-08 12:12:22

by Christoph Hellwig

[permalink] [raw]
Subject: Re: 2.5.70-mm6

On Sat, Jun 07, 2003 at 05:56:49PM -0700, Andrew Morton wrote:
> > Attached scsi generic sg0 at scsi0, channel 0, id 0, lun 0, type 0
> > spurious 8259A interrupt: IRQ7.
> > SCSI device sda: 490232832 512-byte hdwr sectors (250999 MB)
> > sda: cache data unavailable
> > sda: assuming drive cache: write through
> > /dev/scsi/host0/bus0/target0/lun0: p1
> > devfs_mk_dir(scsi/host0/bus0/target0/lun0): could not append to dir: ea549820 "target0"
>
> Maybe Christph can decode this one for us.

There's multiple gendisks with the same .devfs_name in scsi and we call
devfs_mk_dir on each of them. I think the right fix is to let
devfs_mk_dir succeed on an existing directory.


--- 1.91/fs/devfs/base.c Wed Jun 4 09:50:29 2003
+++ edited/fs/devfs/base.c Sat Jun 7 16:09:26 2003
@@ -1684,7 +1684,10 @@
}

error = _devfs_append_entry(dir, de, &old);
- if (error) {
+ if (error == -EEXIST) {
+ error = 0;
+ devfs_put(old);
+ } else if (error) {
PRINTK("(%s): could not append to dir: %p \"%s\"\n",
buf, dir, dir->name);
devfs_put(old);

2003-06-08 15:42:54

by Adrian Bunk

[permalink] [raw]
Subject: [patch] 2.5.70-mm6: ethertap.c doesn't compile


I got the following compile error in 2.5.70-mm6:

<-- snip -->

...
CC drivers/net/ethertap.o
drivers/net/ethertap.c: In function `ethertap_rx':
drivers/net/ethertap.c:295: structure has no member named `protocol'
drivers/net/ethertap.c:300: structure has no member named `receive_queue'
drivers/net/ethertap.c:307: structure has no member named `receive_queue'
drivers/net/ethertap.c: In function `ethertap_close':
drivers/net/ethertap.c:323: structure has no member named `socket'
make[2]: *** [drivers/net/ethertap.o] Error 1

<-- snip -->

The patch below fixes the compilation.



cu
Adrian

--- linux-2.5.70-mm6/drivers/net/ethertap.c.old 2003-06-08 17:48:57.000000000 +0200
+++ linux-2.5.70-mm6/drivers/net/ethertap.c 2003-06-08 17:49:53.000000000 +0200
@@ -292,19 +292,19 @@

static void ethertap_rx(struct sock *sk, int len)
{
- struct net_device *dev = tap_map[sk->protocol];
+ struct net_device *dev = tap_map[sk->sk_protocol];
struct sk_buff *skb;

if (dev==NULL) {
printk(KERN_CRIT "ethertap: bad unit!\n");
- skb_queue_purge(&sk->receive_queue);
+ skb_queue_purge(&sk->sk_receive_queue);
return;
}

if (ethertap_debug > 3)
printk("%s: ethertap_rx()\n", dev->name);

- while ((skb = skb_dequeue(&sk->receive_queue)) != NULL)
+ while ((skb = skb_dequeue(&sk->sk_receive_queue)) != NULL)
ethertap_rx_skb(skb, dev);
}

@@ -320,7 +320,7 @@

if (sk) {
lp->nl = NULL;
- sock_release(sk->socket);
+ sock_release(sk->sk_socket);
}

return 0;

2003-06-08 15:46:08

by Arnaldo Carvalho de Melo

[permalink] [raw]
Subject: Re: [patch] 2.5.70-mm6: ethertap.c doesn't compile

Thanks for the patch, but it was already submitted by Martin@gentoo and I
pushed to Linus that already has this in his tree.

- Arnaldo

Em Sun, Jun 08, 2003 at 05:56:23PM +0200, Adrian Bunk escreveu:
>
> I got the following compile error in 2.5.70-mm6:
>
> <-- snip -->
>

2003-06-08 21:27:56

by Adrian Bunk

[permalink] [raw]
Subject: Re: [patch] 2.5.70-mm6: ethertap.c doesn't compile

On Sun, Jun 08, 2003 at 01:00:55PM -0300, Arnaldo Carvalho de Melo wrote:

> Thanks for the patch, but it was already submitted by Martin@gentoo and I
> pushed to Linus that already has this in his tree.

Ups, yes, I missed this patch...

> - Arnaldo

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

2003-06-08 22:41:39

by Pasi Savolainen

[permalink] [raw]
Subject: Re: 2.5.70-mm6

* Andrew Morton <[email protected]>:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.5/2.5.70/2.5.70-mm6/

Xfree86 4.3.0 won't start on this one. -mm4 started fine.
X will stop (and seemingly hang) on PCI initialization and iteration stage.

> linus.patch

I'd say this is the source of this. Some cleanup along pci_for_each_dev
removal. All the 'fixes' (into while) don't even compile warningless.


--
Psi -- <http://www.iki.fi/pasi.savolainen>

2003-06-08 23:04:31

by Adrian Bunk

[permalink] [raw]
Subject: [patch] 2.5.70-mm6: isp driver cleanups

On Sat, Jun 07, 2003 at 03:14:40PM -0700, Andrew Morton wrote:
>...
> linux-isp.patch
>
> isp-update-1.patch
>...

isp_linux.h already states kernels < 2.4 are not supported. The patch
below removes #ifdef'd code for kernels < 2.4.

diffstat output:

isp_linux.c | 42 ----------
isp_linux.h | 100 +-----------------------
isp_pci.c | 248 ------------------------------------------------------------
3 files changed, 6 insertions(+), 384 deletions(-)

I've tested the compilation with 2.5.70-mm6.

cu
Adrian

--- linux-2.5.70-mm6/drivers/scsi/isp/isp_linux.h.old 2003-06-09 01:07:27.000000000 +0200
+++ linux-2.5.70-mm6/drivers/scsi/isp/isp_linux.h 2003-06-09 00:58:53.000000000 +0200
@@ -39,35 +39,13 @@
#ifndef _ISP_LINUX_H
#define _ISP_LINUX_H

-#ifndef ISP_MODULE
-#define __NO_VERSION__
-#endif
-#ifdef LINUX_ISP_TARGET_MODE
-#define EXPORT_SYMTAB
-#endif
-
#include <linux/version.h>
-#ifndef KERNEL_VERSION
-#define KERNEL_VERSION(v,p,s) (((v)<<16)+(p<<8)+s)
-#endif
-#define _KVC KERNEL_VERSION
-
-#if LINUX_VERSION_CODE <= _KVC(2,2,0)
-#error "Linux 2.0 and 2.1 kernels are not supported anymore"
-#endif
-#if LINUX_VERSION_CODE >= _KVC(2,3,0) && LINUX_VERSION_CODE < _KVC(2,4,0)
-#error "Linux 2.3 kernels are not supported"
-#endif

-#ifndef UNUSED_PARAMETER
-#define UNUSED_PARAMETER(x) (void) x
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2,4,0)
+#error "Linux 2.3 and earlier kernels are not supported"
#endif

#include <linux/autoconf.h>
-#ifdef CONFIG_SMP
-#define __SMP__ 1
-#endif
-

/*
* Be nice and get ourselves out of the way of other drivers.
@@ -103,12 +81,8 @@
#include <asm/dma.h>
#include <asm/io.h>
#include <asm/irq.h>
-#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,4,0)
#include <linux/smp.h>
#include <linux/spinlock.h>
-#else
-#include <asm/spinlock.h>
-#endif
#include <asm/system.h>
#include <asm/byteorder.h>
#include <linux/interrupt.h>
@@ -141,15 +115,15 @@
#undef __pa
#define __pa(x) x
#endif
-#if defined (__i386__) && LINUX_VERSION_CODE >= KERNEL_VERSION(2,4,0)
+#if defined (__i386__)
#undef __pa
#define __pa(x) x
#endif
-#if defined (__sparc__) && LINUX_VERSION_CODE >= KERNEL_VERSION(2,4,0)
+#if defined (__sparc__)
#undef __pa
#define __pa(x) x
#endif
-#if defined (__alpha__) && LINUX_VERSION_CODE >= KERNEL_VERSION(2,4,0)
+#if defined (__alpha__)
#undef __pa
#define __pa(x) x
#endif
@@ -180,11 +154,6 @@
#define BYTE_ORDER LITTLE_ENDIAN
#endif

-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,4,0)
-#define DMA_ADDR_T unsigned long
-#define QLA_SG_C(sg) sg->length
-#define QLA_SG_A(sg) virt_to_bus(sg->address)
-#else
#define DMA_ADDR_T dma_addr_t
#define QLA_SG_C(sg) sg_dma_len(sg)
#define QLA_SG_A(sg) sg_dma_address(sg)
@@ -195,7 +164,6 @@
#define DMA_HTYPE_T dma_addr_t
#define QLA_HANDLE(cmd) (cmd)->SCp.dma_handle
#endif
-#endif

#define HANDLE_LOOPSTATE_IN_OUTER_LAYERS 1
#ifdef min
@@ -398,20 +366,6 @@
#define ISP_IUNLK_SOFTC ISP_UNLK_SOFTC
#define ISP_IGET_LK_SOFTC ISP_LOCK_SOFTC
#define ISP_DROP_LK_SOFTC ISP_UNLK_SOFTC
-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,4,0)
-#define ISP_LOCK_SCSI_DONE(isp) { \
- unsigned long _flags; \
- spin_lock_irqsave(&io_request_lock, _flags); \
- isp->iflags = _flags; \
- }
-#define ISP_UNLK_SCSI_DONE(isp) { \
- unsigned long _flags = isp->iflags; \
- spin_unlock_irqrestore(&io_request_lock, _flags); \
- }
-#else
-#define ISP_LOCK_SCSI_DONE(isp) do { } while(0)
-#define ISP_UNLK_SCSI_DONE(isp) do { } while(0)
-#endif
#define ISP_LOCKU_SOFTC ISP_ILOCK_SOFTC
#define ISP_UNLKU_SOFTC ISP_IUNLK_SOFTC
#define ISP_TLOCK_INIT(isp) spin_lock_init(&isp->isp_osinfo.tlock)
@@ -448,13 +402,8 @@

#define ISP2100_SCRLEN 0x800

-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,4,0)
-#define MEMZERO _isp_memzero
-#define MEMCPY _isp_memcpy
-#else
#define MEMZERO(b, a) memset(b, 0, a)
#define MEMCPY memcpy
-#endif
#define SNPRINTF isp_snprintf
#define USEC_DELAY _isp_usec_delay
#define USEC_SLEEP(isp, x) \
@@ -476,11 +425,7 @@
((u_int64_t) ((((u_int64_t)(x)->tv_sec) * 1000000 + (x)->tv_usec)))
#define NANOTIME_SUB _isp_microtime_sub

-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,4,0)
-#define MAXISPREQUEST(isp) 256
-#else
#define MAXISPREQUEST(isp) ((IS_FC(isp) || IS_ULTRA2(isp))? 1024 : 256)
-#endif

#if defined(__i386__)
#define MEMORYBARRIER(isp, type, offset, size) barrier()
@@ -739,10 +684,6 @@
int isp_drain_reset(struct ispsoftc *, char *);
int isp_drain(struct ispsoftc *, char *);

-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,4,0)
-static INLINE void _isp_memcpy(void *, void *, size_t);
-static INLINE void _isp_memzero(void *, size_t);
-#endif
static INLINE u_int64_t _isp_microtime_sub(struct timeval *, struct timeval *);
static INLINE void _isp_usec_delay(unsigned int);
static INLINE unsigned long _usec_to_jiffies(unsigned int);
@@ -816,37 +757,6 @@
#define _SBSWAP(a, b, c)
#endif

-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,4,0)
-static INLINE void
-_isp_memcpy(void *to, void *from, size_t amt)
-{
- unsigned char *x = to; unsigned char *y = from;
- while (amt-- != 0) *x++ = *y++;
-}
-
-static INLINE void
-_isp_memzero(void *to, size_t amt)
-{
- unsigned char *x = to;
- while (amt-- != 0) *x++ = 0;
-}
-
-static INLINE unsigned long IspOrder(int);
-static INLINE unsigned long
-IspOrder(int nelem)
-{
- unsigned long order, rsize;
-
- order = 0;
- rsize = PAGE_SIZE;
- while (rsize < (unsigned long) ISP_QUEUE_SIZE(nelem)) {
- order++;
- rsize <<= 1;
- }
- return (order);
-}
-#endif
-
static INLINE u_int64_t
_isp_microtime_sub(struct timeval *b, struct timeval *a)
{
--- linux-2.5.70-mm6/drivers/scsi/isp/isp_linux.c.old 2003-06-09 00:41:58.000000000 +0200
+++ linux-2.5.70-mm6/drivers/scsi/isp/isp_linux.c 2003-06-09 01:05:32.000000000 +0200
@@ -91,11 +91,6 @@
static int isp_en_dis_lun(struct ispsoftc *, int, int, int, int);
#endif

-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,3,27)
-struct proc_dir_entry proc_scsi_qlc = {
- PROC_SCSI_QLOGICISP, 3, "isp", S_IFDIR | S_IRUGO | S_IXUGO, 2
-};
-#endif
static const char *class3_roles[4] = {
"None", "Target", "Initiator", "Target/Initiator"
};
@@ -404,11 +399,7 @@
isplinux_detect(Scsi_Host_Template *tmpt)
{
int rval;
-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,4,0)
- tmpt->proc_dir = &proc_scsi_qlc;
-#else
tmpt->proc_name = "isp";
-#endif
#if LINUX_VERSION_CODE < KERNEL_VERSION(2,5,0)
spin_unlock_irq(&io_request_lock);
rval = isplinux_pci_detect(tmpt);
@@ -511,9 +502,7 @@
scsi_add_timer(Cmnd, Cmnd->timeout_per_command, Cmnd->done);
isp_prt(isp, ISP_LOGDEBUG0, "giving up on target %d", XS_TGT(Cmnd));
ISP_UNLK_SOFTC(isp);
- ISP_LOCK_SCSI_DONE(isp);
(*Cmnd->scsi_done)(Cmnd);
- ISP_UNLK_SCSI_DONE(isp);
ISP_LOCK_SOFTC(isp);
return;
}
@@ -650,9 +639,7 @@
* Add back a timer else scsi_done drops this on the floor.
*/
scsi_add_timer(Cmnd, Cmnd->timeout_per_command, Cmnd->done);
- ISP_LOCK_SCSI_DONE(isp);
(*Cmnd->scsi_done)(Cmnd);
- ISP_UNLK_SCSI_DONE(isp);
} while ((Cmnd = Ncmnd) != NULL);
ISP_LOCK_SOFTC(isp);
}
@@ -2466,7 +2453,6 @@
}
ISP_IUNLK_SOFTC(isp);
if (Cmnd) {
- ISP_LOCK_SCSI_DONE(isp);
while (Cmnd) {
Scsi_Cmnd *f = (Scsi_Cmnd *) Cmnd->host_scribble;
Cmnd->host_scribble = NULL;
@@ -2479,7 +2465,6 @@
(*Cmnd->scsi_done)(Cmnd);
Cmnd = f;
}
- ISP_UNLK_SCSI_DONE(isp);
}
}

@@ -2532,7 +2517,6 @@
ISP_IUNLK_SOFTC(isp);
#endif
if (Cmnd) {
- ISP_LOCK_SCSI_DONE(isp);
while (Cmnd) {
Scsi_Cmnd *f = (Scsi_Cmnd *) Cmnd->host_scribble;
Cmnd->host_scribble = NULL;
@@ -2545,7 +2529,6 @@
(*Cmnd->scsi_done)(Cmnd);
Cmnd = f;
}
- ISP_UNLK_SCSI_DONE(isp);
}
return IRQ_HANDLED;
}
@@ -2839,11 +2822,7 @@
}
isp->isp_state = ISP_RUNSTATE;

-#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,4,0)
isp->isp_osinfo.host->can_queue = isp->isp_maxcmds;
-#else
- isp->isp_osinfo.host->can_queue = min(255, isp->isp_maxcmds);
-#endif
if (isp->isp_osinfo.host->can_queue == 0)
isp->isp_osinfo.host->can_queue = 1;

@@ -2947,12 +2926,6 @@
return (0);
}

-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,4,0)
-#define ISP_THREAD_CAN_EXIT isp->isp_host->loaded_as_module
-#else
-#define ISP_THREAD_CAN_EXIT 0
-#endif
-
static int
isp_task_thread(void *arg)
{
@@ -2964,11 +2937,7 @@

#if LINUX_VERSION_CODE < KERNEL_VERSION(2,5,0)
/* XXX: Not really sure why the 2.5.X changes do this */
- if (ISP_THREAD_CAN_EXIT) {
- siginitsetinv(&current->blocked, sigmask(SIGHUP));
- } else {
- siginitsetinv(&current->blocked, 0);
- }
+ siginitsetinv(&current->blocked, 0);
lock_kernel();
daemonize();
sprintf(current->comm, "isp_thrd%d", isp->isp_unit);
@@ -2988,10 +2957,6 @@
while (exit_thread == 0) {
isp_prt(isp, ISP_LOGDEBUG1, "isp_task_thread sleeping");
down_interruptible(&thread_sleep_semaphore);
- if (ISP_THREAD_CAN_EXIT) {
- if (signal_pending(current))
- break;
- }
isp_prt(isp, ISP_LOGDEBUG1, "isp_task_thread running");

spin_lock_irqsave(&isp->isp_osinfo.tlock, flags);
@@ -3063,9 +3028,6 @@
ISP_UNLKU_SOFTC(isp);
break;
case ISP_THREAD_EXIT:
- if (ISP_THREAD_CAN_EXIT) {
- exit_thread = 1;
- }
break;
default:
break;
@@ -3146,10 +3108,8 @@
MODULE_PARM(isp_default_frame_size, "i");
MODULE_PARM(isp_default_exec_throttle, "i");
#endif
-#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,4,0) || defined(MODULE)
Scsi_Host_Template driver_template = QLOGICISP;
#include "scsi_module.c"
-#endif
/*
* mode: c
* Local variables:
--- linux-2.5.70-mm6/drivers/scsi/isp/isp_pci.c.old 2003-06-09 00:59:34.000000000 +0200
+++ linux-2.5.70-mm6/drivers/scsi/isp/isp_pci.c 2003-06-09 01:02:38.000000000 +0200
@@ -63,13 +63,8 @@
static int
isp_pci_dmasetup(struct ispsoftc *, XS_T *, ispreq_t *, u_int16_t *, u_int16_t);

-#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,4,0)
static void isp_pci_dmateardown(struct ispsoftc *, XS_T *, u_int16_t);
#define IS_HIGH_ISP_ADDR(addr) (addr >= (u_int64_t) 0x100000000)
-#else
-#define isp_pci_dmateardown NULL
-#define IS_HIGH_ISP_ADDR(addr) 0
-#endif

#if ISP_DAC_SUPPORTED == 1
#define ISP_A64 1
@@ -544,7 +539,6 @@
pcs->port = 0;
}
kfree(isp->isp_xflist);
-#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,4,0)
pci_free_consistent(pcs->pci_dev, RQUEST_QUEUE_LEN(isp) * QENTRY_LEN,
isp->isp_rquest, isp->isp_rquest_dma);
pci_free_consistent(pcs->pci_dev, RESULT_QUEUE_LEN(isp) * QENTRY_LEN,
@@ -553,13 +547,6 @@
pci_free_consistent(pcs->pci_dev, ISP2100_SCRLEN,
FCPARAM(isp)->isp_scratch, FCPARAM(isp)->isp_scdma);
}
-#else
- RlsPages(isp->isp_rquest, IspOrder(RQUEST_QUEUE_LEN(isp)));
- RlsPages(isp->isp_result, IspOrder(RESULT_QUEUE_LEN(isp)));
- if (IS_FC(isp) && FCPARAM(isp)->isp_scratch) {
- RlsPages(FCPARAM(isp)->isp_scratch, 1);
- }
-#endif
#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,4,18) && \
LINUX_VERSION_CODE < KERNEL_VERSION(2,5,0)
if (--isp_nfound <= 0) {
@@ -594,7 +581,6 @@
vid = isp_pci->pci_dev->vendor;
did = isp_pci->pci_dev->device;

-#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,4,0)
io_base = pci_resource_start(isp_pci->pci_dev, 0);
if (pci_resource_flags(isp_pci->pci_dev, 0) & PCI_BASE_ADDRESS_MEM_TYPE_64)
irq = 2;
@@ -609,17 +595,6 @@
isp_pci_mapmem &= ~(1 << isp->isp_unit);
#endif
}
-#else /* LINUX_VERSION_CODE >= KERNEL_VERSION(2,4,0) */
- io_base = isp_pci->pci_dev->base_address[0];
- mem_base = isp_pci->pci_dev->base_address[1];
- if (mem_base & PCI_BASE_ADDRESS_MEM_TYPE_64) {
-#if BITS_PER_LONG == 64
- mem_base |= isp_pci->pci_dev->base_address[2] << 32;
-#else
- isp_pci_mapmem &= ~(1 << isp->isp_unit);
-#endif
- }
-#endif /* LINUX_VERSION_CODE >= KERNEL_VERSION(2,4,0) */
irq = isp_pci->pci_dev->irq;

if (vid != PCI_VENDOR_ID_QLOGIC) {
@@ -675,13 +650,11 @@
return (1);
}

-#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,4,0)
if (pci_enable_device(isp_pci->pci_dev)) {
printk("%s: fails to be PCI_ENABLEd\n", loc);
return (1);
}
(void) PRDW(isp_pci, PCI_COMMAND, &cmd);
-#endif

if ((cmd & PCI_CMD_ISP) != pci_cmd_isp) {
if (isp_debug & ISP_LOGINFO)
@@ -1165,7 +1138,6 @@
MEMZERO(isp->isp_xflist, amt);
}
if (isp->isp_rquest == NULL) {
-#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,4,0)
struct isp_pcisoftc *pcs = (struct isp_pcisoftc *) isp;
dma_addr_t busaddr;
isp->isp_rquest =
@@ -1176,17 +1148,6 @@
return (1);
}
isp->isp_rquest_dma = busaddr;
-#else
- isp->isp_rquest = (caddr_t) GetPages(IspOrder(RQUEST_QUEUE_LEN(isp)));
- if (isp->isp_rquest == NULL) {
- isp_prt(isp, ISP_LOGERR, "unable to allocate request queue");
- return (1);
- }
- /*
- * Map the Request queue.
- */
- isp->isp_rquest_dma = virt_to_bus(isp->isp_rquest);
-#endif
if (isp->isp_rquest_dma & 0x3f) {
isp_prt(isp, ISP_LOGERR, "Request Queue not on 64 byte boundary");
return (1);
@@ -1195,7 +1156,6 @@
}

if (isp->isp_result == NULL) {
-#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,4,0)
struct isp_pcisoftc *pcs = (struct isp_pcisoftc *) isp;
dma_addr_t busaddr;
isp->isp_result =
@@ -1206,19 +1166,6 @@
return (1);
}
isp->isp_result_dma = busaddr;
-#else
- isp->isp_result = (caddr_t) GetPages(IspOrder(RESULT_QUEUE_LEN(isp)));
- if (isp->isp_result == NULL) {
- isp_prt(isp, ISP_LOGERR, "unable to allocate result queue");
- free_pages((unsigned long)isp->isp_rquest,
- IspOrder(RQUEST_QUEUE_LEN(isp)));
- return (1);
- }
- /*
- * Map the result queue.
- */
- isp->isp_result_dma = virt_to_bus(isp->isp_result);
-#endif
if (isp->isp_rquest_dma & 0x3f) {
isp_prt(isp, ISP_LOGERR, "Result Queue not on 64 byte boundary");
return (1);
@@ -1229,7 +1176,6 @@
if (IS_FC(isp)) {
fcparam *fcp = isp->isp_param;
if (fcp->isp_scratch == NULL) {
-#if LINUX_VERSION_CODE > KERNEL_VERSION(2,3,92)
struct isp_pcisoftc *pcs = (struct isp_pcisoftc *) isp;
dma_addr_t busaddr;
fcp->isp_scratch =
@@ -1239,17 +1185,6 @@
return (1);
}
fcp->isp_scdma = busaddr;
-#else
- /*
- * Just get a page....
- */
- fcp->isp_scratch = (void *) GetPages(1);
- if (fcp->isp_scratch == NULL) {
- isp_prt(isp, ISP_LOGERR, "unable to allocate scratch space");
- return (1);
- }
- fcp->isp_scdma = virt_to_bus((void *)fcp->isp_scratch);
-#endif
MEMZERO(fcp->isp_scratch, ISP2100_SCRLEN);
if (fcp->isp_scdma & 0x7) {
isp_prt(isp, ISP_LOGERR, "scratch space not 8 byte aligned");
@@ -1325,7 +1260,6 @@
sg++;
}
sg = tcmd->cd_data;
-#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,4,0)
{
struct isp_pcisoftc *pcs = (struct isp_pcisoftc *) isp;
int new_seg_cnt;
@@ -1342,7 +1276,6 @@
return (CMD_COMPLETE);
}
}
-#endif
nctios = nseg / ISP_RQDSEG;
if (nseg % ISP_RQDSEG) {
nctios++;
@@ -1402,11 +1335,7 @@
* Unlike normal initiator commands, we don't do
* any swizzling here.
*/
-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,4,0)
- cto->ct_dataseg[seg].ds_base = virt_to_bus(sg->address);
-#else
cto->ct_dataseg[seg].ds_base = (u_int32_t) sg_dma_address(sg);
-#endif
cto->ct_dataseg[seg].ds_count = (u_int32_t) sg->length;
cto->ct_xfrlen += sg->length;
sg++;
@@ -1586,7 +1515,6 @@
sg++;
}
sg = tcmd->cd_data;
-#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,4,0)
{
struct isp_pcisoftc *pcs = (struct isp_pcisoftc *) isp;
int new_seg_cnt;
@@ -1603,7 +1531,6 @@
return (CMD_COMPLETE);
}
}
-#endif
nctios = nseg / ISP_RQDSEG_T2;
if (nseg % ISP_RQDSEG_T2) {
nctios++;
@@ -1675,12 +1602,8 @@
* Unlike normal initiator commands, we don't do
* any swizzling here.
*/
-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,4,0)
- cto->rsp.m0.ct_dataseg[seg].ds_base = virt_to_bus(sg->address);
-#else
cto->rsp.m0.ct_dataseg[seg].ds_base =
(u_int32_t) sg_dma_address(sg);
-#endif
cto->rsp.m0.ct_dataseg[seg].ds_count = (u_int32_t) sg->length;
cto->rsp.m0.ct_xfrlen += sg->length;
sg++;
@@ -1818,7 +1741,6 @@
}
#endif

-#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,4,0)
#define FOURG_SEG(x) (((u64) (x)) & 0xffffffff00000000ULL)

static int
@@ -2171,176 +2093,6 @@
}
}

-#else
-
-static int
-isp_pci_dmasetup(struct ispsoftc *isp, Scsi_Cmnd *Cmnd, ispreq_t *rq,
- u_int16_t *nxi, u_int16_t optr)
-{
- struct scatterlist *sg;
- DMA_ADDR_T one_shot_addr;
- unsigned int one_shot_length;
- int segcnt, seg, ovseg, seglim;
- void *h;
- u_int16_t nxti;
-
-#ifdef LINUX_ISP_TARGET_MODE
- if (rq->req_header.rqs_entry_type == RQSTYPE_CTIO ||
- rq->req_header.rqs_entry_type == RQSTYPE_CTIO2) {
- int s;
- if (IS_SCSI(isp))
- s = tdma_mk(isp, (tmd_cmd_t *)Cmnd, (ct_entry_t *)rq, nxi, optr);
- else
- s = tdma_mkfc(isp, (tmd_cmd_t *)Cmnd, (ct2_entry_t *)rq, nxi, optr);
- return (s);
- }
-#endif
-
- nxti = *nxi;
- h = (void *) ISP_QUEUE_ENTRY(isp->isp_rquest, isp->isp_reqidx);
-
- if (Cmnd->request_bufflen == 0) {
- rq->req_seg_count = 1;
- goto mbxsync;
- }
-
- if (IS_FC(isp)) {
- if (rq->req_header.rqs_entry_type == RQSTYPE_T3RQS)
- seglim = ISP_RQDSEG_T3;
- else
- seglim = ISP_RQDSEG_T2;
- ((ispreqt2_t *)rq)->req_totalcnt = Cmnd->request_bufflen;
- /*
- * Linux doesn't make it easy to tell which direction
- * the data is expected to go, and you really need to
- * know this for FC. We'll have to assume that some
- * of these commands that might be used for writes
- * our outbounds and all else are inbound.
- */
- switch (Cmnd->cmnd[0]) {
- case FORMAT_UNIT:
- case WRITE_6:
- case MODE_SELECT:
- case SEND_DIAGNOSTIC:
- case WRITE_10:
- case WRITE_BUFFER:
- case WRITE_LONG:
- case WRITE_SAME:
- case MODE_SELECT_10:
- case WRITE_12:
- case WRITE_VERIFY_12:
- case SEND_VOLUME_TAG:
- ((ispreqt2_t *)rq)->req_flags |= REQFLAG_DATA_OUT;
- break;
- default:
- ((ispreqt2_t *)rq)->req_flags |= REQFLAG_DATA_IN;
- }
- } else {
- if (Cmnd->cmd_len > 12)
- seglim = 0;
- else
- seglim = ISP_RQDSEG;
- rq->req_flags |= REQFLAG_DATA_OUT | REQFLAG_DATA_IN;
- }
-
- one_shot_addr = (DMA_ADDR_T) 0;
- one_shot_length = 0;
- if ((segcnt = Cmnd->use_sg) == 0) {
- segcnt = 1;
- sg = NULL;
- one_shot_length = Cmnd->request_bufflen;
- one_shot_addr = virt_to_bus(Cmnd->request_buffer);
- } else {
- sg = (struct scatterlist *) Cmnd->request_buffer;
- }
- if (segcnt == 0) {
- isp_prt(isp, ISP_LOGWARN, "unable to dma map request");
- XS_SETERR(Cmnd, HBA_BOTCH);
- return (CMD_EAGAIN);
- }
-
- for (seg = 0, rq->req_seg_count = 0;
- seg < segcnt && rq->req_seg_count < seglim;
- seg++, rq->req_seg_count++) {
- DMA_ADDR_T addr;
- unsigned int length;
-
- if (sg) {
- length = QLA_SG_C(sg);
- addr = QLA_SG_A(sg);
- sg++;
- } else {
- length = one_shot_length;
- addr = one_shot_addr;
- }
-
- if (rq->req_header.rqs_entry_type == RQSTYPE_T2RQS) {
- ispreqt2_t *rq2 = (ispreqt2_t *)rq;
- rq2->req_dataseg[rq2->req_seg_count].ds_count = length;
- rq2->req_dataseg[rq2->req_seg_count].ds_base = addr;
- } else {
- rq->req_dataseg[rq->req_seg_count].ds_count = length;
- rq->req_dataseg[rq->req_seg_count].ds_base = addr;
- }
- isp_prt(isp, ISP_LOGDEBUG1, "seg0[%d]%llx:%u from %p", seg,
- (long long)addr, length, sg? sg->address : Cmnd->request_buffer);
- }
-
- if (seg == segcnt) {
- goto mbxsync;
- }
-
- do {
- int lim;
- u_int16_t curip;
- ispcontreq_t local, *crq = &local, *qep;
-
- curip = nxti;
- qep = (ispcontreq_t *) ISP_QUEUE_ENTRY(isp->isp_rquest, curip);
- nxti = ISP_NXT_QENTRY((curip), RQUEST_QUEUE_LEN(isp));
- if (nxti == optr) {
- isp_prt(isp, ISP_LOGDEBUG0, "out of space for continuations");
- XS_SETERR(Cmnd, HBA_BOTCH);
- return (CMD_EAGAIN);
- }
- rq->req_header.rqs_entry_count++;
- MEMZERO((void *)crq, sizeof (*crq));
- crq->req_header.rqs_entry_count = 1;
- if (rq->req_header.rqs_entry_type == RQSTYPE_T3RQS) {
- lim = ISP_CDSEG64;
- crq->req_header.rqs_entry_type = RQSTYPE_A64_CONT;
- } else {
- lim = ISP_CDSEG;
- crq->req_header.rqs_entry_type = RQSTYPE_DATASEG;
- }
-
- for (ovseg = 0; seg < segcnt && ovseg < lim;
- rq->req_seg_count++, seg++, ovseg++, sg++) {
- if (sg->length == 0) {
- panic("zero length s-g element at line %d", __LINE__);
- }
- crq->req_dataseg[ovseg].ds_count = QLA_SG_C(sg);
- crq->req_dataseg[ovseg].ds_base = QLA_SG_A(sg);
- isp_prt(isp, ISP_LOGDEBUG1, "seg%d[%d]%llx:%u from %p",
- rq->req_header.rqs_entry_count-1, ovseg,
- (unsigned long long) QLA_SG_A(sg), QLA_SG_C(sg), sg->address);
- }
- MEMORYBARRIER(isp, SYNC_REQUEST, curip, QENTRY_LEN);
- isp_put_cont_req(isp, crq, qep);
- } while (seg < segcnt);
-mbxsync:
- if (rq->req_header.rqs_entry_type == RQSTYPE_T3RQS) {
- isp_put_request_t3(isp, (ispreqt3_t *) rq, (ispreqt3_t *) h);
- } else if (rq->req_header.rqs_entry_type == RQSTYPE_T2RQS) {
- isp_put_request_t2(isp, (ispreqt2_t *) rq, (ispreqt2_t *) h);
- } else {
- isp_put_request(isp, (ispreq_t *) rq, (ispreq_t *) h);
- }
- *nxi = nxti;
- return (CMD_QUEUED);
-}
-#endif
-
static void
isp_pci_reset1(struct ispsoftc *isp)
{

2003-06-08 23:11:17

by Joe

[permalink] [raw]
Subject: Re: 2.5.70-mm6

All in all -mm6 seems fine here but for two small
problems, one of which is the continuing issue with
gdm which first surfaced in -mm5 IIRC -

Jun 7 18:32:01 jyro kernel: ip_tables: (C) 2000-2002 Netfilter core team
Jun 7 18:32:01 jyro kernel: ip_conntrack version 2.1 (4086 buckets,
32688 max)
- 324 bytes per conntrack
Jun 7 18:32:06 jyro gdm[1282]: gdm_slave_xioerror_handler: Fatal X
error - Restarting :0
Jun 7 18:32:07 jyro gdm[1293]: gdm_slave_xioerror_handler: Fatal X
error - Restarting :0
Jun 7 18:32:12 jyro gdm[1305]: gdm_slave_xioerror_handler: Fatal X
error - Restarting :0
Jun 7 18:32:16 jyro gdm[1311]: gdm_slave_xioerror_handler: Fatal X
error - Restarting :0
Jun 7 18:32:16 jyro gdm[1237]: deal_with_x_crashes: Running the
XKeepsCrashing script
Jun 7 18:32:54 jyro gdm[1237]: Failed to start X server several times
in a short time period; disabling display :0




2003-06-08 23:13:37

by Andrew Morton

[permalink] [raw]
Subject: Re: [patch] 2.5.70-mm6: isp driver cleanups

Adrian Bunk <[email protected]> wrote:
>
> isp_linux.h already states kernels < 2.4 are not supported. The patch
> below removes #ifdef'd code for kernels < 2.4.

I shall forward this along to Matthew, but there is not a lot of point in
working against the -mm version of this driver: it is just there for people
to test.

Thanks.

2003-06-09 17:32:23

by Maciej Soltysiak

[permalink] [raw]
Subject: Re: 2.5.70-mm6

> . -mm kernels will be running at HZ=100 for a while. This is because
> the anticipatory scheduler's behaviour may be altered by the lower
> resolution. Some architectures continue to use 100Hz and we need the
> testing coverage which x86 provides.
The interactivity seems to have dropped. Again, with common desktop
applications: xmms playing with ALSA, when choosing navigating through
evolution options or browsing with opera, music skipps.
X is running with nice -10, but with mm5 it ran smoothly.

Regards,
Maciej

2003-06-09 17:36:54

by Martin J. Bligh

[permalink] [raw]
Subject: Re: 2.5.70-mm6

--On Monday, June 09, 2003 19:45:58 +0200 Maciej Soltysiak <[email protected]> wrote:

>> . -mm kernels will be running at HZ=100 for a while. This is because
>> the anticipatory scheduler's behaviour may be altered by the lower
>> resolution. Some architectures continue to use 100Hz and we need the
>> testing coverage which x86 provides.
>
> The interactivity seems to have dropped. Again, with common desktop
> applications: xmms playing with ALSA, when choosing navigating through
> evolution options or browsing with opera, music skipps.
> X is running with nice -10, but with mm5 it ran smoothly.

If you don't nice the hell out of X, does it work OK?

M.

2003-06-09 17:53:02

by Alistair John Strachan

[permalink] [raw]
Subject: Re: 2.5.70-mm6

On Monday 09 June 2003 18:45, Maciej Soltysiak wrote:
> > . -mm kernels will be running at HZ=100 for a while. This is because
> > the anticipatory scheduler's behaviour may be altered by the lower
> > resolution. Some architectures continue to use 100Hz and we need the
> > testing coverage which x86 provides.
>
> The interactivity seems to have dropped. Again, with common desktop
> applications: xmms playing with ALSA, when choosing navigating through
> evolution options or browsing with opera, music skipps.
> X is running with nice -10, but with mm5 it ran smoothly.

[alistair] 07:02 PM [~] uname -r
2.5.70-mm6

For what it's worth, I'm running an LFS base system with very few packages
installed over the top. X is as packaged, it is not reniced. I am, however,
running setiathome constantly in the background, which seems to pound the
scheduler.

As Maciej reported, this seems to be significantly better with -mm5 (HZ =
1000?). Amusingly, doing a renice -20 `pidof xmms` seems to make absolutely
no difference to the scheduler in 2.5-mm.

This kernel does not have preempt enabled.

Cheers,
Alistair.

2003-06-09 18:06:08

by Maciej Soltysiak

[permalink] [raw]
Subject: Re: 2.5.70-mm6

> If you don't nice the hell out of X, does it work OK?
No.

The way I reproduce the sound skips:
run xmms, run evolution, compose a mail with gpg.
on mm6 the gpg part stops the sound for a few seconds. (with X -10 and 0)
on mm5 xmms plays without stops. (with X -10)

Regards,
Maciej

2003-06-09 18:22:29

by Felipe Alfaro Solana

[permalink] [raw]
Subject: Re: 2.5.70-mm6

On Mon, 2003-06-09 at 19:45, Maciej Soltysiak wrote:
> > . -mm kernels will be running at HZ=100 for a while. This is because
> > the anticipatory scheduler's behaviour may be altered by the lower
> > resolution. Some architectures continue to use 100Hz and we need the
> > testing coverage which x86 provides.
> The interactivity seems to have dropped. Again, with common desktop
> applications: xmms playing with ALSA, when choosing navigating through
> evolution options or browsing with opera, music skipps.
> X is running with nice -10, but with mm5 it ran smoothly.

Sadly, I must agree with you... Sound with XMMS and Mplayer is chunky
when switching between virtual desktops, or even dragging windows. Is
this caused by latest scheduler patches, or has something to with
HZ=100?

2003-06-09 18:25:56

by Felipe Alfaro Solana

[permalink] [raw]
Subject: Re: 2.5.70-mm6

On Mon, 2003-06-09 at 19:39, Martin J. Bligh wrote:
> --On Monday, June 09, 2003 19:45:58 +0200 Maciej Soltysiak <[email protected]> wrote:
>
> >> . -mm kernels will be running at HZ=100 for a while. This is because
> >> the anticipatory scheduler's behaviour may be altered by the lower
> >> resolution. Some architectures continue to use 100Hz and we need the
> >> testing coverage which x86 provides.
> >
> > The interactivity seems to have dropped. Again, with common desktop
> > applications: xmms playing with ALSA, when choosing navigating through
> > evolution options or browsing with opera, music skipps.
> > X is running with nice -10, but with mm5 it ran smoothly.
>
> If you don't nice the hell out of X, does it work OK?

I can't appreciate much different. I've assigned shortcuts to switch
between desktops easily. Switching between desktops very fast causes
XMMS to skip sound. This also happens when dragging windows.

2003-06-09 18:49:14

by Martin J. Bligh

[permalink] [raw]
Subject: Re: 2.5.70-mm6

>> If you don't nice the hell out of X, does it work OK?
> No.
>
> The way I reproduce the sound skips:
> run xmms, run evolution, compose a mail with gpg.
> on mm6 the gpg part stops the sound for a few seconds. (with X -10 and 0)
> on mm5 xmms plays without stops. (with X -10)

Does this (from Ingo?) do anything useful to it?

diff -urpN -X /home/fletch/.diff.exclude 400-reiserfs_dio/kernel/sched.c 420-sched_interactive/kernel/sched.c
--- 400-reiserfs_dio/kernel/sched.c Fri May 30 19:26:34 2003
+++ 420-sched_interactive/kernel/sched.c Fri May 30 19:28:06 2003
@@ -89,6 +89,8 @@ int node_threshold = 125;
#define STARVATION_LIMIT (starvation_limit)
#define NODE_THRESHOLD (node_threshold)

+#define TIMESLICE_GRANULARITY (HZ/20 ?: 1)
+
/*
* If a task is 'interactive' then we reinsert it in the active
* array after it has expired its current timeslice. (it will not
@@ -1365,6 +1367,27 @@ void scheduler_tick(int user_ticks, int
enqueue_task(p, rq->expired);
} else
enqueue_task(p, rq->active);
+ } else {
+ /*
+ * Prevent a too long timeslice allowing a task to monopolize
+ * the CPU. We do this by splitting up the timeslice into
+ * smaller pieces.
+ *
+ * Note: this does not mean the task's timeslices expire or
+ * get lost in any way, they just might be preempted by
+ * another task of equal priority. (one with higher
+ * priority would have preempted this task already.) We
+ * requeue this task to the end of the list on this priority
+ * level, which is in essence a round-robin of tasks with
+ * equal priority.
+ */
+ if (!(p->time_slice % TIMESLICE_GRANULARITY) &&
+ (p->array == rq->active)) {
+ dequeue_task(p, rq->active);
+ set_tsk_need_resched(p);
+ p->prio = effective_prio(p);
+ enqueue_task(p, rq->active);
+ }
}
out_unlock:
spin_unlock(&rq->lock);

2003-06-09 19:01:26

by Pasi Savolainen

[permalink] [raw]
Subject: Re: 2.5.70-mm6

* Maciej Soltysiak <[email protected]>:
>> . -mm kernels will be running at HZ=100 for a while. This is because
>> the anticipatory scheduler's behaviour may be altered by the lower
>> resolution. Some architectures continue to use 100Hz and we need the
>> testing coverage which x86 provides.
> The interactivity seems to have dropped. Again, with common desktop
> applications: xmms playing with ALSA, when choosing navigating through
> evolution options or browsing with opera, music skipps.
> X is running with nice -10, but with mm5 it ran smoothly.

I see that idle() is called much less often than before (1000
calls/second down to 150 calls/second, estimated and non-scientifical).

non-linear scale down is most probably because processes get more done
and don't wait so much.

idle() is also get called more when there is some load.

There is something weird though, I have this constant 0.8 load which I
can't pinpoint, in -mm4 fully idle machine was at about 0.1 load.

Regarding my stupidly reported Xfree86 -problem, it was PEBKAC, though I
can't tell what exactly that was. Only one module changed way to iterate
pci_find_device between boots.


--
Psi -- <http://www.iki.fi/pasi.savolainen>

2003-06-09 19:28:58

by Maciej Soltysiak

[permalink] [raw]
Subject: Re: 2.5.70-mm6

> > on mm6 the gpg part stops the sound for a few seconds. (with X -10 and 0)
> > on mm5 xmms plays without stops. (with X -10)
>
> Does this (from Ingo?) do anything useful to it?
No, maybe a little bit, the skips are still there.

Regards,
Maciej

2003-06-09 19:51:14

by William Lee Irwin III

[permalink] [raw]
Subject: Re: 2.5.70-mm6

At some point in the past, mbligh wrote:
>> Does this (from Ingo?) do anything useful to it?

On Mon, Jun 09, 2003 at 09:42:36PM +0200, Maciej Soltysiak wrote:
> No, maybe a little bit, the skips are still there.

How about one or the other of these two? (not both at once, though,
they appear to clash).

I apologize in advance if MIME attachments are bad for you?


-- wli


Attachments:
(No filename) (375.00 B)
galbraith.patch (7.20 kB)
galbraith.patch
galbraith_thud.diff (1.13 kB)
galbraith_thud.diff
Download all attachments

2003-06-09 19:55:21

by Felipe Alfaro Solana

[permalink] [raw]
Subject: Re: 2.5.70-mm6

On Mon, 2003-06-09 at 20:51, Martin J. Bligh wrote:
> >> If you don't nice the hell out of X, does it work OK?
> > No.
> >
> > The way I reproduce the sound skips:
> > run xmms, run evolution, compose a mail with gpg.
> > on mm6 the gpg part stops the sound for a few seconds. (with X -10 and 0)
> > on mm5 xmms plays without stops. (with X -10)
>
> Does this (from Ingo?) do anything useful to it?

I can confirm that 2.5.70-mm6 with Ingo's patch and HZ set back to 1000
is nearly perfect (it still takes some seconds for the scheduler to
adjust dynamic priorities).

2003-06-09 20:12:19

by Martin J. Bligh

[permalink] [raw]
Subject: Re: 2.5.70-mm6

--On Monday, June 09, 2003 22:08:42 +0200 Felipe Alfaro Solana <[email protected]> wrote:

> On Mon, 2003-06-09 at 20:51, Martin J. Bligh wrote:
>> >> If you don't nice the hell out of X, does it work OK?
>> > No.
>> >
>> > The way I reproduce the sound skips:
>> > run xmms, run evolution, compose a mail with gpg.
>> > on mm6 the gpg part stops the sound for a few seconds. (with X -10 and 0)
>> > on mm5 xmms plays without stops. (with X -10)
>>
>> Does this (from Ingo?) do anything useful to it?
>
> I can confirm that 2.5.70-mm6 with Ingo's patch and HZ set back to 1000
> is nearly perfect (it still takes some seconds for the scheduler to
> adjust dynamic priorities).

OK ... sorry to be pedantic, but I want to nail this down.
It's still broken with HZ=1000, but without Ingo's patch, right?

M.

2003-06-09 20:55:40

by Felipe Alfaro Solana

[permalink] [raw]
Subject: Re: 2.5.70-mm6

On Mon, 2003-06-09 at 22:14, Martin J. Bligh wrote:
> --On Monday, June 09, 2003 22:08:42 +0200 Felipe Alfaro Solana <[email protected]> wrote:
>
> > On Mon, 2003-06-09 at 20:51, Martin J. Bligh wrote:
> >> >> If you don't nice the hell out of X, does it work OK?
> >> > No.
> >> >
> >> > The way I reproduce the sound skips:
> >> > run xmms, run evolution, compose a mail with gpg.
> >> > on mm6 the gpg part stops the sound for a few seconds. (with X -10 and 0)
> >> > on mm5 xmms plays without stops. (with X -10)
> >>
> >> Does this (from Ingo?) do anything useful to it?
> >
> > I can confirm that 2.5.70-mm6 with Ingo's patch and HZ set back to 1000
> > is nearly perfect (it still takes some seconds for the scheduler to
> > adjust dynamic priorities).
>
> OK ... sorry to be pedantic, but I want to nail this down.
> It's still broken with HZ=1000, but without Ingo's patch, right?

I have to try that combination... Please, allow for a few hours and I'll
post the results.

2003-06-09 21:13:57

by Diego Calleja

[permalink] [raw]
Subject: Re: 2.5.70-mm6

On Mon, 9 Jun 2003 19:45:58 +0200 (CEST)
Maciej Soltysiak <[email protected]> wrote:

> The interactivity seems to have dropped. Again, with common desktop
> applications: xmms playing with ALSA, when choosing navigating through
> evolution options or browsing with opera, music skipps.
> X is running with nice -10, but with mm5 it ran smoothly.

Under "heavy" disk usage (when sylpheed finish merging the lkml
messages in the 92M lkml mail folder) X pointer stops moving
(say, 1/8 or 1/6 seconds, very noticeable, pointer stops, windows stop
redrawing, etc).

System is a dual p3 800; fs is ext3. This odd behaviour
seems to happen since the 2.5.69-mm9 ext3 locking changes.
(well i started testing 2.5.70-mm3 because i'm timid,
but never happened before in mm or mainline)

Sorry that i can't provide really useful information now ;(

2003-06-09 21:32:58

by Andrew Morton

[permalink] [raw]
Subject: Re: 2.5.70-mm6

Diego Calleja Garc?a <[email protected]> wrote:
>
> On Mon, 9 Jun 2003 19:45:58 +0200 (CEST)
> Maciej Soltysiak <[email protected]> wrote:
>
> > The interactivity seems to have dropped. Again, with common desktop
> > applications: xmms playing with ALSA, when choosing navigating through
> > evolution options or browsing with opera, music skipps.
> > X is running with nice -10, but with mm5 it ran smoothly.
>
> Under "heavy" disk usage (when sylpheed finish merging the lkml
> messages in the 92M lkml mail folder) X pointer stops moving
> (say, 1/8 or 1/6 seconds, very noticeable, pointer stops, windows stop
> redrawing, etc).

I've noticed similar. Just a new vague jerkiness.

> System is a dual p3 800; fs is ext3. This odd behaviour
> seems to happen since the 2.5.69-mm9 ext3 locking changes.
> (well i started testing 2.5.70-mm3 because i'm timid,
> but never happened before in mm or mainline)

Might be. There were some CPU scheduler changes a week before 2.5.69-mm9.
If it's in ext3 then profiling will probably shake it out. I haven't done
a lot of profiling yet.

2003-06-10 08:41:16

by Maciej Soltysiak

[permalink] [raw]
Subject: Re: 2.5.70-mm6

> How about one or the other of these two? (not both at once, though,
> they appear to clash).
Success, no audio skipps with galbraith.patch and mm6.

> -- wli
Maciej

2003-06-10 09:07:28

by William Lee Irwin III

[permalink] [raw]
Subject: Re: 2.5.70-mm6

At some point in the past, I wrote:
>> How about one or the other of these two? (not both at once, though,
>> they appear to clash).

On Tue, Jun 10, 2003 at 10:54:55AM +0200, Maciej Soltysiak wrote:
> Success, no audio skipps with galbraith.patch and mm6.

Mike, any chance you can turn your series of patches into one that
applies atop mingo's intra-timeslice priority preemption patch? If
not, I suppose someone else could.

There also appears to be some kind of issue with using monotonic_clock()
with timer_pit as well as some locking overhead concerns. Something
should probably be done about those things before trying to merge the
fine-grained time accounting patch.


-- wli

2003-06-10 09:42:58

by Felipe Alfaro Solana

[permalink] [raw]
Subject: Re: 2.5.70-mm6

On Mon, 2003-06-09 at 22:14, Martin J. Bligh wrote:
> --On Monday, June 09, 2003 22:08:42 +0200 Felipe Alfaro Solana <[email protected]> wrote:
>
> > On Mon, 2003-06-09 at 20:51, Martin J. Bligh wrote:
> >> >> If you don't nice the hell out of X, does it work OK?
> >> > No.
> >> >
> >> > The way I reproduce the sound skips:
> >> > run xmms, run evolution, compose a mail with gpg.
> >> > on mm6 the gpg part stops the sound for a few seconds. (with X -10 and 0)
> >> > on mm5 xmms plays without stops. (with X -10)
> >>
> >> Does this (from Ingo?) do anything useful to it?
> >
> > I can confirm that 2.5.70-mm6 with Ingo's patch and HZ set back to 1000
> > is nearly perfect (it still takes some seconds for the scheduler to
> > adjust dynamic priorities).
>
> OK ... sorry to be pedantic, but I want to nail this down.
> It's still broken with HZ=1000, but without Ingo's patch, right?

Well, Ingo's patch makes XMMS more resistant to audio skip when HZ=1000.
Anyways, with HZ=1000 interactivity is much better than with HZ=100
(with or without Ingo's patch).


2003-06-10 11:13:30

by Mike Galbraith

[permalink] [raw]
Subject: Re: 2.5.70-mm6

At 02:20 AM 6/10/2003 -0700, William Lee Irwin III wrote:
>At some point in the past, I wrote:
> >> How about one or the other of these two? (not both at once, though,
> >> they appear to clash).
>
>On Tue, Jun 10, 2003 at 10:54:55AM +0200, Maciej Soltysiak wrote:
> > Success, no audio skipps with galbraith.patch and mm6.

(victim of fast hw methinks. dog slow old isa card will probably work fine)

>Mike, any chance you can turn your series of patches into one that
>applies atop mingo's intra-timeslice priority preemption patch? If
>not, I suppose someone else could.

I've never seen it. Is this the test-starve fix I heard mentioned on lkml
once?

>There also appears to be some kind of issue with using monotonic_clock()
>with timer_pit as well as some locking overhead concerns. Something
>should probably be done about those things before trying to merge the
>fine-grained time accounting patch.

Ingo had me measure impact with lat_ctx, and it wasn't very encouraging
(and my box is UP). I'm not sure that I wasn't seeing some cache effects
though, because the numbers jumped around quite a bit. Per Ingo, the
sequence lock change will greatly improve scalability. Doing anything
extra in that path is going to cost some pain though, so I'm trying to
figure out a way to do something ~similar. (ala perfect is the enemy of
good mantra).

wrt pit, yeah, that diff won't work if you don't have a tsc. If something
like it were used, it'd have to have ifdefs to continue using
jiffies. (the other option being only presentable on April 1:)

-Mike

2003-06-10 11:28:01

by William Lee Irwin III

[permalink] [raw]
Subject: Re: 2.5.70-mm6

At 02:20 AM 6/10/2003 -0700, William Lee Irwin III wrote:
>> Mike, any chance you can turn your series of patches into one that
>> applies atop mingo's intra-timeslice priority preemption patch? If
>> not, I suppose someone else could.

On Tue, Jun 10, 2003 at 01:31:32PM +0200, Mike Galbraith wrote:
> I've never seen it. Is this the test-starve fix I heard mentioned on lkml
> once?

No idea what the posted name was. What it does is obvious enough. It
was posted earlier in this thread.


At 02:20 AM 6/10/2003 -0700, William Lee Irwin III wrote:
>> There also appears to be some kind of issue with using monotonic_clock()
>> with timer_pit as well as some locking overhead concerns. Something
>> should probably be done about those things before trying to merge the
>> fine-grained time accounting patch.

On Tue, Jun 10, 2003 at 01:31:32PM +0200, Mike Galbraith wrote:
> Ingo had me measure impact with lat_ctx, and it wasn't very encouraging
> (and my box is UP). I'm not sure that I wasn't seeing some cache effects
> though, because the numbers jumped around quite a bit. Per Ingo, the
> sequence lock change will greatly improve scalability. Doing anything
> extra in that path is going to cost some pain though, so I'm trying to

Okay, so mitigating the hit to context switch is ongoing.


On Tue, Jun 10, 2003 at 01:31:32PM +0200, Mike Galbraith wrote:
> figure out a way to do something ~similar. (ala perfect is the enemy of
> good mantra).

\vomit{Next you'll be telling me worse is better.}


On Tue, Jun 10, 2003 at 01:31:32PM +0200, Mike Galbraith wrote:
> wrt pit, yeah, that diff won't work if you don't have a tsc. If something
> like it were used, it'd have to have ifdefs to continue using
> jiffies. (the other option being only presentable on April 1:)

The issue is the driver returning garbage; not having as good of
precision from hardware is no fault of the method. I'd say timer_pit
should just return jiffies converted to nanoseconds.

Also, I posted the "thud" fix earlier in this thread in addition to the
monotonic_clock() bits. AFAICT it mitigates (or perhaps even fixes) an
infinite priority escalation scenario.


-- wli

2003-06-10 11:38:35

by Maciej Soltysiak

[permalink] [raw]
Subject: Re: 2.5.70-mm6

> How about one or the other of these two? (not both at once, though,
> they appear to clash).
2.5.70-mm7 seems not to cause mentioned problems.

Regards,
Maciej

Subject: Re: 2.5.70-mm6

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

It is not only ext3 problem, I've got this issue on reiserfs as well. It is
just coused by schleduer.
Anyway, 2.5.x is now slower than 2.4.21-rc7 about 25% on disc access as well !


- --
Grzegorz Jaskiewicz
K4 Labs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE+5cq9qu082fCQYIgRAj8FAJ9Rmo8q4VYLjrFt0zvtklw+MUFnPQCaA7VA
SzoDJgprNamOpz0qO+HXXKM=
=8FbC
-----END PGP SIGNATURE-----

2003-06-10 18:35:52

by Mike Galbraith

[permalink] [raw]
Subject: Re: 2.5.70-mm6

At 04:41 AM 6/10/2003 -0700, William Lee Irwin III wrote:
>At 02:20 AM 6/10/2003 -0700, William Lee Irwin III wrote:
> >> Mike, any chance you can turn your series of patches into one that
> >> applies atop mingo's intra-timeslice priority preemption patch? If
> >> not, I suppose someone else could.
>
>On Tue, Jun 10, 2003 at 01:31:32PM +0200, Mike Galbraith wrote:
> > I've never seen it. Is this the test-starve fix I heard mentioned on lkml
> > once?
>
>No idea what the posted name was. What it does is obvious enough. It
>was posted earlier in this thread.
>
>
>At 02:20 AM 6/10/2003 -0700, William Lee Irwin III wrote:
> >> There also appears to be some kind of issue with using monotonic_clock()
> >> with timer_pit as well as some locking overhead concerns. Something
> >> should probably be done about those things before trying to merge the
> >> fine-grained time accounting patch.
>
>On Tue, Jun 10, 2003 at 01:31:32PM +0200, Mike Galbraith wrote:
> > Ingo had me measure impact with lat_ctx, and it wasn't very encouraging
> > (and my box is UP). I'm not sure that I wasn't seeing some cache effects
> > though, because the numbers jumped around quite a bit. Per Ingo, the
> > sequence lock change will greatly improve scalability. Doing anything
> > extra in that path is going to cost some pain though, so I'm trying to
>
>Okay, so mitigating the hit to context switch is ongoing.

If it's used, seems some work will be required to measure the true (and
practical) impact.

>On Tue, Jun 10, 2003 at 01:31:32PM +0200, Mike Galbraith wrote:
> > figure out a way to do something ~similar. (ala perfect is the enemy of
> > good mantra).
>
>\vomit{Next you'll be telling me worse is better.}

That's an unearned criticism.

Timeslice management is currently an approximation. IFF the approximation
is good enough, it will/must out perform pedantic bean-counting. Current
timeslice management apparently isn't quite good enough, so I'm trying to
find a way to increase it's informational content without the (in general
case useless) overhead of attempted perfection. I'm failing miserably btw ;-)

>On Tue, Jun 10, 2003 at 01:31:32PM +0200, Mike Galbraith wrote:
> > wrt pit, yeah, that diff won't work if you don't have a tsc. If something
> > like it were used, it'd have to have ifdefs to continue using
> > jiffies. (the other option being only presentable on April 1:)
>
>The issue is the driver returning garbage; not having as good of
>precision from hardware is no fault of the method. I'd say timer_pit
>should just return jiffies converted to nanoseconds.

That's the option that I figured was April 1 material, because of the
missing precision. If it could be made (somehow that I don't understand)
to produce a reasonable approximation of a high resolution clock, sure.

>Also, I posted the "thud" fix earlier in this thread in addition to the
>monotonic_clock() bits. AFAICT it mitigates (or perhaps even fixes) an
>infinite priority escalation scenario.

(yes, mitigates... maybe cures with round down, not really sure)

Couple that change with reintroduction of backboost to offset some of it's
other effects and a serious reduction of CHILD_PENALTY and you'll have a
very snappy desktop. However, there is another side of the
equation. Large instantaneous variance in sleep_avg/prio also enables the
scheduler to react quickly such that tasks which were delayed for whatever
reason rapidly get a chance collect their ticks and catch up. It can and
does cause perceived unfairness... which is in reality quite fair. It's
horrible for short period concurrency, but great for long period
throughput. AFAIKT, it's a hard problem.

-Mike

2003-06-10 19:00:35

by William Lee Irwin III

[permalink] [raw]
Subject: Re: 2.5.70-mm6

At 04:41 AM 6/10/2003 -0700, William Lee Irwin III wrote:
>> \vomit{Next you'll be telling me worse is better.}

On Tue, Jun 10, 2003 at 08:53:51PM +0200, Mike Galbraith wrote:
> That's an unearned criticism.
> Timeslice management is currently an approximation. IFF the approximation
> is good enough, it will/must out perform pedantic bean-counting. Current
> timeslice management apparently isn't quite good enough, so I'm trying to
> find a way to increase it's informational content without the (in general
> case useless) overhead of attempted perfection. I'm failing miserably btw
> ;-)

The criticism was of the maxim invoked, not the specific direction
you're hacking in.


At 04:41 AM 6/10/2003 -0700, William Lee Irwin III wrote:
>> The issue is the driver returning garbage; not having as good of
>> precision from hardware is no fault of the method. I'd say timer_pit
>> should just return jiffies converted to nanoseconds.

On Tue, Jun 10, 2003 at 08:53:51PM +0200, Mike Galbraith wrote:
> That's the option that I figured was April 1 material, because of the
> missing precision. If it could be made (somehow that I don't understand)
> to produce a reasonable approximation of a high resolution clock, sure.

If there's a TSC, it can be used for extra interpolation. But I think
timer_tsc already does that. I don't think it's quite so laughable; the
machines missing reliable time sources are truly crippled in some way,
by obsolescence or misdesign. I wouldn't call this a deficit. The
major platforms will do fine, and the rest will do no worse than now
apart from perhaps some function call and arithmetic overhead.


At 04:41 AM 6/10/2003 -0700, William Lee Irwin III wrote:
>> Also, I posted the "thud" fix earlier in this thread in addition to the
>> monotonic_clock() bits. AFAICT it mitigates (or perhaps even fixes) an
>> infinite priority escalation scenario.

On Tue, Jun 10, 2003 at 08:53:51PM +0200, Mike Galbraith wrote:
> (yes, mitigates... maybe cures with round down, not really sure)
> Couple that change with reintroduction of backboost to offset some of it's
> other effects and a serious reduction of CHILD_PENALTY and you'll have a
> very snappy desktop. However, there is another side of the
> equation. Large instantaneous variance in sleep_avg/prio also enables the
> scheduler to react quickly such that tasks which were delayed for whatever
> reason rapidly get a chance collect their ticks and catch up. It can and
> does cause perceived unfairness... which is in reality quite fair. It's
> horrible for short period concurrency, but great for long period
> throughput. AFAIKT, it's a hard problem.

I don't know that there are answers better than mitigation.

I propose we err on the other side of the fence and back off as cases
where the larger instantaneous variances are more clearly needed arise.


-- wli

2003-06-11 02:02:29

by Mingming Cao

[permalink] [raw]
Subject: Re: 2.5.70-mm6

Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.5/2.5.70/2.5.70-mm6/
>

I run 50 fsx tests on ext3 filesystem on 2.5.70-mm6 kernel. Serveral fsx
tests hang with the status D, after the tests run for a while. No oops,
no error messages. I found same problem on mm5, but 2.5.70 is fine.

Here is the stack info:

fsx D C3496298 932 1 933 852 (NOTLB)
Call Trace:
[<c0109e2e>] apic_timer_interrupt+0x1a/0x20
[<c011c546>] io_schedule+0x26/0x30
[<c01386ac>] wait_on_page_bit_wq+0xcc/0x100
[<c011ddf0>] autoremove_wake_function+0x0/0x50
[<c011ddf0>] autoremove_wake_function+0x0/0x50
[<c0142815>] truncate_inode_pages+0x2e5/0x2f0
[<c014712b>] vmtruncate+0x6b/0x100
[<c0171e94>] inode_setattr+0x134/0x150
[<c0195aca>] ext3_setattr+0x7a/0x1a0
[<c0160f6e>] cp_new_stat64+0xfe/0x110
[<c0172080>] notify_change+0x160/0x19d
[<c0153f3a>] do_truncate+0x6a/0x90
[<c0161037>] sys_fstat64+0x37/0x40
[<c0154228>] sys_ftruncate+0x118/0x1b0
[<c01558f0>] generic_file_llseek+0x0/0xf0
[<c0155c29>] sys_lseek+0x69/0xb0
[<c010943f>] syscall_call+0x7/0xb

fsx D C0109E2E 933 1 934 932 (NOTLB)
Call Trace:
[<c0109e2e>] apic_timer_interrupt+0x1a/0x20
[<c02b04f3>] generic_unplug_device+0x23/0x70
[<c011c546>] io_schedule+0x26/0x30
[<c01386ac>] wait_on_page_bit_wq+0xcc/0x100
[<c011ddf0>] autoremove_wake_function+0x0/0x50
[<c011ddf0>] autoremove_wake_function+0x0/0x50
[<c0142815>] truncate_inode_pages+0x2e5/0x2f0
[<c014712b>] vmtruncate+0x6b/0x100
[<c0171e94>] inode_setattr+0x134/0x150
[<c0195aca>] ext3_setattr+0x7a/0x1a0
[<c0160f6e>] cp_new_stat64+0xfe/0x110
[<c0172080>] notify_change+0x160/0x19d
[<c0153f3a>] do_truncate+0x6a/0x90
[<c0161037>] sys_fstat64+0x37/0x40
[<c0154228>] sys_ftruncate+0x118/0x1b0
[<c01558f0>] generic_file_llseek+0x0/0xf0
[<c0155c29>] sys_lseek+0x69/0xb0
[<c010943f>] syscall_call+0x7/0xb

fsx D F6A43DA8 934 1 935 933 (NOTLB)
Call Trace:
[<c0109e2e>] apic_timer_interrupt+0x1a/0x20
[<c011c546>] io_schedule+0x26/0x30
[<c01386ac>] wait_on_page_bit_wq+0xcc/0x100
[<c011ddf0>] autoremove_wake_function+0x0/0x50
[<c011ddf0>] autoremove_wake_function+0x0/0x50
[<c0142815>] truncate_inode_pages+0x2e5/0x2f0
[<c014712b>] vmtruncate+0x6b/0x100
[<c0171e94>] inode_setattr+0x134/0x150
[<c0195aca>] ext3_setattr+0x7a/0x1a0
[<c0160f6e>] cp_new_stat64+0xfe/0x110
[<c0172080>] notify_change+0x160/0x19d
[<c0153f3a>] do_truncate+0x6a/0x90
[<c0161037>] sys_fstat64+0x37/0x40
[<c0154228>] sys_ftruncate+0x118/0x1b0
[<c01558f0>] generic_file_llseek+0x0/0xf0
[<c0155c29>] sys_lseek+0x69/0xb0
[<c010943f>] syscall_call+0x7/0xb

fsx D F7B55A00 935 1 936 934 (NOTLB)
Call Trace:
[<c02aea96>] elv_next_request+0x16/0x100
[<c02b052a>] generic_unplug_device+0x5a/0x70
[<c011c546>] io_schedule+0x26/0x30
[<c01386ac>] wait_on_page_bit_wq+0xcc/0x100
[<c011ddf0>] autoremove_wake_function+0x0/0x50
[<c011ddf0>] autoremove_wake_function+0x0/0x50
[<c0142815>] truncate_inode_pages+0x2e5/0x2f0
[<c014712b>] vmtruncate+0x6b/0x100
[<c0171e94>] inode_setattr+0x134/0x150
[<c0195aca>] ext3_setattr+0x7a/0x1a0
[<c0160f6e>] cp_new_stat64+0xfe/0x110
[<c0172080>] notify_change+0x160/0x19d
[<c0153f3a>] do_truncate+0x6a/0x90
[<c0161037>] sys_fstat64+0x37/0x40
[<c0154228>] sys_ftruncate+0x118/0x1b0
[<c01558f0>] generic_file_llseek+0x0/0xf0
[<c0155c29>] sys_lseek+0x69/0xb0
[<c010943f>] syscall_call+0x7/0xb

fsx D F6A1E000 936 1 937 935 (NOTLB)
Call Trace:
[<c011bcc0>] schedule+0x280/0x4f0
[<c011c546>] io_schedule+0x26/0x30
[<c01386ac>] wait_on_page_bit_wq+0xcc/0x100
[<c011ddf0>] autoremove_wake_function+0x0/0x50
[<c011ddf0>] autoremove_wake_function+0x0/0x50
[<c0142815>] truncate_inode_pages+0x2e5/0x2f0
[<c014712b>] vmtruncate+0x6b/0x100
[<c0171e94>] inode_setattr+0x134/0x150
[<c0195aca>] ext3_setattr+0x7a/0x1a0
[<c0160f6e>] cp_new_stat64+0xfe/0x110
[<c0172080>] notify_change+0x160/0x19d
[<c0153f3a>] do_truncate+0x6a/0x90
[<c0161037>] sys_fstat64+0x37/0x40
[<c0154228>] sys_ftruncate+0x118/0x1b0
[<c01558f0>] generic_file_llseek+0x0/0xf0
[<c0155c29>] sys_lseek+0x69/0xb0
[<c010943f>] syscall_call+0x7/0xb

fsx D F6A1DDA8 937 1 938 936 (NOTLB)
Call Trace:
[<c0109e2e>] apic_timer_interrupt+0x1a/0x20
[<c011c546>] io_schedule+0x26/0x30
[<c01386ac>] wait_on_page_bit_wq+0xcc/0x100
[<c011ddf0>] autoremove_wake_function+0x0/0x50
[<c011ddf0>] autoremove_wake_function+0x0/0x50
[<c0142815>] truncate_inode_pages+0x2e5/0x2f0
[<c014712b>] vmtruncate+0x6b/0x100
[<c0171e94>] inode_setattr+0x134/0x150
[<c0195aca>] ext3_setattr+0x7a/0x1a0
[<c0160f6e>] cp_new_stat64+0xfe/0x110
[<c0172080>] notify_change+0x160/0x19d
[<c0153f3a>] do_truncate+0x6a/0x90
[<c0161037>] sys_fstat64+0x37/0x40
[<c0154228>] sys_ftruncate+0x118/0x1b0
[<c01558f0>] generic_file_llseek+0x0/0xf0
[<c0155c29>] sys_lseek+0x69/0xb0
[<c010943f>] syscall_call+0x7/0xb

fsx D 00000001 938 1 939 937 (NOTLB)
Call Trace:
[<c011c546>] io_schedule+0x26/0x30
[<c0157565>] __wait_on_buffer_wq+0xf5/0x100
[<c011ddf0>] autoremove_wake_function+0x0/0x50
[<c011ddf0>] autoremove_wake_function+0x0/0x50
[<c0157587>] __wait_on_buffer+0x17/0x20
[<c01a3018>] journal_invalidatepage+0x88/0x130
[<c0193e93>] ext3_invalidatepage+0x43/0x50
[<c01423e7>] do_invalidatepage+0x27/0x30
[<c014247e>] truncate_complete_page+0x8e/0x90
[<c0142604>] truncate_inode_pages+0xd4/0x2f0
[<c014712b>] vmtruncate+0x6b/0x100
[<c0171e94>] inode_setattr+0x134/0x150
[<c0195aca>] ext3_setattr+0x7a/0x1a0
[<c0160f6e>] cp_new_stat64+0xfe/0x110
[<c0172080>] notify_change+0x160/0x19d
[<c0153f3a>] do_truncate+0x6a/0x90
[<c0161037>] sys_fstat64+0x37/0x40
[<c0154228>] sys_ftruncate+0x118/0x1b0
[<c01558f0>] generic_file_llseek+0x0/0xf0
[<c0155c29>] sys_lseek+0x69/0xb0
[<c010943f>] syscall_call+0x7/0xb

fsx D C0109E2E 939 1 940 938 (NOTLB)
Call Trace:
[<c0109e2e>] apic_timer_interrupt+0x1a/0x20
[<c011c546>] io_schedule+0x26/0x30
[<c01386ac>] wait_on_page_bit_wq+0xcc/0x100
[<c011ddf0>] autoremove_wake_function+0x0/0x50
[<c011ddf0>] autoremove_wake_function+0x0/0x50
[<c0142815>] truncate_inode_pages+0x2e5/0x2f0
[<c014712b>] vmtruncate+0x6b/0x100
[<c0171e94>] inode_setattr+0x134/0x150
[<c0195aca>] ext3_setattr+0x7a/0x1a0
[<c0160f6e>] cp_new_stat64+0xfe/0x110
[<c0172080>] notify_change+0x160/0x19d
[<c0153f3a>] do_truncate+0x6a/0x90
[<c0161037>] sys_fstat64+0x37/0x40
[<c0154228>] sys_ftruncate+0x118/0x1b0
[<c01558f0>] generic_file_llseek+0x0/0xf0
[<c0155c29>] sys_lseek+0x69/0xb0
[<c010943f>] syscall_call+0x7/0xb

fsx D 00000001 940 1 941 939 (NOTLB)
Call Trace:
[<c011c546>] io_schedule+0x26/0x30
[<c0157565>] __wait_on_buffer_wq+0xf5/0x100
[<c011ddf0>] autoremove_wake_function+0x0/0x50
[<c011ddf0>] autoremove_wake_function+0x0/0x50
[<c0157587>] __wait_on_buffer+0x17/0x20
[<c01a3018>] journal_invalidatepage+0x88/0x130
[<c0193e93>] ext3_invalidatepage+0x43/0x50
[<c01423e7>] do_invalidatepage+0x27/0x30
[<c014247e>] truncate_complete_page+0x8e/0x90
[<c0142604>] truncate_inode_pages+0xd4/0x2f0
[<c014712b>] vmtruncate+0x6b/0x100
[<c0171e94>] inode_setattr+0x134/0x150
[<c0195aca>] ext3_setattr+0x7a/0x1a0
[<c0160f6e>] cp_new_stat64+0xfe/0x110
[<c0172080>] notify_change+0x160/0x19d
[<c0153f3a>] do_truncate+0x6a/0x90
[<c0161037>] sys_fstat64+0x37/0x40
[<c0154228>] sys_ftruncate+0x118/0x1b0
[<c01558f0>] generic_file_llseek+0x0/0xf0
[<c0155c29>] sys_lseek+0x69/0xb0
[<c010943f>] syscall_call+0x7/0xb

fsx D 00000001 941 1 940 (NOTLB)
Call Trace:
[<c011c546>] io_schedule+0x26/0x30
[<c0157565>] __wait_on_buffer_wq+0xf5/0x100
[<c011ddf0>] autoremove_wake_function+0x0/0x50
[<c015af00>] submit_bh+0x90/0x1e0
[<c011ddf0>] autoremove_wake_function+0x0/0x50
[<c02b1cc4>] submit_bio+0x54/0xa0
[<c0158acd>] __bread_slow_wq+0xad/0xf0
[<c0158db6>] __bread+0x46/0x50
[<c018eb98>] read_block_bitmap+0x58/0xa0
[<c018f902>] ext3_new_block+0x1a2/0x590
[<c0158c73>] __find_get_block+0x73/0x100
[<c01922f7>] ext3_alloc_block+0x37/0x40
[<c01926ba>] ext3_alloc_branch+0x4a/0x2c0
[<c01924c2>] ext3_get_branch+0x72/0x100
[<c0192cbc>] ext3_get_block_handle+0x18c/0x360
[<c015b501>] alloc_buffer_head+0x41/0x50
[<c0192ef4>] ext3_get_block+0x64/0xb0
[<c0159827>] __block_prepare_write+0x227/0x4b0
[<c015a364>] block_prepare_write+0x34/0x50
[<c0192e90>] ext3_get_block+0x0/0xb0
[<c01934d1>] ext3_prepare_write+0x71/0x130
[<c0192e90>] ext3_get_block+0x0/0xb0
[<c013a5cd>] generic_file_aio_write_nolock+0x38d/0xa50
[<c0195808>] ext3_do_update_inode+0x1c8/0x3d0
[<c0158d97>] __bread+0x27/0x50
[<c01951f3>] ext3_get_inode_loc+0x103/0x1a0
[<c013adee>] generic_file_aio_write+0x9e/0x120
[<c0190bf4>] ext3_file_write+0x44/0xe0
[<c0156046>] do_sync_write+0xb6/0xf0
[<c0177a56>] __mark_inode_dirty+0xf6/0x100
[<c0160f6e>] cp_new_stat64+0xfe/0x110
[<c011ddf0>] autoremove_wake_function+0x0/0x50
[<c0127cb6>] update_wall_time+0x16/0x40
[<c01280f0>] do_timer+0xc0/0xd0
[<c015613e>] vfs_write+0xbe/0x130
[<c01558f0>] generic_file_llseek+0x0/0xf0
[<c0156262>] sys_write+0x42/0x70
[<c010943f>] syscall_call+0x7/0xb


2003-06-11 02:58:17

by Andrew Morton

[permalink] [raw]
Subject: Re: 2.5.70-mm6

Mingming Cao <[email protected]> wrote:
>
> I run 50 fsx tests on ext3 filesystem on 2.5.70-mm6 kernel. Serveral fsx
> tests hang with the status D, after the tests run for a while. No oops,
> no error messages. I found same problem on mm5, but 2.5.70 is fine.
>
> Here is the stack info:

Thanks for this.

Everything is waiting on I/O. It looks like either the device driver
failed or the IO scheduler got its state all screwed up.

Which device driver are you using there?

If you could, please retest with "elevator=deadline"?


2003-06-11 22:01:38

by Mingming Cao

[permalink] [raw]
Subject: Re: 2.5.70-mm6

On Tue, 2003-06-10 at 20:12, Andrew Morton wrote:
> Mingming Cao <[email protected]> wrote:
> >
> > I run 50 fsx tests on ext3 filesystem on 2.5.70-mm6 kernel. Serveral fsx
> > tests hang with the status D, after the tests run for a while. No oops,
> > no error messages. I found same problem on mm5, but 2.5.70 is fine.
> >
> > Here is the stack info:
>
> Thanks for this.
>
> Everything is waiting on I/O. It looks like either the device driver
> failed or the IO scheduler got its state all screwed up.
>
> Which device driver are you using there?

I am usering Qlogic qla2xxx V8 driver
>
> If you could, please retest with "elevator=deadline"?
>
Sure.

And I saw sysrq on 2.5.70-mm6 failed on my test machine, 2.5.70-mm5
works. I could trigger sysrq by send"t", but the stack info for all
threads are the same ---the stack info of the sysrq itself.


2003-06-12 16:54:21

by Mingming Cao

[permalink] [raw]
Subject: Re: 2.5.70-mm6


> Mingming Cao <[email protected]> wrote:
> >
> > I run 50 fsx tests on ext3 filesystem on 2.5.70-mm6 kernel. Serveral fsx
> > tests hang with the status D, after the tests run for a while. No oops,
> > no error messages. I found same problem on mm5, but 2.5.70 is fine.
Sorry, the tests in 2.5.70 also failed, same problem.

On Tue, 2003-06-10 at 20:12, Andrew Morton wrote
> If you could, please retest with "elevator=deadline"?
>
Thanks for your feedback.

This time I got more fsx tests hang(about 25). Before normally I saw 5
or 10 tests fail. Here is the stack info.

kjournald D 00000001 849 1 900 847 (L-TLB)
Call Trace:
[<c011c546>] io_schedule+0x26/0x30
[<c0157565>] __wait_on_buffer_wq+0xf5/0x100
[<c011ddf0>] autoremove_wake_function+0x0/0x50
[<c011ddf0>] autoremove_wake_function+0x0/0x50
[<c015b14c>] sync_dirty_buffer+0x6c/0xd0
[<c0157587>] __wait_on_buffer+0x17/0x20
[<c01a43b7>] journal_commit_transaction+0xbf7/0x122b
[<c011ddf0>] autoremove_wake_function+0x0/0x50
[<c011ddf0>] autoremove_wake_function+0x0/0x50
[<c011bc47>] schedule+0x207/0x4f0
[<c01a7246>] kjournald+0x236/0x260
[<c011ddf0>] autoremove_wake_function+0x0/0x50
[<c011ddf0>] autoremove_wake_function+0x0/0x50
[<c0109352>] ret_from_fork+0x6/0x14
[<c01a6ff0>] commit_timeout+0x0/0x10
[<c01a7010>] kjournald+0x0/0x260
[<c010722d>] kernel_thread_helper+0x5/0x18

fsx D 00000001 900 1 901 849 (NOTLB)
Call Trace:
[<c01a1862>] do_get_write_access+0x522/0x680
[<c011bf30>] default_wake_function+0x0/0x30
[<c01951f3>] ext3_get_inode_loc+0x103/0x1a0
[<c01a19f9>] journal_get_write_access+0x39/0x60
[<c0195d46>] ext3_reserve_inode_write+0x86/0xe0
[<c0195dcb>] ext3_mark_inode_dirty+0x2b/0x60
[<c0195e8c>] ext3_dirty_inode+0x8c/0x90
[<c0177a56>] __mark_inode_dirty+0xf6/0x100
[<c0171680>] inode_update_time+0x80/0xb0
[<c013a455>] generic_file_aio_write_nolock+0x215/0xa50
[<c0195808>] ext3_do_update_inode+0x1c8/0x3d0
[<c0158d97>] __bread+0x27/0x50
[<c01951f3>] ext3_get_inode_loc+0x103/0x1a0
[<c013adee>] generic_file_aio_write+0x9e/0x120
[<c0190bf4>] ext3_file_write+0x44/0xe0
[<c0156046>] do_sync_write+0xb6/0xf0
[<c0177a56>] __mark_inode_dirty+0xf6/0x100
[<c0160f6e>] cp_new_stat64+0xfe/0x110
[<c011ddf0>] autoremove_wake_function+0x0/0x50
[<c011b7ee>] scheduler_tick+0x16e/0x3b0
[<c015613e>] vfs_write+0xbe/0x130
[<c01558f0>] generic_file_llseek+0x0/0xf0
[<c0156262>] sys_write+0x42/0x70
[<c010943f>] syscall_call+0x7/0xb

fsx D C3812E48 901 1 902 900 (NOTLB)
Call Trace:
[<c0109e2e>] apic_timer_interrupt+0x1a/0x20
[<c015b390>] block_sync_page+0x0/0x10
[<c011c546>] io_schedule+0x26/0x30
[<c01386ac>] wait_on_page_bit_wq+0xcc/0x100
[<c011ddf0>] autoremove_wake_function+0x0/0x50
[<c011ddf0>] autoremove_wake_function+0x0/0x50
[<c0142815>] truncate_inode_pages+0x2e5/0x2f0
[<c014712b>] vmtruncate+0x6b/0x100
[<c0171e94>] inode_setattr+0x134/0x150
[<c0195aca>] ext3_setattr+0x7a/0x1a0
[<c0160f6e>] cp_new_stat64+0xfe/0x110
[<c0172080>] notify_change+0x160/0x19d
[<c0153f3a>] do_truncate+0x6a/0x90
[<c0161037>] sys_fstat64+0x37/0x40
[<c0154228>] sys_ftruncate+0x118/0x1b0
[<c01558f0>] generic_file_llseek+0x0/0xf0
[<c0155c29>] sys_lseek+0x69/0xb0
[<c010943f>] syscall_call+0x7/0xb

fsx D 00000001 902 1 903 901 (NOTLB)
Call Trace:
[<c015b390>] block_sync_page+0x0/0x10
[<c011c546>] io_schedule+0x26/0x30
[<c01386ac>] wait_on_page_bit_wq+0xcc/0x100
[<c011ddf0>] autoremove_wake_function+0x0/0x50
[<c011ddf0>] autoremove_wake_function+0x0/0x50
[<c0142815>] truncate_inode_pages+0x2e5/0x2f0
[<c014712b>] vmtruncate+0x6b/0x100
[<c0171e94>] inode_setattr+0x134/0x150
[<c0195aca>] ext3_setattr+0x7a/0x1a0
[<c0160f6e>] cp_new_stat64+0xfe/0x110
[<c0172080>] notify_change+0x160/0x19d
[<c0153f3a>] do_truncate+0x6a/0x90
[<c0161037>] sys_fstat64+0x37/0x40
[<c0154228>] sys_ftruncate+0x118/0x1b0
[<c01558f0>] generic_file_llseek+0x0/0xf0
[<c0155c29>] sys_lseek+0x69/0xb0
[<c010943f>] syscall_call+0x7/0xb

fsx D 00000001 903 1 904 902 (NOTLB)
Call Trace:
[<c011c546>] io_schedule+0x26/0x30
[<c0157565>] __wait_on_buffer_wq+0xf5/0x100
[<c011ddf0>] autoremove_wake_function+0x0/0x50
[<c015af00>] submit_bh+0x90/0x1e0
[<c011ddf0>] autoremove_wake_function+0x0/0x50
[<c02b1cc4>] submit_bio+0x54/0xa0
[<c0158acd>] __bread_slow_wq+0xad/0xf0
[<c0158db6>] __bread+0x46/0x50
[<c018eb98>] read_block_bitmap+0x58/0xa0
[<c018f902>] ext3_new_block+0x1a2/0x590
[<c0158c73>] __find_get_block+0x73/0x100
[<c01922f7>] ext3_alloc_block+0x37/0x40
[<c01926ba>] ext3_alloc_branch+0x4a/0x2c0
[<c01924c2>] ext3_get_branch+0x72/0x100
[<c0192cbc>] ext3_get_block_handle+0x18c/0x360
[<c015b501>] alloc_buffer_head+0x41/0x50
[<c0192ef4>] ext3_get_block+0x64/0xb0
[<c0159827>] __block_prepare_write+0x227/0x4b0
[<c015a364>] block_prepare_write+0x34/0x50
[<c0192e90>] ext3_get_block+0x0/0xb0
[<c01934d1>] ext3_prepare_write+0x71/0x130
[<c0192e90>] ext3_get_block+0x0/0xb0
[<c013a5cd>] generic_file_aio_write_nolock+0x38d/0xa50
[<c0195808>] ext3_do_update_inode+0x1c8/0x3d0
[<c01715a2>] update_atime+0x92/0xf0
[<c01393d4>] __generic_file_aio_read+0x1c4/0x210
[<c013adee>] generic_file_aio_write+0x9e/0x120
[<c0190bf4>] ext3_file_write+0x44/0xe0
[<c0156046>] do_sync_write+0xb6/0xf0
[<c0177a56>] __mark_inode_dirty+0xf6/0x100
[<c0160f6e>] cp_new_stat64+0xfe/0x110
[<c011ddf0>] autoremove_wake_function+0x0/0x50
[<c0161037>] sys_fstat64+0x37/0x40
[<c015613e>] vfs_write+0xbe/0x130
[<c01558f0>] generic_file_llseek+0x0/0xf0
[<c0156262>] sys_write+0x42/0x70
[<c010943f>] syscall_call+0x7/0xb

fsx D 00000001 904 1 925 903 (NOTLB)
Call Trace:
[<c0109e2e>] apic_timer_interrupt+0x1a/0x20
[<c011c546>] io_schedule+0x26/0x30
[<c01386ac>] wait_on_page_bit_wq+0xcc/0x100
[<c011ddf0>] autoremove_wake_function+0x0/0x50
[<c0138be6>] find_get_pages+0x36/0x60
[<c011ddf0>] autoremove_wake_function+0x0/0x50
[<c014230e>] pagevec_lookup+0x2e/0x40
[<c01426fc>] truncate_inode_pages+0x1cc/0x2f0
[<c014712b>] vmtruncate+0x6b/0x100
[<c0171e94>] inode_setattr+0x134/0x150
[<c0195aca>] ext3_setattr+0x7a/0x1a0
[<c0160f6e>] cp_new_stat64+0xfe/0x110
[<c0172080>] notify_change+0x160/0x19d
[<c0153f3a>] do_truncate+0x6a/0x90
[<c0161037>] sys_fstat64+0x37/0x40
[<c0154228>] sys_ftruncate+0x118/0x1b0
[<c01558f0>] generic_file_llseek+0x0/0xf0
[<c0155c29>] sys_lseek+0x69/0xb0
[<c010943f>] syscall_call+0x7/0xb

fsx D EF963DD4 925 1 926 904 (NOTLB)
Call Trace:
[<c02b0537>] generic_unplug_device+0x67/0x70
[<c011c546>] io_schedule+0x26/0x30
[<c01386ac>] wait_on_page_bit_wq+0xcc/0x100
[<c011ddf0>] autoremove_wake_function+0x0/0x50
[<c011ddf0>] autoremove_wake_function+0x0/0x50
[<c0142815>] truncate_inode_pages+0x2e5/0x2f0
[<c014712b>] vmtruncate+0x6b/0x100
[<c0171e94>] inode_setattr+0x134/0x150
[<c0195aca>] ext3_setattr+0x7a/0x1a0
[<c0160f6e>] cp_new_stat64+0xfe/0x110
[<c0172080>] notify_change+0x160/0x19d
[<c0153f3a>] do_truncate+0x6a/0x90
[<c0161037>] sys_fstat64+0x37/0x40
[<c0154228>] sys_ftruncate+0x118/0x1b0
[<c01558f0>] generic_file_llseek+0x0/0xf0
[<c0155c29>] sys_lseek+0x69/0xb0
[<c010943f>] syscall_call+0x7/0xb

fsx D C3810004 926 1 927 925 (NOTLB)
Call Trace:
[<c0109e2e>] apic_timer_interrupt+0x1a/0x20
[<c015b390>] block_sync_page+0x0/0x10
[<c011c546>] io_schedule+0x26/0x30
[<c01386ac>] wait_on_page_bit_wq+0xcc/0x100
[<c011ddf0>] autoremove_wake_function+0x0/0x50
[<c011ddf0>] autoremove_wake_function+0x0/0x50
[<c0142815>] truncate_inode_pages+0x2e5/0x2f0
[<c014712b>] vmtruncate+0x6b/0x100
[<c0171e94>] inode_setattr+0x134/0x150
[<c0195aca>] ext3_setattr+0x7a/0x1a0
[<c0160f6e>] cp_new_stat64+0xfe/0x110
[<c0172080>] notify_change+0x160/0x19d
[<c0153f3a>] do_truncate+0x6a/0x90
[<c0161037>] sys_fstat64+0x37/0x40
[<c0154228>] sys_ftruncate+0x118/0x1b0
[<c01558f0>] generic_file_llseek+0x0/0xf0
[<c0155c29>] sys_lseek+0x69/0xb0
[<c010943f>] syscall_call+0x7/0xb

fsx D EF95FDA8 927 1 928 926 (NOTLB)
Call Trace:
[<c0109e2e>] apic_timer_interrupt+0x1a/0x20
[<c011c546>] io_schedule+0x26/0x30
[<c01386ac>] wait_on_page_bit_wq+0xcc/0x100
[<c011ddf0>] autoremove_wake_function+0x0/0x50
[<c0138be6>] find_get_pages+0x36/0x60
[<c011ddf0>] autoremove_wake_function+0x0/0x50
[<c014230e>] pagevec_lookup+0x2e/0x40
[<c01426fc>] truncate_inode_pages+0x1cc/0x2f0
[<c014712b>] vmtruncate+0x6b/0x100
[<c0171e94>] inode_setattr+0x134/0x150
[<c0195aca>] ext3_setattr+0x7a/0x1a0
[<c0160f6e>] cp_new_stat64+0xfe/0x110
[<c0172080>] notify_change+0x160/0x19d
[<c0153f3a>] do_truncate+0x6a/0x90
[<c0161037>] sys_fstat64+0x37/0x40
[<c0154228>] sys_ftruncate+0x118/0x1b0
[<c01558f0>] generic_file_llseek+0x0/0xf0
[<c0155c29>] sys_lseek+0x69/0xb0
[<c010943f>] syscall_call+0x7/0xb

fsx D 00000001 928 1 929 927 (NOTLB)
Call Trace:
[<c011c546>] io_schedule+0x26/0x30
[<c0157565>] __wait_on_buffer_wq+0xf5/0x100
[<c011ddf0>] autoremove_wake_function+0x0/0x50
[<c015af00>] submit_bh+0x90/0x1e0
[<c011ddf0>] autoremove_wake_function+0x0/0x50
[<c02b1cc4>] submit_bio+0x54/0xa0
[<c0158acd>] __bread_slow_wq+0xad/0xf0
[<c0158db6>] __bread+0x46/0x50
[<c018eb98>] read_block_bitmap+0x58/0xa0
[<c018f902>] ext3_new_block+0x1a2/0x590
[<c0158c73>] __find_get_block+0x73/0x100
[<c01922f7>] ext3_alloc_block+0x37/0x40
[<c01926ba>] ext3_alloc_branch+0x4a/0x2c0
[<c01924c2>] ext3_get_branch+0x72/0x100
[<c0192cbc>] ext3_get_block_handle+0x18c/0x360
[<c015b501>] alloc_buffer_head+0x41/0x50
[<c0192ef4>] ext3_get_block+0x64/0xb0
[<c0159827>] __block_prepare_write+0x227/0x4b0
[<c015a364>] block_prepare_write+0x34/0x50
[<c0192e90>] ext3_get_block+0x0/0xb0
[<c01934d1>] ext3_prepare_write+0x71/0x130
[<c0192e90>] ext3_get_block+0x0/0xb0
[<c013a5cd>] generic_file_aio_write_nolock+0x38d/0xa50
[<c011bf9a>] __wake_up_common+0x3a/0x60
[<c0158d97>] __bread+0x27/0x50
[<c01951f3>] ext3_get_inode_loc+0x103/0x1a0
[<c013adee>] generic_file_aio_write+0x9e/0x120
[<c0190bf4>] ext3_file_write+0x44/0xe0
[<c0156046>] do_sync_write+0xb6/0xf0
[<c0177a56>] __mark_inode_dirty+0xf6/0x100
[<c0160f6e>] cp_new_stat64+0xfe/0x110
[<c011ddf0>] autoremove_wake_function+0x0/0x50
[<c0161037>] sys_fstat64+0x37/0x40
[<c015613e>] vfs_write+0xbe/0x130
[<c01558f0>] generic_file_llseek+0x0/0xf0
[<c0156262>] sys_write+0x42/0x70
[<c010943f>] syscall_call+0x7/0xb

fsx D 00000001 929 1 935 928 (NOTLB)
Call Trace:
[<c01a1862>] do_get_write_access+0x522/0x680
[<c011bf30>] default_wake_function+0x0/0x30
[<c0158c73>] __find_get_block+0x73/0x100
[<c01a19f9>] journal_get_write_access+0x39/0x60
[<c0194879>] ext3_free_data+0x39/0x150
[<c0194a7d>] ext3_free_branches+0xed/0x280
[<c019508e>] ext3_truncate+0x47e/0x4e0
[<c014703c>] invalidate_mmap_range+0x7c/0x100
[<c0194c10>] ext3_truncate+0x0/0x4e0
[<c014714c>] vmtruncate+0x8c/0x100
[<c0171e94>] inode_setattr+0x134/0x150
[<c0195aca>] ext3_setattr+0x7a/0x1a0
[<c0160f6e>] cp_new_stat64+0xfe/0x110
[<c0172080>] notify_change+0x160/0x19d
[<c0153f3a>] do_truncate+0x6a/0x90
[<c0161037>] sys_fstat64+0x37/0x40
[<c0154228>] sys_ftruncate+0x118/0x1b0
[<c010943f>] syscall_call+0x7/0xb

fsx D 00000001 935 1 936 929 (NOTLB)
Call Trace:
[<c02b0537>] generic_unplug_device+0x67/0x70
[<c011c546>] io_schedule+0x26/0x30
[<c01386ac>] wait_on_page_bit_wq+0xcc/0x100
[<c011ddf0>] autoremove_wake_function+0x0/0x50
[<c0138be6>] find_get_pages+0x36/0x60
[<c011ddf0>] autoremove_wake_function+0x0/0x50
[<c014230e>] pagevec_lookup+0x2e/0x40
[<c01426fc>] truncate_inode_pages+0x1cc/0x2f0
[<c014712b>] vmtruncate+0x6b/0x100
[<c0171e94>] inode_setattr+0x134/0x150
[<c0195aca>] ext3_setattr+0x7a/0x1a0
[<c0160f6e>] cp_new_stat64+0xfe/0x110
[<c0172080>] notify_change+0x160/0x19d
[<c0153f3a>] do_truncate+0x6a/0x90
[<c0161037>] sys_fstat64+0x37/0x40
[<c0154228>] sys_ftruncate+0x118/0x1b0
[<c01558f0>] generic_file_llseek+0x0/0xf0
[<c0155c29>] sys_lseek+0x69/0xb0
[<c010943f>] syscall_call+0x7/0xb

fsx D EF8FBDD4 936 1 937 935 (NOTLB)
Call Trace:
[<c0109e2e>] apic_timer_interrupt+0x1a/0x20
[<c02b007b>] ll_front_merge_fn+0x4b/0x120
[<c011c546>] io_schedule+0x26/0x30
[<c01386ac>] wait_on_page_bit_wq+0xcc/0x100
[<c011ddf0>] autoremove_wake_function+0x0/0x50
[<c011ddf0>] autoremove_wake_function+0x0/0x50
[<c0142815>] truncate_inode_pages+0x2e5/0x2f0
[<c014712b>] vmtruncate+0x6b/0x100
[<c0171e94>] inode_setattr+0x134/0x150
[<c0195aca>] ext3_setattr+0x7a/0x1a0
[<c0160f6e>] cp_new_stat64+0xfe/0x110
[<c0172080>] notify_change+0x160/0x19d
[<c0153f3a>] do_truncate+0x6a/0x90
[<c0161037>] sys_fstat64+0x37/0x40
[<c0154228>] sys_ftruncate+0x118/0x1b0
[<c01558f0>] generic_file_llseek+0x0/0xf0
[<c0155c29>] sys_lseek+0x69/0xb0
[<c010943f>] syscall_call+0x7/0xb

fsx D 00000001 937 1 938 936 (NOTLB)
Call Trace:
[<c011c546>] io_schedule+0x26/0x30
[<c01386ac>] wait_on_page_bit_wq+0xcc/0x100
[<c011ddf0>] autoremove_wake_function+0x0/0x50
[<c0138be6>] find_get_pages+0x36/0x60
[<c011ddf0>] autoremove_wake_function+0x0/0x50
[<c014230e>] pagevec_lookup+0x2e/0x40
[<c01426fc>] truncate_inode_pages+0x1cc/0x2f0
[<c014712b>] vmtruncate+0x6b/0x100
[<c0171e94>] inode_setattr+0x134/0x150
[<c0195aca>] ext3_setattr+0x7a/0x1a0
[<c0160f6e>] cp_new_stat64+0xfe/0x110
[<c0172080>] notify_change+0x160/0x19d
[<c0153f3a>] do_truncate+0x6a/0x90
[<c0161037>] sys_fstat64+0x37/0x40
[<c0154228>] sys_ftruncate+0x118/0x1b0
[<c01558f0>] generic_file_llseek+0x0/0xf0
[<c0155c29>] sys_lseek+0x69/0xb0
[<c010943f>] syscall_call+0x7/0xb

fsx D 00000001 938 1 939 937 (NOTLB)
Call Trace:
[<c01a1862>] do_get_write_access+0x522/0x680
[<c011bf30>] default_wake_function+0x0/0x30
[<c01a19f9>] journal_get_write_access+0x39/0x60
[<c0194879>] ext3_free_data+0x39/0x150
[<c0194e9b>] ext3_truncate+0x28b/0x4e0
[<c014703c>] invalidate_mmap_range+0x7c/0x100
[<c0194c10>] ext3_truncate+0x0/0x4e0
[<c014714c>] vmtruncate+0x8c/0x100
[<c0171e94>] inode_setattr+0x134/0x150
[<c0195aca>] ext3_setattr+0x7a/0x1a0
[<c0160f6e>] cp_new_stat64+0xfe/0x110
[<c0172080>] notify_change+0x160/0x19d
[<c0153f3a>] do_truncate+0x6a/0x90
[<c0161037>] sys_fstat64+0x37/0x40
[<c0154228>] sys_ftruncate+0x118/0x1b0
[<c01558f0>] generic_file_llseek+0x0/0xf0
[<c0155c29>] sys_lseek+0x69/0xb0
[<c010943f>] syscall_call+0x7/0xb

fsx D 00000001 939 1 940 938 (NOTLB)
Call Trace:
[<c011c546>] io_schedule+0x26/0x30
[<c0157565>] __wait_on_buffer_wq+0xf5/0x100
[<c011ddf0>] autoremove_wake_function+0x0/0x50
[<c015af00>] submit_bh+0x90/0x1e0
[<c011ddf0>] autoremove_wake_function+0x0/0x50
[<c02b1cc4>] submit_bio+0x54/0xa0
[<c0158acd>] __bread_slow_wq+0xad/0xf0
[<c0158db6>] __bread+0x46/0x50
[<c018eb98>] read_block_bitmap+0x58/0xa0
[<c018f902>] ext3_new_block+0x1a2/0x590
[<c011bf9a>] __wake_up_common+0x3a/0x60
[<c01922f7>] ext3_alloc_block+0x37/0x40
[<c01926ba>] ext3_alloc_branch+0x4a/0x2c0
[<c0158bc9>] bh_lru_install+0xb9/0xf0
[<c0192cbc>] ext3_get_block_handle+0x18c/0x360
[<c015b501>] alloc_buffer_head+0x41/0x50
[<c0192ef4>] ext3_get_block+0x64/0xb0
[<c0159827>] __block_prepare_write+0x227/0x4b0
[<c015a364>] block_prepare_write+0x34/0x50
[<c0192e90>] ext3_get_block+0x0/0xb0
[<c01934d1>] ext3_prepare_write+0x71/0x130
[<c0192e90>] ext3_get_block+0x0/0xb0
[<c013a5cd>] generic_file_aio_write_nolock+0x38d/0xa50
[<c0195808>] ext3_do_update_inode+0x1c8/0x3d0
[<c011bf5a>] default_wake_function+0x2a/0x30
[<c011de17>] autoremove_wake_function+0x27/0x50
[<c011bf9a>] __wake_up_common+0x3a/0x60
[<c013adee>] generic_file_aio_write+0x9e/0x120
[<c0190bf4>] ext3_file_write+0x44/0xe0
[<c0156046>] do_sync_write+0xb6/0xf0
[<c02f689e>] scsi_put_command+0x6e/0x90
[<c02fb63e>] scsi_end_request+0xae/0xc0
[<c011ddf0>] autoremove_wake_function+0x0/0x50
[<c011bf9a>] __wake_up_common+0x3a/0x60
[<c03332b3>] qla2x00_intr_handler+0x203/0x220
[<c015613e>] vfs_write+0xbe/0x130
[<c01558f0>] generic_file_llseek+0x0/0xf0
[<c0156262>] sys_write+0x42/0x70
[<c010943f>] syscall_call+0x7/0xb

fsx D 00000001 940 1 941 939 (NOTLB)
Call Trace:
[<c02b0537>] generic_unplug_device+0x67/0x70
[<c011c546>] io_schedule+0x26/0x30
[<c01386ac>] wait_on_page_bit_wq+0xcc/0x100
[<c011ddf0>] autoremove_wake_function+0x0/0x50
[<c0138be6>] find_get_pages+0x36/0x60
[<c011ddf0>] autoremove_wake_function+0x0/0x50
[<c014230e>] pagevec_lookup+0x2e/0x40
[<c01426fc>] truncate_inode_pages+0x1cc/0x2f0
[<c014712b>] vmtruncate+0x6b/0x100
[<c0171e94>] inode_setattr+0x134/0x150
[<c0195aca>] ext3_setattr+0x7a/0x1a0
[<c0160f6e>] cp_new_stat64+0xfe/0x110
[<c0172080>] notify_change+0x160/0x19d
[<c0153f3a>] do_truncate+0x6a/0x90
[<c0161037>] sys_fstat64+0x37/0x40
[<c0154228>] sys_ftruncate+0x118/0x1b0
[<c01558f0>] generic_file_llseek+0x0/0xf0
[<c0155c29>] sys_lseek+0x69/0xb0
[<c010943f>] syscall_call+0x7/0xb

fsx D C3815338 941 1 942 940 (NOTLB)
Call Trace:
[<c0109e2e>] apic_timer_interrupt+0x1a/0x20
[<c015b390>] block_sync_page+0x0/0x10
[<c011c546>] io_schedule+0x26/0x30
[<c01386ac>] wait_on_page_bit_wq+0xcc/0x100
[<c011ddf0>] autoremove_wake_function+0x0/0x50
[<c0138be6>] find_get_pages+0x36/0x60
[<c011ddf0>] autoremove_wake_function+0x0/0x50
[<c014230e>] pagevec_lookup+0x2e/0x40
[<c01426fc>] truncate_inode_pages+0x1cc/0x2f0
[<c014712b>] vmtruncate+0x6b/0x100
[<c0171e94>] inode_setattr+0x134/0x150
[<c0195aca>] ext3_setattr+0x7a/0x1a0
[<c0160f6e>] cp_new_stat64+0xfe/0x110
[<c0172080>] notify_change+0x160/0x19d
[<c0153f3a>] do_truncate+0x6a/0x90
[<c0161037>] sys_fstat64+0x37/0x40
[<c0154228>] sys_ftruncate+0x118/0x1b0
[<c01558f0>] generic_file_llseek+0x0/0xf0
[<c0155c29>] sys_lseek+0x69/0xb0
[<c010943f>] syscall_call+0x7/0xb

fsx D 00000001 942 1 943 941 (NOTLB)
Call Trace:
[<c0109e2e>] apic_timer_interrupt+0x1a/0x20
[<c011c546>] io_schedule+0x26/0x30
[<c01386ac>] wait_on_page_bit_wq+0xcc/0x100
[<c011ddf0>] autoremove_wake_function+0x0/0x50
[<c011ddf0>] autoremove_wake_function+0x0/0x50
[<c0142815>] truncate_inode_pages+0x2e5/0x2f0
[<c014712b>] vmtruncate+0x6b/0x100
[<c0171e94>] inode_setattr+0x134/0x150
[<c0195aca>] ext3_setattr+0x7a/0x1a0
[<c0160f6e>] cp_new_stat64+0xfe/0x110
[<c0172080>] notify_change+0x160/0x19d
[<c0153f3a>] do_truncate+0x6a/0x90
[<c0161037>] sys_fstat64+0x37/0x40
[<c0154228>] sys_ftruncate+0x118/0x1b0
[<c01558f0>] generic_file_llseek+0x0/0xf0
[<c0155c29>] sys_lseek+0x69/0xb0
[<c010943f>] syscall_call+0x7/0xb

fsx D 00000001 943 1 944 942 (NOTLB)
Call Trace:
[<c011c546>] io_schedule+0x26/0x30
[<c01386ac>] wait_on_page_bit_wq+0xcc/0x100
[<c011ddf0>] autoremove_wake_function+0x0/0x50
[<c011ddf0>] autoremove_wake_function+0x0/0x50
[<c0142815>] truncate_inode_pages+0x2e5/0x2f0
[<c014703c>] invalidate_mmap_range+0x7c/0x100
[<c014712b>] vmtruncate+0x6b/0x100
[<c0171e94>] inode_setattr+0x134/0x150
[<c0195aca>] ext3_setattr+0x7a/0x1a0
[<c0160f6e>] cp_new_stat64+0xfe/0x110
[<c0172080>] notify_change+0x160/0x19d
[<c0153f3a>] do_truncate+0x6a/0x90
[<c0161037>] sys_fstat64+0x37/0x40
[<c0154228>] sys_ftruncate+0x118/0x1b0
[<c01558f0>] generic_file_llseek+0x0/0xf0
[<c0155c29>] sys_lseek+0x69/0xb0
[<c010943f>] syscall_call+0x7/0xb

fsx D 00000001 944 1 945 943 (NOTLB)
Call Trace:
[<c011c546>] io_schedule+0x26/0x30
[<c0157565>] __wait_on_buffer_wq+0xf5/0x100
[<c011ddf0>] autoremove_wake_function+0x0/0x50
[<c015af00>] submit_bh+0x90/0x1e0
[<c011ddf0>] autoremove_wake_function+0x0/0x50
[<c02b1cc4>] submit_bio+0x54/0xa0
[<c0158acd>] __bread_slow_wq+0xad/0xf0
[<c0158db6>] __bread+0x46/0x50
[<c018eb98>] read_block_bitmap+0x58/0xa0
[<c018f902>] ext3_new_block+0x1a2/0x590
[<c0158c73>] __find_get_block+0x73/0x100
[<c01922f7>] ext3_alloc_block+0x37/0x40
[<c01926ba>] ext3_alloc_branch+0x4a/0x2c0
[<c01924c2>] ext3_get_branch+0x72/0x100
[<c0192cbc>] ext3_get_block_handle+0x18c/0x360
[<c015b501>] alloc_buffer_head+0x41/0x50
[<c0192ef4>] ext3_get_block+0x64/0xb0
[<c0159827>] __block_prepare_write+0x227/0x4b0
[<c015a364>] block_prepare_write+0x34/0x50
[<c0192e90>] ext3_get_block+0x0/0xb0
[<c01934d1>] ext3_prepare_write+0x71/0x130
[<c0192e90>] ext3_get_block+0x0/0xb0
[<c013a5cd>] generic_file_aio_write_nolock+0x38d/0xa50
[<c0195808>] ext3_do_update_inode+0x1c8/0x3d0
[<c011de17>] autoremove_wake_function+0x27/0x50
[<c011bf9a>] __wake_up_common+0x3a/0x60
[<c013adee>] generic_file_aio_write+0x9e/0x120
[<c0190bf4>] ext3_file_write+0x44/0xe0
[<c0156046>] do_sync_write+0xb6/0xf0
[<c02fb63e>] scsi_end_request+0xae/0xc0
[<c02fb95d>] scsi_io_completion+0x14d/0x470
[<c011ddf0>] autoremove_wake_function+0x0/0x50
[<c0342c31>] sd_rw_intr+0x61/0x270
[<c02f6fdc>] scsi_finish_command+0x8c/0xc0
[<c03332b3>] qla2x00_intr_handler+0x203/0x220
[<c015613e>] vfs_write+0xbe/0x130
[<c01558f0>] generic_file_llseek+0x0/0xf0
[<c0156262>] sys_write+0x42/0x70
[<c010943f>] syscall_call+0x7/0xb

fsx D C0109E2E 945 1 946 944 (NOTLB)
Call Trace:
[<c0109e2e>] apic_timer_interrupt+0x1a/0x20
[<c011c546>] io_schedule+0x26/0x30
[<c01386ac>] wait_on_page_bit_wq+0xcc/0x100
[<c011ddf0>] autoremove_wake_function+0x0/0x50
[<c011ddf0>] autoremove_wake_function+0x0/0x50
[<c0142815>] truncate_inode_pages+0x2e5/0x2f0
[<c014712b>] vmtruncate+0x6b/0x100
[<c0171e94>] inode_setattr+0x134/0x150
[<c0195aca>] ext3_setattr+0x7a/0x1a0
[<c0160f6e>] cp_new_stat64+0xfe/0x110
[<c0172080>] notify_change+0x160/0x19d
[<c0153f3a>] do_truncate+0x6a/0x90
[<c0161037>] sys_fstat64+0x37/0x40
[<c0154228>] sys_ftruncate+0x118/0x1b0
[<c01558f0>] generic_file_llseek+0x0/0xf0
[<c0155c29>] sys_lseek+0x69/0xb0
[<c010943f>] syscall_call+0x7/0xb

fsx D C380CA70 946 1 947 945 (NOTLB)
Call Trace:
[<c0109e2e>] apic_timer_interrupt+0x1a/0x20
[<c015b390>] block_sync_page+0x0/0x10
[<c011c546>] io_schedule+0x26/0x30
[<c01386ac>] wait_on_page_bit_wq+0xcc/0x100
[<c011ddf0>] autoremove_wake_function+0x0/0x50
[<c0138be6>] find_get_pages+0x36/0x60
[<c011ddf0>] autoremove_wake_function+0x0/0x50
[<c014230e>] pagevec_lookup+0x2e/0x40
[<c01426fc>] truncate_inode_pages+0x1cc/0x2f0
[<c014712b>] vmtruncate+0x6b/0x100
[<c0171e94>] inode_setattr+0x134/0x150
[<c0195aca>] ext3_setattr+0x7a/0x1a0
[<c0160f6e>] cp_new_stat64+0xfe/0x110
[<c0172080>] notify_change+0x160/0x19d
[<c0153f3a>] do_truncate+0x6a/0x90
[<c0161037>] sys_fstat64+0x37/0x40
[<c0154228>] sys_ftruncate+0x118/0x1b0
[<c01558f0>] generic_file_llseek+0x0/0xf0
[<c0155c29>] sys_lseek+0x69/0xb0
[<c010943f>] syscall_call+0x7/0xb

fsx D 00000001 947 1 948 946 (NOTLB)
Call Trace:
[<c011c546>] io_schedule+0x26/0x30
[<c0157565>] __wait_on_buffer_wq+0xf5/0x100
[<c011ddf0>] autoremove_wake_function+0x0/0x50
[<c015af00>] submit_bh+0x90/0x1e0
[<c011ddf0>] autoremove_wake_function+0x0/0x50
[<c02b1cc4>] submit_bio+0x54/0xa0
[<c0158acd>] __bread_slow_wq+0xad/0xf0
[<c0158db6>] __bread+0x46/0x50
[<c018eb98>] read_block_bitmap+0x58/0xa0
[<c018f902>] ext3_new_block+0x1a2/0x590
[<c0195ca9>] ext3_mark_iloc_dirty+0x29/0x40
[<c01922f7>] ext3_alloc_block+0x37/0x40
[<c01926ba>] ext3_alloc_branch+0x4a/0x2c0
[<c0192cbc>] ext3_get_block_handle+0x18c/0x360
[<c015b501>] alloc_buffer_head+0x41/0x50
[<c0192ef4>] ext3_get_block+0x64/0xb0
[<c0159827>] __block_prepare_write+0x227/0x4b0
[<c0195808>] ext3_do_update_inode+0x1c8/0x3d0
[<c015a364>] block_prepare_write+0x34/0x50
[<c0192e90>] ext3_get_block+0x0/0xb0
[<c01934d1>] ext3_prepare_write+0x71/0x130
[<c0192e90>] ext3_get_block+0x0/0xb0
[<c013a5cd>] generic_file_aio_write_nolock+0x38d/0xa50
[<c0195808>] ext3_do_update_inode+0x1c8/0x3d0
[<c011bf5a>] default_wake_function+0x2a/0x30
[<c011de17>] autoremove_wake_function+0x27/0x50
[<c011bf9a>] __wake_up_common+0x3a/0x60
[<c013adee>] generic_file_aio_write+0x9e/0x120
[<c0190bf4>] ext3_file_write+0x44/0xe0
[<c0156046>] do_sync_write+0xb6/0xf0
[<c02f689e>] scsi_put_command+0x6e/0x90
[<c02fb63e>] scsi_end_request+0xae/0xc0
[<c011ddf0>] autoremove_wake_function+0x0/0x50
[<c011bf9a>] __wake_up_common+0x3a/0x60
[<c03332b3>] qla2x00_intr_handler+0x203/0x220
[<c015613e>] vfs_write+0xbe/0x130
[<c01558f0>] generic_file_llseek+0x0/0xf0
[<c0156262>] sys_write+0x42/0x70
[<c010943f>] syscall_call+0x7/0xb

fsx D C0109E2E 948 1 949 947 (NOTLB)
Call Trace:
[<c0109e2e>] apic_timer_interrupt+0x1a/0x20
[<c011c546>] io_schedule+0x26/0x30
[<c01386ac>] wait_on_page_bit_wq+0xcc/0x100
[<c011ddf0>] autoremove_wake_function+0x0/0x50
[<c011ddf0>] autoremove_wake_function+0x0/0x50
[<c0142815>] truncate_inode_pages+0x2e5/0x2f0
[<c014712b>] vmtruncate+0x6b/0x100
[<c0171e94>] inode_setattr+0x134/0x150
[<c0195aca>] ext3_setattr+0x7a/0x1a0
[<c0160f6e>] cp_new_stat64+0xfe/0x110
[<c0172080>] notify_change+0x160/0x19d
[<c0153f3a>] do_truncate+0x6a/0x90
[<c0161037>] sys_fstat64+0x37/0x40
[<c0154228>] sys_ftruncate+0x118/0x1b0
[<c01558f0>] generic_file_llseek+0x0/0xf0
[<c0155c29>] sys_lseek+0x69/0xb0
[<c010943f>] syscall_call+0x7/0xb

fsx D EF86BDD4 949 1 988 948 (NOTLB)
Call Trace:
[<c02b0537>] generic_unplug_device+0x67/0x70
[<c011c546>] io_schedule+0x26/0x30
[<c01386ac>] wait_on_page_bit_wq+0xcc/0x100
[<c011ddf0>] autoremove_wake_function+0x0/0x50
[<c011ddf0>] autoremove_wake_function+0x0/0x50
[<c0142815>] truncate_inode_pages+0x2e5/0x2f0
[<c014712b>] vmtruncate+0x6b/0x100
[<c0171e94>] inode_setattr+0x134/0x150
[<c0195aca>] ext3_setattr+0x7a/0x1a0
[<c0160f6e>] cp_new_stat64+0xfe/0x110
[<c0172080>] notify_change+0x160/0x19d
[<c0153f3a>] do_truncate+0x6a/0x90
[<c0161037>] sys_fstat64+0x37/0x40
[<c0154228>] sys_ftruncate+0x118/0x1b0
[<c01558f0>] generic_file_llseek+0x0/0xf0
[<c0155c29>] sys_lseek+0x69/0xb0
[<c010943f>] syscall_call+0x7/0xb



2003-06-12 17:36:50

by Andrew Morton

[permalink] [raw]
Subject: Re: 2.5.70-mm6

Mingming Cao <[email protected]> wrote:
>
>
> > Mingming Cao <[email protected]> wrote:
> > >
> > > I run 50 fsx tests on ext3 filesystem on 2.5.70-mm6 kernel. Serveral fsx
> > > tests hang with the status D, after the tests run for a while. No oops,
> > > no error messages. I found same problem on mm5, but 2.5.70 is fine.
>
> Sorry, the tests in 2.5.70 also failed, same problem.

OK. It would be useful to test ext2 as well.

> On Tue, 2003-06-10 at 20:12, Andrew Morton wrote
> > If you could, please retest with "elevator=deadline"?
> >
> Thanks for your feedback.
>
> This time I got more fsx tests hang(about 25). Before normally I saw 5
> or 10 tests fail. Here is the stack info.

Everything stuck waiting for IO to complete again.

Are you able to try a different qlogic driver? Or a different HBA?

I tried to reproduce this but I don't have sufficient info.

How much memory does that machine have, and what fsx-linux command lines
are you using?

Thanks.

2003-06-12 18:29:54

by Mingming Cao

[permalink] [raw]
Subject: Re: 2.5.70-mm6

On Thu, 2003-06-12 at 10:50, Andrew Morton wrote:
> > > Mingming Cao <[email protected]> wrote:
> > Sorry, the tests in 2.5.70 also failed, same problem.
>
> OK. It would be useful to test ext2 as well.
I will try ext2.

> > On Tue, 2003-06-10 at 20:12, Andrew Morton wrote
>
> Everything stuck waiting for IO to complete again.
>
> Are you able to try a different qlogic driver? Or a different HBA?
I will try.
>
> I tried to reproduce this but I don't have sufficient info.
>
Sorry about this.

> How much memory does that machine have, and what fsx-linux command lines
> are you using?
The tests were run on 8 way PIII 700MHZ, with 4G memory. The fsx
command line is:

/root/fsx -R -W -r 4096 -w 4096 /mnt/mntxx/foo &


Thanks for looking at this.