From: Andrew Morton <akpm@digeo.com>
To: yuval yeret <yuval_yeret@hotmail.com>
Cc: linux-kernel@vger.kernel.org, yuval@exanet.com
Subject: Re: 2.4.18-14 kernel stuck during ext3 umount with ping still responding
Date: Thu, 09 Jan 2003 02:06:55 -0800 [thread overview]
Message-ID: <3E1D49BF.5114A896@digeo.com> (raw)
In-Reply-To: F12N44yQegpeDBHkKx400013b3e@hotmail.com
yuval yeret wrote:
>
> Hi,
>
> I'm running a 2.4.18-14 kernel with a heavy IO profile using ext3 over RAID
> 0+1 volumes.
>
> >From time to time I get a black screen stuck machine while trying to umount
> a volume during an IO workload (as part of a failback solution - but after
> killing all IO processes ), with ping still responding, but everything else
> mostly dead.
>
> I tried using the forcedumount patch to solve this problem - to no avail.
> Also tried upgrading the qlogic drivers to the latest drivers from Qlogic.
>
> After one of the occurences I managed to get some output using the sysrq
> keys.
>
> This seems similar to what is described in
> http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=77508 but with a
> different call trace
>
> What I have here is what I managed to copy down (for some reason pgup/pgdown
> didn't work so not all information is full...) together with a manual lookup
> of the call trace
> from /proc/ksyms :
>
> process umount
> EIP c01190b8 (set_running_and_schedule)
> call trace:
> c01144c9 f25f9ec0 IO_APIC_get_PCI_irq_vector
> c010a8b0 f25f9ed0 enable_irq
> c014200c f25f9ef0 fsync_buffers_list
> c0155595 f25f9efc clear_inode
> c015553d f25f9f2c invalidate_inodes
> c01461d8 f25f9f78 get_super
> c014a629 f25f9f94 path_release
> c0157c58 f25f9fc0 sys_umount
> c0108cab sys_sigaltstack
>
> Any idea what can cause this ?
>
If you have a large amount of data against two or more filesystems,
and you try to unmount one of them the kernel can seize up for a
very long time in the fsync_dev()->sync_buffers() function. Under
these circumstances that function has O(n*n) search complexity
and n is quite large.
However your backtrace shows neither of those functions.
Still, as an experiment it would be interesting to see if the below
patch fixes it up. It converts O(n*n) to O(m), where m > n.
fs/buffer.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
--- 2420/fs/buffer.c~a Thu Jan 9 02:03:06 2003
+++ 2420-akpm/fs/buffer.c Thu Jan 9 02:04:02 2003
@@ -307,11 +307,11 @@ int sync_buffers(kdev_t dev, int wait)
* 2) write out all dirty, unlocked buffers;
* 2) wait for completion by waiting for all buffers to unlock.
*/
- write_unlocked_buffers(dev);
+ write_unlocked_buffers(NODEV);
if (wait) {
- err = wait_for_locked_buffers(dev, BUF_DIRTY, 0);
+ err = wait_for_locked_buffers(NODEV, BUF_DIRTY, 0);
write_unlocked_buffers(dev);
- err |= wait_for_locked_buffers(dev, BUF_LOCKED, 1);
+ err |= wait_for_locked_buffers(NODEV, BUF_LOCKED, 1);
}
return err;
}
_
next prev parent reply other threads:[~2003-01-09 9:58 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-01-09 9:38 2.4.18-14 kernel stuck during ext3 umount with ping still responding yuval yeret
2003-01-09 9:58 ` Arjan van de Ven
2003-01-09 10:06 ` Andrew Morton [this message]
-- strict thread matches above, loose matches on Subject: below --
2003-01-15 19:13 yuval yeret
2003-01-22 18:02 yuval yeret
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3E1D49BF.5114A896@digeo.com \
--to=akpm@digeo.com \
--cc=linux-kernel@vger.kernel.org \
--cc=yuval@exanet.com \
--cc=yuval_yeret@hotmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.