LinuxQuestions.org - Lockup with new Kernel on 12.1

- Slackware (https://www.linuxquestions.org/questions/slackware-14/)

- - Lockup with new Kernel on 12.1 (https://www.linuxquestions.org/questions/slackware-14/lockup-with-new-kernel-on-12-1-a-704560/)

Lockup with new Kernel on 12.1

Hello all,
I ran 12.1 on my desktop for some time. It was a learning experience and for the most part a good one. Now I've bought myself a laptop, a Lenovo 3000 N500 4233 (there are actually more numbers, but that's probably enough for now) and went back to 12.1.

I started by moving to the generic kernel. Worked fine. But then I tried compiling my own kernel -- based on the stock 2.6.24.5 but with some modifications -- and that's when the trouble started. Basically, it works normally for some period of time but then suddenly slows to a crawl and ultimately freezes.

My question isn't so much what is wrong with my kernel (or hardware?) but where do I start trying to track down the problem. I'm back with generic now, but I would like to hear what others do in such situations.

-B

Howdy,

Anytime I compile a kernel and things lock up or just don't go right I start from the beginning.

I boot a stock kernel and scroll back through the boot messages taking note of all hardware detected. Especially SATA controllers, USB (UHCI, OHCI, EHCI, etc...) and everything else I can grab. Then go through the kernel config hitting every section and making sure the list matches. After that I go for features like audio, usb devices and power management.

After I get the kernel configured correctly I make a backup of the .config file so I don't have to go through that again.

Hopefully someone else has a more focused method of tracking down the problem. :-)

Good luck!

-Adam

Go slowly when customiting your kernel compile options. Turn on or off just a couple of things at a time and write down the changes so you can keep track of them.
A couple of months ago, someone was on the subject of streamlining kernel configuration and posted a script which would do some of the work for you. I do't find it right now, but I did find this one which I saw around that time, so I'll include it here. If you run this while running from a generic kernel, it should produce a kernel config which will build all the stuff loaded as modules as hardcompiled features. You'll probably still need/want to tweak it some more.

Code:

#!/usr/bin/perl -w

#

# Copywrite 2005-2008 - Steven Rostedt

# Copyright 2008 Phil Endecott

# Licensed under the terms of the GNU GPL License version 2

#

# This script modifies your .config so that modules that are currently

# in use (i.e. as indicated in the output of lsmod) will be built in.

# Modules that are not in use will still be built as modules.

#

# This is based on streamline_config.pl by Steven Rostedt, which

# modifies your .config to not build unused modules at all.  The changes

# from Steven's code are indicated below.



my $config = ".config";

my $linuxpath = ".";



open(CIN,$config) || die "Can't open current config file: $config";

my @makefiles = `find $linuxpath -name Makefile`;



my %objects;

my $var;

my $cont = 0;



foreach my $makefile (@makefiles) {

        chomp $makefile;



        open(MIN,$makefile) || die "Can't open $makefile";

        while (<MIN>) {

                my $catch = 0;



                if ($cont && /(\S.*)$/) {

                        $objs = $1;

                        $catch = 1;

                }

                $cont = 0;



                if (/obj-\$\((CONFIG_[^)]*)\)\s*[+:]?=\s*(.*)/) {

                        $var = $1;

                        $objs = $2;

                        $catch = 1;

                }

                if ($catch) {

                        if ($objs =~ m,(.*)\\$,) {

                                $objs = $1;

                                $cont = 1;

                        }



                        foreach my $obj (split /\s+/,$objs) {

                                $obj =~ s/-/_/g;

                                if ($obj =~ /(.*)\.o$/) {

                                        $objects{$1} = $var;

                                }

                        }

                }

        }

        close(MIN);

}



my %modules;



open(LIN,"/sbin/lsmod|") || die "Cant lsmod";

while (<LIN>) {

        next if (/^Module/);  # Skip the first line.

        if (/^(\S+)/) {

                $modules{$1} = 1;

        }

}

close (LIN);



my %configs;

foreach my $module (keys(%modules)) {

        if (defined($objects{$module})) {

                $configs{$objects{$module}} = $module;

        } else {

                print STDERR "$module config not found!!\n";

        }

}



while(<CIN>) {

        if (/^(CONFIG.*)=m/) {

                if (defined($configs{$1})) {

                        # print; (streamline_config)

                        print "$1=y\n";

                } else {

                        # print "# $1 is not set\n"; (streamline_config)

                        print;

                }

        } else {

                print;

        }

}

close(CIN);

OK thanks for the tips guys. I'll look into doing things more slowly and methodically than simply mass purging. And I'll give some of those scripts a try.

Another question -- could my kernel recompile be behind the fact that even now that I'm back with generic, Klaptop doesn't throttle my cpu automatically anymore? It used to bump it down per my settings whenever I unplugged and put it back to full when I plugged in again. (Or maybe time for a new thread?)

If you did the compilation on the original 2.6.24.5 tree it must have written over the original files (in /lib/modules, say) therefore you may have broken something. In that case you may try reinstalling the original kernel packages to restore the things. If you want to modify 2.6.24.5 without interfering with the original, try using the "General setup ---> Local version - append to kernel release" option so that your version has a different name (like 2.6.24.5-custom).

Quote:

Originally Posted by Ilgar (Post 3444247)

I tried to be careful about that by putting a -custom on the end. But besides /lib/modules, does installing a newly compiled kernel clobber anything else? I actually reinstalled kernel-modules-2.6.24.5-smp just to be sure but I have this sinking feeling that I might have misstepped somewhere along the line ... Sağol!

Quote:

Originally Posted by brixtoncalling (Post 3444474)

But besides /lib/modules, does installing a newly compiled kernel clobber anything else?

It shouldn't. If you put the -custom then your new modules should be under /lib/modules/2.6.24.5-custom and not interfere with the stock kernel modules. This means the source of the Klaptop problem must be something else (but I have no idea what...).

Does anyone have any experience of the Tickless System (dynamic ticks) option causing lockups? By trial and error it seems that it might be the culprit.

It's working fine here. But then, I'm using 2.6.28. In the short time that I used the stock 2.6.24.5 I didn't have any issues (is dynamic ticks enabled in the stock kernel?).

As far as I remember these dynamic ticks were introduced around 2.6.23 (give or take 1), so I'd say 2.6.24 is one of the early kernels supporting it. If you're compiling a custom kernel you may have better luck if you use the latest ones. Maybe there was a bug and it's fixed now.

It is not compiled in the stock 2.6.24.5 but when I made my own kernel I had lockups. I can't say for certain that it was dynamic ticks causing the problem, but since I removed them things appear to be fine.

I'm on a slow dial up right now so I haven't downloaded later kernel sources but I'll be on the road where the 'net is fast in a week so I'm going to grab some new stuff then.

Yes we had several reports of lockups with the tickless kernel a while back.

Quote:

Originally Posted by mRgOBLIN (Post 3474743)

Yes we had several reports of lockups with the tickless kernel a while back.

... You say "a while back", so should we understand that the newer kernels solve this problem? PV was wise not to enable it in the stock kernel, as it had been just recently introduced; but I believe the bugs should've been sorted out by now.

From memory there were issues with (some?) AMD cpus but it seemed to run fine on Intel chips. And no, as far as I'm aware no more experiments have been done with the newer kernels but it's certainly worth looking into.

I'll see if we can't get it added to the list of new options to try for the next kernel build.