Re: 2.6.20-mm1 - Oops using Minix 3 file system

[Cédric Augonnet]

2007/2/17, Daniel Aragonés <danarag@xxxxxxxxx>:
> On 2/17/07, Cédric Augonnet <cedric.augonnet@xxxxxxxxx> 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
> >

More precisely, i traced how we call the count_free procedure : it is
once called by minix_count_free_blocks (and succeeds) and then by
minix_count_free_inodes and fails.

For the first call, which does not fail :
  minix_count_free_blocks(0xd4105240)
      sbi->s_zmap_blocks = 0x00000010
      sbi->s_nzones = 0x00080000
      sbi->s_firstdatazone = 0x00001266
      (sbi->s_nzones - sbi->s_firstdatazone + 1) = 0x0007ed9b

 count_free( ...., 0x00000010, 0x0007ed9b)
       unsigned numblocks = 0x00000010 = 16
       __u32 numbits =0x0007ed9b = 519579
       bh->b_size = 0x00001000 = 4096
== > i = 3506
This is consistent with the formula



For the second call
  minix_count_free_inodes(0xd4105240)
      sbi->s_imap_blocks = 0x0000000a
      sbi->s_ninodes = 0x00009280

  count_free(..., 0x0000000a, 0x00009281)
       unsigned numblocks = 0x0000000a  = 10
       __u32 numbits = 0x00009281 = 37505
       bh->b_size =0x00001000 = 4096
==> i = 536838736

(gdb) p/x (( 0x00009281 - (0x00a-1) * 0x1000 * 8) / 16) * 2
$20 = 0xffff8252
$21 = -32174

(Very sorry for than mess !)

> 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
> emulating.
>
> Also, though your dmesg shows a mounted loop partition, the minix
> subpartition in it is not stated. So it cannot be accessed.

Well i actually do access to this partition, i can edit it and use it,
this on Linux. Sorry if this is not clear.

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

Actually i am running a full Minix OS in the qemu emulator and all
Linux does is providing me some disk images.

To make it more clear, i created a disk image file on Linux.  I
created a FS on that partition in Minix using mkfs inside qemu running
Minix. And then i just want to mount this partition to have access to
this filesystem on my Linux. This is ugly for sure, but it should
still not be oopsing.

> Regards
>
> Daniel

I thought you could be interested in having the actual image doing all
these nasty things :
     http://perso.ens-lyon.fr/cedric.augonnet/Linux/br.tar
     tar -xvf br.tar   should produce some br.img file that you can
mount using
     mount -o loop -t minix br.img /mnt/foo
     df -h should there be issuing the oops.

     Please remark that all the files inside this image were created
with Linux, not Minix, the _only_ thing done with minix and qemu was
to create the file system on the image.

Hoping this will be a bit useful,
Regards,
Cédric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/