___DEPRECATED___ 2.6.14-nitro2

[b3cks]

i am switching to ext3 for my / partition and leaving reiser4, i'll report back to say if it solves my disk load problem. I really do like reiser4, but something happened in 1.0.5 that slowed it way down for me, at least for my laptop hard drive.

I checked the disk performance this morning and it's just normal. I copied small and big files, did a sync and ran Anjuta for test-compiling a project. All things ran well and normal. Maybe this is really because of a newer Reiser4(Progs) version. My last installation is about six months ago.

[HecHacker1]

yeah.. Well I just got back into my new ext3 partition with dir_index and journaling enabled, and guess what.. the disk load issues are gone! The problem really was caused by reiser4. Now with ext3 it takes only 1 second to open /etc/X11/xorg.conf instead of the 30+ for reiser4.

Everything is sooo much faster and the disk load is almost 0 instead of 100%. Hmmm, i think the reiser4 1.0.5 tools did something to cause massive latency or disk thrashing.

[fauxalliance]

Many thanks for another rippin' kernel.

Are there still issues wth vesa-tng? I have been unable to sync my LCD monitor when leaving X. According to nvnews, its not news. Trying vesa drivers now.

-fa

[Tiger683]

vesafb-tng works well in this release....

[mayday147]

Many thanks for another rippin' kernel.

Are there still issues wth vesa-tng? I have been unable to sync my LCD monitor when leaving X. According to nvnews, its not news. Trying vesa drivers now.

-fa

Are you using ATI? I had the same problem on my laptop and I had to switch to 16bpp in xorg.conf.

[tuam]

It means you shouldn't build reiser4 as module....

there is a patch for this error on namesys ftp though.....

Thanks, as builtin it's OK now.

FF,

Daniel

[satanskin]

yeah.. Well I just got back into my new ext3 partition with dir_index and journaling enabled, and guess what.. the disk load issues are gone! The problem really was caused by reiser4. Now with ext3 it takes only 1 second to open /etc/X11/xorg.conf instead of the 30+ for reiser4.

Everything is sooo much faster and the disk load is almost 0 instead of 100%. Hmmm, i think the reiser4 1.0.5 tools did something to cause massive latency or disk thrashing.

Why not just use the stable release of Reiser if you liked Reiser but R4 broke stuff? Why go back to Ext3 instead?

[bollucks]

Tuned ext3 has lower latency than reiser3. Try also noatime and changing journalling to writeback with tune2fs; this helps as well.

[HecHacker1]

yeah.. Well I just got back into my new ext3 partition with dir_index and journaling enabled, and guess what.. the disk load issues are gone! The problem really was caused by reiser4. Now with ext3 it takes only 1 second to open /etc/X11/xorg.conf instead of the 30+ for reiser4.

Everything is sooo much faster and the disk load is almost 0 instead of 100%. Hmmm, i think the reiser4 1.0.5 tools did something to cause massive latency or disk thrashing.

Why not just use the stable release of Reiser if you liked Reiser but R4 broke stuff? Why go back to Ext3 instead?

because the official portage version of reiser4 is 1.0.5 and even the livecd's I use to set up the reiser4 partitions use 1.0.5. I would have to get an old version that uses 1.0.0.

I am happy with ext3 right now, it is slower on some things like emerge sync, but it does have it's benefits. Now I can use inotify with rlocate to have real time file location, and beagle to search all my data. I think beagle works with reiser4 too, but in an emulation mode that will use more cpu and be slower.

I think i'll wait for an updated version of reiser4 before I go back, it's a simple procedure anyways.

[Tiger683]

Using recent reiser4 code with early reiser4progs would most probably break your system badly....

[Thetargos]

Just saw this a few moments ago... I don't like the looks of it, anyone seen this?

Code: Select all

nvidia: module license 'NVIDIA' taints kernel.
ACPI: PCI Interrupt 0000:01:00.0[A] -> GSI 16 (level, low) -> IRQ 217
NVRM: loading NVIDIA Linux x86_64 NVIDIA Kernel Module  1.0-7676  Fri Jul 29 13: 15:16 PDT 2005
agpgart: Found an AGP 3.0 compliant device at 0000:00:00.0.
agpgart: Putting AGP V3 device at 0000:00:00.0 into 8x mode
agpgart: Putting AGP V3 device at 0000:01:00.0 into 8x mode
Debug: sleeping function called from invalid context at include/linux/rwsem.h:66
in_atomic():1, irqs_disabled():0

Call Trace:<ffffffff8011fb7f>{change_page_attr_addr+43} <ffffffff8011efed>{iorem ap_change_attr+77}
       <ffffffff8011f64d>{iounmap+130} <ffffffff88533510>{:nvidia:os_unmap_kerne l_space+9}
       <ffffffff88335905>{:nvidia:_nv002010rm+101} <ffffffff8846bf0c>{:nvidia:_n v004040rm+102}
       <ffffffff8845ee75>{:nvidia:_nv004588rm+145} <ffffffff8845e8e1>{:nvidia:_n v004386rm+99}
       <ffffffff88338775>{:nvidia:_nv001419rm+251} <ffffffff8833ba23>{:nvidia:rm _shutdown_adapter+99}
       <ffffffff88530a3d>{:nvidia:nv_kern_close+205} <ffffffff801759fa>{__fput+1 83}
       <ffffffff80172f92>{filp_close+93} <ffffffff8017350f>{sys_close+155}
       <ffffffff8010e950>{tracesys+209}
agpgart: Found an AGP 3.0 compliant device at 0000:00:00.0.
agpgart: Putting AGP V3 device at 0000:00:00.0 into 8x mode
agpgart: Putting AGP V3 device at 0000:01:00.0 into 8x mode
Debug: sleeping function called from invalid context at include/linux/rwsem.h:66
in_atomic():1, irqs_disabled():0

Call Trace:<ffffffff8011fb7f>{change_page_attr_addr+43} <ffffffff8011efed>{iorem ap_change_attr+77}
       <ffffffff8011f64d>{iounmap+130} <ffffffff88533510>{:nvidia:os_unmap_kerne l_space+9}
       <ffffffff88335905>{:nvidia:_nv002010rm+101} <ffffffff8846bf0c>{:nvidia:_n v004040rm+102}
       <ffffffff8845ee75>{:nvidia:_nv004588rm+145} <ffffffff8845e8e1>{:nvidia:_n v004386rm+99}
       <ffffffff88338775>{:nvidia:_nv001419rm+251} <ffffffff8833ba23>{:nvidia:rm _shutdown_adapter+99}
       <ffffffff88530a3d>{:nvidia:nv_kern_close+205} <ffffffff801759fa>{__fput+1 83}
       <ffffffff80172f92>{filp_close+93} <ffffffff8017350f>{sys_close+155}
       <ffffffff8010e950>{tracesys+209}

This thing gets logged everytime the card is used... in oder words, games suffer a lot from IO activity and whatever this would mean. I'm not sure what is causing this, but seems like "sleep in spinlock" is the responsible for this. This is a reference kernel I built to test things out, anyone else noticed anything unsual? This is with nVidia's 7676 driver.

[Tiger683]

omg!!!!! my eyes!!!!!!

now seriously, if i were you i would disable kernel debugging entirely,
or at least the sleep inside spinlock checks, this bug is on nvidia side AFAIK.

[Thetargos]

I'm in the process of building another test case, without debugging options (I left them in thsi test case to see if it catched anythig, boy did it catch something!) Oddly enough with Gentoo sources (or reference Fedora kernel), this does not happen... I just hope this is not caused by setting low-lat desktop...

[ahorn]

thanks for including the voltage patch in the next releases.

anyway, this release works fine at some pcs, but one (an old p3 500mhz) got a segfault at hibernating to suspend2 (no modules are loaded). any ideas? it works fine at my laptop.

greetings, ahorn.

[tagwar]

woohoo.. just tried hibernating and resuming once again, and this time it worked... i haven't changed anything, but it works... great!!! Now i'm realy happy...

[1U]

I moved to this kernel from the previous 14-rc3-nitro1 I think it was. All my crashing has stopped. I was getting insane pdflush problems and it was impossible to use the computer for more than 20 minutes. I'm glad this one works nicely. Thanks for the suggestion Tiger. Btw, did you rename this release? Or how was it that I was posting about serious problems and this was r3-nitro1 and now they are gone?

[Tiger683]

I moved to this kernel from the previous 14-rc3-nitro1 I think it was. All my crashing has stopped. I was getting insane pdflush problems and it was impossible to use the computer for more than 20 minutes. I'm glad this one works nicely. Thanks for the suggestion Tiger. Btw, did you rename this release? Or how was it that I was posting about serious problems and this was r3-nitro1 and now they are gone?

hmm, mysterious, i didn't rename threads, to keep things more transparent i usually do not do it...

[1U]

Then perhaps I must have downloaded the wrong ebuild or I got all of the recent nitro threads mixed up. Btw, you wouldn't happen to know if there were any major tulip changes since .12 do you? Because my tulip card fails after some usage and it worked great in the .12 nitro releases.

[Tiger683]

Then perhaps I must have downloaded the wrong ebuild or I got all of the recent nitro threads mixed up. Btw, you wouldn't happen to know if there were any major tulip changes since .12 do you? Because my tulip card fails after some usage and it worked great in the .12 nitro releases.

There certainly were some, and if not in driver, then in the network device framework...
If it needs firmare loaded to work, you might try to upgrade/reemerge the firmware...

[satanskin]

yeah.. Well I just got back into my new ext3 partition with dir_index and journaling enabled, and guess what.. the disk load issues are gone! The problem really was caused by reiser4. Now with ext3 it takes only 1 second to open /etc/X11/xorg.conf instead of the 30+ for reiser4.

Everything is sooo much faster and the disk load is almost 0 instead of 100%. Hmmm, i think the reiser4 1.0.5 tools did something to cause massive latency or disk thrashing.

Why not just use the stable release of Reiser if you liked Reiser but R4 broke stuff? Why go back to Ext3 instead?

because the official portage version of reiser4 is 1.0.5 and even the livecd's I use to set up the reiser4 partitions use 1.0.5. I would have to get an old version that uses 1.0.0.

I am happy with ext3 right now, it is slower on some things like emerge sync, but it does have it's benefits. Now I can use inotify with rlocate to have real time file location, and beagle to search all my data. I think beagle works with reiser4 too, but in an emulation mode that will use more cpu and be slower.

I think i'll wait for an updated version of reiser4 before I go back, it's a simple procedure anyways.

I didn't mean an earlier version of Reiser4. I meant the stable Reiserfs. I believe it's 3.5 or 3.4 or something like that. The one that nearly every kernel supports without a patch.

[1U]

That's ReiserFS which is 3.6 btw.

[phranzee]

another problem - external usb 2.0 hdd connects as usb 1.0 no matter what i do.

i don't have this problem with other kernel

[yaneurabeya]

Don't see much of a difference between vanilla sources and nitro, but the differences may be small enough to be non-noticeable... I also upgraded my video card yesterday so it's difficult to differentiate ;p.

I'm running reiserfsprogs-3.6 and I did see some lessened disk access (more burstlike behavior) I think, which is definitely a good thing.

I also didn't enable a lot of the features in nitro though.

[Thetargos]

Bur you are using ReiserFS 3.6, don't you? Because Reiser4 requires you to have ReiserProgrs 4

[Thetargos]

Maybe the reason some people is experiencing problems with their RiserFS partitions and Nitro2 is due to a problem actually found in CK5 (reported to the CKML), regarding an issue with CFQ scheduler. Have any of you with the problem tried anticipatory I/O sched only? In the report to the ML they say:

Thomas Kuther
most impressive example was when copying a big file from one
partition to another (ext3 to reiserfs), and the copy process even
stalled. While the copy process hang there, i switched
to anticipatory, then it took a short moment, and the copy process
finished in between some seconds. uptime has been over 6 days till this
morning without any slowdowns whatsoever.