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
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
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
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.