public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jesper Juhl <jesper.juhl@gmail.com>
To: Jens Axboe <jens.axboe@oracle.com>
Cc: Linus Torvalds <torvalds@osdl.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@osdl.org>,
	Jesper Juhl <jesper.juhl@gmail.com>
Subject: Re: Simple script that locks up my box with recent kernels
Date: Fri, 24 Nov 2006 00:52:13 +0100	[thread overview]
Message-ID: <200611240052.13719.jesper.juhl@gmail.com> (raw)
In-Reply-To: <20061122110740.GA8055@kernel.dk>

On Wednesday 22 November 2006 12:07, Jens Axboe wrote:
> On Wed, Nov 22 2006, Jesper Juhl wrote:
> > On 22/11/06, Jens Axboe <jens.axboe@oracle.com> wrote:
> > >On Wed, Nov 22 2006, Jesper Juhl wrote:
> > >> On 22/11/06, Jens Axboe <jens.axboe@oracle.com> wrote:
> > >> >On Tue, Nov 21 2006, Linus Torvalds wrote:
> > >> >> I don't think we use any irq-disable locking in the VM itself, but I
> > >> >could
> > >> >> imagine some nasty situation with the block device layer getting into 
> > >a
> > >> >> deadlock with interrupts disabled when it runs out of queue entries 
> > >and
> > >> >> cannot allocate more memory..
> > >> >
> > >> >Not likely. Request allocation is done with GFP_NOIO and backed by a
> > >> >memory pool, so as long the vm doesn't go totally nuts because
> > >> >__GFP_WAIT is set, we should be safe there. If it did go crazy, I
> > >> >suspect a sysrq-t would still work.
> > >> >
> > >> >If bouncing is involved for swap, we do have a potential deadlock issue
> > >> >that isn't fixed yet. I just whipped up this completely untested patch,
> > >> >it should shed some light on that issue.
> > >> >
> > >> Thanks Jens, I'll apply that later tonight and force a few lockups and
> > >> see if I get any extra details with that patch.
> > >
> > >Can you post a full dmesg too, as well as clarify which device holds the
> > >swap space?
> > >
> > Sure. I'll post a full dmesg as soon as I get home.
> > 
> > The swap partition is on a IBM Ultrastar U160 10K RPM SCSI disk,
> > hooked up to an Adaptec 29160N controller, using the aic7xxx driver.
> > That disk holds all my filesystems as well and the controller also has
> > a SCSI DVD drive and a SCSI CD writer attached to it.  No SATA/PATA
> > devices in the box, in case that matters.
> 
> Does the box survive io intensive workloads? 

It seems to. It does get sluggish as hell when there is lots of disk I/O but
it seems to be able to survive.  
I'll try some more, with some IO benchmarks + various other stuff to see 
if I can get it to die that way.

> Have you tried using net or 
> serial console to see if it spits out any info before it crashes?

Lacking a second box at the moment, so that's not an option currently :(


> I 
> would not be too surprised if it's the aic7xxx driver taking a dive, I'd
> be a lot more surprised if it's actually the bouncing (I don't think you
> do any, can you post cat /proc/meminfo | grep -i bounce on that box?) or
> a generic vm/block bug causing you problems.
> 
$ cat /proc/meminfo | grep -i bounce
Bounce:              0 kB


-- 
Jesper Juhl <jesper.juhl@gmail.com>



  reply	other threads:[~2006-11-23 23:50 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-06 23:36 Simple script that locks up my box with recent kernels Jesper Juhl
2006-10-06 23:54 ` Andrew Morton
2006-10-07  0:06   ` Jesper Juhl
2006-10-07  0:21     ` Jesper Juhl
2006-10-07  3:11 ` Linus Torvalds
2006-10-07 21:02   ` Jesper Juhl
2006-10-07 21:25     ` Linus Torvalds
2006-10-08 23:33       ` Jesper Juhl
2006-10-16 22:45         ` Jesper Juhl
2006-10-16 23:04           ` Linus Torvalds
2006-10-16 23:13             ` Jesper Juhl
2006-10-23 20:30               ` Jesper Juhl
2006-11-22  0:46                 ` Jesper Juhl
2006-11-22  2:36                   ` Linus Torvalds
2006-11-22  3:25                     ` Dave Jones
2006-11-22  3:44                       ` Linus Torvalds
2006-11-22  3:49                         ` Dave Jones
2006-11-22 10:32                           ` Pádraig Brady
2006-11-22 17:58                             ` Dave Jones
2006-11-22  8:03                     ` Jens Axboe
2006-11-22 10:55                       ` Jesper Juhl
2006-11-22 10:57                         ` Jens Axboe
2006-11-22 11:04                           ` Jesper Juhl
2006-11-22 11:07                             ` Jens Axboe
2006-11-23 23:52                               ` Jesper Juhl [this message]
2006-11-24  6:52                                 ` Jens Axboe
2006-11-24  9:41                                   ` Jesper Juhl
2006-11-24  9:46                                     ` Jens Axboe
2006-11-24  9:52                                       ` Jesper Juhl
2006-11-23 10:22                             ` Jesper Juhl
2006-11-23 23:48                           ` Jesper Juhl
2006-11-22 11:00                     ` Jesper Juhl
2006-11-24  0:50                     ` Jesper Juhl
2006-10-07  3:40 ` Grant Coady

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=200611240052.13719.jesper.juhl@gmail.com \
    --to=jesper.juhl@gmail.com \
    --cc=akpm@osdl.org \
    --cc=jens.axboe@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@osdl.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox