Re: Can't free the ramdisk (initrd, pivot_root)
On the same topic, I have not found any change in free memory reported before and after the ioctl call. Though umount /initrd does free around 2 MB. Amit - 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: Can't free the ramdisk (initrd, pivot_root)
On the same topic, I have not found any change in free memory reported before and after the ioctl call. Though umount /initrd does free around 2 MB. Amit - 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: Memory leak in the ramfs file system
Hi, After testing with patch-2.4.2-ac28, the df commands works fine on a dir mounted as ramfs. Also, it recognizes the limits set, etc. Thanks to David Gibson, Alan and others for making this available. Regards Amit - 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: Memory leak in the ramfs file system
Hi, After testing with patch-2.4.2-ac28, the df commands works fine on a dir mounted as ramfs. Also, it recognizes the limits set, etc. Thanks to David Gibson, Alan and others for making this available. Regards Amit - 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: Memory leak in the ramfs file system
>(none):/mnt/ramfs/root# df -h /mnt/ramfs/ >FilesystemSize Used Avail Use% Mounted on >ramfs0 0 0 - /mnt/ramfs I am not sure, how related this is, but we have / on ramfs and using rpm to install(-iUvh) fails with the mesages, need 12K on / Amit - 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: Memory leak in the ramfs file system
(none):/mnt/ramfs/root# df -h /mnt/ramfs/ FilesystemSize Used Avail Use% Mounted on ramfs0 0 0 - /mnt/ramfs I am not sure, how related this is, but we have / on ramfs and using rpm to install(-iUvh) fails with the mesages, need 12K on / Amit - 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: question \ information request on init \ boot sequence when using initrd
Werner Almesberger wrote: > Easy solution: don't run linuxrc, run something else instead. E.g. > putting the following into the kernel's command line should do th > trick: > init=/your_script root=/dev/ram > > (With your_script being the original version, without real-root-dev) This works. And in a similar fashion as the version below. Which might not be safe for future kernels. Though note, this means not using /linuxrc. And I thought /linuxrc was for cases like this. Thanks for all the info. Regards Amit - 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: question \ information request on init \ boot sequence when using initrd
Werner Almesberger wrote: Easy solution: don't run linuxrc, run something else instead. E.g. putting the following into the kernel's command line should do th trick: init=/your_script root=/dev/ram (With your_script being the original version, without real-root-dev) This works. And in a similar fashion as the version below. Which might not be safe for future kernels. Though note, this means not using /linuxrc. And I thought /linuxrc was for cases like this. Thanks for all the info. Regards Amit - 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/
question \ information request on init \ boot sequence when using initrd
Hi, We(my team) had some questions regarding booting from initrd and using /linuxrc. It will help someone(David, Werner,...) can give their thoughts on this. To put it in brief, since running sbin/init from /linuxrc as resulting in init not having PID 1 and thereby not doing some initialization as expected. Thereby instead of loading running /sbin/init, we just set /proc/sys/kernel/real-root-dev to /dev/ram0's value which then does the following runs 2 statements in init/main.c to unlock_kernel and free init memory and then run sbin/init. This results in /sbin/init running fine. Is this ok or should be modify /sbin/init to run properly inspite of PID <> 1 or is there a 3rd way of doing this? Thanks Amit This is on linux-2.4.1 kernel running on PPC. /linuxrc is as follow: ../bin/mount -t ramfs none tmp_rootfs #untar'ing the new root. ../bin/tar -b 512 -zxf /dev/mtd1 mkdir initrd ../bin/pivot_root . initrd exec sbin/chroot . sbin/init.new 3 dev/console 2>&1 The above results in init running with PID != 1 and thereby skipping some relevant processing my default. see ps output below: Instead of the "chroot" above is changed to following exec sbin/chroot . sh -c 'bin/mount proc proc -t proc; echo 0x0100 > proc/sys/kernel/real-root-dev' And linuxrc exits (none):root> ps -e PID TTY TIME CMD 1 ?00:00:04 swapper 2 ?00:00:00 keventd 3 ?00:00:00 kswapd 4 ?00:00:00 kreclaimd 5 ?00:00:00 bdflush 6 ?00:00:00 kupdate 7 ?00:00:00 mtdblockd 8 ?00:00:00 init 26 ?00:00:00 sh 39 ?00:00:00 portmap 50 ?00:00:00 ypbind 51 ?00:00:00 ypbind 84 ?00:00:00 inetd 93 ?00:00:00 syslogd 100 ?00:00:00 klogd 119 ?00:00:00 ps - 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/
question \ information request on init \ boot sequence when using initrd
Hi, We(my team) had some questions regarding booting from initrd and using /linuxrc. It will help someone(David, Werner,...) can give their thoughts on this. To put it in brief, since running sbin/init from /linuxrc as resulting in init not having PID 1 and thereby not doing some initialization as expected. Thereby instead of loading running /sbin/init, we just set /proc/sys/kernel/real-root-dev to /dev/ram0's value which then does the following runs 2 statements in init/main.c to unlock_kernel and free init memory and then run sbin/init. This results in /sbin/init running fine. Is this ok or should be modify /sbin/init to run properly inspite of PID 1 or is there a 3rd way of doing this? Thanks Amit This is on linux-2.4.1 kernel running on PPC. /linuxrc is as follow: ../bin/mount -t ramfs none tmp_rootfs #untar'ing the new root. ../bin/tar -b 512 -zxf /dev/mtd1 mkdir initrd ../bin/pivot_root . initrd exec sbin/chroot . sbin/init.new 3 dev/console dev/console 21 The above results in init running with PID != 1 and thereby skipping some relevant processing my default. see ps output below: Instead of the "chroot" above is changed to following exec sbin/chroot . sh -c 'bin/mount proc proc -t proc; echo 0x0100 proc/sys/kernel/real-root-dev' And linuxrc exits (none):root ps -e PID TTY TIME CMD 1 ?00:00:04 swapper 2 ?00:00:00 keventd 3 ?00:00:00 kswapd 4 ?00:00:00 kreclaimd 5 ?00:00:00 bdflush 6 ?00:00:00 kupdate 7 ?00:00:00 mtdblockd 8 ?00:00:00 init 26 ?00:00:00 sh 39 ?00:00:00 portmap 50 ?00:00:00 ypbind 51 ?00:00:00 ypbind 84 ?00:00:00 inetd 93 ?00:00:00 syslogd 100 ?00:00:00 klogd 119 ?00:00:00 ps - 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: CRAMFS
> I don't know why the comparision is made though, they are used for two > completely different things... ramfs is for temporary file storage, cramfs > is for immutable files stored on flash. Each by itself is quite optimal > for what it's designed for, isn't it ? Exactly. My mistake earlier to assume cramfs was "compressed ramfs"! ;-) I should compare it to the tar.gz option and JFFS2. Will do in the next evaluation. This will be more of a replace initrd+custom /linuxrc with a CRAMFS-based rootfs on a flash device assuming CRAMFS can be directly read by kernel\init for getting the rootfs. Ditto for JFFS2 Also, the platform is PPC, IBM 405GP to be precise. Regards Amit - 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/
RAMFS, CRAMFS and JFFS2(was Re: /linuxrc query)
Hi David, I did consider CRAMFS and JFFS2 when it was announced on the mtd list. Conserving flash over system ram is more relevant. Our reasons are below: RAMFS v/s CRAMFS 1. RAMFS is just more stable in terms of less complexity, less bugs reported over the time, etc. 2. RAMFS is a fairly robust filesystem and all features required as far as I can tell. RAMFS v/s ext2 on a ramdisk 1. Fixed size. Results in overallocation or more dangerously overshooting the size decided earlier during mke2fs. RAMFS v/s JFFS2 1. JFFS2 was announced around a month ago and few utils were still in development, hence it was not there for the first development cycle. 2. Just offhand, joining 100 small files (say in /etc) and then compressing into a one file over these 100 files in a JFFS2 fs seems to give better overall space usage and probably less flash wear during modifications. 3. JFFS2 does has some compelling reasons, more robustness ofcourse with JFFS2 over above approach, flash wearing(though would require sufficient free space on that mtd partition), etc. Plan to compare these later. I might be wrong and hence would welcome any suggestions. Regards Amit David Woodhouse wrote: > [EMAIL PROTECTED] said: > >> Also as a note, what we are doing is keeping our rootfs on flash as a >> tar.gz and reading it and mounting it on a ramfs in the /linuxrc >> before doing a pivot_root. To summarize, pivot_root has been a life >> saver as the earlier real_root_dev might not have been useful in this >> case. Not using the ramfs limits for now, will do soon. > > > If you're concerned about memory usage - why untar the whole of your root > filesystem into a ramfs? My preferred solution is to just mount the root > filesystem directly from the flash as cramfs (or JFFS2), with symlinks into a > ramfs for appropriate parts like /tmp and /var. > > I suppose the best option is actually to union-mount the ramfs over the > root, rather than mucking about with symlinks. I just haven't got round to > doing that yet. > > -- > dwmw2 - 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: /linuxrc query
Werner Almesberger wrote: > Amit D Chaudhary wrote: >> But other information in the >> initrd.txt mentions otherwise, hence the query here. > > > Hmm, sounds like a bug. Where did you find this ? I quote from the version in linux-2.4.2-ac22 " Now, the initrd can be unmounted and the memory allocated by the RAM disk can be freed: # umount /initrd # blockdev --flushbufs /dev/ram0# /dev/rd/0 if using devfs " I guess I assumed the above has to be put in /linuxrc as it follows other commands which do go in the /linuxrc. The assumption is not quite correct as I have since found out. Regards Amit - 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: /linuxrc query
Werner Almesberger wrote: Amit D Chaudhary wrote: But other information in the initrd.txt mentions otherwise, hence the query here. Hmm, sounds like a bug. Where did you find this ? I quote from the version in linux-2.4.2-ac22 " Now, the initrd can be unmounted and the memory allocated by the RAM disk can be freed: # umount /initrd # blockdev --flushbufs /dev/ram0# /dev/rd/0 if using devfs " I guess I assumed the above has to be put in /linuxrc as it follows other commands which do go in the /linuxrc. The assumption is not quite correct as I have since found out. Regards Amit - 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/
RAMFS, CRAMFS and JFFS2(was Re: /linuxrc query)
Hi David, I did consider CRAMFS and JFFS2 when it was announced on the mtd list. Conserving flash over system ram is more relevant. Our reasons are below: RAMFS v/s CRAMFS 1. RAMFS is just more stable in terms of less complexity, less bugs reported over the time, etc. 2. RAMFS is a fairly robust filesystem and all features required as far as I can tell. RAMFS v/s ext2 on a ramdisk 1. Fixed size. Results in overallocation or more dangerously overshooting the size decided earlier during mke2fs. RAMFS v/s JFFS2 1. JFFS2 was announced around a month ago and few utils were still in development, hence it was not there for the first development cycle. 2. Just offhand, joining 100 small files (say in /etc) and then compressing into a one file over these 100 files in a JFFS2 fs seems to give better overall space usage and probably less flash wear during modifications. 3. JFFS2 does has some compelling reasons, more robustness ofcourse with JFFS2 over above approach, flash wearing(though would require sufficient free space on that mtd partition), etc. Plan to compare these later. I might be wrong and hence would welcome any suggestions. Regards Amit David Woodhouse wrote: [EMAIL PROTECTED] said: Also as a note, what we are doing is keeping our rootfs on flash as a tar.gz and reading it and mounting it on a ramfs in the /linuxrc before doing a pivot_root. To summarize, pivot_root has been a life saver as the earlier real_root_dev might not have been useful in this case. Not using the ramfs limits for now, will do soon. If you're concerned about memory usage - why untar the whole of your root filesystem into a ramfs? My preferred solution is to just mount the root filesystem directly from the flash as cramfs (or JFFS2), with symlinks into a ramfs for appropriate parts like /tmp and /var. I suppose the best option is actually to union-mount the ramfs over the root, rather than mucking about with symlinks. I just haven't got round to doing that yet. -- dwmw2 - 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: CRAMFS
I don't know why the comparision is made though, they are used for two completely different things... ramfs is for temporary file storage, cramfs is for immutable files stored on flash. Each by itself is quite optimal for what it's designed for, isn't it ? Exactly. My mistake earlier to assume cramfs was "compressed ramfs"! ;-) I should compare it to the tar.gz option and JFFS2. Will do in the next evaluation. This will be more of a replace initrd+custom /linuxrc with a CRAMFS-based rootfs on a flash device assuming CRAMFS can be directly read by kernel\init for getting the rootfs. Ditto for JFFS2 Also, the platform is PPC, IBM 405GP to be precise. Regards Amit - 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: /linuxrc query
Hi, Also as a note, what we are doing is keeping our rootfs on flash as a tar.gz and reading it and mounting it on a ramfs in the /linuxrc before doing a pivot_root. To summarize, pivot_root has been a life saver as the earlier real_root_dev might not have been useful in this case. Not using the ramfs limits for now, will do soon. Thanks Amit Werner Almesberger wrote: > Amit D Chaudhary wrote: > >> what does redirecting stdin\stdout\stderr to dev/console achieve? I thought >> since the root is now the "new" root, dev/console will be used automatically? > > > No, you would continue using the file descriptors which are already > open, i.e. on /dev/console on the old root. > > >> Also, why chroot, why not call init directly? > > > To make sure the root of the current process is indeed changed. > pivot_root currently forces a chroot on all processes (except the > ones that have explicitly moved out of /) in order to move all the > kernel threads too, but this is not a nice solution. Once a better > solution is implemented for the kernel threads, we might drop the > forced chroot, and then the explicit chroot here becomes important. > > >> Since the above never returns, what follows in not freed. > > > You can run them later, e.g. /etc/rc.d/rc.local > Or, if you needs the space immediately, make "what-follows" a > script than first frees them, and then exec's init. > > - Werner - 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: /linuxrc query
Hi, Thanks for the response. PSB, Werner Almesberger wrote: > Amit D Chaudhary wrote: > > No, you would continue using the file descriptors which are already > open, i.e. on /dev/console on the old root. So, makes sense. And the child process that follow will use now the new fd's. >> Also, why chroot, why not call init directly? > > > To make sure the root of the current process is indeed changed. > pivot_root currently forces a chroot on all processes (except the > ones that have explicitly moved out of /) in order to move all the > kernel threads too, but this is not a nice solution. Once a better > solution is implemented for the kernel threads, we might drop the > forced chroot, and then the explicit chroot here becomes important. So, it is not a requirement currently but it is useful to have the script not dependent on the current pivot_root implementation. > You can run them later, e.g. /etc/rc.d/rc.local > Or, if you needs the space immediately, make "what-follows" a > script than first frees them, and then exec's init. Sure will put in a script that does it. I had left it in /linuxrc as I thought that's what initrd.txt suggested one to do. But other information in the initrd.txt mentions otherwise, hence the query here. I am assuming umount and thereby blockdev after pivot_script and before "chroot . init ..." don't make sense as files(dev/console among others) are\might still be in use. Best Regards Amit - 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/
/linuxrc query
Hi, I have a initrd working, a /linuxrc on it that runs and executes. My question for the commands after pivot_root which works like a charm, thanks to initrd.txt, what does redirecting stdin\stdout\stderr to dev/console achieve? I thought since the root is now the "new" root, dev/console will be used automatically? Also, why chroot, why not call init directly? #exec chroot . sbin/init 3 dev/console 2>&1 Since the above never returns, what follows in not freed. Does this mean I have around 4-6 mb of ram being used up unnecessarily? Any solution? #umount /initrd #blockdev --flushbufs /dev/ram0# /dev/rd/0 if using devfs Thanks and Regards Amit - 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/
/linuxrc query
Hi, I have a initrd working, a /linuxrc on it that runs and executes. My question for the commands after pivot_root which works like a charm, thanks to initrd.txt, what does redirecting stdin\stdout\stderr to dev/console achieve? I thought since the root is now the "new" root, dev/console will be used automatically? Also, why chroot, why not call init directly? #exec chroot . sbin/init 3 dev/console dev/console 21 Since the above never returns, what follows in not freed. Does this mean I have around 4-6 mb of ram being used up unnecessarily? Any solution? #umount /initrd #blockdev --flushbufs /dev/ram0# /dev/rd/0 if using devfs Thanks and Regards Amit - 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: /linuxrc query
Hi, Thanks for the response. PSB, Werner Almesberger wrote: Amit D Chaudhary wrote: No, you would continue using the file descriptors which are already open, i.e. on /dev/console on the old root. So, makes sense. And the child process that follow will use now the new fd's. Also, why chroot, why not call init directly? To make sure the root of the current process is indeed changed. pivot_root currently forces a chroot on all processes (except the ones that have explicitly moved out of /) in order to move all the kernel threads too, but this is not a nice solution. Once a better solution is implemented for the kernel threads, we might drop the forced chroot, and then the explicit chroot here becomes important. So, it is not a requirement currently but it is useful to have the script not dependent on the current pivot_root implementation. You can run them later, e.g. /etc/rc.d/rc.local Or, if you needs the space immediately, make "what-follows" a script than first frees them, and then exec's init. Sure will put in a script that does it. I had left it in /linuxrc as I thought that's what initrd.txt suggested one to do. But other information in the initrd.txt mentions otherwise, hence the query here. I am assuming umount and thereby blockdev after pivot_script and before "chroot . init ..." don't make sense as files(dev/console among others) are\might still be in use. Best Regards Amit - 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: /linuxrc query
Hi, Also as a note, what we are doing is keeping our rootfs on flash as a tar.gz and reading it and mounting it on a ramfs in the /linuxrc before doing a pivot_root. To summarize, pivot_root has been a life saver as the earlier real_root_dev might not have been useful in this case. Not using the ramfs limits for now, will do soon. Thanks Amit Werner Almesberger wrote: Amit D Chaudhary wrote: what does redirecting stdin\stdout\stderr to dev/console achieve? I thought since the root is now the "new" root, dev/console will be used automatically? No, you would continue using the file descriptors which are already open, i.e. on /dev/console on the old root. Also, why chroot, why not call init directly? To make sure the root of the current process is indeed changed. pivot_root currently forces a chroot on all processes (except the ones that have explicitly moved out of /) in order to move all the kernel threads too, but this is not a nice solution. Once a better solution is implemented for the kernel threads, we might drop the forced chroot, and then the explicit chroot here becomes important. Since the above never returns, what follows in not freed. You can run them later, e.g. /etc/rc.d/rc.local Or, if you needs the space immediately, make "what-follows" a script than first frees them, and then exec's init. - Werner - 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: mke2fs hangs while running on /dev/loop0 - kernel version 2.4
Hi Arnaldo, Thanks every much for the pointer. Yes, with 2.4.2-ac5 the problem is gone. Also, there was another similar problem with lilo stalling that is gone too. Regards Amit Arnaldo Carvalho de Melo wrote: > Em Tue, Feb 27, 2001 at 06:25:08PM -0800, Amit D Chaudhary escreveu: > >> I am hoping someone knows more about this case. I have a intel pc >> running linux 2.4 and the last command below hangs and the statements as >> they are printed. Even kill -9 does not get it to terminate. >> >> #touch img.test >> #dd if=/dev/zero of=img.test bs=1k count=2000 >> 2000+0 records in >> 2000+0 records out >> #losetup /dev/loop0 img.test >> #mke2fs >> > > > known bug, try 2.4.2-ac5 (ac6 seems to have some small problems, > Keith seems to have fixed with a patch some moments ago) some friends of > mine said 2.4.2-ac seems to make loop behave, haven't checked > > - Arnaldo - 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: mke2fs hangs while running on /dev/loop0 - kernel version 2.4
Hi Arnaldo, Thanks every much for the pointer. Yes, with 2.4.2-ac5 the problem is gone. Also, there was another similar problem with lilo stalling that is gone too. Regards Amit Arnaldo Carvalho de Melo wrote: Em Tue, Feb 27, 2001 at 06:25:08PM -0800, Amit D Chaudhary escreveu: I am hoping someone knows more about this case. I have a intel pc running linux 2.4 and the last command below hangs and the statements as they are printed. Even kill -9 does not get it to terminate. #touch img.test #dd if=/dev/zero of=img.test bs=1k count=2000 2000+0 records in 2000+0 records out #losetup /dev/loop0 img.test #mke2fs known bug, try 2.4.2-ac5 (ac6 seems to have some small problems, Keith seems to have fixed with a patch some moments ago) some friends of mine said 2.4.2-ac seems to make loop behave, haven't checked - Arnaldo - 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/
mke2fs hangs while running on /dev/loop0 - kernel version 2.4
Hi, I am hoping someone knows more about this case. I have a intel pc running linux 2.4 and the last command below hangs and the statements as they are printed. Even kill -9 does not get it to terminate. #touch img.test #dd if=/dev/zero of=img.test bs=1k count=2000 2000+0 records in 2000+0 records out #losetup /dev/loop0 img.test #mke2fs mke2fs 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09 Filesystem label= OS type: Linux Block size=1024 (log=0) Fragment size=1024 (log=0) 256 inodes, 2000 blocks 100 blocks (5.00%) reserved for the super user First data block=1 1 block group 8192 blocks per group, 8192 fragments per group 256 inodes per group Writing inode tables: done .. Thanks Amit - 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/
mke2fs hangs while running on /dev/loop0 - kernel version 2.4
Hi, I am hoping someone knows more about this case. I have a intel pc running linux 2.4 and the last command below hangs and the statements as they are printed. Even kill -9 does not get it to terminate. #touch img.test #dd if=/dev/zero of=img.test bs=1k count=2000 2000+0 records in 2000+0 records out #losetup /dev/loop0 img.test #mke2fs mke2fs 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09 Filesystem label= OS type: Linux Block size=1024 (log=0) Fragment size=1024 (log=0) 256 inodes, 2000 blocks 100 blocks (5.00%) reserved for the super user First data block=1 1 block group 8192 blocks per group, 8192 fragments per group 256 inodes per group Writing inode tables: done .. Thanks Amit - 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: getting include-files from arch//subdir
why not
#include
Amit
"Heusden, Folkert van" wrote:
>
> I need to include (in a driver) a header-file from arch//subdir. I
> could, of course,
> do something like #include "../../arch/i386/{etc}" with a couple of #ifdef's
> to get things
> working for each environment. I guess that's now the way to do it cleanly.
> What would be _the_ way to do it?
>
> Thanks.
>
> Folkert van Heusden.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: getting include-files from arch/arch/subdir
why not
#include arch/i386/etc.h
Amit
"Heusden, Folkert van" wrote:
I need to include (in a driver) a header-file from arch/arch/subdir. I
could, of course,
do something like #include "../../arch/i386/{etc}" with a couple of #ifdef's
to get things
working for each environment. I guess that's now the way to do it cleanly.
What would be _the_ way to do it?
Thanks.
Folkert van Heusden.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: 0 size files in linux-2.2.17.tar.gz
Sorry, I might not been clear enough, I meant the files are of size 0 in the following file and also it's valinux mirror, ftp://ftp.kernel.org/pub/linux/kernel/v2.2/linux-2.2.17.tar.gz I did not patch the sources, I was just extracting the tar file. Alan or someone who looks in the sources, please advice? Thanks Amit Peter Samuelson wrote: > > [Jan-Benedict Glaw] > > Your kernel was probably patched te become a 2.2.17. The "problem" > > is diff. It can > > - add lines > > - remove lines > > - add files > > but it *cannot remove files. The only way to "remove" a file is to > > delete all ist contents, but the (empty) file remains... > > You mean you don't use 'patch -E'? > > Hmmm, the kernel README file doesn't mention -E either. > > It also says to use -p0, which only works if your kernel directory is > still named 'linux', which doesn't tend to last long when you start > managing multiple trees. > > Alan, would you put this in 2.2.18pre? The '-p1' part isn't essential > -- though it's a good habit to get into -- but '-E' can be in some > cases. (Remember arch/i386/checksum.c?) > > Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 0 size files in linux-2.2.17.tar.gz
Hi, When trying to create a patch with linux 2.2.17 sources, I found the following files to be of size 0 in linux-2.2.17.tar.gz. linux/include/linux/dasd.h linux/include/linux/coda_opstats.h Since the file is the most latest in the kernel/v2.2 directory, thought should point this out. Amit - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 0 size files in linux-2.2.17.tar.gz
Hi, When trying to create a patch with linux 2.2.17 sources, I found the following files to be of size 0 in linux-2.2.17.tar.gz. linux/include/linux/dasd.h linux/include/linux/coda_opstats.h Since the file is the most latest in the kernel/v2.2 directory, thought should point this out. Amit - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
