Linux Kernel 2.2.13 Makes the Scene 103
Mads-Martin was one of the many folks to point out that 2.2.13 has made the mirrors. The patch is also up on kernel.org. You know the routine - download, compile, etc.
This discussion has been archived.
No new comments can be posted.
Linux Kernel 2.2.13 Makes the Scene
Related Links Top of the: day, week, month.
If you want to put yourself on the map, publish your own map.
I'm waiting... (Score:1)
God bless Alan Cox and Linux Torvalds. (Score:1)
Hope the nasties are gone.
More details soon, I expect (Score:3)
More info, changelogs (Score:4)
Re:God bless Alan Cox and Linux Torvalds. (Score:5)
2.2.13 croaks w/ gcc 2.95.1 (Score:1)
Re:More details soon, I expect (Score:1)
Re:2.2.13 croaks w/ gcc 2.95.1 (Score:1)
Re:2.2.13 croaks w/ gcc 2.95.1 (Score:2)
(I've had no problems with kernels up to 2.2.12, with assorted patches, so I'm going to give 2.2.13 a try with 2.95.1. :)
Depending on when/how the error occurs, you might want to make -every- non-essential option that you want into an option, where "non-essential" includes anything not absolutely needed to boot the OS. I can't promise that'll fix anything, but it might just coax the kernel into booting, by using less memory, to start with.
Bad luck? ;-) (Score:1)
One thing puzzles me though; may I assume that Linux users are by default not supersticious since kernel development now went to number 13 ? ;-)
Re:I know this is a stupid question.... (Score:1)
Re:.13 voodoo (Score:1)
Re:2.2.13 croaks w/ gcc 2.95.1 (Score:2)
From what I understand, 2.95 (not 2.95.1) has some serious bugs, which can cause some spectacular roll & burns with the kernel. I've not seen any bugs -definitely- attributable to the compiler, so far. However, I -have- seen some quirky behaviour when trying to get Linux 2.3.xx kernels working, which -may- be compiler glitches, or may simply be a result of my habit of compiling with very high optimiser flags.
Mirrors (Score:1)
Re:2.2.13 croaks w/ gcc 2.95.1 (Score:4)
A while ago somebody posted in the gcc 2.95 announcement article that all you had to do to get the kernel compiled fine with 2.95(.1) was add -fno-strict-aliasing to the CFLAGS in the Makefile - it works fine for me, I've been running 2.2.13 compiled with gcc 2.95.1 since a few hours now.
Here's the gcc 2.95 story [slashdot.org], it's comment #26.
Re:2.2.13 croaks w/ gcc 2.95.1 (Score:2)
---------------------
question: (Score:2)
When 2.2.11 there was an issue that I had mentioned here; It was as follows. If you have a fresh 2.2.11 you could apply the 2.2.12 patch right on top of it, however if you had applied any of the patches to 2.2.11 (in my case the tcp/ip fix -> they are found at www.linux.org.uk) then you had to revert the patch or start out with a clean 2.2.11 or just download the 2.2.12.
My question now is: for 2.2.12 there was a patch for a slow page leak which I just applied. This patch actually reverted part of the 2.2.12 patch. Do I now need to re apply this patch and then apply the 2.2.13 patch or can I just patch my system with the 2.2.13 patch?
My best guess: from my past experience I am going to guess to say that I must apply the reverted patch to 2.2.12 and then apply the patch to 2.2.13. Or start out with a fresh 2.2.12 and patch to 2.2.13 or just download the whole 2.2.13.
Although having a new kernel out is good news as I am sure it has fixes and new featuress, I am not sure it is necessary for me to upgrade. Also something to add here is that according to the linux kernel howto (last time I read it atleast) they suggested that upgrading the kernel is only done if you need some feature or bug fix in a newer kernel.
hmm Maybe I'll wait this time and see if there are bugs in there that will affect me. Besides 13 is not the luckest number.-> If you believe in superstition ;-0
Re:Bad luck? ;-) (Score:4)
Re:Bad luck? ;-) (Score:1)
It is known that 2.95 does not work (Score:1)
This code is intended to build with gcc 2.7.2 and egcs 1.1.2. It is known that not all of it builds validly on the x86 CPU's with gcc 2.95. As far as we know these are Linux not gcc issues. Fixes for gcc 2.95 to gcc 3.0 may go into Linux 2.2 in time. You should therefore not use gcc 2.95 to build stable kernels for the moment.
Re:God bless Alan Cox and Linux Torvalds. (Score:2)
But...
There's some of us (I'm included
So, please
Steven Rostedt
Re:It is known that 2.95 does not work (Score:2)
old news? (Score:2)
Re:.13 voodoo (Score:1)
of course, the pre-releases were for the internal qa team to check for bugs before releasing...
Re:Bad luck? ;-) (Score:1)
Well, just like you said; it depends very much on the sort of machine you're using and the parts of the kernel. 2.2.11 never failed me on my system. Anyway; perhaps I'll notice some improvement once I give 2.2.13 a try.
Re:More details soon, I expect (Score:2)
Re:Bad luck? ;-) (Score:1)
Re:old news? (Score:3)
Re:2.2.13 croaks w/ gcc 2.95.1 (Score:1)
ok, compilation with the new CFLAGS just finished and looks like it worked like a charm. YAY!
-l
Re:old news? (Score:1)
WOW!!!
Production(?) kernel built with 2.95.1.
Is it "approved" by "big guys" (I mean Alan Cox etc...) now?
Have bugs gone?
Re:.13 voodoo (Score:1)
No, no, no! In software industry, '0' is the unlucky number -- most initial (.0 implied) releases are buggy, just look at gcc 2.95(.0)!
--
bttv driver fixed? (Score:1)
I will compile now and see if this fixes my problem, and report back.
:P Was: Re:help! (Score:1)
Re:question: (Score:1)
Second I always wait a few days after a release to patch up cause I do run a few non-standard patches that aren't available right away.
Third, 13 is my lucky number.
Re:More details soon (PLEASE?) (Score:2)
Is this supposed to prevent people from addopting 2.2.13 too fast? What's the deal? I really should not have to read the development mailing list archives to find out what the latest "stable" kernel does.
That said, I can see the other side of the coin. Most of the people who should upgrade are those who have specific problems, and their vendors will direct them to the new version.... I dunno, it just seems odd. What do others think?
Re:Bad luck? ;-) (Score:3)
furthermore, there is a new -microsoftslave flag (which disables the -nerd flag) and a new -linuxnerd flag (which enables -nerd , -mustreadslashdot12timesaday and -hateMS )
---
You asked for it... (Score:1)
----
Re:2.2.13 croaks w/ gcc 2.95.1 (Score:1)
I'm using RedHat 6.0 with kernel-2.2.12 compiled with gcc-2.95.1.
The only problem I have had is when backing up my Windoze partition with
dd if=/dev/hda1 bs=32M | gzip > windoze.1999xx.gz
I have not reported, as Alan Cox said that if you are using gcc-2.95.x you are on your own
Using stock RedHat kernel 2.2.5plx it works just fine.
florin
Re:.13 voodoo (Score:1)
Re:HELLLLLLOOOO moderators! (Score:1)
SMP back up to snuff? (Score:1)
You really should upgrade (Score:5)
This is important: there was a nasty stack-smashing bug that was fixed late in the pre-releases for this kernel.
It was discovered by ben at valinux dot com, and was posted to BugTraq on Friday.
Ben writes:
While doing some debugging, I discovered a really nasty stack smash
bug in linux-2.2.12. The I haven't checked previous versions of the
2.2 kernel but bug appears to be fixed in linux-2.2.13pre17.
If I am reading this correctly, the implications of this bug could be
very dire. It may be possible to easily obtain root privilege on any
box running this kernel.
Basically the problem is that the execve system call checks that argv
is a valid pointer but it doesn't check that all of the pointers in
argv array are valid pointers. If you pass bad pointers into the
execve system call you can corrupt the processes stack before it
returns to user space. Then when the kernel hands off the process to
the elf loader code and which begins to setup the processes it can be
made to execute some malicious code in place of the program's main
function.
This is particularly scary because all of this occurs BEFORE the
program begins executing its main function and AFTER the program
returns to user space with privilege. Therefore no matter how well
audited the program may be it can be used as to gain privilege.
The thing that tipped me off to the problem was that a program that I
exec'd was getting killed with SIGSEGV in __libc_start_main before my
main function began running.
-ben
There was more discussion that followed, tho I won't summarize it here. But do upgrade
Re:HELLLLLLOOOO moderators! (Score:1)
Major Vomitting Upon Kernel Compile (Score:2)
I just used the same makefile from 2.2.12, is there some new weirdness in this kernel? Doh.
This was in i2c.c (Score:1)
Re:.13 voodoo (Score:1)
Like that guy who was going to bungee jump from an old hotel and in his calculations he forgot there wasn't a 13th floor so he got the cord a little too long....
how is that for bad luck and the number 13. seems like omitting the 13 could be bad luck too!
---
Re:.13 voodoo (Score:1)
ALG
Check your hardware if you get signal 11s! (Score:1)
well, the compilation died on me too but if you keep re-executing the commandline (make bzImage, or whatever) it'll eventually finish building.
If you have to reissue 'make bzImage' commands to finish building the kernel, you most definately have some faulty hardware, most likely bad memory. I bet that you're seeing signal 11's when compiling.
Check the The Signal 11 FAQ [bitwizard.nl] for clues on how to debug your problem.
First hint, if you're overclocking, don't!
12 times a day??? (Score:1)
Changelog? (Score:1)
Re:old news? (Score:1)
Rollover problem? (Score:1)
Or was this bug introduced later on?
Solution to this problem (Score:3)
a modification in the kernel sources should
do it (it was mentioned in a threat about 2.2.13pre18).
from Matthias Hanisch:
Try to increase the HEAP_SIZE constant to 0x3000 in
linux/arch/i386/boot/compressed/misc.c (as set in current 2.3.x kernels).
Re:IS THIS NEWS FOR NYRDS? (Score:1)
AND IMPLEMENTATION DETAILS OF OPERATING SYSTEMS.
Hmmm, if the kernel isn't an implementation detail of an operating system, what is.
True. (Score:1)
2.2.13 on Alpha won't boot (Score:2)
ChangeLog (kinda) (Score:1)
His diary [linux.org.uk] says he sent it to Linus for the official ok.
Re:More details soon (PLEASE?) (Score:1)
2.2.13pre18 released [linuxtoday.com]
Odds are that the official release will be pretty close.
Exploit for 2.2.12 (Score:3)
Re:bttv driver fixed? (Score:1)
The patch adds an extra cli() to the bttv.c code, which appears to fix a part of the driver where interrupts could be disabled and not re-enabled.
No one else using it??
Re:2.2.13 croaks w/ gcc 2.95.1 (Score:1)
Re:kppp and latest kernel (Score:1)
Re:old news? (Score:1)
Re:Rollover problem? (Score:1)
Re:help! (Score:1)
Re:.13 voodoo (Score:1)
Re:I'm waiting... (Score:2)
To be fair, 2.2.13 is intended to be a bit more than just a routine kernel release. There have been important small and not-so-small problems with all of the 2.2.* kernels so far.
2.2.13 is Alan's attempt to make a really bulletproof clean-up of the 2.2.* series so far, and to get it out as a definitive stable reference kernel, before he allows in quite a lot of exciting but more risky new stuff.
2.2.13 is intended as a kernel that distributions should go on including (at least as an option) long after 14,15,16,17 etc are all released and obsolete.
That's why it has taken a lot longer than most releases to go final, and why it is a worthy news item.
No solution to bttv lockups (Score:2)
I've had problems with bttv drivers as well. :( (Score:2)
When I moved my one of my boxen with a tv card in it from 2.2.10 to 2.2.12 (didn't have net access between the two), i lost the ability to have both sound and picture at the same time. I could get one or the other, depending on what I passed as argments when insmoding. (I use an ADS Channel Surfer). I mailed ac (as per one of the documentation files about bttv in the kernel), but never heard a response from him. *shrug* I just stayed with 2.2.10.
I believe there was some major re-writing activity going on in the kernel bttv drivers around 2.2.11, 2.2.12, so hopefully they will begin to stabilize with time.
Unfortunatly, I just fried the mb in that box 2 days ago, so I haven't been able to try 2.2.13 on it. It'll be interesting to see how it works out, pending that everything else in that box didn't get fried as well.
Here is the REAL release notes! (Score:3)
http://www.linux.org.uk/VERSION/ relnotes.2213.html [linux.org.uk]
Enjoy!
Re:Bad luck? ;-) (Score:1)
No. (Score:2)
KeepaliveThread::run: device crashed
KeepaliveThread::run: device crashed
KeepaliveThread::run: device crashed
After only 7 minutes of capturing 640x480 15fps. The biggest joke of all about this driver is that the bug was fixed by an EE student in his video4linux 2 revision and promptly rejected by Linus. At the same time the student created several new bugs which don't exist in the video4linux 1 revision. So we have 2 drivers: 1 which deadlocks at high frame rates and 1 which gives offset fields but doesn't deadlock and with the holidays coming don't expect anything to get fixed.
Re:No. (Score:1)
--
Re:Solution to this problem (Score:1)
I read the same email, but thought somehow it only applied to 2.3.x kernels.
Re:More details soon (PLEASE?) (Score:1)
I doubt that's the situation. I'd just be patient and wait for the notes to be released =) In the USA anyway, it was released quite late in the nite (from when I got the gist of it anyway...
This is a bug in kppp (Score:1)
The way kppp tested whether the kernel supports PPP, unwittingly took advantage of a security hole that was fixed in the kernel versions 2.2.13 and 2.3.x. See Bug 2164 [kde.org] on the KDE web site. Nothing serious.
According to the bug report, you can simply ignore the error message or remove the test for the ppp0 device from the kppp source code.
2.2.13 release notes (Score:1)
But I think that people reading the 2.2.13 thread
here should find out directly about the 2.2.13 new/uptedated stuff.
So here we go:
Linux 2.2.13 Release Notes [linux.org]
Platforms:Alpha (see notes), PowerPC, Sparc, X86
Introduction
Linux 2.2.13 is the latest update to the Linux kernel tree. It fixes the memory leak bug in the 2.2.11 kernel. In addition it updates various drivers
and the platform specific support. The out of the box tree supports the Alpha, PPC, Sparc and X86 platforms. MIPS is mostly merged but you
should obtain the platform specific tree. ARM and M680x0 users should get their platform specific tree.
Errata
Compilers
This code is intended to build with gcc 2.7.2 and egcs 1.1.2. It is known that not all of it builds validly on the x86 CPU's with gcc 2.95. As far
as we know these are Linux not gcc issues. Fixes for gcc 2.95 to gcc 3.0 may go into Linux 2.2 in time. You should therefore not use gcc 2.95
to build stable kernels for the moment.
Binary Compatibility
Linux 2.2.13 changes a few internal system structures. You may need to rebuild a few third party modules such as pcmcia-cs when upgrading
from older kernels to this one.
Security Notes
2.2.13 fixes numerous small security issues. Most of these were not publically known and exploited. Nevertheless anyone with untrusted local
users should upgrade. Other users are recommended to upgrade.
Architecture Updates
Alpha
i386
The APM code works around a Thinkpad BIOS error reporting bug.
The EBDA BIOS pointer is now honoured if it appears sane. This should fix problems with some large SMP boxes.
A TLB handling race on SMP boxes has been fixed.
The APIC support has been updated.
Workarounds have been added for audio bugs in the MediaGX CPU.
Workarounds have been added for an ISA DMA hang on the VIA Apollo Pro.
MIPS
PowerPC
A collection of PowerPC updates have been merged with the main tree.
Sparc
A bug in the locking of the video card drivers on SMP boxes has been fixed.
General updates and merges of Sparc fixes into the main tree.
Core Updates
A.out loader
Bugs have been fixed in the ZMAGIC loader code.
Bad PCI cards
A PCI card with faulty configuration entries for the devsel could cause a crash when the
Boot up
On some boots machines with very large numbers of processors may not successfully boot all processors. This is now fixed.
Bottom Half Locking
An SMP race in the bottom half handling has been fixed.
Buffer Leak
A buffer leak has been fixed.
Console logging
A race with klogd and the console has been fixed.
Optimisations
The ISA DMA handling in the memory allocator has been optimised.
PCI
Fixes have been made to the PCI multi-function handling.
Shared IRQ's
A shared IRQ handling bug was fixed.
Signal queue corruption
A bug in the real time signal queue handling has been fixed.
Task counting
An SMP task counting race has been fixed.
VM cache handling
A bug where mmap data might not get written back has been fixed.
Xntp
The NTP code has SMP locking fixes.
Driver Updates
BTTV TV card
ADS data update. Fixed schedule in interrupt crash. Updated tuners.
CD-ROM drivers
The CD-ROM drivers have been updated.
C-Media CM8338
A vendor supplied driver has been added.
Console
TIOCCONS tests have been updated.
Cyclades
The cyclades driver has been updated.
EEpro100
The EEpro100 card could lock up on configuration if it shared an IRQ.
EEpro100
The EEpro100 driver now supports the Ultrasparc.
IDE on SMP boxes
The IDE code has been updated to fix several hangs on SMP machines, especially when the machine has the IDE IRQ shared.
ESS Solo
The ESS solo claimed extra I/O resources.
ISDN
The ISDN layer and drivers have been updated.
MSP 3400
The MSP3400 driver for the sound decoders on some TV cards has been updated.
Multisound
The Multisound drivers have been updated.
Neomagic Audio
An audio driver for the Neomagic 256 has been added.
PCWD
The PCWD Watchdog driver has been updated.
SB1000 Cable Modem
Documentation has been updated.
Serial
The 16450/16550 driver didn't correctly reset the FIFO settings on a manually requested chip change.
Memory leaks fixed.
Sound
The core sound code has been updated to handle the ARM.
SoundPro
The documentation has been improved.
SX Serial driver
Small fixes have been made.
Synclink
The synclink driver has been updated
Trust radio card
This is now supported.
VIA 82Cxxx audio
The VIA 82Cxx audio is now supported.
File System Updates
Amiga RDSK
The Amiga partitioning code has been fixed to remove a leak.
Ctime
The ctime of a file is updated on a rename.
Ext2 flags
The ext2 attribute flags could be mishandled.
ISOfs
A small bug in the ISOfs handling has been sorted.
Procfs
The procfs allowed some files to be opened by incorrect names.
QNXfs
Memory corruption in the QNX code has been fixed.
Quota
Small quota bugs were fixed.
Miscellaneous Updates
Message formatting
A couple of message formatting errors/typos have been cured.
Poll
Some internal code tidyup has been done.
Network Updates
1 Second Delay
A bug in the traffic scheduling that could cause 1 second delays in packet transmission is fixed.
3c527
This driver now should work in a multicast environments.
3c529
A confusing message on load has been fixed.
3c59x/3c90x
The driver recognizes some of the newer cards.
64bit cleanness
The 8390, ne2k-pci and rtl8139 drivers have been updated to be 64bit clean.
Amateur radio
Several amateur radio protocol updates.
Arcnet
A crash in the arcnet driver has been fixed.
ATP Ethernet
The delay loops in this driver were faulty and have been fixed.
Davicom DM9102
A vendor provided driver has been added.
Defragment
The always defragment feature is now run time configured.
EEpro
The EEPro driver supports multiple cards now.
IPX
A bug in the IPX packet forwarding for netbios flood fill has been fixed.
Masquerade
Fixes have been made in the masquerade list and memory handling.
Networking
Assorted small fixes have been made.
NFS Logging
A collection of debugging log messages have been removed.
SiS 900 driver
The SiS900 driver had a compile bug in some situations.
SMC Ultra
An oops on module unloading has been fixed.
Thunderlan
Thunderlan now unloads if it finds no cards. It also takes module parameters.
SCSI Updates
Acard ATP870-U
This driver had problems with earlier 2.2 kernels. It should now be stable both compiled-in and as a module.
Advansys SCSI
The Advansys scsi driver has been updated.
DVD handling
The DVD handling code has been cleaned up.
EATA SCSI
The EATA SCSI driver has been updated and now supports Alpha
IBM ServeRAID
An IBM contributed driver is now included.
NCR 5380
A problem parsing command line options when the NCR5380 is compiled in has been resolved.
NCR 53c710
A driver has been added for generic NCR53c710 devices.
Qlogic FC
The Qlogic fibrechannel driver has been updated.
Qlogic ISP
Updates and bug fixes.
Scsi Generic
Documentation updated.
Symbios 1510D
The Symbios driver now supports this code.
Security Updates
Chown
Chown now clears the setuid bit.
Clone
The CLONE_PID flag is no longer available except to the kernel.
Exec
A denial of service attack in the execve() code has been fixed, as well as a potential case where a corrupt argument set could be
passed to the process being executed.
Mknod
Mknod no longer follows symbolic links.
Rate limiting error logs
The a.out and Sunrpc layers now limit their error logging rate.
Procfs
The stack pointer is not visible to other processes when it might provide useful info to an attacker.
Shared memory
The amount of shared memory allocatable is now configurable.
Signal handling
Sending non standard process exit signals is now restricted to thread groups.
TCP Sequence Guessing
A bug allowing TCP sequence guessing has been fixed.
TTY Locking
A tty locking bug that could allow denial of service attacks.
DVD Question? (Score:2)
SCSI Updates
DVD handling
The DVD handling code has been cleaned up.
Can anyone give me a quick "State of the DVD" update for Linux. Reccommend a drive??
Re:old news? (Score:1)
Are you suggesting they should not have shipped with 2.2.13pre7 and instead shipped with the buggier 2.2.12? Why? You enjoy memory leaks and crashes?
--
Re:.13 voodoo (Score:1)
Too much data!!! (Score:1)
Oct 21, 1999: We're done with 10% of 2.3.23
Oct 22, 1999: We're done with 19% of 2.3.23
Oct 23, 1999: We're done with 43% of 2.3.23
Oct 24, 1999: We're done with 69% of 2.3.23
Oct 25, 1999: We're done with 85% of 2.3.23
Oct 25, 1999: We're done with 99% of 2.3.23
Oct 26, 1999: We're done with 2.3.23
Oct 26, 1999: We released 2.3.23 and since it was still buggy, we're working on 2.3.24...
Oct 27, 1999: We're done with 11% of 2.3.24
etc, etc, etc...
OK OK OK!!! Hooray! We're getting more kernels! But do we have to see EACH AND EVERY LITTLE ONE publicised like its a whole new world every minor patch!!!! AGGGGHH!!
I'm done.
-fno-strict-aliasing (Score:1)
compiler accepted -fno-strict-aliasing, and
included it in CFLAGS if so. It has been doing
this since 2.2.11 (or earlier, I don't know when
the first kernel to do this was).
This should mean that it will be included without you having to do anything. You can tell whether it worked or not by looking at make's output, to see what it says it's passing to gcc.
#define X(x,y) x##y