public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Frank Steiner <fsteiner-mail@bio.ifi.lmu.de>
To: James Bottomley <James.Bottomley@SteelEye.com>
Cc: Jens Axboe <axboe@suse.de>,
	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: Sat, 25 Dec 2004 23:49:46 +0100	[thread overview]
Message-ID: <41CDEE8A.80407@bio.ifi.lmu.de> (raw)
In-Reply-To: <1103916492.5448.27.camel@mulgrave>

Hi all,

thanks for caring! I don't fully understand what you are talking about
in detail :-), but maybe I can give some more information that could help.

- If you suspect the gdth driver causing the error, it must be some very
   special situation on this host causing it. We have 2 other hosts
   with the same icp vortex GDT8514RZ controller like the host
   where the kblockd message occured. They all have internal raid1 disks
   (73gb or 146gb). One is our main NFS server (it has two raid1 with 146g
   each) and it has a lot of I/O, sometimes 50GB or more a day with peaks
   up to 200MB per second (reading), and we never saw any kblockd message
   in the logs (I just checked them all).

- there were no messages "around" the kblockd messages in /var/log/messages
   but the usual ones about remote ssh login, cron jobs etc., but the messages
   were all more than 10 minutes "away" before and after the kblockd happened.

- not much I/O can have taken place on the internal disks attached to the
   icp controller when the bug was triggered, because all the I/O for
   e.g. updates or backups happens only in the night for all hosts except
   the NFS servers.

- the host where the error occured is the only one that (in addition to the icp
   controller with the internal raid1) has two external SCSI-to-IDE-Raids
   attached to the adaptec 29160 controller that runs with the aic7xxx modul.

- According to the user working a lot on this host, it is possible that he
   did a dump of a large mysql database on the external SCSI-to-IDE raids
   around the time where the kblockd messages occured. He can't tell
   for sure if it was the same time.
   Since we never had any problems on the other hosts with the icp
   controllers and the gdth module, maybe the bug occurs in the aic7xxx
   module? Or if it occurs in the gdth, maybe it's caused by some interaction
   between the gdth and the aic7xxx driver both accessing the scsi bus?
   The gdth driver is compiled into the kernel, the aic7xxx loads as module.

- I did a "dd if=/dev/sd? of=/dev/null bs=500M" for all disks (sda on gdth,
   sdb and sdc on aic7xxx) to check if it could be some disk error or sth..
   but those dd went fine without triggering the bug.

Don't know if this info helps...

Please let me know if there is something I can do to help finding
the bug. I don't mind to compile a special kernel for this host if I can
turn on some debugging options. I saw some DEBUG_GDTH variable in gdth.c,
but I don't know how to turn this on exactly, would I have to define the
variable in the header file somehow? (Sorry, I'm not very familiar with
C :-() For the aic7xxx I found two config options AIC7XXX_DEBUG_ENABLE
and AIC7XXX_DEBUG_MASK. Could that help you identify the bug if I have all
this enabled when the bug shows up again?

Thanks!

Frank



-- 
Dipl.-Inform. Frank Steiner   Web:  http://www.bio.ifi.lmu.de/~steiner/
Lehrstuhl f. Bioinformatik    Mail: http://www.bio.ifi.lmu.de/~steiner/m/
LMU, Amalienstr 17            Phone: +49 89 2180-4049
80333 Muenchen, Germany       Fax:              -4054
* Rekursion kann man erst verstehen, wenn man Rekursion verstanden hat. *

  reply	other threads:[~2004-12-25 22:38 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
2004-12-25 22:49           ` Frank Steiner [this message]
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=41CDEE8A.80407@bio.ifi.lmu.de \
    --to=fsteiner-mail@bio.ifi.lmu.de \
    --cc=James.Bottomley@SteelEye.com \
    --cc=akpm@osdl.org \
    --cc=axboe@suse.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox