Re: 2.6.20-mm1 - Oops using Minix 3 file system
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=117176125510900=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 - 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/
Re: 2.6.20-mm1 - Oops using Minix 3 file system
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-commitsm=117176125510900w=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 - 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/
Re: 2.6.20-mm1 - Oops using Minix 3 file system
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 - 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/
Re: 2.6.20-mm1 - Oops using Minix 3 file system
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 - 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/
Re: 2.6.20-mm1 - Oops using Minix 3 file system
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 - 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/
Re: 2.6.20-mm1 - Oops using Minix 3 file system
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 = 0x0010 sbi->s_nzones = 0x0008 sbi->s_firstdatazone = 0x1266 (sbi->s_nzones - sbi->s_firstdatazone + 1) = 0x0007ed9b count_free( , 0x0010, 0x0007ed9b) unsigned numblocks = 0x0010 = 16 __u32 numbits =0x0007ed9b = 519579 bh->b_size = 0x1000 = 4096 == > i = 3506 This is consistent with the formula For the second call minix_count_free_inodes(0xd4105240) sbi->s_imap_blocks = 0x000a sbi->s_ninodes = 0x9280 count_free(..., 0x000a, 0x9281) unsigned numblocks = 0x000a = 10 __u32 numbits = 0x9281 = 37505 bh->b_size =0x1000 = 4096 ==> i = 536838736 (gdb) p/x (( 0x9281 - (0x00a-1) * 0x1000 * 8) / 16) * 2 $20 = 0x8252 $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/
Re: 2.6.20-mm1 - Oops using Minix 3 file system
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 - 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/
Re: 2.6.20-mm1 - Oops using Minix 3 file system
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 - 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/
Re: 2.6.20-mm1 - Oops using Minix 3 file system
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 - 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/
Re: 2.6.20-mm1 - Oops using Minix 3 file system
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 - 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/
Re: 2.6.20-mm1 - Oops using Minix 3 file system
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 - 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/
Re: 2.6.20-mm1 - Oops using Minix 3 file system
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 - 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/
Re: 2.6.20-mm1 - Oops using Minix 3 file system
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 = 0x0010 sbi-s_nzones = 0x0008 sbi-s_firstdatazone = 0x1266 (sbi-s_nzones - sbi-s_firstdatazone + 1) = 0x0007ed9b count_free( , 0x0010, 0x0007ed9b) unsigned numblocks = 0x0010 = 16 __u32 numbits =0x0007ed9b = 519579 bh-b_size = 0x1000 = 4096 == i = 3506 This is consistent with the formula For the second call minix_count_free_inodes(0xd4105240) sbi-s_imap_blocks = 0x000a sbi-s_ninodes = 0x9280 count_free(..., 0x000a, 0x9281) unsigned numblocks = 0x000a = 10 __u32 numbits = 0x9281 = 37505 bh-b_size =0x1000 = 4096 == i = 536838736 (gdb) p/x (( 0x9281 - (0x00a-1) * 0x1000 * 8) / 16) * 2 $20 = 0x8252 $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/
Re: 2.6.20-mm1 - Oops using Minix 3 file system
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 - 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/
Re: 2.6.20-mm1 - Oops using Minix 3 file system
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 - 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/
Re: 2.6.20-mm1 - Oops using Minix 3 file system
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 - 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/