2007/2/15, Andrew Morton <[email protected]>:
>
> Temporarily at
>
> http://userweb.kernel.org/~akpm/2.6.20-mm1/
>
> Will appear later at
>
>
> Changes since 2.6.20-rc6-mm3:
>
> -minix-v3-support.patch
Hi Daniel,
On 2.6.20-rc6-mm3 and 2.6.20-mm1, i get an OOPS when using the minix 3
file system. I enclose the dmesg and the .config to that mail.
Here are the steps to reproduce this oops (they involve using qemu to
run Minix 3)
- First create a 2GB image using
qemu-img create minix.img 2G
(Please note that this seem to be producing an eroneous image)
- Then launch Minix inside qemu to make a minix partition on this
image using mkfs on the corresponding device.
- Mount the image on loopback using
mount -t minix -o loop minix.img /mnt/qemu/
- issue a "df" command on /mnt/qemu
This oops occurs everytime i use df on this directory. However, this
does not occur if the image was for a 1MB partition. And it does not
occur if the partition on which we created minix.img was the same as
the partition on which qemu stands. Sounds like qemu has an issue and
creates an erroneous partition which linux does not handle correctly.
Regards, and thanks for your patch by the way !
C?dric
On 2/17/07, C?dric Augonnet <[email protected]> wrote:
> ...
> Hi Daniel,
>
> On 2.6.20-rc6-mm3 and 2.6.20-mm1, i get an OOPS when using the minix 3
> file system. I enclose the dmesg and the .config to that mail.
>
> Here are the steps to reproduce this oops (they involve using qemu to
> run Minix 3)
> - First create a 2GB image using
> qemu-img create minix.img 2G
> (Please note that this seem to be producing an eroneous image)
> - Then launch Minix inside qemu to make a minix partition on this
> image using mkfs on the corresponding device.
> - Mount the image on loopback using
> mount -t minix -o loop minix.img /mnt/qemu/
> - issue a "df" command on /mnt/qemu
>...
Well, a glance at your dmesg doesn' show that a minix partition was
recognized. Otherwise it would sow it. So you have not such a
partition within your drives.
You are using an emulator to run minix. You will have the same problem
if you run minix2 or minix3 through an emulator and not from a real
minix2 or minix3 partition.
Regards,
Daniel
2007/2/17, Daniel Aragon?s <[email protected]>:
> Well, a glance at your dmesg doesn' show that a minix partition was
> recognized. Otherwise it would sow it. So you have not such a
> partition within your drives.
>
> You are using an emulator to run minix. You will have the same problem
> if you run minix2 or minix3 through an emulator and not from a real
> minix2 or minix3 partition.
>
> Regards,
>
> Daniel
>
Indeed the only line of dmesg showing i mounted the partition is
loop: loaded (max 8 devices)
Still I actually mount an image : i can add files, edit and so on. If
i use the emulator and mount the partition, this partition works
perfectly and even the df commands works.
Now i tried to understand what is going on and traced the program :
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
Tt really seems to me that this value should not be so large.
Unfortunately, i cannot get any deeper in tracing the problem since
even if i tried to read the code, it not documented, so i can't be
sure I understand everything you're doing in count_free ...
Regards,
C?dric
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
>
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.
By the way, you don't need to support minix on your Linux box to run
it through an emulator, do you?
Regards
Daniel
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
On 2/17/07, C?dric Augonnet <[email protected]> wrote:
>
> Well i actually do access to this partition, i can edit it and use it,
> this on Linux. Sorry if this is not clear.
>
Here is the point, I think. I'm afraid that you don't really access
any *real* partition. If it were so, that partition would have an
identifying *device* name. You access something within an image for an
emulating program that you interpret as a partition but not the
kernel. So it cannot access the superblock of it in its buffer and
recover bh->b_size to go on properly. It recovers something else. And
this triggers the oops.
Regards,
Daniel
C?dric Augonnet wrote:
> 2007/2/15, Andrew Morton <[email protected]>:
>>
>> Temporarily at
>>
>> http://userweb.kernel.org/~akpm/2.6.20-mm1/
>>
>> Will appear later at
>>
>>
>> Changes since 2.6.20-rc6-mm3:
>>
>> -minix-v3-support.patch
>
> Hi Daniel,
>
> On 2.6.20-rc6-mm3 and 2.6.20-mm1, i get an OOPS when using the minix 3
> file system. I enclose the dmesg and the .config to that mail.
>
> Here are the steps to reproduce this oops (they involve using qemu to
> run Minix 3)
> - First create a 2GB image using
> qemu-img create minix.img 2G
> (Please note that this seem to be producing an eroneous image)
> - Then launch Minix inside qemu to make a minix partition on this
> image using mkfs on the corresponding device.
That's two steps, right? First you make a partition on the "disk" qemu
provides, then you put a filesystem on the partition? Or did you put a
filesystem on the raw device?
> - Mount the image on loopback using
> mount -t minix -o loop minix.img /mnt/qemu/
Does mount know to use Minux3 with this command line?
> - issue a "df" command on /mnt/qemu
>
> This oops occurs everytime i use df on this directory. However, this
> does not occur if the image was for a 1MB partition. And it does not
> occur if the partition on which we created minix.img was the same as
> the partition on which qemu stands. Sounds like qemu has an issue and
> creates an erroneous partition which linux does not handle correctly.
>
> Regards, and thanks for your patch by the way !
Having been burned a few times by the fact that qemu provides disk
images which then (normally) get partitions, I'm not sure you aren't
having the same problem.
None of which justifies the OOPS, of course, nice kernels don't go down.
--
Bill Davidsen <[email protected]>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
2007/2/17, Bill Davidsen <[email protected]>:
> C?dric Augonnet wrote:
> >
> > Hi Daniel,
> >
> > On 2.6.20-rc6-mm3 and 2.6.20-mm1, i get an OOPS when using the minix 3
> > file system. I enclose the dmesg and the .config to that mail.
> >
> > Here are the steps to reproduce this oops (they involve using qemu to
> > run Minix 3)
> > - First create a 2GB image using
> > qemu-img create minix.img 2G
> > (Please note that this seem to be producing an eroneous image)
> > - Then launch Minix inside qemu to make a minix partition on this
> > image using mkfs on the corresponding device.
>
> That's two steps, right? First you make a partition on the "disk" qemu
> provides, then you put a filesystem on the partition? Or did you put a
> filesystem on the raw device?
>
Yes, i first create a RAW image of a disk. Then, i use this image file
as an image given to qemu. Inside qemu, running Minix i issue mkfs
/dev/c0d1 (this is corresponding to this image).
> > - Mount the image on loopback using
> > mount -t minix -o loop minix.img /mnt/qemu/
>
> Does mount know to use Minux3 with this command line?
>
Well at least it is yet allowing to do so. And most things work like hell.
> > - issue a "df" command on /mnt/qemu
> >
> > This oops occurs everytime i use df on this directory. However, this
> > does not occur if the image was for a 1MB partition. And it does not
> > occur if the partition on which we created minix.img was the same as
> > the partition on which qemu stands. Sounds like qemu has an issue and
> > creates an erroneous partition which linux does not handle correctly.
> >
> > Regards, and thanks for your patch by the way !
>
> Having been burned a few times by the fact that qemu provides disk
> images which then (normally) get partitions, I'm not sure you aren't
> having the same problem.
>
> None of which justifies the OOPS, of course, nice kernels don't go down.
>
That is my all point actually, i am not telling i have a valid
partition. I'm just describing the fact that the minix fs driver is
making too many assumptions on the partition it is given. For sure
there must be something nasty about this image, as you told this is
the duty of the kernel not to mount such a partition if it is not a
partition. Here I was only giving an example of the way we could trick
the driver. This is as important as having the driver working
correctly on valid partitions i suppose.
> --
> Bill Davidsen <[email protected]>
> "We have more to fear from the bungling of the incompetent than from
> the machinations of the wicked." - from Slashdot
>
Regards,
C?dric
2007/2/17, C?dric Augonnet <[email protected]>:
> 2007/2/17, Bill Davidsen <[email protected]>:
> > C?dric Augonnet wrote:
>
> That is my all point actually, i am not telling i have a valid
> partition. I'm just describing the fact that the minix fs driver is
> making too many assumptions on the partition it is given. For sure
> there must be something nasty about this image, as you told this is
> the duty of the kernel not to mount such a partition if it is not a
> partition. Here I was only giving an example of the way we could trick
> the driver. This is as important as having the driver working
> correctly on valid partitions i suppose.
Eventually the problem got solved by Andries Bouwer :
http://marc.theaimsgroup.com/?l=linux-mm-commits&m=117176125510900&w=2
Now i can issue a df command on this partition or whatever it may be,
and i obtain a consistent result wiythout any oops.
Regards,
C?dric