[lkml]   [2007]   [Feb]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: 2.6.20-mm1 - Oops using Minix 3 file system
    On 2/17/07, Cédric Augonnet <> wrote:

    > It appears that the trouble is in the count_free of file
    > fs/minix/bitmap.c . This procedure is actually called twice when we
    > issue a df command.
    > The point where things start to get strange is
    > i = ((numbits - (numblocks-1) * bh->b_size * 8) / 16) * 2; at line 36
    > In the first call to that procedure i have
    > i = 3506
    > bh->b_data = 0xd4e79000
    > Whereas in the second call i have something much different :
    > i = 536838736
    > bh->b_data = d4e78000

    Well, that line is modified by my patch. The original one is:
    i = ((numbits-(numblocks-1)*BLOCK_SIZE*8)/16)*2;

    As you see, the constant is substituted by a variable. As you are
    running under emulation, the true value of that variable ( 4096 in
    standard minix3 releases, instead of the constant 1024 in minix1 and
    minix2), is probably found where it should not be found, or not found
    at all. And the result is what you show. Minix 3 provides for a
    variable size of the blocks. Try to find what block size you are

    Also, though your dmesg shows a mounted loop partition, the minix
    subpartition in it is not stated. So it cannot be accessed.

    By the way, you don't need to support minix on your Linux box to run
    it through an emulator, do you?


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-02-17 17:47    [W:0.043 / U:9.060 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site