* 2.5.70-mm6 @ 2003-06-07 22:14 Andrew Morton 2003-06-08 0:37 ` 2.5.70-mm6 Alexander Hoogerhuis ` (7 more replies) 0 siblings, 8 replies; 43+ messages in thread From: Andrew Morton @ 2003-06-07 22:14 UTC (permalink / raw) To: linux-kernel, linux-mm 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 <anton@samba.org> 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 <maneesh@in.ibm.com> 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 ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: 2.5.70-mm6 2003-06-07 22:14 2.5.70-mm6 Andrew Morton @ 2003-06-08 0:37 ` Alexander Hoogerhuis 2003-06-08 0:56 ` 2.5.70-mm6 Andrew Morton 2003-06-08 12:09 ` 2.5.70-mm6 Felipe Alfaro Solana ` (6 subsequent siblings) 7 siblings, 1 reply; 43+ messages in thread From: Alexander Hoogerhuis @ 2003-06-08 0:37 UTC (permalink / raw) To: Andrew Morton; +Cc: linux-kernel, linux-mm Andrew Morton <akpm@digeo.com> 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 | alexh@ihatent.com CCNP - CCDP - MCNE - CCSE | +47 908 21 485 "You have zero privacy anyway. Get over it." --Scott McNealy ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: 2.5.70-mm6 2003-06-08 0:37 ` 2.5.70-mm6 Alexander Hoogerhuis @ 2003-06-08 0:56 ` Andrew Morton 2003-06-08 1:13 ` 2.5.70-mm6 Alexander Hoogerhuis 2003-06-08 12:25 ` 2.5.70-mm6 Christoph Hellwig 0 siblings, 2 replies; 43+ messages in thread From: Andrew Morton @ 2003-06-08 0:56 UTC (permalink / raw) To: Alexander Hoogerhuis; +Cc: linux-kernel, linux-mm, Christoph Hellwig Alexander Hoogerhuis <alexh@ihatent.com> wrote: > > Andrew Morton <akpm@digeo.com> 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. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: 2.5.70-mm6 2003-06-08 0:56 ` 2.5.70-mm6 Andrew Morton @ 2003-06-08 1:13 ` Alexander Hoogerhuis 2003-06-08 12:25 ` 2.5.70-mm6 Christoph Hellwig 1 sibling, 0 replies; 43+ messages in thread From: Alexander Hoogerhuis @ 2003-06-08 1:13 UTC (permalink / raw) To: Andrew Morton; +Cc: linux-kernel, linux-mm, Christoph Hellwig, mdharm-usb Andrew Morton <akpm@digeo.com> writes: > Alexander Hoogerhuis <alexh@ihatent.com> wrote: > > > > Andrew Morton <akpm@digeo.com> 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 | alexh@ihatent.com CCNP - CCDP - MCNE - CCSE | +47 908 21 485 "You have zero privacy anyway. Get over it." --Scott McNealy ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: 2.5.70-mm6 2003-06-08 0:56 ` 2.5.70-mm6 Andrew Morton 2003-06-08 1:13 ` 2.5.70-mm6 Alexander Hoogerhuis @ 2003-06-08 12:25 ` Christoph Hellwig 1 sibling, 0 replies; 43+ messages in thread From: Christoph Hellwig @ 2003-06-08 12:25 UTC (permalink / raw) To: Andrew Morton; +Cc: Alexander Hoogerhuis, linux-kernel, linux-mm 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); ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: 2.5.70-mm6 2003-06-07 22:14 2.5.70-mm6 Andrew Morton 2003-06-08 0:37 ` 2.5.70-mm6 Alexander Hoogerhuis @ 2003-06-08 12:09 ` Felipe Alfaro Solana 2003-06-08 15:56 ` [patch] 2.5.70-mm6: ethertap.c doesn't compile Adrian Bunk ` (5 subsequent siblings) 7 siblings, 0 replies; 43+ messages in thread From: Felipe Alfaro Solana @ 2003-06-08 12:09 UTC (permalink / raw) To: Andrew Morton; +Cc: LKML, linux-mm 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. ^ permalink raw reply [flat|nested] 43+ messages in thread
* [patch] 2.5.70-mm6: ethertap.c doesn't compile 2003-06-07 22:14 2.5.70-mm6 Andrew Morton 2003-06-08 0:37 ` 2.5.70-mm6 Alexander Hoogerhuis 2003-06-08 12:09 ` 2.5.70-mm6 Felipe Alfaro Solana @ 2003-06-08 15:56 ` Adrian Bunk 2003-06-08 16:00 ` Arnaldo Carvalho de Melo 2003-06-08 22:52 ` 2.5.70-mm6 Pasi Savolainen ` (4 subsequent siblings) 7 siblings, 1 reply; 43+ messages in thread From: Adrian Bunk @ 2003-06-08 15:56 UTC (permalink / raw) To: Andrew Morton, linux-net; +Cc: linux-kernel 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; ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [patch] 2.5.70-mm6: ethertap.c doesn't compile 2003-06-08 15:56 ` [patch] 2.5.70-mm6: ethertap.c doesn't compile Adrian Bunk @ 2003-06-08 16:00 ` Arnaldo Carvalho de Melo 2003-06-08 21:41 ` Adrian Bunk 0 siblings, 1 reply; 43+ messages in thread From: Arnaldo Carvalho de Melo @ 2003-06-08 16:00 UTC (permalink / raw) To: Adrian Bunk; +Cc: Andrew Morton, linux-net, linux-kernel 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 --> > ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [patch] 2.5.70-mm6: ethertap.c doesn't compile 2003-06-08 16:00 ` Arnaldo Carvalho de Melo @ 2003-06-08 21:41 ` Adrian Bunk 0 siblings, 0 replies; 43+ messages in thread From: Adrian Bunk @ 2003-06-08 21:41 UTC (permalink / raw) To: Arnaldo Carvalho de Melo, Andrew Morton, linux-net, linux-kernel 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 ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: 2.5.70-mm6 2003-06-07 22:14 2.5.70-mm6 Andrew Morton ` (2 preceding siblings ...) 2003-06-08 15:56 ` [patch] 2.5.70-mm6: ethertap.c doesn't compile Adrian Bunk @ 2003-06-08 22:52 ` Pasi Savolainen 2003-06-08 23:17 ` [patch] 2.5.70-mm6: isp driver cleanups Adrian Bunk ` (3 subsequent siblings) 7 siblings, 0 replies; 43+ messages in thread From: Pasi Savolainen @ 2003-06-08 22:52 UTC (permalink / raw) To: linux-kernel; +Cc: linux-mm * Andrew Morton <akpm@digeo.com>: > 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> ^ permalink raw reply [flat|nested] 43+ messages in thread
* [patch] 2.5.70-mm6: isp driver cleanups 2003-06-07 22:14 2.5.70-mm6 Andrew Morton ` (3 preceding siblings ...) 2003-06-08 22:52 ` 2.5.70-mm6 Pasi Savolainen @ 2003-06-08 23:17 ` Adrian Bunk 2003-06-08 23:27 ` Andrew Morton 2003-06-08 23:24 ` 2.5.70-mm6 Joe ` (2 subsequent siblings) 7 siblings, 1 reply; 43+ messages in thread From: Adrian Bunk @ 2003-06-08 23:17 UTC (permalink / raw) To: Andrew Morton; +Cc: linux-kernel 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(¤t->blocked, sigmask(SIGHUP)); - } else { - siginitsetinv(¤t->blocked, 0); - } + siginitsetinv(¤t->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) { ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [patch] 2.5.70-mm6: isp driver cleanups 2003-06-08 23:17 ` [patch] 2.5.70-mm6: isp driver cleanups Adrian Bunk @ 2003-06-08 23:27 ` Andrew Morton 0 siblings, 0 replies; 43+ messages in thread From: Andrew Morton @ 2003-06-08 23:27 UTC (permalink / raw) To: Adrian Bunk; +Cc: linux-kernel Adrian Bunk <bunk@fs.tum.de> 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. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: 2.5.70-mm6 2003-06-07 22:14 2.5.70-mm6 Andrew Morton ` (4 preceding siblings ...) 2003-06-08 23:17 ` [patch] 2.5.70-mm6: isp driver cleanups Adrian Bunk @ 2003-06-08 23:24 ` Joe 2003-06-09 17:45 ` 2.5.70-mm6 Maciej Soltysiak 2003-06-11 2:15 ` 2.5.70-mm6 Mingming Cao 7 siblings, 0 replies; 43+ messages in thread From: Joe @ 2003-06-08 23:24 UTC (permalink / raw) To: linux-kernel; +Cc: Andrew Morton 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 ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: 2.5.70-mm6 2003-06-07 22:14 2.5.70-mm6 Andrew Morton ` (5 preceding siblings ...) 2003-06-08 23:24 ` 2.5.70-mm6 Joe @ 2003-06-09 17:45 ` Maciej Soltysiak 2003-06-09 17:39 ` 2.5.70-mm6 Martin J. Bligh ` (4 more replies) 2003-06-11 2:15 ` 2.5.70-mm6 Mingming Cao 7 siblings, 5 replies; 43+ messages in thread From: Maciej Soltysiak @ 2003-06-09 17:45 UTC (permalink / raw) To: Andrew Morton; +Cc: linux-kernel, linux-mm > . -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 ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: 2.5.70-mm6 2003-06-09 17:45 ` 2.5.70-mm6 Maciej Soltysiak @ 2003-06-09 17:39 ` Martin J. Bligh 2003-06-09 18:19 ` 2.5.70-mm6 Maciej Soltysiak 2003-06-09 18:39 ` 2.5.70-mm6 Felipe Alfaro Solana 2003-06-09 18:06 ` 2.5.70-mm6 Alistair J Strachan ` (3 subsequent siblings) 4 siblings, 2 replies; 43+ messages in thread From: Martin J. Bligh @ 2003-06-09 17:39 UTC (permalink / raw) To: Maciej Soltysiak, Andrew Morton; +Cc: linux-kernel, linux-mm --On Monday, June 09, 2003 19:45:58 +0200 Maciej Soltysiak <solt@dns.toxicfilms.tv> 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. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: 2.5.70-mm6 2003-06-09 17:39 ` 2.5.70-mm6 Martin J. Bligh @ 2003-06-09 18:19 ` Maciej Soltysiak 2003-06-09 18:51 ` 2.5.70-mm6 Martin J. Bligh 2003-06-09 18:39 ` 2.5.70-mm6 Felipe Alfaro Solana 1 sibling, 1 reply; 43+ messages in thread From: Maciej Soltysiak @ 2003-06-09 18:19 UTC (permalink / raw) To: Martin J. Bligh; +Cc: Andrew Morton, linux-kernel, linux-mm > 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 ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: 2.5.70-mm6 2003-06-09 18:19 ` 2.5.70-mm6 Maciej Soltysiak @ 2003-06-09 18:51 ` Martin J. Bligh 2003-06-09 19:42 ` 2.5.70-mm6 Maciej Soltysiak 2003-06-09 20:08 ` 2.5.70-mm6 Felipe Alfaro Solana 0 siblings, 2 replies; 43+ messages in thread From: Martin J. Bligh @ 2003-06-09 18:51 UTC (permalink / raw) To: Maciej Soltysiak; +Cc: Andrew Morton, linux-kernel, linux-mm >> 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); ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: 2.5.70-mm6 2003-06-09 18:51 ` 2.5.70-mm6 Martin J. Bligh @ 2003-06-09 19:42 ` Maciej Soltysiak 2003-06-09 20:04 ` 2.5.70-mm6 William Lee Irwin III 2003-06-09 20:08 ` 2.5.70-mm6 Felipe Alfaro Solana 1 sibling, 1 reply; 43+ messages in thread From: Maciej Soltysiak @ 2003-06-09 19:42 UTC (permalink / raw) To: Martin J. Bligh; +Cc: Andrew Morton, linux-kernel, linux-mm > > 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 ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: 2.5.70-mm6 2003-06-09 19:42 ` 2.5.70-mm6 Maciej Soltysiak @ 2003-06-09 20:04 ` William Lee Irwin III 2003-06-10 8:54 ` 2.5.70-mm6 Maciej Soltysiak 2003-06-10 11:52 ` 2.5.70-mm6 Maciej Soltysiak 0 siblings, 2 replies; 43+ messages in thread From: William Lee Irwin III @ 2003-06-09 20:04 UTC (permalink / raw) To: Maciej Soltysiak; +Cc: Martin J. Bligh, Andrew Morton, linux-kernel, linux-mm [-- Attachment #1: Type: text/plain, Size: 375 bytes --] 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 [-- Attachment #2: galbraith.patch --] [-- Type: text/plain, Size: 7376 bytes --] diff -prauN linux-2.5.70-bk8/include/linux/sched.h galbraith-2.5.70-bk8-1/include/linux/sched.h --- linux-2.5.70-bk8/include/linux/sched.h Mon Jun 2 02:15:11 2003 +++ galbraith-2.5.70-bk8-1/include/linux/sched.h Tue Jun 3 07:10:17 2003 @@ -336,7 +336,9 @@ prio_array_t *array; unsigned long sleep_avg; - unsigned long last_run; + unsigned long long last_run; + unsigned int run_nsecs; + unsigned int sleep_nsecs; unsigned long policy; unsigned long cpus_allowed; diff -prauN linux-2.5.70-bk8/kernel/sched.c galbraith-2.5.70-bk8-1/kernel/sched.c --- linux-2.5.70-bk8/kernel/sched.c Tue May 27 04:05:34 2003 +++ galbraith-2.5.70-bk8-1/kernel/sched.c Tue Jun 3 07:10:18 2003 @@ -74,6 +74,12 @@ #define MAX_SLEEP_AVG (10*HZ) #define STARVATION_LIMIT (10*HZ) #define NODE_THRESHOLD 125 +#define SCHED_NANOSECOND 1 +#define SCHED_SECOND (1000000000 * SCHED_NANOSECOND) +#define SCHED_TICK (SCHED_SECOND / HZ) +#define TICKS_PER_SECOND (SCHED_SECOND / SCHED_TICK) + +extern unsigned long long monotonic_clock(void); /* * If a task is 'interactive' then we reinsert it in the active @@ -342,9 +348,23 @@ */ static inline void activate_task(task_t *p, runqueue_t *rq) { - long sleep_time = jiffies - p->last_run - 1; + unsigned long long now = monotonic_clock(); + long long sleep = now - p->last_run + p->sleep_nsecs; + int ticks = 0, requeue_waker = 0; + + if (sleep >= SCHED_TICK) { + while (sleep >= SCHED_SECOND) { + sleep -= SCHED_SECOND; + ticks += TICKS_PER_SECOND; + } + while (sleep >= SCHED_TICK) { + sleep -= SCHED_TICK; + ticks++; + } + p->sleep_nsecs = sleep; + } else p->sleep_nsecs += sleep; - if (sleep_time > 0) { + if (ticks > 0) { int sleep_avg; /* @@ -355,7 +375,7 @@ * spends sleeping, the higher the average gets - and the * higher the priority boost gets as well. */ - sleep_avg = p->sleep_avg + sleep_time; + sleep_avg = p->sleep_avg + ticks; /* * 'Overflow' bonus ticks go to the waker as well, so the @@ -363,8 +383,10 @@ * boosting tasks that are related to maximum-interactive * tasks. */ - if (sleep_avg > MAX_SLEEP_AVG) + if (sleep_avg > MAX_SLEEP_AVG) { sleep_avg = MAX_SLEEP_AVG; + p->sleep_nsecs = 0; + } if (p->sleep_avg != sleep_avg) { p->sleep_avg = sleep_avg; p->prio = effective_prio(p); @@ -548,6 +570,8 @@ current->sleep_avg = current->sleep_avg * PARENT_PENALTY / 100; p->sleep_avg = p->sleep_avg * CHILD_PENALTY / 100; p->prio = effective_prio(p); + p->run_nsecs = 0; + p->sleep_nsecs = 0; set_task_cpu(p, smp_processor_id()); if (unlikely(!current->array)) @@ -1147,6 +1171,49 @@ (jiffies - (rq)->expired_timestamp >= \ STARVATION_LIMIT * ((rq)->nr_running) + 1))) +inline void __scheduler_tick(runqueue_t *rq, task_t *p) +{ + unsigned long long now = monotonic_clock(); + prio_array_t *array = rq->active; + int ticks; + + p->run_nsecs += now - p->last_run; + /* Task might have expired already, but not scheduled off yet */ + if (p->array != array) { + set_tsk_need_resched(p); + goto abort; + } + if (p->run_nsecs < SCHED_TICK || p->policy == SCHED_FIFO ) + goto abort; + + for (ticks = 0; p->run_nsecs >= SCHED_TICK; ticks++) + p->run_nsecs -= SCHED_TICK; + if (ticks > p->time_slice) + show_task(p); + if (p->sleep_avg > ticks) + p->sleep_avg -= ticks; + else + p->sleep_avg = 0; + p->time_slice -= ticks; + + if (p->time_slice <= 0) { + dequeue_task(p, p->array); + p->prio = effective_prio(p); + p->time_slice = task_timeslice(p); + p->first_time_slice = 0; + set_tsk_need_resched(p); + if ((EXPIRED_STARVING(rq) && !rt_task(p)) || + !TASK_INTERACTIVE(p)) { + array = rq->expired; + if (!rq->expired_timestamp) + rq->expired_timestamp = jiffies; + } + enqueue_task(p, array); + } +abort: + p->last_run = monotonic_clock(); +} + /* * This function gets called by the timer code, with HZ frequency. * We call it with interrupts disabled. @@ -1159,11 +1226,12 @@ int cpu = smp_processor_id(); runqueue_t *rq = this_rq(); task_t *p = current; + int idle = p == rq->idle; if (rcu_pending(cpu)) rcu_check_callbacks(cpu, user_ticks); - if (p == rq->idle) { + if (idle) { /* note: this timer irq context must be accounted for as well */ if (irq_count() - HARDIRQ_OFFSET >= SOFTIRQ_OFFSET) kstat_cpu(cpu).cpustat.system += sys_ticks; @@ -1171,8 +1239,7 @@ kstat_cpu(cpu).cpustat.iowait += sys_ticks; else kstat_cpu(cpu).cpustat.idle += sys_ticks; - rebalance_tick(rq, 1); - return; + goto out; } if (TASK_NICE(p) > 0) kstat_cpu(cpu).cpustat.nice += user_ticks; @@ -1180,11 +1247,6 @@ kstat_cpu(cpu).cpustat.user += user_ticks; kstat_cpu(cpu).cpustat.system += sys_ticks; - /* Task might have expired already, but not scheduled off yet */ - if (p->array != rq->active) { - set_tsk_need_resched(p); - goto out; - } spin_lock(&rq->lock); /* * The task was running during this tick - update the @@ -1194,42 +1256,10 @@ * it possible for interactive tasks to use up their * timeslices at their highest priority levels. */ - if (p->sleep_avg) - p->sleep_avg--; - if (unlikely(rt_task(p))) { - /* - * RR tasks need a special form of timeslice management. - * FIFO tasks have no timeslices. - */ - if ((p->policy == SCHED_RR) && !--p->time_slice) { - p->time_slice = task_timeslice(p); - p->first_time_slice = 0; - set_tsk_need_resched(p); - - /* put it at the end of the queue: */ - dequeue_task(p, rq->active); - enqueue_task(p, rq->active); - } - goto out_unlock; - } - if (!--p->time_slice) { - dequeue_task(p, rq->active); - set_tsk_need_resched(p); - p->prio = effective_prio(p); - p->time_slice = task_timeslice(p); - p->first_time_slice = 0; - - if (!TASK_INTERACTIVE(p) || EXPIRED_STARVING(rq)) { - if (!rq->expired_timestamp) - rq->expired_timestamp = jiffies; - enqueue_task(p, rq->expired); - } else - enqueue_task(p, rq->active); - } -out_unlock: + __scheduler_tick(rq, p); spin_unlock(&rq->lock); out: - rebalance_tick(rq, 0); + rebalance_tick(rq, idle); } void scheduling_functions_start_here(void) { } @@ -1264,8 +1294,8 @@ rq = this_rq(); release_kernel_lock(prev); - prev->last_run = jiffies; spin_lock_irq(&rq->lock); + __scheduler_tick(rq, prev); /* * if entering off of a kernel preemption go straight @@ -1320,6 +1350,7 @@ if (likely(prev != next)) { rq->nr_switches++; rq->curr = next; + next->last_run = prev->last_run; prepare_arch_switch(rq, next); prev = context_switch(rq, prev, next); diff -prauN linux-2.5.70-bk8/arch/i386/kernel/timers/timer_tsc.c galbraith-2.5.70-bk8-1/arch/i386/kernel/timers/timer_tsc.c --- linux-2.5.70-bk8/arch/i386/kernel/timers/timer_tsc.c Mon Apr 21 08:11:07 2003 +++ galbraith-2.5.70-bk8-1/arch/i386/kernel/timers/timer_tsc.c Tue Jun 3 07:10:18 2003 @@ -102,12 +102,13 @@ static unsigned long long monotonic_clock_tsc(void) { unsigned long long last_offset, this_offset, base; + unsigned long flags; /* atomically read monotonic base & last_offset */ - read_lock_irq(&monotonic_lock); + read_lock_irqsave(&monotonic_lock, flags); last_offset = ((unsigned long long)last_tsc_high<<32)|last_tsc_low; base = monotonic_base; - read_unlock_irq(&monotonic_lock); + read_unlock_irqrestore(&monotonic_lock, flags); /* Read the Time Stamp Counter */ rdtscll(this_offset); [-- Attachment #3: galbraith_thud.diff --] [-- Type: text/plain, Size: 1162 bytes --] --- linux-2.5.70.virgin/kernel/sched.c.org Tue Jun 3 06:44:48 2003 +++ linux-2.5.70.virgin/kernel/sched.c Tue Jun 3 17:28:10 2003 @@ -66,7 +66,7 @@ */ #define MIN_TIMESLICE ( 10 * HZ / 1000) #define MAX_TIMESLICE (200 * HZ / 1000) -#define CHILD_PENALTY 50 +#define CHILD_PENALTY 80 #define PARENT_PENALTY 100 #define EXIT_WEIGHT 3 #define PRIO_BONUS_RATIO 25 @@ -355,6 +355,7 @@ * spends sleeping, the higher the average gets - and the * higher the priority boost gets as well. */ + sleep_time = min(sleep_time, (long) p->time_slice); sleep_avg = p->sleep_avg + sleep_time; /* @@ -545,8 +546,10 @@ * and children as well, to keep max-interactive tasks * from forking tasks that are max-interactive. */ - current->sleep_avg = current->sleep_avg * PARENT_PENALTY / 100; - p->sleep_avg = p->sleep_avg * CHILD_PENALTY / 100; + if (likely(current->parent->pid > 1)) { + current->sleep_avg = current->sleep_avg * PARENT_PENALTY / 100; + p->sleep_avg = p->sleep_avg * CHILD_PENALTY / 100; + } else current->sleep_avg = p->sleep_avg = MAX_SLEEP_AVG; p->prio = effective_prio(p); set_task_cpu(p, smp_processor_id()); ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: 2.5.70-mm6 2003-06-09 20:04 ` 2.5.70-mm6 William Lee Irwin III @ 2003-06-10 8:54 ` Maciej Soltysiak 2003-06-10 9:20 ` 2.5.70-mm6 William Lee Irwin III 2003-06-10 11:52 ` 2.5.70-mm6 Maciej Soltysiak 1 sibling, 1 reply; 43+ messages in thread From: Maciej Soltysiak @ 2003-06-10 8:54 UTC (permalink / raw) To: William Lee Irwin III Cc: Martin J. Bligh, Andrew Morton, linux-kernel, linux-mm > 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 ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: 2.5.70-mm6 2003-06-10 8:54 ` 2.5.70-mm6 Maciej Soltysiak @ 2003-06-10 9:20 ` William Lee Irwin III 2003-06-10 11:31 ` 2.5.70-mm6 Mike Galbraith 0 siblings, 1 reply; 43+ messages in thread From: William Lee Irwin III @ 2003-06-10 9:20 UTC (permalink / raw) To: Maciej Soltysiak Cc: Martin J. Bligh, Andrew Morton, linux-kernel, linux-mm, efault 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 ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: 2.5.70-mm6 2003-06-10 9:20 ` 2.5.70-mm6 William Lee Irwin III @ 2003-06-10 11:31 ` Mike Galbraith 2003-06-10 11:41 ` 2.5.70-mm6 William Lee Irwin III 0 siblings, 1 reply; 43+ messages in thread From: Mike Galbraith @ 2003-06-10 11:31 UTC (permalink / raw) To: William Lee Irwin III Cc: Maciej Soltysiak, Martin J. Bligh, Andrew Morton, linux-kernel, linux-mm 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 ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: 2.5.70-mm6 2003-06-10 11:31 ` 2.5.70-mm6 Mike Galbraith @ 2003-06-10 11:41 ` William Lee Irwin III 2003-06-10 18:53 ` 2.5.70-mm6 Mike Galbraith 0 siblings, 1 reply; 43+ messages in thread From: William Lee Irwin III @ 2003-06-10 11:41 UTC (permalink / raw) To: Mike Galbraith Cc: Maciej Soltysiak, Martin J. Bligh, Andrew Morton, linux-kernel, linux-mm 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 ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: 2.5.70-mm6 2003-06-10 11:41 ` 2.5.70-mm6 William Lee Irwin III @ 2003-06-10 18:53 ` Mike Galbraith 2003-06-10 19:11 ` 2.5.70-mm6 William Lee Irwin III 0 siblings, 1 reply; 43+ messages in thread From: Mike Galbraith @ 2003-06-10 18:53 UTC (permalink / raw) To: William Lee Irwin III Cc: Maciej Soltysiak, Martin J. Bligh, Andrew Morton, linux-kernel, linux-mm 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 ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: 2.5.70-mm6 2003-06-10 18:53 ` 2.5.70-mm6 Mike Galbraith @ 2003-06-10 19:11 ` William Lee Irwin III 0 siblings, 0 replies; 43+ messages in thread From: William Lee Irwin III @ 2003-06-10 19:11 UTC (permalink / raw) To: Mike Galbraith Cc: Maciej Soltysiak, Martin J. Bligh, Andrew Morton, linux-kernel, linux-mm 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 ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: 2.5.70-mm6 2003-06-09 20:04 ` 2.5.70-mm6 William Lee Irwin III 2003-06-10 8:54 ` 2.5.70-mm6 Maciej Soltysiak @ 2003-06-10 11:52 ` Maciej Soltysiak 1 sibling, 0 replies; 43+ messages in thread From: Maciej Soltysiak @ 2003-06-10 11:52 UTC (permalink / raw) To: William Lee Irwin III Cc: Martin J. Bligh, Andrew Morton, linux-kernel, linux-mm > 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 ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: 2.5.70-mm6 2003-06-09 18:51 ` 2.5.70-mm6 Martin J. Bligh 2003-06-09 19:42 ` 2.5.70-mm6 Maciej Soltysiak @ 2003-06-09 20:08 ` Felipe Alfaro Solana 2003-06-09 20:14 ` 2.5.70-mm6 Martin J. Bligh 1 sibling, 1 reply; 43+ messages in thread From: Felipe Alfaro Solana @ 2003-06-09 20:08 UTC (permalink / raw) To: Martin J. Bligh; +Cc: Maciej Soltysiak, Andrew Morton, LKML, linux-mm 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). ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: 2.5.70-mm6 2003-06-09 20:08 ` 2.5.70-mm6 Felipe Alfaro Solana @ 2003-06-09 20:14 ` Martin J. Bligh 2003-06-09 21:09 ` 2.5.70-mm6 Felipe Alfaro Solana 2003-06-10 9:56 ` 2.5.70-mm6 Felipe Alfaro Solana 0 siblings, 2 replies; 43+ messages in thread From: Martin J. Bligh @ 2003-06-09 20:14 UTC (permalink / raw) To: Felipe Alfaro Solana; +Cc: Maciej Soltysiak, Andrew Morton, LKML, linux-mm --On Monday, June 09, 2003 22:08:42 +0200 Felipe Alfaro Solana <felipe_alfaro@linuxmail.org> 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. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: 2.5.70-mm6 2003-06-09 20:14 ` 2.5.70-mm6 Martin J. Bligh @ 2003-06-09 21:09 ` Felipe Alfaro Solana 2003-06-10 9:56 ` 2.5.70-mm6 Felipe Alfaro Solana 1 sibling, 0 replies; 43+ messages in thread From: Felipe Alfaro Solana @ 2003-06-09 21:09 UTC (permalink / raw) To: Martin J. Bligh; +Cc: Maciej Soltysiak, Andrew Morton, LKML, linux-mm On Mon, 2003-06-09 at 22:14, Martin J. Bligh wrote: > --On Monday, June 09, 2003 22:08:42 +0200 Felipe Alfaro Solana <felipe_alfaro@linuxmail.org> 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. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: 2.5.70-mm6 2003-06-09 20:14 ` 2.5.70-mm6 Martin J. Bligh 2003-06-09 21:09 ` 2.5.70-mm6 Felipe Alfaro Solana @ 2003-06-10 9:56 ` Felipe Alfaro Solana 1 sibling, 0 replies; 43+ messages in thread From: Felipe Alfaro Solana @ 2003-06-10 9:56 UTC (permalink / raw) To: Martin J. Bligh; +Cc: Maciej Soltysiak, Andrew Morton, LKML, linux-mm On Mon, 2003-06-09 at 22:14, Martin J. Bligh wrote: > --On Monday, June 09, 2003 22:08:42 +0200 Felipe Alfaro Solana <felipe_alfaro@linuxmail.org> 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). ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: 2.5.70-mm6 2003-06-09 17:39 ` 2.5.70-mm6 Martin J. Bligh 2003-06-09 18:19 ` 2.5.70-mm6 Maciej Soltysiak @ 2003-06-09 18:39 ` Felipe Alfaro Solana 1 sibling, 0 replies; 43+ messages in thread From: Felipe Alfaro Solana @ 2003-06-09 18:39 UTC (permalink / raw) To: Martin J. Bligh; +Cc: Maciej Soltysiak, Andrew Morton, LKML, linux-mm On Mon, 2003-06-09 at 19:39, Martin J. Bligh wrote: > --On Monday, June 09, 2003 19:45:58 +0200 Maciej Soltysiak <solt@dns.toxicfilms.tv> 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. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: 2.5.70-mm6 2003-06-09 17:45 ` 2.5.70-mm6 Maciej Soltysiak 2003-06-09 17:39 ` 2.5.70-mm6 Martin J. Bligh @ 2003-06-09 18:06 ` Alistair J Strachan 2003-06-09 18:36 ` 2.5.70-mm6 Felipe Alfaro Solana ` (2 subsequent siblings) 4 siblings, 0 replies; 43+ messages in thread From: Alistair J Strachan @ 2003-06-09 18:06 UTC (permalink / raw) To: Maciej Soltysiak, Andrew Morton; +Cc: linux-kernel, linux-mm 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. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: 2.5.70-mm6 2003-06-09 17:45 ` 2.5.70-mm6 Maciej Soltysiak 2003-06-09 17:39 ` 2.5.70-mm6 Martin J. Bligh 2003-06-09 18:06 ` 2.5.70-mm6 Alistair J Strachan @ 2003-06-09 18:36 ` Felipe Alfaro Solana 2003-06-09 19:07 ` 2.5.70-mm6 Pasi Savolainen 2003-06-09 21:20 ` 2.5.70-mm6 Diego Calleja García 4 siblings, 0 replies; 43+ messages in thread From: Felipe Alfaro Solana @ 2003-06-09 18:36 UTC (permalink / raw) To: Maciej Soltysiak; +Cc: Andrew Morton, LKML, linux-mm 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? ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: 2.5.70-mm6 2003-06-09 17:45 ` 2.5.70-mm6 Maciej Soltysiak ` (2 preceding siblings ...) 2003-06-09 18:36 ` 2.5.70-mm6 Felipe Alfaro Solana @ 2003-06-09 19:07 ` Pasi Savolainen 2003-06-09 21:20 ` 2.5.70-mm6 Diego Calleja García 4 siblings, 0 replies; 43+ messages in thread From: Pasi Savolainen @ 2003-06-09 19:07 UTC (permalink / raw) To: linux-kernel; +Cc: linux-mm * Maciej Soltysiak <solt@dns.toxicfilms.tv>: >> . -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> ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: 2.5.70-mm6 2003-06-09 17:45 ` 2.5.70-mm6 Maciej Soltysiak ` (3 preceding siblings ...) 2003-06-09 19:07 ` 2.5.70-mm6 Pasi Savolainen @ 2003-06-09 21:20 ` Diego Calleja García 2003-06-09 21:40 ` 2.5.70-mm6 Andrew Morton 2003-06-10 12:10 ` 2.5.70-mm6 Grzegorz Jaskiewicz 4 siblings, 2 replies; 43+ messages in thread From: Diego Calleja García @ 2003-06-09 21:20 UTC (permalink / raw) To: Maciej Soltysiak; +Cc: akpm, linux-kernel On Mon, 9 Jun 2003 19:45:58 +0200 (CEST) Maciej Soltysiak <solt@dns.toxicfilms.tv> 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 ;( ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: 2.5.70-mm6 2003-06-09 21:20 ` 2.5.70-mm6 Diego Calleja García @ 2003-06-09 21:40 ` Andrew Morton 2003-06-10 12:10 ` 2.5.70-mm6 Grzegorz Jaskiewicz 1 sibling, 0 replies; 43+ messages in thread From: Andrew Morton @ 2003-06-09 21:40 UTC (permalink / raw) To: Diego Calleja García; +Cc: solt, linux-kernel Diego Calleja García <diegocg@teleline.es> wrote: > > On Mon, 9 Jun 2003 19:45:58 +0200 (CEST) > Maciej Soltysiak <solt@dns.toxicfilms.tv> 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. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: 2.5.70-mm6 2003-06-09 21:20 ` 2.5.70-mm6 Diego Calleja García 2003-06-09 21:40 ` 2.5.70-mm6 Andrew Morton @ 2003-06-10 12:10 ` Grzegorz Jaskiewicz 1 sibling, 0 replies; 43+ messages in thread From: Grzegorz Jaskiewicz @ 2003-06-10 12:10 UTC (permalink / raw) To: Diego Calleja García, Maciej Soltysiak; +Cc: akpm, linux-kernel -----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----- ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: 2.5.70-mm6 2003-06-07 22:14 2.5.70-mm6 Andrew Morton ` (6 preceding siblings ...) 2003-06-09 17:45 ` 2.5.70-mm6 Maciej Soltysiak @ 2003-06-11 2:15 ` Mingming Cao 2003-06-11 3:12 ` 2.5.70-mm6 Andrew Morton 7 siblings, 1 reply; 43+ messages in thread From: Mingming Cao @ 2003-06-11 2:15 UTC (permalink / raw) To: Andrew Morton; +Cc: linux-kernel, linux-mm, pbadari 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 ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: 2.5.70-mm6 2003-06-11 2:15 ` 2.5.70-mm6 Mingming Cao @ 2003-06-11 3:12 ` Andrew Morton 2003-06-11 22:15 ` 2.5.70-mm6 Mingming Cao 2003-06-12 16:37 ` 2.5.70-mm6 Mingming Cao 0 siblings, 2 replies; 43+ messages in thread From: Andrew Morton @ 2003-06-11 3:12 UTC (permalink / raw) To: Mingming Cao; +Cc: linux-kernel, linux-mm, pbadari Mingming Cao <cmm@us.ibm.com> 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"? ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: 2.5.70-mm6 2003-06-11 3:12 ` 2.5.70-mm6 Andrew Morton @ 2003-06-11 22:15 ` Mingming Cao 2003-06-12 16:37 ` 2.5.70-mm6 Mingming Cao 1 sibling, 0 replies; 43+ messages in thread From: Mingming Cao @ 2003-06-11 22:15 UTC (permalink / raw) To: Andrew Morton; +Cc: linux-kernel, linux-mm, pbadari On Tue, 2003-06-10 at 20:12, Andrew Morton wrote: > Mingming Cao <cmm@us.ibm.com> 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. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: 2.5.70-mm6 2003-06-11 3:12 ` 2.5.70-mm6 Andrew Morton 2003-06-11 22:15 ` 2.5.70-mm6 Mingming Cao @ 2003-06-12 16:37 ` Mingming Cao 2003-06-12 17:50 ` 2.5.70-mm6 Andrew Morton 1 sibling, 1 reply; 43+ messages in thread From: Mingming Cao @ 2003-06-12 16:37 UTC (permalink / raw) To: Andrew Morton; +Cc: linux-kernel, linux-mm, pbadari > Mingming Cao <cmm@us.ibm.com> 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 ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: 2.5.70-mm6 2003-06-12 16:37 ` 2.5.70-mm6 Mingming Cao @ 2003-06-12 17:50 ` Andrew Morton 2003-06-12 18:43 ` 2.5.70-mm6 Mingming Cao 0 siblings, 1 reply; 43+ messages in thread From: Andrew Morton @ 2003-06-12 17:50 UTC (permalink / raw) To: Mingming Cao; +Cc: linux-kernel, linux-mm, pbadari Mingming Cao <cmm@us.ibm.com> wrote: > > > > Mingming Cao <cmm@us.ibm.com> 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. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: 2.5.70-mm6 2003-06-12 17:50 ` 2.5.70-mm6 Andrew Morton @ 2003-06-12 18:43 ` Mingming Cao 0 siblings, 0 replies; 43+ messages in thread From: Mingming Cao @ 2003-06-12 18:43 UTC (permalink / raw) To: Andrew Morton; +Cc: linux-kernel, linux-mm, pbadari On Thu, 2003-06-12 at 10:50, Andrew Morton wrote: > > > Mingming Cao <cmm@us.ibm.com> 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. ^ permalink raw reply [flat|nested] 43+ messages in thread
end of thread, other threads:[~2003-06-12 18:29 UTC | newest] Thread overview: 43+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-06-07 22:14 2.5.70-mm6 Andrew Morton 2003-06-08 0:37 ` 2.5.70-mm6 Alexander Hoogerhuis 2003-06-08 0:56 ` 2.5.70-mm6 Andrew Morton 2003-06-08 1:13 ` 2.5.70-mm6 Alexander Hoogerhuis 2003-06-08 12:25 ` 2.5.70-mm6 Christoph Hellwig 2003-06-08 12:09 ` 2.5.70-mm6 Felipe Alfaro Solana 2003-06-08 15:56 ` [patch] 2.5.70-mm6: ethertap.c doesn't compile Adrian Bunk 2003-06-08 16:00 ` Arnaldo Carvalho de Melo 2003-06-08 21:41 ` Adrian Bunk 2003-06-08 22:52 ` 2.5.70-mm6 Pasi Savolainen 2003-06-08 23:17 ` [patch] 2.5.70-mm6: isp driver cleanups Adrian Bunk 2003-06-08 23:27 ` Andrew Morton 2003-06-08 23:24 ` 2.5.70-mm6 Joe 2003-06-09 17:45 ` 2.5.70-mm6 Maciej Soltysiak 2003-06-09 17:39 ` 2.5.70-mm6 Martin J. Bligh 2003-06-09 18:19 ` 2.5.70-mm6 Maciej Soltysiak 2003-06-09 18:51 ` 2.5.70-mm6 Martin J. Bligh 2003-06-09 19:42 ` 2.5.70-mm6 Maciej Soltysiak 2003-06-09 20:04 ` 2.5.70-mm6 William Lee Irwin III 2003-06-10 8:54 ` 2.5.70-mm6 Maciej Soltysiak 2003-06-10 9:20 ` 2.5.70-mm6 William Lee Irwin III 2003-06-10 11:31 ` 2.5.70-mm6 Mike Galbraith 2003-06-10 11:41 ` 2.5.70-mm6 William Lee Irwin III 2003-06-10 18:53 ` 2.5.70-mm6 Mike Galbraith 2003-06-10 19:11 ` 2.5.70-mm6 William Lee Irwin III 2003-06-10 11:52 ` 2.5.70-mm6 Maciej Soltysiak 2003-06-09 20:08 ` 2.5.70-mm6 Felipe Alfaro Solana 2003-06-09 20:14 ` 2.5.70-mm6 Martin J. Bligh 2003-06-09 21:09 ` 2.5.70-mm6 Felipe Alfaro Solana 2003-06-10 9:56 ` 2.5.70-mm6 Felipe Alfaro Solana 2003-06-09 18:39 ` 2.5.70-mm6 Felipe Alfaro Solana 2003-06-09 18:06 ` 2.5.70-mm6 Alistair J Strachan 2003-06-09 18:36 ` 2.5.70-mm6 Felipe Alfaro Solana 2003-06-09 19:07 ` 2.5.70-mm6 Pasi Savolainen 2003-06-09 21:20 ` 2.5.70-mm6 Diego Calleja García 2003-06-09 21:40 ` 2.5.70-mm6 Andrew Morton 2003-06-10 12:10 ` 2.5.70-mm6 Grzegorz Jaskiewicz 2003-06-11 2:15 ` 2.5.70-mm6 Mingming Cao 2003-06-11 3:12 ` 2.5.70-mm6 Andrew Morton 2003-06-11 22:15 ` 2.5.70-mm6 Mingming Cao 2003-06-12 16:37 ` 2.5.70-mm6 Mingming Cao 2003-06-12 17:50 ` 2.5.70-mm6 Andrew Morton 2003-06-12 18:43 ` 2.5.70-mm6 Mingming Cao
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).