Slashdot Mirror
Kernel 2.4.12 Released
Whoops. A nasty bug affecting symlinks made it into 2.4.11, and Linus has ditched that "sorry excuse for a kernel" in favor of the new and improved 2.4.12. :) See the (short) changelog or list of mirrors, as usual.
← Back to Stories (view on slashdot.org)
I did not even finish compiling 2.4.11 on my older boxen :(
Does Linus put about to be released kernels through any tests in attempt to avoid bugs like these? Does anyone else remember the brown paper bag bug at the begining of the 2.2 series?
2.4.12 has a new bug that crept in with the parport update that Tim Waugh did.
Check lkml archives for a patch to fix it.
-- MartinG To mail me: echo kewyjlcxyzvjfxbqwh | tr bcefhjklqvwxyz
so much for "stable" huh?
If this had been a really obscure bug I can understand it making it into a stable release, but symlinks? Come on... Where is the sense of quality?
Luckily I only use Linux at work. I use FreeBSD and Mac OSX at home (Windows for games).
you would see a majour turnaround like that from certain large vendors.....
OSS - Imediate effective response.
"Things that you own end up owning you" - Tyler Durden (via Diogenes of Sinope).
Users, doing the QA in Linux for over 10 years!
----- One piece short of Legoland
Just a little Freudian slip there...
Wow, this is bad, but it doesn't appear to be the first time something like this has happened. Testing is something that is sadly overlooked, it seems, for Open Source projects.
Off the top of my head, Mozilla is the only large Open Source project I can think of that has a reliable testing process. I'm sure there are others of course, it just seems that Linux is not one of them. Saying "Release early, release often" and wait for your users to find your bugs is nice in practice, but for large projects you need to have a more structured approach to testing, at least IMHO. Obviously there is some small Unit & Intergration testing done when the code is written and the patches applied, but that won't catch things like this in general. Whats needed is an overall testing plan.
Maybe it's about time the Open Source world started paying more attention to testing?
I already tried downloading and compiling 2.4.12, but in both the .tar.gz and .tar.bz2 files, I get error messages unpacking the tar balls:
---
[lots of names of unpacked files deleted]
linux/drivers/ide/ide-probe.c
linux/drivers/ide/ide-proc.c
linux/drivers/ide/ide-tape.c
tar: Skipping to next header
tar: Archive contains obsolescent base-64 headers
bzip2: Data integrity error when decompressing.
Input file = (stdin), output file = (stdout)
It is possible that the compressed file(s) have become corrupted.
You can use the -tvv option to test integrity of such files.
You can use the `bzip2recover' program to *attempt* to recover
data from undamaged sections of corrupted files.
tar: 160 garbage bytes ignored at end of archive
tar: Child returned status 2
tar: Error exit delayed from previous errors
---
Did anybody else have these problems? I tried downloading from two different mirrors.
Martijn
the file linux/drivers/partport/ieee1284_ops.c dosn't compile due to an undefined constant: IEEE1284_PH_DIR_UNKNOWN, the nearest match found is IEEE1284_PH_ECP_DIR_UNKNOWN in linux/include/linux/parport.h. I don't know, wether that is the right constant.
Read it here
Haha! I wish these people would learn how to code, people in my freshmen CS courses have written better OS's than this! I mean, really, was there no testing done on this? How many bugs don't we know about? What? This happened in Linux, not Windows? Oh, well you know, everyone does make mistakes. Look at the power of open source. Within days, service pack...I mean, a patch was out.
Funny! On the flip side, look how many patches and service packs come out for Windows, but they don't make the Slashdot home page. Good to see we're covering the bad as well as the good.
What's your damage, Heather?
I'm aware that this is not the KernelCrisis hotline; however, since it doesn't appear to be offtopic and it really bugs me and there's a heap of wizzards in here, I'd like to find out more.
Usually, when a new kernel is out, I download the patch, apply it, use the most recent config file, which I go through some, but not necessary through all umpteen options and this usually worked just fine. It doesn't anymore since 2.4.10. From aborting compilations for strange missing files, up to USB race conditions and kernels which if they boot at all, sputter all sorts of gibberish, I've seen it all.
Any suggestions where to look ? Could it be that gcc 2.95.x is really too buggy and why suddenly.
I don't really have the expertise to up/downgrade the compiler and the related libraries. So, I'd be really thankful for each and every hint.
ich bin der musikant
mit taschenrechner in der hand
kraftwerk
Personally I'm sticking with 2.4.9 until 2.4.12 hangs around for a while. I like to see open source developing things quickly, but having 2 kernel releases in 2 days is a little absurd. I think Linus should slow down a little and make sure to hammer out glaring errors like having something defined incorrectly in a file. We'll see if things improve once the 2.5.x series comes out though.
Don't you know that the odd numbered kernels are experimental?
When in doubt, have a man come through a door with a gun in his hand.
Umm, who ever said that?. With open source bugs can be found and fixed much quicker than closed software.
Linux is just a kernel, Windows complete system; like 40 million lines of code or more.
Don't you think it might be about time to have a linux CVS and bugtracker. To my knowledge no such thing exists. Perhaps other people would have actually tried to compile some of this stuff and caught the bugs.
That way each new release can be a "tag" and every new 2.x+1 that occurs can be a branch.
FreeBSD (while not void of bugs) has had a great deal of success with CVS IMHO. The parport bug is that the author submitted something that can't even compile due to a #define constant name that was malformed. I think he forgot the ECP part of it. Someone else posted the patch here in the replies section.
2.4.11 wouldn't even compile for me with either
the old or new Adaptec 7xxx driver enabled. This is the 3rd or 4th 2.4.x kernel that would not compile "out of the box" for me. 2.4.9-ac18 compiled and seems OK on that particular box.
On the bright side, 2.4.11 does seem to have decent VM. And the firewire support seems to be better than before with my Digital 8 camcorder.
My definition of a stable kernel is one that has been handed over to the stable kernel maintainer, Alan Cox.
The stable kernel has become ready for production usage once development has started somewhere else.
May I recommend this attitude to people who complain about the instability of the 2.4 series. It's called pragmatism.
Yours Sincerely, Michael.
I'm in New Zealand, and Troll Friday just doesn't have the same ring to it. Sorry 'bout that.
...because this is Linux we don't need to bother with testing or trying to improve the procedure?!? What kind of BS is that. Anything that would improve the procedure should be considered.
I agree this is an annoying bug, but to paraphrase a coversation between the comic book guy and Bart:
Comic Guy: Worst kernel EVER
Bart: Why do you get to complain? They've given you thousands of hours of entertainment for free?
Comic Guy:As a loyal [user], they owe me.
Admittedly, I'm probably off the actual text by a bit here, the point remain. Try not to be the Comic Book Guy when Linus makes one mistake.
----------------- "I have a bone to pick, and a few to break." - Refused -------------------
On Thu, 11 Oct 2001, Linus Torvalds wrote: ;)
> Not a good week.
>
> On the other hand, the good news is that I'll open 2.5.x RSN, just
> because Alan is so much better at maintaining things
On Thu, 2001-10-11 at 07:54, Alan Cox wrote:
> > And will Alan release 2.4.13 asap with Rik's VM? - (sorry, couldn't resist)
>
> I think 2.4.13 will be a Linus release
Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
lines of code = quality?
Ahhh that's nothing. How do you think windows got from 3.11 to 2000 in a little over 6 years?
compiled 2.4.11 fine on mandrake 8.1
would be interested to know if there's anything i should test to see if it works, but as far as i can tell, everything works.
On the flip side, look how many patches and service packs come out for Windows, but they don't make the Slashdot home page. Good to see we're covering the bad as well as the good.
What are you talking about ? Seems like Slashdot is constantly running stories about this or that bug in Outlook, or Powerpoint, or IE, or....
If WinXP had as big a showstopper flaw as this one in 2.4.11, you can bet the criticism here would be loud, ridiculing, and vociferous, even if MS released a patch for it in the same timeframe. As it is, there is really no criticism, just a big mutual love-in. You are deluded if you think Linux flaws are covered with the same scrutiny here that Windows' shortcomings are.
No, you have it completely wrong. Of course you do pre-relese testing, and better pre-release testing is always a good thing if you can manage it.
Open source is a paradigm shift. The standard way of thinking about releases, which never was very practical, IMHO, is misleading.
There are two outmoded connotations to the word "release" which you need to free yourself from. First, is that "release" is a indicator of some absolute level of quality: that the number of bugs is small and their severity is low. Second, that the "Current Release" is the best version for you.
I don't think the idea of "release quality" was ever realistic, except in some limited circumstances. Another way of putting this is that the true test of a product is when it is put into actual widespread use. What a release represents in most case is a slowing of velocity of change, at which point more testing benefit is gained by putting the product into use than by our contrived tests. This slowed velocity is sometimes a sign that the bugs are few and not very severe, but it is always a sign that the developer's ingenuity or energy is exhausted. There are always more bugs. You have to be re-energized and refocused by reports of needs or problems by people in the field.
Sometimes this comes quickly. I personally have "released" software which I almost immediately retracted because of a severe flaw I missed. In any case, more energy and ingenuity in testing is always better, but the marginal value of internal testing at some point is always outweighed by real world tests.
The second mistaken idea is that the "current release" is always best. This idea was never very credible -- it's more of a fiction which enriches the software developer. Ask a common user, and you will find they often favor older versions of the tools they use.
To bring this back to testing, one benefit of open source or free software for something like an operating system is that I can get a better tested product (in real world terms) by being selective about which release I choose.
And, the level of testing for a complex product like the kernel is not a single metric -- it depends on your exact configuration and requirements. Thus for some embedded developers, versions of the kernel in the 1.x range are the best tested alternatives to use. For most users today, late version of the 2.2 tree are the best alternatives. For people with multiple processors, their best bet may be somewhere in the 2.4 tree, although it may not be ready for mainstream use.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
Maybe now this has happenned he will start 2.5 and hand over 2.4.x to Alan who IMO keeps kernel series stable better than Linux does.
;o)
That's exactly what Linus said in his 2.4.12 annoucement. But I guess you knew that already
Black holes occur when God divides by zero.
I'll be more than glad to cut 'n paste all the supportive responses here into that one for you. No worries.
Christ. When it comes to Microsoft, you make it sound like downloading service packs twice a year and patches once a month is an impossible task for people to undertake, yet when it comes to Linux, you willingly download and compile buggy code on a regular basis?
Posting anonymously to preserve my karma as the mob mentality here can be a bit frightful. Doesn't seem to matter if the differing opinion is an insightful one: we keep things happy by making the dissenters disappear. Huzzah.
Yeah, but this is really an internal release from the linux kernel group to the distributors. Any large ISV will produce many 'release' builds that would be knocked back by their release/quality control teams. With linux everything is out in the open and you are seeing all these communications. You want to be part of the linux kernel release team then down load it and play with it. If you don't then wait for Redhat, Mandrake, Debian (stable series) to be relesaed.
This is rated as "funny" and I just don't understand why. Obviously there are a lot of people who compile a new kernel without complaining but when they are told to "uncheck the xyz box in preferences" to prevent an exploit, they just freak out.
This is just ignorant. Get over it.
in drivers/parport/ieee1284_ops.c replace
IEEE1284_PH_DIR_UNKNOWN with IEEE1284_PH_ECP_DIR_UNKNOWN
Are you suggesting a conspiracy?
I've had enough abrasive sigs. Kittens are cute and fuzzy.
...im still running ol'trusty 1.1.59.....
...
but i cant figure out why my box keeps getting owned...
oh well
I lost my concept of community when my community lost all concept of me.
Comparing a release version of windows to a development version of linux is hardly fair. Do you remember beta-1 of win2k? it crashed on 90% of attempts to open a folder, and i`m sure there were even worse development versions which never were released
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
This is the stable-series kernel.
I really feel that 2.3 was turned into 2.4 because of marketing reasons, since it is obvious that 2.4 isn't ready yet.
2.2->2.4 was supposed to go faster than 2.0->2.2 took (ages). As the release of 2.4 was postponed and postponed the pressure got (too) big to give in and release it.
allows a bug like this? I was about to upgrade my Kernel to 2.4.11...good thing I hestitated.
This release process, along with the 2.4.x VM problems may induce me to try FreeBSD....
hmm... i've only just had a kernel panic while recompiling 2.4.12... waiting a couple of days before installing the latest kernel might be a good idea :)
I'm running 2.4.11 so I just downloaded the 2.4.12 patch and attempted to apply it.
/tmp), but using the --dry-run command it seemed fine.
/usr/src/linux symlink, and tried to 'mv linux-2.4.11 linux' to see if that would allow me to apply the patch. Well, thats the first time i've seen the 'mv' command segfault! Machine then locked solid. Is this a manifestation of the symlink bug?
Well, the patch wouldn't apply properly (some crap about a file already existing in
Sooo, I deleted my
After rebooting, fsck went mad, but I seem to have a working system again. Watch out!
Jeff
stty erase ^H
It is encouraging to see this kind of outrage over a mistake like this. It tells me that OSS still has higher standards than closed-source software.
Let's never become complacent!
This kind of bug should be caught by regression tests before it's released in an official kernel. Anyone knows what kind of tests the kernel people use?
I'm a relative newcomer to the Open Source world, but what has struck me is how none of the big profile projects seem to have their own test harness or test suites. Maybe I'm missing something. Please let me know what test suites major OSS software ships with. (The only one I could think of was autoconf, which isn't a quality-management test suite but a build manager, and the Perl build process does a few demonstrations of terminal features.)
What I mean is something like "make test" integrated into the project. Running that generated test code would perform hundreds of sanity checks (or even thousands for complicated projects) on the code.
Perhaps Red Hat and SuSE have this kind of code locked away in their "commercial advantage" (and I could see the arguments for keeping those closed) but it would seem to me that Linux and Alan Cox and crew would be more open about test suite software for the kernel.
Install a kernel, run a battery of tests. Find systemic breakers really quickly. It's not hard, it's just a matter of discipline to write the tests. As code is written, write the tests for the code. Any time a bug is found outside the normal test suite, write the test that should have found it. Automatable tests wherever possible.
In the "eXtreme Programming" development paradigm, this is codified even more vigorously: write the test(s) BEFORE the code. In Eiffel, you program by contract; each method has a pretest and a posttest to ensure that the state of the world is correct. Part of the official build process for releasing the software should be a 100% compliance with the automated tests.
[
Nowdays we get a newkernel spit out every second day and people instantly downloads it.
thenthey start to complain about lackof testing.
YOU are the ones who should testthis folks.
if you dont like it, why change kernel.
my main machine still running 2.0.30
why ? well i dont need any of the newthings.
just because its new and shiny, it doesnt have to be better folks.
with 2 yearsof uptime, i would never even think of swapping kernel.
andif i find i abug, i dont complain, instead i fix it, that is the way of open source.
learn to code before complaining people, it really isnt all that hard.
my main question is why download a new "release"
if you arent prepared for bugs orto sort them out?. No one, and i mean nooo one who codes can make a totally bugfree product.
/ J.Thorsell Sysadm.
[toasters ? we don't need no stinking toasters!]
Ya, and at least we don't have to patch Windows with crap like this: ;)
--- linux/drivers/parport/ieee1284_ops.c.orig Thu Oct 11 09:40:39 2001
+++ linux/drivers/parport/ieee1284_ops.c Thu Oct 11 09:40:42 2001
@@ -362,7 +362,7 @@
} else {
DPRINTK (KERN_DEBUG "%s: ECP direction: failed to reverse\n",
port->name);
- port->ieee1284.phase = IEEE1284_PH_DIR_UNKNOWN;
[ETC]
There is no longer anything that can be done with computers that is nontrivial and clearly legal. -- Paul Phillips
First of all, let's all remember that the amount of money we are paying for the linux kernel is $0.00. Secondely, if you are bothered by the testing process, download some pre-releases and test it yourself. Thirdly, this kernel was not included in any linux package that I know of, and we all know that Mandrake, Redhat, and all the other linux packages, do testing themselves, and usually don't release the bleeding edge kernel in their releases, so the amount of exposure is minimal. Should 2.4.11 been released, well no, but it was and it was fixed quickely, and you can always revert back one version if something is not working. So everyone take a deep breath, and remember, IT'S FREE, a lot of these guys are submitting these patches on their spare time. What have you done to help out?
KidA
"Karma can only be portioned out by the cosmos." -Homer Simpson
Personall, I don't.
sometimes I compile new modules, but that's it
Just look to see if there is a problem fixed with the new kernel, if not, leave it.
This is only the second kernel I will have built (just installed Slackware 8.0 for the first time, and built 2.4.11)...Can I reuse the configuration file created by "make menuconfig" with 2.4.12, or should I try and re-select all the options I had previously?
i think "uptime" would be more accurate than "entertainment". Unless you think Linux still belongs in the game section.
Lycestra
Believe it or not Linus is Human, people do make mistakes. Show me software that has never had a bug.
Snoozer.
I have 2.4.9 and have patched it with 2.4.10 and in kernel.org there are files that say: :-(
patch-2.4.11-dontuse.bz2
but there is a
patch-2.4.12.bz2
Now to go from my 2.4.9 to 2.4.12 is it somehow possible to just patch it with patch-2.4.12.bz2, or do I have to download the whole kernel again?
Hope not, as my little modem won't be very happy.
There is no test suite because
1. Producing them is boring
2. They take a long time to write
3. 'Real Hackers'(TM) don't use them
4. Did I mention boring?
5. If you get them wrong, you can end up keeping bugs because it's easier to work round the bug than to change the test (been there, done that)
I get the impression that Linus is "rushing" releases of 2.4.x in an atempt to get it mature. Perhaps then he can say, "it's stable/it works" so that development on 2.6.x/3.0.x(?) can open up full swing? He mention in the interview posted yesterday that he wouldn't really jump into that until 2.4.x was a little older.
:)
*shrug*
It just seems that the patch on this tree are coming out faster than any of the other branches before it. And many more "issues" slipping through the cracks including controversy and laziness. I don't know about the rest of you, but I would prefer slower progress in favor of more careful, more tested releases.
Why bother.
gcc has a testsuite. Mozilla has a form of a testsuite.
Yeah, but Linus doesn't really give a crap if his 'stable' kernels destroy your system or not, so it really doesn't matter what the marketing is.
If you want a stable kernel from someone who does give a crap, go to RedHat or another vendor.
My pet complaint is documentation which is sometimes barely there at all. Saying, as some do, "Well, what did you pay for it?" implying that its "free beer" status excuses this doesn't cut it when we're also saying "Hey, ditch your proprietary commercial stuff and use this instead!" We should coin a new acronym. WITFM. Where is the F#%@#*@ manual?
We bash M$ when they turn out buggy products and declare that they don't have a quality software process. The same is true of open source. The problem isn't closed source and the solution isn't open source. Both sides simply need to use a stronger process if they're to produce quality software.
that's why I always wait some weeks before I install some new kernel..
shame on you!
tsk tsk tsk...
I'm sorry that Linus hasn't grown up yet. He scoffs at version control, he scoffs at regression testing. In fact he scoffs at QA. Pity.
I couldn't agree more. Testing is incredibly important for software projects and automated tests makes sure that certain test are not forgotten.
GCC has a test suite: http://gcc.gnu.org/testresults/ and uses the test suite as a formal release criterion. The GCC team also uses those tests as benchmarks for the compiler.
Where are the ext3 patches for 2.4.11 and 12? I can only find some -ac patches and 2.4.10
My other car is first.
devel opers devel opers dev elo dev elo devel op ers *scratch the harddisk to the record*
Install a kernel, run a battery of tests. Find systemic breakers really quickly. It's not hard, it's just a matter of discipline to write the tests. As code is written, write the tests for the code. Any time a bug is found outside the normal test suite, write the test that should have found it. Automatable tests wherever possible...Part of the official build process for releasing the software should be a 100% compliance with the automated tests.
There is a comprehensive testing suite in place for linux; in fact, we just saw it in action. It involves testing the kernel on thousands of boxes simultaneously, running ten of thousands of hours of tests, and getting feedback to the developers within a few hours.
To paraphrase pogo: "We've seen the test suite, and it is us."
Now, this may seem odd or broken, but it has a few charming advantages. First, the costs are distributed amongst those that benefit most, with zero accounting overhead. Second, the response time is very fast. Third (and, IMHO, most importantly) test coverage is maintained by the same laws of statistics that make sure there is air for you each time you take a breath; if usage patterns change, the new usage is included in the tests automatically--even if no one is consciously aware that they are doing "something new" it still gets tested.
-- MarkusQ
Some projects do have a "make check". Perl does. Kaffe does, though the Kaffe checks usually fail because Kaffe kinda sucks :)
Not a typewriter
People this is unacceptable, we need to do some rigorous automated verification before releasing kernels. Come on! Release often, yes when it passes the test suite. Add to the test suite as bugs slip through. This is basic software development, testing is NOT a separate proces, repeat, testing is NOT a separate process
Can you imagine a proprietary software company saying the truth (let alone such a harsh coment as Linus') about its own product?
"I'm ditching the sorry excuse for a web server that IIS is..." Yeah, right.
As for "extreme programming". I've tried it, and it sucks. You get a nominal improvement in efficiency for small projects and a HUGE increase in overhead for anything over a million lines (ie: 7 people).
Linux Test Project.
M. R.
VA linux has a test suite for the linux kernel which they use to qualify the kernels before using them on their boxes (that is why they stayed with the 2.2.18pre11 instead of moving to the 2.4.* series). It is hosted on sourceforge now (too lazy to lookup the name of the package).
SGI and others have started a quality assurance program for the linux kernel too. Maybe it is time these got integrated into the release process.
unless pass test suite languish;
release non buggy kernel;
1
They exist, created by VA Linux and now SGI and others. Problem is they aren't integerated into the release process so separate entities privately test the kernels before including them in their products.
What should be done is integrate them into the release process
you're old enough to drive and work and you still troll slashdot?
jeez, that's pathethic.
at least if you were 12, you'd have an excuse.
Both GCC and Mozilla are primarily driven by commercial software companies.
It should be noted that RedHat and Mandrake have test suites and don't ship kernel du jour.
TeX has the trip test (and MetaFont has the trap test). But writing good testsuites is hard.
You can also use make menuconfig, then do load old config (all the way on the bottom for the menu)
Although You don't get to see what new options they added, but if you really wanna stick with the menu UI then that method's fine.
Kernel 2.4.12 does not build. This the error it fails with:
init/main.o: In function `check_fpu':
init/main.o(.text.init+0x63): undefined reference to `__buggy_fxsr_alignment
make: *** [vmlinux] Error 1
I, for one, welcome our new Antichrist overlord.
There's a very easy solution: Just wait for a while before you upgrade. That way you can decide for yourself how long you think the code should be tested before want to use it.
There's just one problem with it. If most people did that, bugs would take a lot longer to be found, let alone squashed. And the problem we've seen in 2.4.11 is not some obscure, minor thing that would have not have hindered stable use of the kernel. (Before you argue that, consider how severe it is, this is a show-stopper bug. Bugs in the kernel that corrupt the file system, even if they are rare, are serious problems.) This should have been caught and the fact that the bug exists indicates that whoever made the changes that created failed to even test said changes. 2.4.x is a "stable" kernel tree, and there's no reason why anyone should have to wait a couple patch levels before upgrading to the latest. There should be more thought and testing done on such a branch before releases are made. Period.
Why bother.
"showstopper flaw"? It affected one part of one program that NOBODY, other than the ppl at SUSE who are building the distro, would ever rationally run under the new kernel. Yes, people upgrade their kernels all the time, but how many of them upgrade before they run the installer?
In any case, this pointed out something awkward that the SUSE installer was doing, and it will probably not do it in the future. I'm sure there are quite a few syscalls in XP that won't work right given a particular set of obscure options. On top of that, when has MS -ever- had a rapid turn-around on bug-fixes?
my sig's at the bottom of the page.
What I guess happened, is that the initial success of upgrading from 2.2.x to 2.4.x somehow steamed into my head. And after I had 2.4.x successfully running, I never really bothered to go through all the config options again.
Obviously that works fine to a point, but only to a point.
So, I'll do it with the make oldconfig from scratch.
Thanks to everybody who contributed, you live and learn...
BTW: The compelling reason is the HP82xx CD writer, which apparently has to either be patched in, or is hopefully supported in 2.4.12 without too much pain.
ich bin der musikant
mit taschenrechner in der hand
kraftwerk
We have to ASSUME that the MS service pack installer does what it's supposed to, and doesn't break anything in Windows, or in your applications.
2.4.11: shortest release ever (must be said in the voice of that fat comic book guy on the Simpsons)
How many bugs don't we know about?
:P
If nobody knows about it, it's not a bug.
This space intentionally left blank
REALTEK driver fucked in 2.4.11 -> 2.4.12
As someone who ran 2.3.48 for six months on several machines with no problems, I was bitten by massive IDE disk corruption when I went to 2.4.1.
A bunch of us did a WTF and wondered if this stuff was still beta. How can 2.4.X series be called anything other than development when serious changes continue to be made without serious testing?
Relying to test suite practically quarantees that there're bugs in your end product. Test can only guarantee that previously occurred bug doesn't happen again. This is because you cannot test all inputs for any non-trivial program. And practically all programs that can be proved to be correct are so trivial that one can hardly make any mistake coding them...
_________________________
Spelling and grammar mistakes left as an exercise for the reader.
The perl test suite is FAR more than just testing the terminal. It is very nearly a full-coverage regression suite. There are defined procedures for module authors and tools to create test suites.
There's been work to get similar things for the kernel, as well.
I'd personally be a little scared of testing kernel functions, but I've tested a lot of so-called "untestable" things lately. It's worth doing.
how to invest, a novice's guide
I've heard of "release early, release often" but this is ridiculous. (-:
Actually, I can't wait to see what 2.5 development will bring us. The fact that so much is changing even in the stable kernel likely means developers will really cut loose when 2.5 work begins. I think it's actually quite exciting. (As long as 2.4 gets all its holes patched up in the near future of course..)
Calling this bug a “showstopper flaw” is wrong and uninformed. It caused a problem with one application in one distribution that was doing something that it probably shouldn't have been doing (creating files through a dangling symlink? ugly!).
A 24 hour patch release from MS is insanely unlikely, especially for a small bug like this one. It took them months to fix the ping-o-death bug, and they didn't even fix it correctly the first time.
If windows flaws recieve greater attention than linux flaws, it's probably because there are so many more of them and they're so much more severe.
"To blow recursion, you must first blow recus
At least we get to see those changes and the source itself with OSS and free software.
J
So many folks get mad when Linux has bugs. Most of this is because they do not understand the model.
Let us compare the Linux development of a 2.odd version to a project branch in your average software company. That project branch will be unstable and used only for feature testing.
Then, you have the 2.evens. These are equivalent to a release branch or product mainline. You expect these to be *more* stable, but you still don't expect perfect code. When these are sent to your release egnineers and Q/A, you get several small rounds of bug-fixing as a result of regression tests, feature verification and so on.
This last step can be mapped to what distribution vendors do. So, for example, we expect Red Hat to go with something like 2.4.12, but to add the parport patch into their SRPM. They will doubtless also discover several other problems, or may be dragging along patches from previous kernels that have yet to be merged.
This is the art of release engineering. There's no such thing as a developer-released product. Never was. This is the value-add that distributions give us. They act as Q/A.
Would there have been a test for this - probably not?
Not the first time it crops up.
But test suites grow as new, previously unthought of, bugs emerge blinking into the daylight.
*cough* in theory *cough*
__
Arse
The Gnu Compiler Suite has an extensive regression test. See for example "GCC Automated Testing System" or "GCC 2.95 Regression Test Strategy"
If you need to write a regression test for your own software check out DejaGnu.
--Andre
...I had just finished downloading 2.4.11 on my SLOW 24k connection when it was released. :(
How I wish for broadband.
Ummm... Let me guess. You haven't even READ the MS help files have you? At least linux has FAQs scattered across the net (also free). You don't have to go purchase a $50-$100 book on the OS to get the most out of it. I don't mean to be making excuses. We (the linux community) could be doing better. I'm just saying that "evil corporate constructs" such as managers do not usable documentation make.
Yes I do sound like a linux zealot. That's my cross to bear. My message is no less poignant or acurate.
I spoke sloppily. Only a few terminal tests are made prominent because they are interactive. Agreed and understood.
[
Stanford already has a test suite for linux kernels, and it fixes hundreds of bugs that Alan Cox incorporates and passes along.
The checker lives here
Keep in mind that the first release of 2.4.0 was only released because Linus had gotten tired of the same people testing the 2.3 kernels, or 2.4 prereleases, whatever they were called.
Not that I agree with doing things that way, it is somewhat practical. A user of a 2.4 kernel has to keep in mind that although it was a 2.4 release, the series hasn't been officially declared totally stable yet, at least to my knowledge.
So Linus screwed up and instituted a bug into the kernel, but do you realize how fast it was fixed?
(about 2 days I think....)
You show me what other OS has that kind of turnaround on patches. (And don't say that other OSes wouldn't have released it with this kind of bug, because we all know it happens...)
why didn't they release a patch and they actually prefered to release a new version.
they get released into the "stable" tree.
Perhaps, then, it can be said that they follow the "Slashdot" model of development: Post first and correct things (maybe) later.
Is your company running tools written by ma
This won't affect many uptimes, and most frustrations will be brief. The only fallout will be damage to that massive, precarious infrastructure that is the Linux Community Ego. We spend all day bashing Gates and his team of one million monkeys banging on one million keyboards connected to one million NT boxes running one million copies of VC++.. but when our resident messiah releases defective code? The contents of this thread is proof enough that we're ill-equipped to deal with it.
C/C++ and many other languages have an equivalent to Eiffels pre/post tests....use asserts :)
I am sure that the kernel has liberal use of assertions, if not well, I would be very suprised
proxy
Wow, this really *is* an insightful comment. Thanks, you made at least me think about this.
;))
Fans of closed source might take your comment as an attack on open source, but I think many closed source programs suffer some of the problems you name too (for example, lack of documentation). Still, you really have a point. Security audits, documentation, user interface consistency checks, timely testing features that might have been broken, centralization and management are things that are essential for end-users, who want to trust their programs. But few people do these things in the open-source community, at least AFAIK. It is difficult work, responsible work, sometimes even boring. We really need these people who dare to stretch their heads above the crowd.
(Hmm, now hear me.. For a moment I thought managers could be useful!
I had been bullish on the Linus+AA kernels (2.4.10 ran pretty well with week-long uptimes) but 2.4.11 had the symlink thing and only got 8 hours up before 2.4.12, which just locked hard under load after only about 4 hours.
I guess it's time to hit 2.4.10-ac11 and see what Alan+Rik can do for me. The 2.4 series so far has been a crap shoot... I wonder if they can save it before 2.4.15-20 or so?
My vote (I don't know these people so it's by no means binding): Linus starts 2.5 and leaves this 2.4 nonsense behind (sooner we get a 2.6 the better) and Alan makes a big, ugly change to allow user-select at compile time of Rik's VM vs. AA VM. Both Rik and AA then both get to keep going nuts trying to keep the 2.4 boxes up...
STOP . AMERICA . NOW
I saw which file was causing the problem and simply turned that option off. Very bad move.
Writing to my zip drive (imm, not ppa) now no longer works properly. I can say 'sync' and even umount the thing while it is writing and it simply does it. What it does not do is wait for my data to be written.
It is back to 2.4.10 for me, even the 2.4.11 bug is preferable to this. I will be upgrading to SuSE 7.3 at the end of the week anyway and it uses 2.4.10 so this is not just defeatism.
Mielipiteet omiani - Opinions personal, facts suspect.
There are three issues in the case of the Linux kernel: (1) It depends on hardware. Nobody has one of everything, so nobody could do a comprehensive test. Sometime one driver will turn out to make one assumption, and another driver will make a conflicting assumption; either will work, but not together. (2) There are a lot of situations where the specified behavior is underdetermined, and, in particular, cases where you can do a set of things the original programmers didn't expect you to do together. There won't be tests for these sorts of things. (3) There are a lot of corner cases that are hard to make happen. It's very difficult to put the kernel into certain combinations of states, so, on most trials, the situation won't even get tested. This is particularly the case with race conditions between processors and things that depend on peripheral timing.
I agree that having a test suite would be good for catching a lot of simple bugs in places that are easy to test. Sometimes a new kernel will have something that doesn't work at all, and that should get caught. But there are relatively few of these, compared to things which aren't really quite safe, although you have to look at them carefully and think about them, understanding the code, for a while, and these are the more important bugs.
I did a make oldconfig from my 2.4.7 build, everything compiled fine, but no targets in my rules were recognized.
I did the same thing with 2.4.12 and everything works fine. BTW, Im not using a modular kernel. My FW has only 50Mb of ram. I assume a static kernel is faster, and uses less RAM. Am I wrong?
I've recently noticed the addition kernel debugging under the kernel hacking section. Is this adding support for the long debated kernel debugger, or is it just a new name for the Magic SysRq key?
A musician without the RIAA, is like a fish without a bicycle.
to release 2.4.13?
Slow down, cowboy! It has been 4 hours since you last posted. You must wait another few hours.
> You want to be part of the linux kernel release team then down load it and play with it. If you don't then wait for Redhat, Mandrake, Debian (stable series) to be relesaed.
Not Debian stable if you expect to use 2.4.x; all the packages in stable are 2.2.x.
There was this guy at Cisco, I forget his name who did a really excellent speech at OScon (which was webcast, though I cant remember where. The speech was entitled something like "Will the future of the interned depend on Open Source?"
;)
He brought up a few really good points and one of them is that few people run their businesses off of open source software they downloaded from the web because of compatibility testing and difficulty in support (because the system may end up with a non-standard setup which may be difficult to administrate). So instead they use commercial products. Commercial != proprietary, in this case, and definitely includes Linux distributions where everything has been tested together and has a consistant administration interface.
So for the most part, these "releases" are more like "beta products" which require further testing before they are released in the production system. So what you are talking about when you say "released" is really irrelavent anyway because the kernel IS NOT aimed at production systems initially. It is aimed at developers primarily. So if you are a developer, you will find the bugs and these can be fixed
Your concept of the procedure seems to be:
1: Kernel is developed.
2: Kernel is released with little or no testing.
In actuality the process is more like:
1: Kernel is developed.
2: Kernel is released with little testing.
3: Kernel is tested by developers and distributors. If distributors find that it works, they use it.
4: Bug fixes are developed into the kernel (go to step 2, add one to z where release number is x.y.z). Some times kernels with an odd-numbered y will be released as kernels with an even numbered y by incrimenting them when they become ready for real testing.
LedgerSMB: Open source Accounting/ERP
Slackware also uses 2.2.19. Hmmm, I wonder why 2 distros with a rep for stability would use such an old kernel. :)
Slow down, cowboy! It has been 4 hours since you last posted. You must wait another few hours.
PostgreSQL has "make check". GCC has a regression test suite.
Most CPAN modules have tests, whether trivial or comprehensive.
And these are the ones I can think of off the top of my head.
Become a FSF associate member before the low #s are used
Problem 1: Writes to /dev/fd0 with 'dd' were corrupted when dumping a disk image to a 3.5 floppy. I tested this a couple of times on two new floppies dumping a chunk of bytes from /dev/urandom into a floppy-sized file, using 'dd' to dump the file to floppy, and doing a 'cmp' between the file and floppy. When I looked at the floppy with a hexeditor, I saw that a chunk of bytes from the source file were repeated at the beginning of the floppy. I went back to 2.4.9 to test writes, and they all seemed to work properly.
Problem 2: 2.4.10 didn't boot properly when I dumped it to a floppy. I got a oops and a kernel panic when it would reach the point where it loads the rootdisk portion of the floppy into the ramdisk. Again, regressing to 2.4.9 with a similar configuration fixed the problem first try.
The first one worries me a bit, although I didn't notice any corruption elsewhere. I wonder if one of the later -ac patches would be safer.
Try not. Do or do not, there is no try.
-- Dr. Spock, stardate 2822-3.
Through extensive testing I've discovered a huge bug. In fact, I've sent several e-mails to M$ about this, informing them that it's impossible to win this wretched game.
Not to mention the addictiveness - this game should be regulated as a controlled substance.
Is it just me, or does it seem like 7.2 is a little late? I recall downloading earlier fall RedHat releases in mid september rather than mid October. If it means that the code will be of a higher quality, so be it. I don't mind the delay, but I am curious if it is coming soon, and if anyone knows when.
I certainly have to wonder exactly how you could automate testing of kernel processes, without making it a habit of completely blowing up your test machine every time you try something new. heh.
"Champagne for my real friends - and real pain for my sham friends!" http://ericblade.postalboard.com/
2.4.12 installed and running:
(1) my power supply fan that has been squeaking for weeks stopped
[i think that had to do with the fact that i moved something that it was rubbing against more than ugprading the kernel]
(2) when i booted, i logged in as root, and typed "free" - it reported close to 55MB free (out of 96) - previous kernels gave me sub 32MB.
(3) after 'startx' (running GNOME w/sawfish), i opened an xterm, and STILL had 10MB ram, no swapping yet.
(4) executed a kernel recompile, loaded my web browser, and still haven't gone more then 4MB into the swapper yet.
I"m impressed.
"Champagne for my real friends - and real pain for my sham friends!" http://ericblade.postalboard.com/
I guess I'm also saying pick which side of the fence you want to be on. Are we saying don't whine about what you get because you didn't pay anything for it and should therefore be expected to work harder to get it to work, or are we saying Open Source is a viable alternative to commercial software? You can't have it both ways. More to the point, your potential customers (users, if you prefer) won't let you have it both ways. People have work to do and killing a day or two of work to figure out how to make the software do something is very often not acceptable.
Looks like a Linux company in the making. Two goals: a) test the kernel as well as popular apps and release reports of the results on the web, and b) take the current (often cryptic) FAQs and HOWTOs and write *understandable* books on various topics. Books which can be bought in paper form or downloaded from the aforementioned web site for a much smaller fee. Or parts of books/documentation which can be ordered via a web-based index system for just those problems that the user wishes to address.
The only weak point that I see in Linux (OS and apps) is the documentation, much of which generally sucks because it was written by someone with little skill in stringing non-code-oriented sentences together. Or because the person who was writing the documentation was actually pretty good at it, but took a great many things for granted that utterly confuse a newcomer to Linux. I think a company like this, if it did the job well, would make a tidy profit - especially with the Linux adoption rate growing as it is.
If any non-neo-nazi management-types are up to creating such a company I'd be happy to write some of the books/chapters/documents in question. Scratch an itch and make money at something I like to do at the same time.
Assuming you're willing to pay me enough to pry me away from teaching children about computers, of course. So far no job that I've had beats teaching middle school students!
Max
My god carries a hammer. Your god died nailed to a tree. Any questions?
I did work experience @ SGI and they made me do PCPQA testing, boy was that boring, trust me I can give you a compelling reason not to, you just try to PCPQA for IRIX!
Don't get me started on their "troubleshooters". The first question a MS troubleshooter should ask is "Are you an idiot?" and when you click "No" it should take you straight to the "The troubleshooter could not help you with this problem." screen. This would have saved me hours, I don't even bother to start up the troubleshooters anymore.
With linux I have some hope finding the info I need in the man/info pages, with windows it's straight to google.
I fully agree with your basic premise. Regression testing is vitally important for these kinds of large systems. The process of developing your test suite in parallel with your production code can go a long way to helping structure and document the system as well.
That about sums it up.
Remember -- you have a choice about which kernels, and which kernel patches you want to run.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
2.4.11 : a kernel that will forever live in infamy.
my sig's at the bottom of the page.
It seems to me that the Linux kernel was written by linus in the first place for himself and then given to the open source community to help others learn and, to possibly provide an alternative to proprietary software as is the same deal with other open source projects. You people are complaining that a bug was released in 2.4.12 but simply put this is not commercial software and if you look at commercial alternatives they have many more "bugs" than Linux does anyway. Your getting high quality software for free and complaining that your not recieving commercial type support and QA...
blah blah blah... get a grip people!