From mboxrd@z Thu Jan 1 00:00:00 1970 From: Robert Hancock Subject: Re: [PATCH] sata_nv ADMA/NCQ support for nForce4 (updated) II Date: Sun, 22 Oct 2006 10:36:14 -0600 Message-ID: <453B9DFE.9070802@shaw.ca> References: <45397D22.4030200@shaw.ca> <453B1946.3070201@shaw.ca> <200610221519.20721.ak@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from shawidc-mo1.cg.shawcable.net ([24.71.223.10]:6940 "EHLO pd3mo1so.prod.shaw.ca") by vger.kernel.org with ESMTP id S1751272AbWJVQgY (ORCPT ); Sun, 22 Oct 2006 12:36:24 -0400 In-reply-to: <200610221519.20721.ak@suse.de> Sender: linux-ide-owner@vger.kernel.org List-Id: linux-ide@vger.kernel.org To: Andi Kleen Cc: linux-kernel@vger.kernel.org, linux-ide@vger.kernel.org Andi Kleen wrote: >> Hmm.. The system hanging up for 5 minutes > > I've actually seen that before on different systems. Sometimes > under some IO loads writes can be really starved for that long > and they block the calling process. Normally it only happened > when a very slow IO device (like slow USB storage) was involved > > e.g. typical trace: > > sshd D ffff810001072b20 0 11554 3381 11556 11127 (NOTLB) > ffff810114dffb08 0000000000000086 5353535353535353 5353535353535353 > 5353535353535353 000000000000057e ffff81014b344af0 ffff81014b404770 > 000001ede41c7140 ffff81014b344cc8 5353535300000001 5353535353535353 > Call Trace: > [] start_this_handle+0x2f4/0x37b > [] journal_start+0xcd/0x105 > [] > DWARF2 unwinder stuck at 0xffff81014b11e800 > Leftover inexact backtrace: > [] ext3_dirty_inode+0x28/0x7b > [] __mark_inode_dirty+0x2c/0x17d > [] do_generic_mapping_read+0x3b0/0x3c2 > [] file_read_actor+0x0/0xd6 > [] generic_file_aio_read+0x164/0x1b8 > [] do_sync_read+0xc9/0x10c > [] autoremove_wake_function+0x0/0x2e > [] cond_resched+0x34/0x3b > [] __alloc_pages+0x5e/0x2ae > [] cache_alloc_refill+0xf1/0x1f8 > [] vfs_read+0xa8/0x14e > [] kernel_read+0x38/0x4c > [] do_execve+0x105/0x1f9 > [] sys_execve+0x33/0x8b > [] stub_execve+0x67/0xb0 > > > I've got quite a lot of processes in journal_start -> start_this_handle. > I suppose they're waiting for the transaction to finish. It could be that with 8GB of RAM you've got a ton of buffered writes piled up which the kernel has decided need to be written out and which takes 5 minutes.. That amount of time seems a bit extreme to be blocking other IO, though.. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from hancockr@nospamshaw.ca Home Page: http://www.roberthancock.com/