mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Peter T. Breuer" <ptb@it.uc3m.es>
To: Andrew Morton <akpm@digeo.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: getblk spins endlessly in 2.4.19 SMP
Date: Fri, 3 Jan 2003 01:30:39 +0100	[thread overview]
Message-ID: <200301030030.h030Udk24218@oboe.it.uc3m.es> (raw)
In-Reply-To: <3E14906E.7F6D3226@digeo.com>


Hi - thanks for replying!

In article <3E14906E.7F6D3226@digeo.com> you wrote:
> "Peter T. Breuer" wrote:
>> 
>> get_blk() loops forever internally for in a sort piece of driver code of
>> mine.

> probably it found some buffers with the wrong ->b_size, tried to
> get rid of them via try_to_free_buffers(), failed, and then fell
> into the "oh, we're out of memory" loop.

Sounds just like what I see.

> You need to work out why grow_dev_page() is seeing buffers with
> the wrong size against the page.  Be looking for incorrect or
> missing calls to set_blocksize().

Set_blocksize was indeed not called before. I had set the size on the
kernel blksize_size array by hand. I now see that in addition to that
set_blocksize sets the bdev->bd_inode->i_blkbits value.

But I'm now calling set_blocksize when I set the device block size,
and no change.  The portable (running SMP with one processor) still
works fine.  The SMP server goes into a loop on the first call to
getblk, because get_hash_table returns NULL when asked for a block of
size 1024. Always. Same binaries. Both machines are running the same
kernel and modules.

Can you see anything that would explain the difference? Should
I call for a 4K block instead? I'm mystified. Tomorrow I'll boot
the server nosmp and see what happens.

I'll look inside grow_dev_page. It this called from free_more_memory
or from grow_buffers? Ahh .. the latter. Indeed, if it returns 0,
grow_buffers will return 0, and then we try free_more_memory,
whoch presumably does nothing, and loop.

grow_dev_page fails if find_or_create_page fails. Or if it returns a
page of the wrong size. Or if create_buffers fails. Sigh .. I guess
I get a page of the wrong size. I'll try asking for 4K instead of 1K.

Is there some way I  can "seed" things so that a call to getblk
will succeed? I mean, by making a buffer of teg right size be
available?

Peter

      reply	other threads:[~2003-01-03  0:22 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-01-02 17:46 Peter T. Breuer
2003-01-02 19:18 ` Andrew Morton
2003-01-03  0:30   ` Peter T. Breuer [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=200301030030.h030Udk24218@oboe.it.uc3m.es \
    --to=ptb@it.uc3m.es \
    --cc=akpm@digeo.com \
    --cc=linux-kernel@vger.kernel.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

all inboxes | Powered by JetHome®