Re: getblk spins endlessly in 2.4.19 SMP

[Peter T. Breuer]

Hi - thanks for replying!

In article <[e-mail]> 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