[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20061122110740.GA8055@kernel.dk>
Date: Wed, 22 Nov 2006 12:07:40 +0100
From: Jens Axboe <jens.axboe@...cle.com>
To: Jesper Juhl <jesper.juhl@...il.com>
Cc: Linus Torvalds <torvalds@...l.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Andrew Morton <akpm@...l.org>
Subject: Re: Simple script that locks up my box with recent kernels
On Wed, Nov 22 2006, Jesper Juhl wrote:
> On 22/11/06, Jens Axboe <jens.axboe@...cle.com> wrote:
> >On Wed, Nov 22 2006, Jesper Juhl wrote:
> >> On 22/11/06, Jens Axboe <jens.axboe@...cle.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? Have you tried using net or
serial console to see if it spits out any info before it crashes? 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.
--
Jens Axboe
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists