Hi,
What if I wanted to build a kernel RPM for FC1 that was like the existing 2.4.22 ones except for being 2.4.26? Where would I start? I see that the spec is fairly long, and includes a bunch of patches, etc. Can anyone give me a hint on a starting point? Or am I barking up the wrong tree entirely?
The reason I'm trying to do this is that with FC1 stock kernels I am getting random kernel *freezes* - not panics or even oopses - on multiple machines even when trying the usual frequently recommended "apm=off acpi=off nohlt" recommended incantations. It's my hope that some kind of bugfix has been applied somewhere along the line that would address this problem, as I can't seem to debug it.
Any ideas of any kind in this vein would be greatly appreciated at this point...
Thanks, Martin
On Fri, 2004-04-16 at 12:05 -0400, Martin Stone wrote:
The reason I'm trying to do this is that with FC1 stock kernels I am getting random kernel *freezes* - not panics or even oopses - on multiple machines even
It is likely you have a hardware fault.
Did you try booting with FC1 cd and entered memtest (IIRC)?
Hugs, Rui
Rui Miguel Seabra wrote:
On Fri, 2004-04-16 at 12:05 -0400, Martin Stone wrote:
The reason I'm trying to do this is that with FC1 stock kernels I am getting random kernel *freezes* - not panics or even oopses - on multiple machines even
It is likely you have a hardware fault.
Did you try booting with FC1 cd and entered memtest (IIRC)?
Hugs, Rui
I'd agree except that I have this problem on five different machines - I judge it very unlikely that all five have bad RAM... Additionally, the machines are all different hardware. Practically the only thing they have in common is... FC1.
On Fri, 16 Apr 2004 12:05:18 -0400 Martin Stone martin.stone@db.com wrote:
The reason I'm trying to do this is that with FC1 stock kernels I am getting
random kernel *freezes* - not panics or even oopses - on multiple machines even when trying the usual frequently recommended "apm=off acpi=off nohlt" recommended incantations. It's my hope that some kind of bugfix has been applied somewhere along the line that would address this problem, as I can't seem to debug it.
Oh good it's not just us then. What sort of boxes are they? We've begun to see this mostly on dual-xeon machines.
In terms of debugging I'd be tempted to be brutal and just compile vanilla 2.4.26 onto the machines to see if the freezes go away. Then try to rebuild the kernel RPM later. Working out what patches you don't need any more on 2.4.26 will be painful. Amending the patches you do need will be more painful. Then you will have to go through and fix all the stuff in *.config that has changed between versions. That's just annoying. It's possible but don't start the process until you are convinced that 2.4.26 fixes your problems.
On Sat, 2004-04-17 at 00:23, Huw Lynes wrote:
On Fri, 16 Apr 2004 12:05:18 -0400 Martin Stone martin.stone@db.com wrote:
The reason I'm trying to do this is that with FC1 stock kernels I am getting
random kernel *freezes* - not panics or even oopses - on multiple machines even when trying the usual frequently recommended "apm=off acpi=off nohlt" recommended incantations. It's my hope that some kind of bugfix has been applied somewhere along the line that would address this problem, as I can't seem to debug it.
Oh good it's not just us then. What sort of boxes are they? We've begun to see this mostly on dual-xeon machines.
Try setting up a serial console or netdump, and adding the kernel parameter nmi_watchdog=1 to your grub.conf. After booting, check /proc/interrupts to make sure the NMI: count is increasing (if it isn't, try nmi_watchdog=2) This isn't supported on all hardware, but if NMI is increasing, then should NMI stop increasing for 5 seconds the kernel will generate a panic. It should be possible to determine where the kernel got hung from that output.
Huw Lynes wrote:
On Fri, 16 Apr 2004 12:05:18 -0400 Martin Stone martin.stone@db.com wrote:
The reason I'm trying to do this is that with FC1 stock kernels I am getting
random kernel *freezes* - not panics or even oopses - on multiple machines even when trying the usual frequently recommended "apm=off acpi=off nohlt" recommended incantations. It's my hope that some kind of bugfix has been applied somewhere along the line that would address this problem, as I can't seem to debug it.
Oh good it's not just us then. What sort of boxes are they? We've begun to see this mostly on dual-xeon machines.
Oooooo, mine are all dual-xeons too... how frequently do you freeze? Mine seems to average about 0.5 machines per day over a pool of about 5 machines... but it's pretty random and nothing I do in terms of stressing the box seems to make a difference.
In terms of debugging I'd be tempted to be brutal and just compile vanilla 2.4.26 onto the machines to see if the freezes go away. Then try to rebuild the kernel RPM later. Working out what patches you don't need any more on 2.4.26 will be painful. Amending the patches you do need will be more painful. Then you will have to go through and fix all the stuff in *.config that has changed between versions. That's just annoying. It's possible but don't start the process until you are convinced that 2.4.26 fixes your problems.
True that. I may just do a vanilla kernel but I *really really* want NPTL.
Comforted to know that someone shares my pain...
On Friday 16 April 2004 13:23, Martin Stone wrote:
Huw Lynes wrote:
On Fri, 16 Apr 2004 12:05:18 -0400
Martin Stone martin.stone@db.com wrote:
The reason I'm trying to do this is that with FC1 stock kernels I am getting
random kernel *freezes* - not panics or even oopses - on multiple machines even when trying the usual frequently recommended "apm=off acpi=off nohlt" recommended incantations. It's my hope that some kind of bugfix has been applied somewhere along the line that would address this problem, as I can't seem to debug it.
Oh good it's not just us then. What sort of boxes are they? We've begun to see this mostly on dual-xeon machines.
Oooooo, mine are all dual-xeons too... how frequently do you freeze? Mine seems to average about 0.5 machines per day over a pool of about 5 machines... but it's pretty random and nothing I do in terms of stressing the box seems to make a difference.
In case you did not look at Dave Jone'sreply to me, the latest kernel (2179) fixes the hang problem.
On Fri, 2004-04-16 at 18:05, Martin Stone wrote:
Hi,
What if I wanted to build a kernel RPM for FC1 that was like the existing 2.4.22 ones except for being 2.4.26? Where would I start?
start by downloading the 2.4.26 kernel tarbal and change "22" to "26" in the top of the spec for the kernel version. But it'll be painful. I've been doing that kind of work for 3 years now and I estimate it'd take a week to get a decent kernel out of this.
The reason I'm trying to do this is that with FC1 stock kernels I am getting random kernel *freezes* - not panics or even oopses - on multiple machines even when trying the usual frequently recommended "apm=off acpi=off nohlt" recommended incantations. It's my hope that some kind of bugfix has been applied somewhere along the line that would address this problem, as I can't seem to debug it.
you can try the 2.6 kernel rpms if you want; they're pretty solid nowadays...
On Friday 16 April 2004 12:33, Arjan van de Ven wrote:
you can try the
I have been getting sudden system freezes on a dual athlon system with FC1 since FC1 came up. When it happens, it is painful. It usually occurs when I am trying to run the umount command (although it may also have occured for mount).
I would be willing to give the kernel a try (although my need to run vmware may cause other problems). What else is needed to run the 2.6 kernel on FC1 other than the kernel itself?
On Fri, 2004-04-16 at 17:39, Gene C. wrote:
On Friday 16 April 2004 12:33, Arjan van de Ven wrote:
you can try the
I have been getting sudden system freezes on a dual athlon system with FC1 since FC1 came up. When it happens, it is painful. It usually occurs when I am trying to run the umount command (although it may also have occured for mount).
The umount bug should be fixed in the 2179 kernel. It seemed that the low-latency patch caused that problem.
Dave
On Friday 16 April 2004 12:59, Dave Jones wrote:
On Fri, 2004-04-16 at 17:39, Gene C. wrote:
On Friday 16 April 2004 12:33, Arjan van de Ven wrote:
you can try the
I have been getting sudden system freezes on a dual athlon system with FC1 since FC1 came up. When it happens, it is painful. It usually occurs when I am trying to run the umount command (although it may also have occured for mount).
The umount bug should be fixed in the 2179 kernel. It seemed that the low-latency patch caused that problem.
That is timing. I was just about to install and switch to the updated kernel when I got my last hang (it had not occured in a couple of weeks). I am now running 2179 so I will keep an eye out to see if it happens again.
On Fri, 16 Apr 2004 17:59:23 +0100 Dave Jones davej@redhat.com wrote:
On Fri, 2004-04-16 at 17:39, Gene C. wrote:
On Friday 16 April 2004 12:33, Arjan van de Ven wrote:
you can try the
I have been getting sudden system freezes on a dual athlon system with FC1
since FC1 came up. When it happens, it is painful. It usually occurs when I am trying to run the umount command (although it may also have occured for mount).
The umount bug should be fixed in the 2179 kernel. It seemed that the low-latency patch caused that problem.
Yep 2179 seems to have fixed that.
Arjan van de Ven wrote:
On Fri, 2004-04-16 at 18:05, Martin Stone wrote:
Hi,
What if I wanted to build a kernel RPM for FC1 that was like the existing 2.4.22 ones except for being 2.4.26? Where would I start?
start by downloading the 2.4.26 kernel tarbal and change "22" to "26" in the top of the spec for the kernel version. But it'll be painful. I've been doing that kind of work for 3 years now and I estimate it'd take a week to get a decent kernel out of this.
Ouch. Certainly I've looked at the spec and entertained thoughts of changing it... But I don't have a week :-( What about compiling a vanilla kernel.org tree, perhaps with just NPTL applied? Would that have horrible horrible drawbacks?
The reason I'm trying to do this is that with FC1 stock kernels I am getting random kernel *freezes* - not panics or even oopses - on multiple machines even when trying the usual frequently recommended "apm=off acpi=off nohlt" recommended incantations. It's my hope that some kind of bugfix has been applied somewhere along the line that would address this problem, as I can't seem to debug it.
you can try the 2.6 kernel rpms if you want; they're pretty solid nowadays...
Yeah, tried them on a couple of machines, saw many more freezes than with 2.4 and then got bit by the NFS kernel oops in 2.6.4 and gave up...
On Fri, Apr 16, 2004 at 01:19:13PM -0400, Martin Stone wrote:
start by downloading the 2.4.26 kernel tarbal and change "22" to "26" in the top of the spec for the kernel version. But it'll be painful. I've been doing that kind of work for 3 years now and I estimate it'd take a week to get a decent kernel out of this.
Ouch. Certainly I've looked at the spec and entertained thoughts of changing it... But I don't have a week :-( What about compiling a vanilla kernel.org tree, perhaps with just NPTL applied? Would that have horrible horrible drawbacks?
A few weeks ago I started working on this, then got sidetracked by other tasks at work. Now that a huge fraction of AKPM's -mm tree has been merged into 2.6.6-rc1, I'm inclined to put it off for a few more weeks, and just use 2.6 instead.
IMHO, for FC1, it's O(1)-scheduler + futex + NPTL that matters most, if you want threading, job control, etc., to work properly. It is also the biggest hassle to merge. The rest of the patches in the SRPM are mostly cruft, much of it backported and "selected" patches from -ac or later 2.4 kernels. If you find that the Marcelo kernel VM is unacceptable, you might consider using Rik van Riel's latest rmap patch:
If you care about NFS issues, you might also want Trond's NFS patches:
http://www.fys.uio.no/~trondmy/src/Linux-2.4.x/
A few tools that will definitely help:
The latest version of Tim Waugh's patchutils:
http://cyberelk.net/tim/patchutils/
(FC already includes patchutils, but it's old.)
Neil Brown's wiggle:
"Wiggle is a program for applying patches that 'patch' cannot apply due to conflicting changes in the original."
http://cgi.cse.unsw.edu.au/~neilb/source/wiggle/
Andrew Morton's patch management scripts:
"This is a description of a bunch of shell scripts which I use for managing kernel patches. They are quite powerful. They can be used on projects other than the linux kernel. They are easy to use, and fast."
http://www.zip.com.au/~akpm/linux/patches/patch-scripts-0.16/patch-scripts-0...
It's also nice to have an interactive diff/merge tool. Emacs has a mode, or you can look at tkdiff,
http://sourceforge.net/projects/tkdiff/
or xxdiff,
http://sourceforge.net/projects/xxdiff/
Regards,
Bill Rugolsky
Bill Rugolsky Jr. wrote:
It's also nice to have an interactive diff/merge tool. Emacs has a mode, or you can look at tkdiff,
http://sourceforge.net/projects/tkdiff/
or xxdiff,
Meld falls into this caregory too:
Also does directory and CVS diffs.
Carwyn
On Fri, 16 Apr 2004 21:15:46 +0100 Carwyn Edwards carwyn@carwyn.com wrote:
Bill Rugolsky Jr. wrote:
It's also nice to have an interactive diff/merge tool. Emacs has a mode, or you can look at tkdiff,
http://sourceforge.net/projects/tkdiff/
or xxdiff,
Meld falls into this caregory too:
Also does directory and CVS diffs.
Available at fedora.us
Carwyn Edwards wrote:
Bill Rugolsky Jr. wrote:
It's also nice to have an interactive diff/merge tool. Emacs has a mode, or you can look at tkdiff,
http://sourceforge.net/projects/tkdiff/
or xxdiff,
Meld falls into this caregory too:
Also does directory and CVS diffs.
Another one is kdiff3
http://kdiff3.sourceforge.net/
From the web page
KDiff3 is a program that * compares or merges two or three text input files or directories, * shows the differences line by line and character by character (!), ^^^^^^^^^^^^^^^^^^^^^^^^^^^ * provides an automatic merge-facility and * an integrated editor for comfortable solving of merge-conflicts, * supports KIO on KDE (allows accessing ftp, sftp, fish, smb etc.), * ...
jpo
devel@lists.stg.fedoraproject.org