2.6.8.1-nitro5 "it cleans your breath while it cleans y

[J0rus]

I too had serious slow down issues with this release...simply unraring a bin/cue made my system crawl till it was finished. I've backed down to nitro4 as its been the fastest of the 2.6.8 releases for me thusfar.
I'm planning on messing with the vm settings later tonite and will report my results.

~J0rus

[Phlogiston]

Honestly (and no offense intended), this is quite possibly the most sluggish kernel I've ever used. I can't multitask at all, and even when I'm trying to do only a single thing, it barely performs adequately, and that's after tweaking the vm and swap settings. Going back to -nitro1.

Strange, I've got the opposite effect here.

yes So do I

Thats I think the best kernel I ever used...

I'm not sure if my swap works? How can I test that?

[rzZzn]

Umm, nothing personal, but could you please use http://nopaste.php.cd/ (or any other nopaste service) for long files like that? Reasons are:
1. harder to read due to formatting
2. forums become slower with more content, saving storage capacity is also reasonable

Thanks for the .config, by the way.

oki did not know of that will try it next time.

/rZn

[zerojay]

I just thought that I would post my .config so that we can all maybe compare .configs between people who are having great and horrible performance and maybe figure out if maybe it's a particular option causing it.

http://darkstalker.newcon.org/.config

[Crisis]

Well I have been running nitro1 for awhile and it has been fine, but I'd really like to try the new nitro especially to fix the problems with cdrecord.

When I try to compile nitro5, however, it fails with this:

Code: Select all

  LD      .tmp_vmlinux1
drivers/built-in.o(.text+0xb7e4c): In function `vesafb_check_var':
: undefined reference to `fb_validate_mode'
drivers/built-in.o(.text+0xb7fdd): In function `vesafb_check_limits':
: undefined reference to `fb_validate_mode'
drivers/built-in.o(.init.text+0x7a9f): In function `vesafb_vbe_init':
: undefined reference to `fb_get_monitor_limits'
drivers/built-in.o(.init.text+0x7ad4): In function `vesafb_vbe_init':
: undefined reference to `fb_create_modedb'
drivers/built-in.o(.init.text+0x7c79): In function `vesafb_probe':
: undefined reference to `framebuffer_alloc'
drivers/built-in.o(.init.text+0x7d77): In function `vesafb_probe':
: undefined reference to `fb_alloc_cmap'
drivers/built-in.o(.init.text+0x7e15): In function `vesafb_probe':
: undefined reference to `vesa_modes'
drivers/built-in.o(.init.text+0x7e25): In function `vesafb_probe':
: undefined reference to `fb_find_mode'
drivers/built-in.o(.init.text+0x7ee6): In function `vesafb_probe':
: undefined reference to `fb_dealloc_cmap'
drivers/built-in.o(.init.text+0x7eee): In function `vesafb_probe':
: undefined reference to `framebuffer_release'
drivers/built-in.o(.init.text+0x7f05): In function `vesafb_probe':
: undefined reference to `fb_destroy_modedb'
drivers/built-in.o(.init.text+0x8084): In function `vesafb_probe':
: undefined reference to `fb_get_mode'
drivers/built-in.o(.init.text+0x81d9): In function `vesafb_probe':
: undefined reference to `register_framebuffer'
drivers/built-in.o(.init.text+0x82e3): In function `vesafb_probe':
: undefined reference to `fb_destroy_modedb'
drivers/built-in.o(.init.text+0x8575): In function `vesafb_probe':
: undefined reference to `fb_get_mode'
drivers/built-in.o(.init.text+0x85ae): In function `vesafb_probe':
: undefined reference to `framebuffer_release'
drivers/built-in.o(.data+0x3fab4): undefined reference to `soft_cursor'
make: *** [.tmp_vmlinux1] Error 1

Any ideas? I can post a config if you need it.

[d0nju4n]

I'm hearing great things about this release but unfortunately I couldnt get it to boot. It compiles just fine, however. It hangs after it attaches the sata disk (I'll post the specific error when I get home)

However, I think I may have fubar'd my .config, and I compiled this kernel while half asleep at 4am...I've never had the slightest problem with nitro before. When I get home I'll review it

Wish me luck for when I get home, lol

[discomfitor]

My config if you wanna try checking it. Perhaps I missed something?

[miseiler]

Honestly (and no offense intended), this is quite possibly the most sluggish kernel I've ever used. I can't multitask at all, and even when I'm trying to do only a single thing, it barely performs adequately, and that's after tweaking the vm and swap settings. Going back to -nitro1.

Sounds like you have the same swap issue some of the others do.

Works WONDERFUL here on my new reiser4 system, no memory problems, very fast, etc. Nitro2 was incredibly unstable with my reiser4 system (2.5 minutes before lockup, max), however this kernel seems to have fixed all my problems AND is faster.

Thank you!

[luqas]

Well I have been running nitro1 for awhile and it has been fine, but I'd really like to try the new nitro especially to fix the problems with cdrecord.

When I try to compile nitro5, however, it fails with this:

Code: Select all

  LD      .tmp_vmlinux1
drivers/built-in.o(.text+0xb7e4c): In function `vesafb_check_var':
: undefined reference to `fb_validate_mode'
drivers/built-in.o(.text+0xb7fdd): In function `vesafb_check_limits':
: undefined reference to `fb_validate_mode'
drivers/built-in.o(.init.text+0x7a9f): In function `vesafb_vbe_init':
: undefined reference to `fb_get_monitor_limits'
drivers/built-in.o(.init.text+0x7ad4): In function `vesafb_vbe_init':
: undefined reference to `fb_create_modedb'
drivers/built-in.o(.init.text+0x7c79): In function `vesafb_probe':
: undefined reference to `framebuffer_alloc'
drivers/built-in.o(.init.text+0x7d77): In function `vesafb_probe':
: undefined reference to `fb_alloc_cmap'
drivers/built-in.o(.init.text+0x7e15): In function `vesafb_probe':
: undefined reference to `vesa_modes'
drivers/built-in.o(.init.text+0x7e25): In function `vesafb_probe':
: undefined reference to `fb_find_mode'
drivers/built-in.o(.init.text+0x7ee6): In function `vesafb_probe':
: undefined reference to `fb_dealloc_cmap'
drivers/built-in.o(.init.text+0x7eee): In function `vesafb_probe':
: undefined reference to `framebuffer_release'
drivers/built-in.o(.init.text+0x7f05): In function `vesafb_probe':
: undefined reference to `fb_destroy_modedb'
drivers/built-in.o(.init.text+0x8084): In function `vesafb_probe':
: undefined reference to `fb_get_mode'
drivers/built-in.o(.init.text+0x81d9): In function `vesafb_probe':
: undefined reference to `register_framebuffer'
drivers/built-in.o(.init.text+0x82e3): In function `vesafb_probe':
: undefined reference to `fb_destroy_modedb'
drivers/built-in.o(.init.text+0x8575): In function `vesafb_probe':
: undefined reference to `fb_get_mode'
drivers/built-in.o(.init.text+0x85ae): In function `vesafb_probe':
: undefined reference to `framebuffer_release'
drivers/built-in.o(.data+0x3fab4): undefined reference to `soft_cursor'
make: *** [.tmp_vmlinux1] Error 1

Any ideas? I can post a config if you need it.

Try this patch (just apply it on top of your nitro source):

nitro5-vesafb-fix

[zerojay]

Actually, I am having one major problem. Running emerge whatsoever hard locks my box completely. It doesn't matter if it's even an privilaged user or not.

[TierMann]

BUT! Nvidia-driver is broken with this release, and the last release too. When I do a startx I get only a black screen. On the last release I even tried patching it with the Nvidia-diff patch.

You need to have the riva module disabled because it conflicts with NVidia's 3D driver.

You probably allready did this though, but it's just a thought.

I'm using 6111 here with no problems for my Geforce 5200 Ultra, using both heads.

[d0nju4n]

OK, I've resolved the issue with my kernel config, and all is working now.

All I can is wow. For my hardware, this is the fastest kernel that I've ever compiled...and it's stable. Awesome job.

Keep 'em commin seppe

[tomm1111]

Nice kernel. Very fast. Does this kernel have the write barriers patch? If so, amend fstab to barriers=flush?? Please advise.

[Vlad]

I too am experiencing swap craziness (but reiser4/nvidia worked fine, needed to use the pci=routeirq kernel flaq, however).

For some reason, it insists on using 120MB of swap (with only 20mb cached and 0(!) in buffers). This is making alt-tabbing damn near unbearable, even switching sessions in Konsole lags the machine up.

Perhaps all of us having strange swap behavious have something in common? I have 1 GB of physical memory and 256MB of swap. What does everyone else have?

[HecHacker1]

thanks for the replys, I haven't tried to pass the pci=routeirq yet, i'll will have to try that, although I haven't needed it before.

btw, yes, i have the riva stuff disabled. I always copy over my .config and then go through the whole config on every kernel make.

4k stacks worked ok for me before I converted to Reiser4, but now that I have my whole system running reiser4 if I have 4k stacks I will get lots of Oops and kernel panics during program compiling and usage, although the Kernel will compile just fine.

[miseiler]

thanks for the replys, I haven't tried to pass the pci=routeirq yet, i'll will have to try that, although I haven't needed it before.

btw, yes, i have the riva stuff disabled. I always copy over my .config and then go through the whole config on every kernel make.

4k stacks worked ok for me before I converted to Reiser4, but now that I have my whole system running reiser4 if I have 4k stacks I will get lots of Oops and kernel panics during program compiling and usage, although the Kernel will compile just fine.

4k stacks + reiser4 = bad...it shouldn't have even let you compile that

[HecHacker1]

i tried adding pci=routepci to the kernel using grub (i assume you just put it in the kernel line with a space between the last command?)

but when I try to startx with Nvidia it still just goes to a black screen.

I tried:

emerge nvidia-kernel
emerge nvidia-glx
emerge opengl-update (incase their was a new one)

and opengl-update nvidia.

I also made sure that my xorg.conf was okay.

I checked out /var/log/Xorg.0.log but it just stops at not being able to load some fonts or someting like that, which happens everytime because i have some font folders in the .conf that aren't there.

Any ideas?

Abit NF7-S
Ti4600

[y0zza]

Thanks again for this kernel patchset.

Working nicely, although I can't say I noticed any change in responsiveness over the previous nitro patchsets. Much more responsive than vanilla and gentoo-dev-sources though.

Haven't noticed the swapping problem that some people have mentioned.

Code: Select all

blah / # free -m
             total       used       free     shared    buffers     cached
Mem:          1518        566        952          0         13        146
-/+ buffers/cache:        406       1112
Swap:         1265          0       1265

blah / # swapon -s
Filename                                Type            Size    Used    Priority
/dev/hde1                               partition       545792  0       3
/dev/hdi1                               partition       750416  0       3

I've got 1.2GB of swap and 1.5GB RAM. The system remains quite responsive even with compiling going on in the background. Kernel config file HERE if it helps anyone.

[miseiler]

Apparently I spoke too soon.

After several hours and lots of tasks an emerge sync finally dredged up the aforementioned swap bug. Really a disappointment, as this kernel was startlingly fast.

Back to trying to find a fast kernel that doesn't break my reiser4 system, I guess...should I go to nitro1 as others have done or try 3 or the mm-sources-based 4?

Nitro2 was incredibly unstable on my system after I moved to reiser4.

EDIT - Nitro1 is even less stable than nitro2 was.

[neonik]

Umm... Interesting... I've got 1GB physical RAM and 494MB swap. Swap less than RAM. May be the cause.

[miseiler]

Umm... Interesting... I've got 1GB physical RAM and 494MB swap. Swap less than RAM. May be the cause.

512MB RAM 512MB SWAP

[neonik]

So... Who's got the same issues as me, try these two patches in the given order:

Code: Select all

--- linux-2.6.8.1-ck4.orig/kernel/sched.c	2004-08-24 11:58:43.000000000 +1000
+++ linux-2.6.8.1-ck4/kernel/sched.c	2004-08-24 12:32:24.000000000 +1000
@@ -352,9 +352,10 @@ static void recalc_task_prio(task_t *p, 
 {
 	unsigned long sleep_time = now - p->timestamp;
 	unsigned int rr = rr_interval(p);
+	unsigned int minrun = rr * (p->burst + 1) / (burst(p) + 1) ? : 1;
 	if (p->flags & PF_FORKED || 
-		(NS_TO_JIFFIES(p->runtime + sleep_time) < rr / 2 || 
-		((!sched_interactive || sched_compute || rr < 3 ) && 
+		(NS_TO_JIFFIES(p->runtime + sleep_time) < minrun || 
+		((!sched_interactive || sched_compute) && 
 		NS_TO_JIFFIES(p->runtime + sleep_time) < rr))) {
 			unsigned long ns_totalrun = p->totalrun + p->runtime;
 			unsigned long total_run = NS_TO_JIFFIES(ns_totalrun);
@@ -366,8 +367,10 @@ static void recalc_task_prio(task_t *p, 
 				unsigned int intervals = total_run / rr;
 				p->totalrun = ns_totalrun;
 				p->slice -= intervals * rr;
-				if (p->slice <= rr)
+				if (p->slice <= rr) {
 					p->totalrun = 0;
+					dec_burst(p);
+				}
 			}
 	} else {
 		if (!(p->flags & PF_UISLEEP))

And this one over:

Code: Select all

--- linux-2.6.8.1-ck.orig/kernel/sched.c	2004-08-24 23:22:39.164068579 +1000
+++ linux-2.6.8.1-ck/kernel/sched.c	2004-08-24 23:23:58.816671055 +1000
@@ -353,7 +353,7 @@ static void recalc_task_prio(task_t *p, 
 	unsigned long sleep_time = now - p->timestamp;
 	unsigned int rr = rr_interval(p);
 	unsigned int minrun = rr * (p->burst + 1) / (burst(p) + 1) ? : 1;
-	if (p->flags & PF_FORKED || 
+	if (p->flags & (PF_FORKED | PF_UISLEEP) || 
 		(NS_TO_JIFFIES(p->runtime + sleep_time) < minrun || 
 		((!sched_interactive || sched_compute) && 
 		NS_TO_JIFFIES(p->runtime + sleep_time) < rr))) {
@@ -373,8 +373,7 @@ static void recalc_task_prio(task_t *p, 
 				}
 			}
 	} else {
-		if (!(p->flags & PF_UISLEEP))
-			inc_burst(p);
+		inc_burst(p);
 		p->runtime = 0;
 		p->totalrun = 0;
 	}

Feel free to try with and without the second patch.
These patches didn't solve the issue, but it's still unclear what causes the slowdown. Eventually APIC or ACPI. See ck-maillist and please see further messages in the thread.

[sibov]

Hello and thanx for the nice kernel patchset seppe,

but only one thing is making my mad:

It is not reproduceabel but from time to time when i switch from X11 (xorg)
to the gensplash console my console get's grizzeld up and system will be
completly freezed up. I can connect via ssh from a nother machine but
i cannot reboot or shutdown only hardreset solves the problem.

Anybody has a idea to fix it?

I use vesafb-tng 1024x768@60 and no riva-module in kernel is enabled
nvidia-kernel is 6111 and all other stuff is working very fine.

Sorry for my bad English and Thanx for any hint.

[Vide]

Very fast kernel, indeed! Launch responsivness is something amazing!

But I have 2 serious (well, one really serious) problems that prevent me from using it:

I'm an ATI 9200 owner, and I found 2 issues with it:

1) can't get framebuffer and hi-res consolle to work, even if (I suppose) I have enabled all correct options. With gentoo-dev-sources instead it works smoothly

2) Serious OpenGL problems: fglrxgears it's rapid as before but it creates serious flickering and image corruption on the screen while running. And the games (I tested with Neverwinter Nights) are definitely slower. Well, not unplayable, but slower. I mean, 85% of what I get with my current 2.6.5-gentoo.

Any idea?

[Crisis]

Try this patch (just apply it on top of your nitro source):

nitro5-vesafb-fix

Thanks! I was able to get the kernel to compile after applying that patch. I just booted to the new kernel (remotely) and ther system came back up, so when I get home we shall see how it is performing and if the cdrecord issues are fixed.