Old posts from the morph-sources thread

Message

yardbird · Post by **yardbird** » Fri Dec 31, 2004 3:05 pm

feld wrote:Removed: 1900_umem_catch.patch

because it causes tons of probs. For GL games and it also doesnt allow TeamSpeak to run for me, and for others it crashes after a min or two. Its just messed up....

Thanks for the info. I removed it from -morph7, which now is out and features an update in the -ac patch. Also I slightly changed the fixes for Win4Lin, anyone interested in this should try -morph7 to confirm that everything is still ok regarding Win4Lin.

JBerro wrote: Feel free to tell me to do some testing if you want, no problem.
Provided of course I undertstand what to do.
I am living in Singapore and I spend a couple of hours every night on my system.
So you can expect a daily feedback plus some additonal time zone delay ( Singapore is 7 hours ahead of Europe right Now.

Thanks for your offer of helping out. I suspect the problem is caused by the compiler. Which version are you using? I have made a simple patch, just apply it on top of -morph7 (or also -morph6):

http://ing.unitn.it/~rbiscani/smp_x86-6 ... _fix.patch

Let me know it it changes something.

yardbird · Post by **yardbird** » Fri Dec 31, 2004 4:10 pm

For those of you out there who like to fiddle around with new and exciting stuff I've got a new year's present for you:

http://ing.unitn.it/~rbiscani/cfq-ts-04 ... rph7.patch
http://ing.unitn.it/~rbiscani/fix_nice_ionice.diff

These patches, applied in the order they are displayed, enable io priority to the cfq scheduler in 2.6.10-morph7 (link). What do these patches do? Basically they implement a mechanism similar to the "nice" levels, only aimed to IO priority instead of CPU usage priority. What does this mean? This means that when you "nice -n 19" a process, not only it gets low-priority CPU usage, but also low priority IO (please note that if the IO priority is not set explicitly it is linked to the process' nice level). This thus translates in yet higher system responsivensess with background IO intensive workloads. If you nice portage to 19, e.g., your desktop will get fair IO in addition to fair CPU disponibility. Nifty eh? It does make quite a difference for me, you are welcome to try this out

This feature will probably get into mainline sooner or later, so I will probably include it in next -morph releases. Enjoy

RealityMage · Post by **RealityMage** » Fri Dec 31, 2004 6:55 pm

When Firefox is rendering complex pages, XMMS skips. I also had this problem with nitro-sources. gentoo-dev-sources was free of this problem.

kontol · Post by **kontol** » Fri Dec 31, 2004 11:50 pm

I hope I'll get new years present patches for orinoco and hostap

....

Cheeerss..happy new year

JBerro · Post by **JBerro** » Sat Jan 01, 2005 6:35 am

I am using gcc 3.4.3 on the x86_64 system and gcc 3.3.4 on the x86 one.
I will apply the patch and let you know.
Happy New Year to all the forum folks

JBerro · Post by **JBerro** » Sat Jan 01, 2005 9:18 am

Well. well I applied the smp patch but the error is still here.
I tried also the nitro2 and now same error.
So something wrong with the 2.6.10 main line.
I will compile the official gentoo-dev-sources and let you know.
So now i have only the nitro1 to support reiser4 on amd64 smp.
BTW: I saw a lot of people having big issues with the support of Reiser4 on amd64.
I must be lucky as so far everything works fine in either x86 or x84_64, so I cross my fingers.

JBerro · Post by **JBerro** » Sat Jan 01, 2005 10:27 am

So the gentoo-dev-sources 2.6.10-r1 compiled ok on X84_64.
But I can't use them because of no reiser4 support and no cool features.

silverter · Post by **silverter** » Sat Jan 01, 2005 1:32 pm

RealityMage wrote:When Firefox is rendering complex pages, XMMS skips. I also had this problem with nitro-sources. gentoo-dev-sources was free of this problem.

Yeah I've had the same problems as cited a couple of messages in this thread and still haven't found a solution to this. The desktop ist responsive no doubt, but as soon as I start intensive background activity, rhythmbox, mplayer skips like hell and my mouse start jumping even the commandline ist difficult to use. I tried to 'renice' the background processes as well as reniing X and it helps a bit, but still not satisfied. As you said, gentoo-dev-sources do not have this problem.

regards,

RogerWilco · Post by **RogerWilco** » Sat Jan 01, 2005 1:42 pm

I

modified the lufs patch so that it'll apply cleanly to morph6. However if compiled as module it gives an unresolved symbol message (which disappear if compiled statically in-kernel). I won't include it since the project seems abandoned, but you can download the patch here:

http://ing.unitn.it/~rbiscani/lufs-0.9. ... rph6.patch

Just apply it on top of morph6. Let me know if it works. Regarding cdfs, the message on their homepage is scary

Sweet, dude, I never got around to modify the lufs patch. Compiles normally (but I don't compile it as a module)

Slow down, will you?! Barely compiled the morph5, now we have morph6 and hell, I've just noticed morph7!!

yardbird · Post by **yardbird** » Sat Jan 01, 2005 3:58 pm

RealityMage wrote:When Firefox is rendering complex pages, XMMS skips. I also had this problem with nitro-sources. gentoo-dev-sources was free of this problem.

silverter wrote:Yeah I've had the same problems as cited a couple of messages in this thread and still haven't found a solution to this. The desktop ist responsive no doubt, but as soon as I start intensive background activity, rhythmbox, mplayer skips like hell and my mouse start jumping even the commandline ist difficult to use. I tried to 'renice' the background processes as well as reniing X and it helps a bit, but still not satisfied. As you said, gentoo-dev-sources do not have this problem.

These issues are almost certainly related to the scheduler changes in the -ck patchset (upon which nitro is based too). You should try the timeslice scheduler patches I've posted some posts earlier. Also, what nice levels are you using for background tasks? I use the parameter PORTAGE_NICENESS=19 in make.conf, and I am very happy with the desktop performances while emerging stuff.

JBerro wrote:Well. well I applied the smp patch but the error is still here.
I tried also the nitro2 and now same error.
So something wrong with the 2.6.10 main line.
I will compile the official gentoo-dev-sources and let you know.
So now i have only the nitro1 to support reiser4 on amd64 smp.
BTW: I saw a lot of people having big issues with the support of Reiser4 on amd64.
I must be lucky as so far everything works fine in either x86 or x84_64, so I cross my fingers.

I've contacted the software-suspend folks, I hope they will resolve the problem soon (but I'm pretty confident - I'm almost sure the issue is triggered by some compiler strangeness: there's no x86-64 specific stuff in the problematic code).

As for reiser4: in -morph7 there is the latest patch, and most x86-64 problems have been ironed out. There are still some bugreports, but they come mainly from people using old reiser4 snapshots.

RogerWilco wrote:Sweet, dude, I never got around to modify the lufs patch. Compiles normally (but I don't compile it as a module).

Sweet. Tell me if there are problems.

RogerWilco wrote: Slow down, will you?! Barely compiled the morph5, now we have morph6 and hell, I've just noticed morph7!!

I like fast release cycles

-morph7 is going quite well, probably -morph8 will integrate the cfq patches since they can make a great difference in interactivity.

feld · Post by **feld** » Sat Jan 01, 2005 4:19 pm

argh.... the frustration!

OK....

I finally got a working gentoo dev sources 2.6.10 because I manually took out their patch and re digested their ebuild, etc, so I could use it with TeamSpeak working since they havent bothered to put r2 in portage yet. I've had this setup working fine for a few days. My first thought was about ALSA. 1.07 in Morph and Nitro has always been kinda worthless for me. Its very skippy and laggy in OpenAL applications. I wasnt sure and couldnt find the info on whether or not 1.07 was part of gentoo-dev-sources, so I adventured into keeping Alsa separate from the kernel and doing it all myself.

My results were astonishing. For the first time, Alsa 1.07 worked perfect for me. Without a hitch. (note I never did it this way for Alsa in 2.6.9 kernels so I have no previous experience with 1.07 other than morph and nitro). I thought *great*! It works this way! Now I can use morph sources and not have any problems. I was wrong.

I use your sources with the same setup after re-emerging all the goods so its prepared for your kernel and I still have a problem. OpenAL is worse than a broken record player with your sources. I am not knowledgeable enough to understand each of your patches and I dont have the time to re-emerge and re-compile my kernel a thousand times to track down the dirty patch but there is SOMETHING there that causes my OpenAL to take a dump. If you think you may have a FEW clues I would be willing to try a few times to see if we can narrow this problem down, but until then, your GREAT and EXTREMELY responsive patchset is useless to me

I hope this eventually works out.....

-Feld

*note i think its a CK patch because I used the CK sources before doing recent nitro/morph and it did the same thing.

yardbird · Post by **yardbird** » Sun Jan 02, 2005 7:08 pm

Hi folks, 2.6.10-morph8 is out.

ATTENTION I've momentarily reverted the cpu-scheduler and low-latency patches from ck-sources. The other stuff (1Gb low-mem, cmd-cdvd-drop, etc.) is still there. This is an attempt to debug the interactivity problems some people (including me) have been experiencing. With this patch the issues I noticed have disappeared, and although I dropped some of the ck stuff, the desktop is overall as responsive as before. If the reports are good I'll start adding back stuff (first the low-latency patches, then the scheduler), to see where the problem lies. So please comment!

In other news, I've merged the cfq io-priority patch, which works quite well for me. With this and PORTAGE_NICENESS=19 you should not even notice that portage is compiling in background (well, almost

). I've also added the sk98lin modified patch (since the official one has not yet been ported to 2.6.10) and re-merged the bk-acpi patch.

Jberro: I've not had an answer from the software-suspend folks regarding the x86-64 SMP bug yet, sorry

Feld: can you try this kernel and see if you still have openAL issues?

Cheers

feld · Post by **feld** » Mon Jan 03, 2005 8:07 am

I'm gettin it right now and i'm gonna test it ASAP. I hope we narrow this down...

-Feld

racoontje · Post by **racoontje** » Mon Jan 03, 2005 8:24 am

BTW, why is morph > ikke / morph > nitro?

feld · Post by **feld** » Mon Jan 03, 2005 9:04 am

^^^ what do you mean??

and YES YES YES! This release fixed my probs!

Thank you! I luv morph sources now! YAY!!!!!!!!!!!!!!

-Feld

yardbird · Post by **yardbird** » Tue Jan 04, 2005 1:32 am

A new release, 2.6.10-morph9, is out.

Most notably this adds support for the Realtime Linux Security Module. With this module it is possible to enable a group of users to start processes with high priority (i.e., "nice -n -20 command"). This is particularly useful for desktop systems and for those who work with real-time sound applications. More informations can be found here.

I've merged back Ingo Molnar's low latency patches. At this point I think that the interactivity problems are caused by the staircase scheduler. I'm thinking of ditching it permanently from -morph until these issues are ironed out.

Lastly I've updated the alsa patch to the version available in current -mm kernels. This is still alsa 1.0.7, so no support for new audio boards yet.

JBerro: I'm working with the softwaresuspend folks on the x86-64 issue. It seems that softwaresuspend support for amd64 is non-existant at the moment. Are you using it on your box?

Cheers..

yardbird · Post by **yardbird** » Tue Jan 04, 2005 1:48 am

racoontje wrote:BTW, why is morph > ikke / morph > nitro?

Well, I wouldn't say that morph is "better" or "worse" than nitro or ikke. I just roll this patch on my own, and others are welcome to use it if they feel like it.

I can tell you that morph is more similar to nitro than ikke (i.e., being based upon -ck rather than -mm). But I try to include only stuff that is quite "stable" and that is not going to cause too much trouble in case of a breakage. Also I try to test more or less extensively all the features I include. I monitor mailing lists and websites, and include in the patch the bugfixes that come out after a vanilla release. My goal is to reach a satisfying balance between features and stability, with a particular focus towards desktop usage.

Did I answer your question?

darklegion · Post by **darklegion** » Tue Jan 04, 2005 2:08 am

yardbird wrote:
I've merged back Ingo Molnar's low latency patches. At this point I think that the interactivity problems are caused by the staircase scheduler. I'm thinking of ditching it permanently from -morph until these issues are ironed out.

Good idea,all kernels that used that scheduler have had poor/audio video performance for me and tend to cause other odd problems as well.I'll also say that morph8 is quite stable and fairly good as far as audio/video performace is concerned although still not the best I have tested.I'll give morph9 a try and see if ingo's patches help at all.

Also I have seen that your patchset(along with some of the other recent patchsets) allow the ability to change the scheduler on-the-fly and on a per disk basis.From what I have read there should be an entry in /sys/block/hdx/scheduler but it is not there(or anywhere else in sysfs or proc)..the only scheduler related files I can find are in /sys/bus/hdx/queue/iosched but that seems to be just statistics.I have also tried passing "elevator=as" but the kernel always seems to force cfq.As a side note I tried the menu-config option in the vivid sources that chooses a particular scheduler at compile time...but still ended up with cfq anyway.

yardbird · Post by **yardbird** » Tue Jan 04, 2005 2:24 am

darklegion wrote:Also I have seen that your patchset(along with some of the other recent patchsets) allow the ability to change the scheduler on-the-fly and on a per disk basis.From what I have read there should be an entry in /sys/block/hdx/scheduler but it is not there(or anywhere else in sysfs or proc)..the only scheduler related files I can find are in /sys/bus/hdx/queue/iosched but that seems to be just statistics.I have also tried passing "elevator=as" but the kernel always seems to force cfq.As a side note I tried the menu-config option in the vivid sources that chooses a particular scheduler at compile time...but still ended up with cfq anyway.

The file to use is:

Code: Select all

/sys/block/hdX/queue/scheduler

For example on my system:

Code: Select all

yardbird@kurtz ~ $ cat /sys/block/hda/queue/scheduler
noop anticipatory deadline [cfq]

The syntax has changed a bit recently, you must use "elevator=anticipatory" in grub.conf instead of "elevator=as".

darklegion · Post by **darklegion** » Tue Jan 04, 2005 3:25 am

Code: Select all

ls: /sys/block/hda/queue/scheduler: No such file or directory

This was just checked with morph9 and before with morph8.
Is there an option in the kernel I need to enable?

yardbird · Post by **yardbird** » Tue Jan 04, 2005 3:04 pm

darklegion wrote:
Code: Select all
ls: /sys/block/hda/queue/scheduler: No such file or directory
This was just checked with morph9 and before with morph8.
Is there an option in the kernel I need to enable?

The only thing that comes to mind is that you must enable the support for multiple schedulers under the "Block Device" section. Maybe you could paste the relevant parts of your .config.

JBerro · Post by **JBerro** » Tue Jan 04, 2005 3:17 pm

Hi yardbird : I am not using the software suspend so no issue.
Because of some stupid keystokes I am currently re-emerging from --emptytree my 64 bit system so i must postpone the latest kernel try to to moprrow.
So far the previous one is running fast and well in the 32 bit system.

JBerro · Post by **JBerro** » Tue Jan 04, 2005 4:01 pm

Hi Yardbird : you are right

just not compiling the power management did the trick.
Now the kernel compile nicely and as i am not using power management it's ok.
But

I think i have to re-install my 64 bit Gentoo as it's a big mess in the ebuilds.
So see you soon with a fresh 64 bit system.

Cheers

gungholady · Post by **gungholady** » Tue Jan 04, 2005 9:27 pm

I don't know what the difference was. I used the same configuration for morph9 that I use for morph8. I got a warning message with morph 9 that said something about bad symbol and missing get_state with reiser4. Morph9 would not boot. It hung at the splash screen and did nothing. I went back to morph8 and booted again with no problem.

feld · Post by **feld** » Tue Jan 04, 2005 10:56 pm

i'll report in on morph9 tonight. its compiling and i'll test it for a few hours.

-Feld