From: Matthias Schniedermeyer <ms@citd.de>
To: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: linux-kernel@vger.kernel.org, Jens Axboe <axboe@suse.de>
Subject: Re: Kernel 2.6.6 & 2.6.7 sometime hang after much I/O
Date: Sun, 20 Jun 2004 16:38:21 +0200 [thread overview]
Message-ID: <20040620143821.GA28338@citd.de> (raw)
In-Reply-To: <20040620141734.GA28048@citd.de>
On Sun, Jun 20, 2004 at 04:17:34PM +0200, Matthias Schniedermeyer wrote:
> On Sun, Jun 20, 2004 at 11:05:23PM +1000, Nick Piggin wrote:
> > Matthias Schniedermeyer wrote:
> >
> > >Here we go.
> > >
> > >Addendum: After some time more and more konsole froze. Up to the point
> > >where i (had to) kill(ed) X(CTRL-ALT-Backspace) and after i couldn't
> > >even log in at the console anymore i rebooted (into 2.6.5). Then i
> > >recompiled 2.6.7 with SYSRQ-support and tried to reproduce the hanging
> > >without X. After 3 runs i "gave up" and started X. Here i had luck and
> > >the process ('cut-movie.pl') froze at first try. Then i killed X and did
> > >the above on the console.
> > >
> > >As the system is currently unsuable enough to reboot, i will reboot in
> > >2.6.5 after this mail, but i can always reboot into 2.6.7 if you need
> > >more input.
> > >
> > >
> >
> > The attached trace was with 2.6.7, right?
>
> Yes.
>
> > Can you reproduce the hang, then, as root, do:
> >
> > echo 1024 > /sys/block/sda/queue/nr_requests
> >
> > Replace sda with whatever devices your hung processes were
> > doing IO to. Do things start up again?
>
> 1 try (with X) with unchanged nr_requests. (I was stupid enough to issues the
> command on the wrong HDD :-) )
> (AFAIR i had the same situation with 2.6.6, sometimes the hang didn't happen)
>
> 6 tries (with X) with nr_requests=1024 and no hang.
>
> 1 try with nr_requests back to 128 and now it hangs.
> now changing to nr_request=1024 doesn't seem to change anyting, my
> konsoles start to freeze.
>
>
> Don't know if it is relevant but the bytes transfered are always rougly
> around 3000-3400MB (1500-1700 MB read & 1500-1700 MB write. The program
> reads 100MB, then writes 100MB, then issues "sync", the hangs happend
> always about every after 15-17 "rounds")
After a fresh bootup i did another try with nr_requests=1024.
This time it froze at the third try. At the same round as the former
try. (17th round)
Bis denn
--
Real Programmers consider "what you see is what you get" to be just as
bad a concept in Text Editors as it is in women. No, the Real Programmer
wants a "you asked for it, you got it" text editor -- complicated,
cryptic, powerful, unforgiving, dangerous.
prev parent reply other threads:[~2004-06-20 14:38 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-06-20 9:41 Kernel 2.6.6 & 2.6.7 sometime hang after much I/O Matthias Schniedermeyer
2004-06-20 10:29 ` Nick Piggin
2004-06-20 11:59 ` Matthias Schniedermeyer
2004-06-20 13:05 ` Nick Piggin
2004-06-20 14:17 ` Matthias Schniedermeyer
2004-06-20 14:19 ` Jens Axboe
2004-06-20 14:43 ` Matthias Schniedermeyer
2004-06-20 14:38 ` Matthias Schniedermeyer [this message]
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=20040620143821.GA28338@citd.de \
--to=ms@citd.de \
--cc=axboe@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=nickpiggin@yahoo.com.au \
/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.