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)
It isn't a bug with all symlinks. It occurs (if I understand it correctly) if you create a file via a dangling symlink, which is really not a good thing to do anyway. (but Suse's YAST does this)
-- MartinG To mail me: echo kewyjlcxyzvjfxbqwh | tr bcefhjklqvwxyz
Actually... according to everything I have ever read about linux the unstable development tree is 2.odd.whatever. Everything in 2.even.whatever is called the "stable tree".
Please correct me if I am wrong.
Read it here
There are errors in the bz2 images on ftp.kernel.org. They do not pass the gpg verification, and are basically corrupted images. the gz images work.
Philip
Do not underestimate the value of print statements for debugging.
Patch is here:
--- 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;
+ port->ieee1284.phase = IEEE1284_PH_ECP_DIR_UNKNOWN;
}
return retval;
@@ -394,7 +394,7 @@
DPRINTK (KERN_DEBUG
"%s: ECP direction: failed to switch forward\n",
port->name);
- port->ieee1284.phase = IEEE1284_PH_DIR_UNKNOWN;
+ port->ieee1284.phase = IEEE1284_PH_ECP_DIR_UNKNOWN;
}
fucktard is a tenderhearted description
Hey, Linus is only taking the responsibility for not having reviewed one of the incoming patches good enough. Having bugs in the current stage of the kernel is understandable - Linus' 2.4.10 and 2.4.11 kernels contain a brand new VM that already needs a lot of his care. What I do: I run Alan Cox' kernel series.
And if like me you couldn't apply this patch, you can do a search and replace for IEEE1284_PH_DIR_UNKNOWN in linux/drivers/parport/ieee1284_ops.c and replace all instances with IEEE1284_PH_ECP_DIR_UNKNOWN
I've compiled and installed 2.4.10 several times now. Works beautifully on all three of my machines, including multiple compilations and installs while I figured out what the different options did. Throughout this process, I never had a non-working kernel, let alone an oops.
I also have a good mix. My first machine (PII) uses USB and devfs extensively. My second (PII laptop) uses USB irregularly, but not devfs. My third (P) uses neither. I've had no USB problems or anything.
Make sure you're using the absolute latest release of 2.95. Mine says 2.95.4 (gcc --version). That's on Debian, so I don't know if it's the same as the RH 2.95.
Don't use GCC 3.0; AFAIK it still doesn't compile the kernel correctly.
Also, you may have to go through all of the umpteen menu items. It looks to me like a lot of new options added between 2.4.2 (the last one I compiled) and 2.4.10. I understand you've been doing this up through 2.4.9, but you might have just been lucky, and with 2.4.10 it was just too fragile. Certainly missing files on compilation suggests that your config file may be broken.
I hope that helps.
Um, you should use "make oldconfig" when you're upgrading kernels and using the same config file. It'll prompt you for any new options.
The Alan Cox series (latest is 2.4.10-ac11) works fine here. I'm currently running 2.4.9-ac18 from a week ago. Here's how to get it. I use gcc 2.95.4 under Debian - as far as I know it was not yet recommended to compile the kernel with 3.0+, but it might work.
It is the right constant. Tim Waugh has released a linux-booboo.patch that corrects the constant in ieee1284_ops.c to IEEE1284_PH_ECP_DIR_UNKNOWN.
Linux 2.4.12 compiles nicely for me now that I've integrated that patch.
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.
This is getting slightly annoying, I just compiled 2.4.11 on my box last night and now I hafta do it again, only to learn of a new bug.
/usr/src/kernels/linux/include/linux/modversions.h -c -o ieee1284_ops.o ieee1284_ops.c
Actually I am not sure what people keep talking about with this bug. As far as I could tell this error is caught by the compiler...
gcc -D__KERNEL__ -I/usr/src/kernels/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2 -march=i686 -malign-functions=4 -DMODULE -DMODVERSIONS -include
ieee1284_ops.c: In function `ecp_forward_to_reverse':
ieee1284_ops.c:365: `IEEE1284_PH_DIR_UNKNOWN' undeclared (first use in this function)
ieee1284_ops.c:365: (Each undeclared identifier is reported only once
ieee1284_ops.c:365: for each function it appears in.)
ieee1284_ops.c: In function `ecp_reverse_to_forward':
ieee1284_ops.c:397: `IEEE1284_PH_DIR_UNKNOWN' undeclared (first use in this function)
make[2]: *** [ieee1284_ops.o] Error 1
make[2]: Leaving directory `/usr/src/kernels/linux/drivers/parport'
make[1]: *** [_modsubdir_parport] Error 2
make[1]: Leaving directory `/usr/src/kernels/linux/drivers'
make: *** [_mod_drivers] Error 2
So if you compiled it and it worked you aren't using the module that this was in. Or your compiler is broke.:)
d
Try "make oldconfig" instead of "make menuconfig". That should work :)
mr.
As much as slashdot likes to joke about "It compiles?! Release it!" over at some commercial shops, that's pretty much exactly the attitude with Linux. A 'released' kernel is about as interesting as a Mozilla nightly.
Stick to a vendor kernel. It's at least had some basic QA tests, and smart people are following the development on the subsystem level. (I heard that RedHat ships with something like 100 patches that weren't in the Linus mainline yet. Furthmore, sometimes Linus drops patches for strange reasons.)
Yes, you can reuse the file. Just run 'make oldconfig' once the .config file is in the linux 2.4.12 source directory - it will ask you any new configuration options.
This is easy: download patch-2.4.11-dontuse.bz2 AND patch-2.4.12.bz2, rename the former to patch-2.4.11.bz2, and run the patch-kernel script. It will see that it needs to apply both patches and will then sing all the magic songs for you.
Linux user since early January 1992.
Due to the massive changes in the recent Linus kernels, they haven't gotten around to pushing out ext3 patches for them. Apparently the -ac kernels were easier to create patches for, since Alan decided not to merge a bunch of the stuff from 2.4.10-12. I think they said next week we should see patches for the Linus kernels.
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
Anytime changes are made to a kernel (or any other code for that matter) there is always the potential for new errors to be introduced. If you want a truly stable kernel then you need to wait until it's been around long enough to be proven to be stable.
The same goes for service packs for Windows. None of the Windows shops that I used to work for would ever install service packs until they had been available long enough to know the new errors they would introduce. In fact many of those companies had policies that declared you would be fired for installing any new service packs until IT had determined that they wouldn't break usability.
If you install software on a production system that was just released yesterday, you're just asking for trouble. This applies to ALL software, not just kernels.
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
Just to add to Leto2's comments: "don't upgrade a stable production system" is not limited to open source. A decent sysadmin will test any patch commercial or otherwise before rolling it out to production systems. Patching blindly is just asking for trouble.
And to all the linux bashers: this is nothing new. Most big software packages that I am aware of has had a bad patch or "fix."
Always use modular kernels. You can fix stuff without rebooting, change options, compile new features without rebooting and lilo'ing, etc. Modular kernels unload unused drivers...
Modular kernels are way cool. Every time I take a look at a Windows box having to reboot for something, I kind of mentally groan.