Re: Cannot mount old ext2 cdrom, but e2fsck shows no problems
On Tuesday 05 June 2001 02:36, Nick Urbanik wrote: > Dear folks, > > I made 18 ext2 cdroms in October 1998 using an old (new at the time) Red > Hat system. Now I can't mount them. e2fsck shows no problems. I also > can dd them to a file, then mount the file. But I want to be able to > simply access them directly. Current system: RH 7.1 with all updates. > > Sorry, I can't remember the exact command I used to create the images. > > I also want to better understand the output of dumpe2fs, and how to > relate this to mount. > I think you are running into a block size issue. I notice your fs block size is only 1024. See if you can mount it on an IDE CDROM drive. I ran into the same problem with file systems with a block size of 1024 when using the ide-scsi module because it saw the device bs as being 4096. You cannot mount a file system with block size smaller than the device. I would unload the the ide-scsi modules and mount it as /dev/hdxx and it mounted just fine. I started specifying the bs to be 4k when creating the file system to backup to CD and the problem went away. The error message was deceiving. I did not discover what it was until I left X windows and tried it from the console and finally got an error relating to block size. - Vincent Stemen > > > $ dumpe2fs -h /dev/scd0 > dumpe2fs 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09 > Filesystem volume name: > Last mounted on: > Filesystem UUID: 7eb1b040-59f7-11d2-9e35-002018530df2 > Filesystem magic number: 0xEF53 > Filesystem revision #:0 (original) > Filesystem features: (none) > Filesystem state: clean > Errors behavior: Continue > Filesystem OS type: Linux > Inode count: 166624 > Block count: 665600 > Reserved block count: 33280 > Free blocks: 142206 > Free inodes: 153910 > First block: 1 > Block size: 1024 > Fragment size:1024 > Blocks per group: 8192 > Fragments per group: 8192 > Inodes per group: 2032 > Inode blocks per group: 254 > Last mount time: Fri Oct 2 21:06:45 1998 > Last write time: Fri Oct 2 23:53:28 1998 > Mount count: 3 > Maximum mount count: 20 > Last checked: Fri Oct 2 20:57:46 1998 > Check interval: 15552000 (6 months) > Next check after: Wed Mar 31 20:57:46 1999 > Reserved blocks uid: 0 (user root) > Reserved blocks gid: 0 (group root) > > (I originally sent this to the Red Hat list, but there was no response). > - 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: Plain 2.4.5 VM... (and 2.4.5-ac3)
On Wednesday 30 May 2001 15:17, Mike Galbraith wrote: > On Wed, 30 May 2001, Vincent Stemen wrote: > > On Wednesday 30 May 2001 01:02, Mike Galbraith wrote: > > > On Tue, 29 May 2001, Vincent Stemen wrote: > > > > On Tuesday 29 May 2001 15:16, Alan Cox wrote: > > > > > > a reasonably stable release until 2.2.12. I do not understand > > > > > > why code with such serious reproducible problems is being > > > > > > introduced into the even numbered kernels. What happened to > > > > > > the plan to use only the > > > > > > > > > > Who said it was introduced ?? It was more 'lurking' than > > > > > introduced. And unfortunately nobody really pinned it down in > > > > > 2.4test. > > > > > > > > I fail to see the distinction. First of all, why was it ever > > > > released as 2.4-test? That question should probably be directed at > > > > Linus. If it is not fully tested, then it should be released it as > > > > an odd number. If it already existed in the odd numbered > > > > development kernel and was known, then it should have never been > > > > released as a production kernel until it was resolved. Otherwise, > > > > it completely defeats the purpose of having the even/odd numbering > > > > system. > > > > > > > > I do not expect bugs to never slip through to production kernels, > > > > but known bugs that are not trivial should not, and serious bugs > > > > like these VM problems especially should not. > > > > > > And you can help prevent them from slipping through by signing up as > > > a shake and bake tester. Indeed, you can make your expectations > > > reality absolutely free of charge, and or compensation > > > what a bargain! > > > > > > X ___ ;-) > > > > > > -Mike > > > > The problem is, that's not true. These problems are not slipping > > through because of lack of testers. As Alan said, the VM problem has > > Sorry, that's a copout. You (we) had many chances to notice. Don't > push the problems back onto developers.. it's our problem. > How is that a copout? The problem was noticed. I am only suggesting that we not be in such a hurry to put code in the production kernels until we are pretty sure it works well enough, and that we release major production versions more often so that they do not contain 2 or 3 years worth of new code making it so hard to debug. We probably should have had 2 or 3 code freezes and production releases since 2.2.x. As I mentioned in a previous posting, this way we do not have to run a 2 or 3 year old kernel in order to have reasonable stability. > > Here are some of the problems I see: > > > > There was far to long of a stretch with to much code dumped into both > > the 2.2 and 2.4 kernels before release. There needs to be a smaller > > number changes between major releases so that they can be more > > thoroughly tested and debugged. In the race to get it out there they > > are making the same mistakes as Microsoft, releasing production > > kernels with known serious bugs because it is taking to long and they > > want to move on forward. I enjoy criticizing Microsoft so much for > > the same thing that I do not want to have to stop in order to not > > sound hypocritical :-). The Linux community has built a lot of it's > > reputation on not making these mistakes. Please lets try not to > > destroy that. > > > > They are disregarding the even/odd versioning system. > > For example: > > There was a new 8139too driver added to the the 2.4.5 (I think) kernel > > which Alan Cox took back out and reverted to the old one in his > > 2.4.5-ac? versions because it is apparently causing lockups. > > Shouldn't this new driver have been released in a 2.5.x development > > kernel and proven there before replacing the one in the production > > kernel? I haven't even seen a 2.5.x kernel released yet. > > > > Based on Linus's original very good plan for even/odd numbers, there > > should not have been 2.4.0-test? kernels either. This was another > > example of the rush to increment to 2.4 long before it was ready. > > There was a long stretch of test kernels and and now we are all the > > way to 2.4.5 and it is still not stable. We are repeating the 2.2.x > > process all over again. It should have been 2.3.x until the > > production release was ready. If they needed to distinguish a code
Re: Plain 2.4.5 VM... (and 2.4.5-ac3)
On Wednesday 30 May 2001 15:30, Rik van Riel wrote: > On Wed, 30 May 2001, Vincent Stemen wrote: > > The problem is, that's not true. These problems are not slipping > > through because of lack of testers. As Alan said, the VM problem has > > been lurking, which means that it was known already. > > Fully agreed, it went through because of a lack of hours > per day and the fact that the priority of developers was > elsewhere. > > For me, for example, the priorities have mostly been with > bugs that bothered me or that bothered Conectiva's customers. > > If you _really_ feel this strongly about the bug, you could > either try to increase the number of hours a day for all of I sure wish I could :-). > us or you could talk to my boss about hiring me as a consultant > to fix the problem for you on an emergency basis :) > The other two alternatives would be either waiting until > somebody gets around to fixing the bug or sending in a patch > yourself. > > Trying to piss off developers has adverse effect on all four > of the methods above :) > Why should my comments piss anybody off? I am just trying to point out a problem, as I see it, an offer suggestions for improvement. Other developers will either agree with me or they wont. Contributions are not made only through writing code. I contribute through code, bug reports, ideas, and suggestions. I would love to dive in and try to help fix some of the kernel problems but my hands are just to full right now. My comments are not meant to rush anybody and I am not criticizing how long it is taking. I know everybody is doing everything they can just like I am, and they are doing a terrific job. I am just suggesting a modification to the way the kernels are distributed that is more like the early versions that I hoped would allow us to maintain a stable kernel for distributions and production machines. - Vincent Stemen - 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: Plain 2.4.5 VM... (and 2.4.5-ac3)
Ronald Bultje writes: > On 30 May 2001 14:58:57 -0500, Vincent Stemen wrote: > > There was a new 8139too driver added to the the 2.4.5 (I think) kernel > > which Alan Cox took back out and reverted to the old one in his > > 2.4.5-ac? versions because it is apparently causing lockups. > > Shouldn't this new driver have been released in a 2.5.x development > > kernel and proven there before replacing the one in the production > > kernel? I haven't even seen a 2.5.x kernel released yet. > > If every driver has to go thorugh the complete development cycle (of 2+ > years), I'm sure very little driver writers will be as motivated as they > are now - it takes ages before they see their efforts "rewarded" with a > place in the kernel. > The ideal case is that odd-numbered kernels are "for testing" and > even-numbered kernels are stable. However, this is only theory. In > practice, you can't rule out all bugs. And you can't test all things for > all cases and every test case, the linux community doesn't have the > manpower for that. And to prevent a complete driver development cycle > taking 2+ years, you have to compromise. > > If you would take 2+ years for a single driver development cycle, nobody > would be interested in linux since the new devices would only be > supported by a stable kernel two years after their release. See the > point? To prevent that, you need to compromise. and thus, sometimes, you > have some crashes. I agree with everything you say up till this point, but you are arguing against a point I never made. First of all, bugs like the 8139too lockup was found within the first day or two of release in the 2.4.3 kernel. Also, most show stopper bugs such as the VM problems are found fairly quickly. Even if it takes a long time to figure out how to fix them, I do not think they should be pushed on through into production kernels until they are until they are fixed. I already said that I do not expect minor bugs not to slip through. However, if they are minor, they can usually be fixed quickly once they are discovered and it is no big deal if they make it into a production kernel. > That's why there's still 2.2.x - that's purely stable > and won't crash as fast as 2.4.x, but misses the "newest > cutting-edge-technology device support" and "newest technology" (like > new SMP handling , ReiserFS, etc... But it *is* stable. > The reason I suggested more frequent major production releases is so that you don't have to go back to a 2 or 3 year old kernel and loose out on years worth of new features to have any stability. One show stopper bug like the VM problems would not be as much of a problem if there was a stable production kernel that we could run that was only 4 or 6 months old. > > Based on Linus's original very good plan for even/odd numbers, there > > should not have been 2.4.0-test? kernels either. This was another > > example of the rush to increment to 2.4 long before it was ready. > > There was a long stretch of test kernels and and now we are all the > > way to 2.4.5 and it is still not stable. We are repeating the 2.2.x > > process all over again. > > Wrong again. > 2.3.x is for development, adding new things, testing, adding, testing, > changing, testing, etc. Which is the same point I made. > 2.4-test is for testing only, it's some sort of feature freeze. Agreed. My only point here was that it suggests that there are only minor bugs left to be solved before the production release by setting the version to 2.4-test. That is one of the reasons I made the suggestion to keep it in the 2.3 range, since there were actually serious VM problems still upon the production 2.4 release. > 2.4.x is for final/stable 2.4. > It's a standard *nix development cycle. That's how everyone does it. My point exactly. > > Regards, > > Ronald Bultje - 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: Plain 2.4.5 VM... (and 2.4.5-ac3)
On Wednesday 30 May 2001 01:02, Mike Galbraith wrote: > On Tue, 29 May 2001, Vincent Stemen wrote: > > On Tuesday 29 May 2001 15:16, Alan Cox wrote: > > > > a reasonably stable release until 2.2.12. I do not understand why > > > > code with such serious reproducible problems is being introduced > > > > into the even numbered kernels. What happened to the plan to use > > > > only the > > > > > > Who said it was introduced ?? It was more 'lurking' than introduced. > > > And unfortunately nobody really pinned it down in 2.4test. > > > > I fail to see the distinction. First of all, why was it ever released > > as 2.4-test? That question should probably be directed at Linus. If > > it is not fully tested, then it should be released it as an odd > > number. If it already existed in the odd numbered development kernel > > and was known, then it should have never been released as a production > > kernel until it was resolved. Otherwise, it completely defeats the > > purpose of having the even/odd numbering system. > > > > I do not expect bugs to never slip through to production kernels, but > > known bugs that are not trivial should not, and serious bugs like > > these VM problems especially should not. > > And you can help prevent them from slipping through by signing up as a > shake and bake tester. Indeed, you can make your expectations reality > absolutely free of charge, and or compensation > what a bargain! > > X ___ ;-) > > -Mike The problem is, that's not true. These problems are not slipping through because of lack of testers. As Alan said, the VM problem has been lurking, which means that it was known already. We currently have no development/production kernel distinction and I have not been able to find even one stable 2.4.x version to run on our main machines. Reverting back to 2.2.x is a real pain because of all the surrounding changes which will affect our initscripts and other system configuration issues, such as Unix98 pty's, proc filesystem differences, device numbering, etc. I have the greatest respect and appreciation for Linus, Alan, and all of the other kernel developers. My comments are not meant to criticize, but rather to point out some the problems I see that are making it so difficult to stabilize the kernel and encourage them to steer back on track. Here are some of the problems I see: There was far to long of a stretch with to much code dumped into both the 2.2 and 2.4 kernels before release. There needs to be a smaller number changes between major releases so that they can be more thoroughly tested and debugged. In the race to get it out there they are making the same mistakes as Microsoft, releasing production kernels with known serious bugs because it is taking to long and they want to move on forward. I enjoy criticizing Microsoft so much for the same thing that I do not want to have to stop in order to not sound hypocritical :-). The Linux community has built a lot of it's reputation on not making these mistakes. Please lets try not to destroy that. They are disregarding the even/odd versioning system. For example: There was a new 8139too driver added to the the 2.4.5 (I think) kernel which Alan Cox took back out and reverted to the old one in his 2.4.5-ac? versions because it is apparently causing lockups. Shouldn't this new driver have been released in a 2.5.x development kernel and proven there before replacing the one in the production kernel? I haven't even seen a 2.5.x kernel released yet. Based on Linus's original very good plan for even/odd numbers, there should not have been 2.4.0-test? kernels either. This was another example of the rush to increment to 2.4 long before it was ready. There was a long stretch of test kernels and and now we are all the way to 2.4.5 and it is still not stable. We are repeating the 2.2.x process all over again. It should have been 2.3.x until the production release was ready. If they needed to distinguish a code freeze for final testing, it could be done with a 4th version component (2.3.xx.xx), where the 4 component is incremented for final bug fixes. - Vincent Stemen - 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: Plain 2.4.5 VM... (and 2.4.5-ac3)
On Tuesday 29 May 2001 10:37, elko wrote: > On Tuesday 29 May 2001 11:10, Alan Cox wrote: > > > It's not a bug. It's a feature. It only breaks systems that are run > > > w= ith "too > > > little" swap, and the only difference from 2.2 till now is, that the > > > de= finition > > > of "too little" changed. > > > > its a giant bug. Or do you want to add 128Gb of unused swap to a full > > kitted out Xeon box - or 512Gb to a big athlon ??? > > this bug is biting me too and I do NOT like it ! > > if it's a *giant* bug, then why is LK-2.4 called a *stable* kernel ?? This has been my complaint ever since the 2.2.0 kernel. I did not see a reasonably stable release until 2.2.12. I do not understand why code with such serious reproducible problems is being introduced into the even numbered kernels. What happened to the plan to use only the odd numbered kernels for debugging and refinement of the code? I never said anything because I thought the the kernel developers would eventually get back on track after the mistakes of the 2.2.x kernels but it has been years now and it still has not happened. I do not wish sound un-appreciative to those that have put so much wonderful work into the Linux kernel but this is the same thing we criticize Microsoft for. Putting out production code that obviously is not ready. Please lets not earn the same reputation of such commercial companies. By the way, The 2.4.5-ac3 kernel still fills swap and runs out of memory during my morning NFS incremental backup. I got this message in the syslog. May 29 06:39:15 (none) kernel: Out of Memory: Killed process 23502 (xteevee). For some reason xteevee is commonly the process that gets killed. My understanding is that it is part of Xscreensaver, but it was during my backup. This was the output of 'free' after I got up and found the swap completely full. By that time the memory was in a reasonable state but the swap space is still never being released. total used free sharedbuffers cached Mem:255960 220668 35292292 110960 80124 -/+ buffers/cache: 29584 226376 Swap:40124 40112 12 Configuration - AMD K6-2/450 256Mb RAM 2.4.5-ac3 Kernel compiled with egcs-1.1.2. - 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.4.4 kernel freeze for unknown reason
On Tuesday 15 May 2001 02:13, Jacky Liu wrote: > Hi everyone, > > Mark, I got your point about the dma/udma stuffs. My hdparm setting is > UDMA w/ MultiSector 16.. > > I had recompiled my kernel and disabled the FB option but my linux box > still hanged (another completely freeze) yesterday... Oh well.. > > I have been tracking this thread for a few days and it seem the source of > this problem is related to swap space. Vincent, would you mind to send me > the patch for swap space problem if Alan had sent it to you? So I can > test it on my machine and report the result later. > I havn't received the patch but, on Byron Stanoszek's suggestion, I have compiled 2.4.4 with gcc-2.95.3 to run on it a few days to see if it is any better. So far, it appears at least as stable as with egcs-1.1.2 and most of the swap was freed up this morning for the first time since 2.4.0. However, it is pretty full tonight. I should know tomorrow if it really made a difference. This is usually the state in which I find it locked up the next morning. It has been up a little over 2 days now. Byron actually suggested I use the ac7 patch but I first wanted to see if the compiler had anything to do with it without changing anything else. > Mark, please suggest a setting for the hdparm so I can test it on my > machine. Thanks alot for your time. > > Best Regards, > Jacky Liu > - 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.4.4 kernel freeze for unknown reason
On Friday 11 May 2001 13:46, Alan Cox wrote: > > I have been monitoring the memory usage constantly with the gnome > > memory usage meter and noticed that as swap grows it is never freed > > back up. I can kill off most of the large applications, such as > > The swap handling in 2.4 is somewhat hosed at the moment. > > > If I turn swap off all together or turn it off and back on > > periodically to clear the swap before it gets full, I do not seem to > > experience the lockups. > > That sounds right. I can give you a tiny patch that should fix the > lockups and instead it will kill processes out of memory but thats > obviously not the actual fix 8) I am not sure if you got my reply to this Alan, but I would like to have you send me the patch. Thanks. Also, I got to thinking back and it dawned on me that there was another significant kernel change when we started experiencing the freezes from the vm problems. We changed the compiler from gcc-2.7.2.3 to egcs-1.1.2 starting with kernel 2.4.0-test10 (That is the version in which gcc-2.7.2.3 stopped being supported for the kernel) and it seems like that was just about the same time frame that we started experiencing the vm/swap problems. I would have to go back and run on the test10 kernel for a while to confirm if it started with it or 2.4.0. I am assuming the source of the vm problem is still unknown or it would have been fixed by now. Is it possible that it could be related to the compiler change? If nobody has considered that, I just thought I would bring the possibility to your attention. - Vincent Stemen - 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.4.4 kernel freeze for unknown reason
On Wednesday 09 May 2001 22:57, Jacky Liu wrote: > Dear All, > > I would like to post a question regarding to a problem of unknown freeze of > my linux firewall/gateway. > > Here is the hardware configuration of my machine: > > AMD K-6 233 MHz > 2theMax P-55 VP3 mobo > 64Mb RAM in a single module (PC-100) > Maxtor 6G UDMA-33 harddisk > Matrox MG-II display card w/8Mb RAM > 3Com 3C905B-TX NIC > RealTek 8129 10/100 NIC > > It's running 2.4.4 kernel (RedHat 7.1) and acting as a firewall using > Netfilter (gShield and Snort), DNS (Cache-Only DNS) and NAT gateway > (ip-masq.) for my home network. I used 3C905B-TX NIC as my internal NIC and > RealTek 8129 as my external NIC. Here is the problem: > > The machine has been randomly lockup (totally freeze) for number of times > without any traceable clue or error message. Usually the time frame between > each lockup is between 24 to 72 hours. The screen just freeze when it's > lockup (either in Console or X) and no "kernel panic" type or any error > message prompt up. All services (SSH, DNS, etc..) are dead when it's lockup > and I cannot find any useful information in /var/log/messages. I cannot > reproduce the lockup since it's totally randomly. The lockup happened > either when I was playing online game (A LOT, like getting thousands of > server status in counter-strike in a very short time frame, of NAT > traffic), surfing the web (normal traffic) or the machine was totally in > idle (lockup when I was sleeping). It was lockup this morning when I was > playing online game (when my game machine was trying to establish > connection to a game server). > > If there is any information you would like to obtain, please let me know. I > would like to receive a copy of your reply, thank you very much for your > kindly attention. > I have been experiencing these same problems since version 2.4.0. Although, I think it has improved a little in 2.4.4, it still locks up. The problem seems to be related to memory management and/or swap, and is seems to do it primarily on machines with over 128Mb of RAM. Although, I have not tested systematically enough to confirm this. I have been monitoring the memory usage constantly with the gnome memory usage meter and noticed that as swap grows it is never freed back up. I can kill off most of the large applications, such as netscape, xemacs, etc, and little or no memory and swap will be freed. Once swap is full after a few days, my machine will lock up. If I turn swap off all together or turn it off and back on periodically to clear the swap before it gets full, I do not seem to experience the lockups. I am running on an AMD K6-400 with 256 Mb RAM but we have experienced these problems with various other machines as well. I hope this information is helpfull in tracking down the problem. The features of the 2.4.x kernels are great and I believe all the kernel developers have done a fantastic job! However, I am disappointed that we are now on the forth 2.4.x kernel version and such as serious problem that has been there since 2.4.0 still exists. This is pretty much a show stopper for having a production machine. In the past when I was running on 2.0.3x kernels, I boasted to everybody about how rock solid Linux was and I was able to run for 5 months without a single reboot or problem, but for the last year or more I have not had much better uptime than certain other commercial operating systems. As important as the new features are, stability should be top priority for production systems. I apologize if this sounds a bit like a rant but I feel that ever since the 2.2.x kernel series, the Linux kernel community has veered away from it's original philosophy of only releasing stable kernels with even numbered versions. In fact, I have seen several even numbered kernels released with far less stability than most of the odd numbered development kernels. - Vincent - 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/
