From: James Bottomley <James.Bottomley@SteelEye.com>
To: Jens Axboe <axboe@suse.de>
Cc: Frank Steiner <fsteiner-mail@bio.ifi.lmu.de>,
Denis Vlasenko <vda@port.imtp.ilyichevsk.odessa.ua>,
Linux Kernel <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@osdl.org>
Subject: Re: kblockd/1: page allocation failure in 2.6.9
Date: Fri, 24 Dec 2004 13:28:12 -0600 [thread overview]
Message-ID: <1103916492.5448.27.camel@mulgrave> (raw)
In-Reply-To: <20041224132006.GC2528@suse.de>
On Fri, 2004-12-24 at 14:20 +0100, Jens Axboe wrote:
> This looks fishy - this is GFP_ATOMIC | GFP_DMA, where it should only be
> GFP_ATOMIC. gdth should not have shost->cmd_pool->gfp_mask ==
> GFP_ATOMIC, that looks like a bug in the driver.
This may be a fault in the gdth driver (if that's where the trace came
from). It sets unchecked_isa_dma to 1 in its template and then resets
it at various places in the driver it may have been reset too late to
prevent it from getting the GFP_DMA scsi command pool.
> Apart from that, the trace looks sane and the SCSI mid layer should
> recover from this condition and not cause a hung io subsystem. The only
> way I can see this fail is if the scsi host free_list is not filled for
> some reason during init, or if the commands allocated from there are
> lost or never finished by the hardware.
Yes, I've checked this out in SCSI by artificially simulating a memory
allocation failure in scsi_get_command(). My system behaves nicely even
as I rack up the failures. Is there anything else unusual in the log
that may indicate what the problem is?
James
next prev parent reply other threads:[~2004-12-24 19:28 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-12-21 7:39 kblockd/1: page allocation failure in 2.6.9 Frank Steiner
2004-12-23 11:26 ` Frank Steiner
2004-12-23 15:51 ` Denis Vlasenko
2004-12-23 15:55 ` Frank Steiner
2004-12-24 13:20 ` Jens Axboe
2004-12-24 19:28 ` James Bottomley [this message]
2004-12-25 22:49 ` Frank Steiner
2004-12-26 15:46 ` James Bottomley
2004-12-26 22:31 ` Frank Steiner
2005-01-10 9:19 ` Frank Steiner
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=1103916492.5448.27.camel@mulgrave \
--to=james.bottomley@steeleye.com \
--cc=akpm@osdl.org \
--cc=axboe@suse.de \
--cc=fsteiner-mail@bio.ifi.lmu.de \
--cc=linux-kernel@vger.kernel.org \
--cc=vda@port.imtp.ilyichevsk.odessa.ua \
/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.