xx-sources

eldiablo · Posted: Mon Aug 02, 2004 12:42 pm Post subject:

I'm dooing a fresh checkout now, it will take some time since I'm just on a 700 kbit line.
I'm using gcc 3.4.0
EDIT: No, i'm still getting the same errors, weird, also getting same error with gcc 3.3.4

EDIT2: How does your arch/i386/kernel/signal.c:589 look like?
mine looks like this

AstralStorm · Posted: Mon Aug 02, 2004 2:08 pm Post subject:

AstralStorm · Posted: Mon Aug 02, 2004 2:32 pm Post subject:

Ehh, logged out, back in and couldn't edit my post.

No matter, just to say that everything except I2C works in this release.

I get some messages like this, looks like some debugging option, although I have everything disabled:
ReiserFS: hda2: checking transaction log (hda2)
bad: scheduling while atomic!
... long trace ...
bad: scheduling while atomic!
... different long trace ...
ReiserFS: hda2: Using r5 hash to sort names

I get them when writing large files too.

In addition to these I sometimes get:
Took swap token, pid <number> (app name)

eldiablo · Posted: Mon Aug 02, 2004 6:49 pm Post subject:

I did a new checkout for a couple of minnutes ago, and it updated very much, and it all compiled cleanly

_________________
Always running the most experimental

xiphux · Posted: Mon Aug 02, 2004 8:45 pm Post subject:

Astralstorm:
In those "scheduling while atomic" traces, is there anything human-readable?

The "swap token" messages are not an issue. I forgot to mention that I added token-based thrashing control, by Rik van Riel.

Evil Dark Archon · Posted: Mon Aug 02, 2004 11:14 pm Post subject:

the scheduling while atomic thing can be traced to the cfq io scheduler because when i switched to the anticipatory io scheduler the scheduling while atomic errors went away, plus the traces specificaly mentioned cfq so that's what gave me the idea to switch to anticipatory.
_________________
This post has been over explained for newb-informing purposes.

Registered Linux user 347334
Abit AV8-3rd eye, AMD Athlon64 3500+ 90nm, ATI Radeon x850 pro

xiphux · Posted: Tue Aug 03, 2004 12:12 am Post subject:

Well, that would do it. There were some more fixes to cfq, and it's probably conflicting with something in the cfqionice conditionals I added. I'll take a look at it.

Actually, at some point I want to remerge the normal / ionice cfq. Since it was added to mainline, more and more of the extra enhancements and cleanups that were in cfqionice are working their way into the vanilla cfq. (Sysfs exports, etc) But I didn't really change the conditionals I had already - so aside from major bugfixes, it's still a dated version of cfq that's in this tree.

AstralStorm · Posted: Tue Aug 03, 2004 8:27 am Post subject:

eldiablo · Posted: Tue Aug 03, 2004 6:35 pm Post subject:

Is mm2 included in cvs?
I don't see anything mentioned.

_________________
Always running the most experimental

xiphux · Posted: Tue Aug 03, 2004 9:31 pm Post subject:

I'm doing the initial import now, and then I need to fix the conflicts.

(Doom 3 has been mighty distracting lately...)

trevorj · n00b Joined: 13 May 2003 Posts: 68

the cpu.c and suspend2.c problem still exists in CVS

hmm. Current cvs won't compile for me...

xiphux · Posted: Thu Aug 05, 2004 4:33 am Post subject:

Whoops. That was the time I was fighting with CVS, and I kinda forgot to fix it when I did get the repository back in sync.

I'm looking at it and I'm about to commit the fix. But can't it just be set static in cpu.c, and then defined as an extern in suspend2.c?

I'll fix that sysfs thing next.

xiphux · Posted: Thu Aug 05, 2004 8:24 am Post subject:

Ok, CVS has really been pissing me off lately. When I first started using it, I stopped using Andrew Morton's patch scripts, thinking I could just rely on CVS for my incremental diffs. However, this was a problem - while the system works great for a constantly evolving single codebase, the kernel is different because the bottom structure is constantly changing. So each time a new base revision is added, all the other patches have to be adapted to any changes. Sometimes this is relatively hassle-free... and sometimes it isn't. I can see now why akpm himself uses those scripts, and not an RCS like CVS. If the bottom changes, you can start from there, apply each patch down the stack, and fix any conflicts you come across. And when you deal with a patchset with hundreds of patches like -mm (or -xx, for that matter), doing it incrementally is much easier than dealing with a giant mass of conflicts.

If you've checked out CVS recently, you'll probably notice that there are some serious issues. In fact, the tree sitting in CVS is no longer 2.6.8-rc2-mm1 nor 2.6.8-rc2-mm2; it's some abominable hybrid that will be a real pain to fix.
So I'm starting from scratch. I'm going to start again with akpm's patch scripts, like I used to. I'll still commit changes into CVS, but I'll do the work in a non-cvs-controlled tree.
I have to break out everything in CVS into individual patches again (that oughta be a real bitch). However, the upside to this is that I can start from scratch on a lot of the spots that are a real mess. For example, I can re-do the scheduer mix. Maybe even write some generic functions to decrease the amount of ifdefs. But anyway, now that that's out, here is the real purpose of this post:
Since I'm starting from scratch, which schedulers should I include? Nicksched, Xsched, and Staircase, I assume, are a given. I could include the runtime selectable version of SPA with priority-based, staircase, and entitlement based options. Or I could break those out into separate ones. I never really included the runtime selectable ones before because it didn't make sense to me to have half of the schedulers compile-selected and half of them runtime-selectable. I really want to include EBS since its algorithms are much more advanced than the ones in the entitlement-based SPA, but since it hasn't been updated since 2.6.4, enough stuff has changed that it would be much too problematic. Actually, I don't even know if EBS in cvs works. But if someone really wants it, I can attempt to port it to the current tree.

But I guess that really applies to anything. Since I have to start from the beginning, it'll be relatively easy to make big infrastructural changes. Want something added? Changed, adjusted, reverted, inverted, perverted, whatever? Go ahead and make a request. Otherwise, I'll just try to emulate the current tree as much as possible.

And hey, at least I'll be able to provide broken-out patches again. At the cheap price of my fingers.

eldiablo · Posted: Thu Aug 05, 2004 8:35 am Post subject:

I'm just using Staircase, so i'm happy with only Nicksched, Xsched and Staircase in.

I'ts also good that you'll be able to make a broken-out dir, i'm a bit into this kernel patching thing myself

_________________
Always running the most experimental

Evil Dark Archon · Posted: Thu Aug 05, 2004 6:52 pm Post subject:

i only use nicksched (staircase produces some nasty sound problems in unreal tournament 2004), but the entitlement based scheduler looks interesting, a port to the current tree would be nice.

* EDIT: Oh btw, your problems with CVS are probably the reason that the linux kernel folks went over to BitKeeper.
_________________
This post has been over explained for newb-informing purposes.

Registered Linux user 347334
Abit AV8-3rd eye, AMD Athlon64 3500+ 90nm, ATI Radeon x850 pro

madmango · Guru Joined: 15 Jul 2003 Posts: 507 Location: PA, USA

You guys and you're slow internet... I've got a 3.5 Mbit cable line. mmmmmm.

Okay, I just checked out the current cvs. You might want to switch to something like bitkeeper or subversion or something.

I'm compiling now, so far so good. I've found that most of the problems I was having earlier with the kernel were attributed to cfq, ionice, reiser4, and, most importantly, the fglrx drivers. I just switched over to a geforce 4 ti 4600 and i'm lovin' it (mcdonalds). Also went from my nforce audio to a sb live card. We'll see how things go.

Thanks, xiphux. You're really doing the linux community a service here.
_________________
word.

eldiablo · Posted: Fri Aug 06, 2004 4:15 pm Post subject:

Couldnt agree more with you madmango

_________________
Always running the most experimental

yngwin · Posted: Fri Aug 06, 2004 4:51 pm Post subject:

madmango · Guru Joined: 15 Jul 2003 Posts: 507 Location: PA, USA

Entitlement based scheduling won't compile, Xsched crashes init with no errors (when entering 3rd runlevel), vesafb-tng is borked (worked before, now just freezes with no errors right after the acpi table).

Does this mean anything to you? I get this when I boot with staircase and xsched.

xiphux · Posted: Fri Aug 06, 2004 9:06 pm Post subject:

I wish I could switch to anything else, but the issue is the hosting space for the patches. Sourceforge gave me the space and offers cvs, so I have to use cvs.

I'm on slow internet at home now. When I go back to school in a month, I'll have a fiber connection with 1 megabyte/sec bandwidth. (It was really awkward coming back in the summer and readjusting to my "slow" cable internet.)

I can probably add gensplash as another option to the stable/experimental bootsplash option. (When I get there)

I'm sure there's all sorts of stuff broken in cvs. madmango, those errors are either from voluntary-preempt or something messed up in the scheduler conditionals.

[edit]
I'm working on the schedulers in the cleaned up version. I've set up some generic functions which should simplify things some. I'm going to add nicksched, staircase, and xsched to start, but spa will come a little later. Peter Williams admitted that he got carried away and made a lot of changes which are mostly overhead bulk. (I was wondering what the point of a lot of that crap was when I looked at the new spa-pb) He says he'll slim it down and release a new one next week, so I'll wait until then. I'll probably add spa-zaphod (runtime selectable between entitlement-based and priority-based). This entitlement-based is different from the actual EBS in that it still uses the same interactivity/throughput bonus system that the priority-based system does. So I can see the merit in merging that one.
Speaking of EBS, that will take some time for me to peruse and port over. I figure I'll get the cleanup overwith, and then tack on EBS later, whenever I get it working.
Sound good?
[/edit]

madmango · Guru Joined: 15 Jul 2003 Posts: 507 Location: PA, USA

ss-coo'
_________________
word.

eldiablo · Posted: Sun Aug 08, 2004 5:07 pm Post subject:

Those patch-scripts are just genious, it makes debugging and managing patches soo easy =)

Is version 0.18 the newest?

EDIT: Oh, it looks like they are named quilt now.
http://savannah.nongnu.org/projects/quilt
_________________
Always running the most experimental

eldiablo · Posted: Sun Aug 08, 2004 8:14 pm Post subject:

Is there long before you got a release(even if it is a small one)? :wink:

It's so long since i updated my kernel, the one i'm running now is breaking quite often :\
_________________
Always running the most experimental

fallow · Posted: Sun Aug 08, 2004 9:06 pm Post subject:

I like to see included zapchod

I don`t test it yet,but extended eb than in hydra sounds good.
Maybe also Hydra. I know that is much more , but will be great

I think also spa_sc is good alternative for people wants little less than staircase and little more than spa only.I`m using it often.

greetings

_________________
"Time is a companion that goes with us on a journey. It reminds us to cherish each moment, because it will never come again. What we leave behind is not as important as how we have lived" J-L. Picard

xiphux · Posted: Mon Aug 09, 2004 3:08 am Post subject:

I just use the version that akpm has in his kernel.org space. It does what I want, so whatever.

I don't think I'm going to be making an actual release soon, especially with all the cleaning and reworking I'm doing. But I plan to commit an almost-complete version of the redone tree to CVS soon.

Spa-staircase isn't really less than staircase. It's just spa with staircase's bonus calculations. Kind of like xsched, which is spa with Nicksched's bonus calculations. For xsched it's more of a change since we're going from a dual-array scheduler to a single-array scheduler; but for spa-sc, all it really does is change the base tasklist structures. One has prio slots which means better load handling but more memory overhead, and the other is the opposite (no prio-slots, less memory, weaker load handling) And none of that is really noticable from an end-user standpoint.

Plus, I think it would be weird to have two staircases - one compile-configured and one runtime selectable...