2007/2/17, Daniel Aragonés <[email protected]>:
On 2/17/07, Cédric Augonnet <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
