[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <f56c1ba00702161500x775fe04bl91889b5819cf9ddc@mail.gmail.com>
Date: Sat, 17 Feb 2007 00:00:50 +0100
From: "Cédric Augonnet" <cedric.augonnet@...il.com>
To: "Andrew Morton" <akpm@...ux-foundation.org>,
"Daniel Aragones" <danarag@...il.com>
Cc: linux-kernel@...r.kernel.org, Cedric.augonnet@...-lyon.org
Subject: Re: 2.6.20-mm1 - Oops using Minix 3 file system
2007/2/15, Andrew Morton <akpm@...ux-foundation.org>:
>
> 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
Download attachment "configOOPS-20-mm1" of type "application/octet-stream" (49900 bytes)
Download attachment "dmesgOOPS-20-mm1" of type "application/octet-stream" (15258 bytes)
Powered by blists - more mailing lists