[08:09] <joris_> I have a rather odd feisty problem. Machine with a core2quad cpu with a 2.6.20-16-generic kernel works very fast, altough with only 3.2 out of 8GB of ram. Installing the 2.6.20-16-server kernel halves disk IO speed (measurably) and subjectively decimates CPU performance... I'm at a complete loss
[08:09] <joris_> I filed a bugreport containing some more info https://launchpad.net/ubuntu/+bugs?field.searchtext=2.6.20-16-server&orderby=-importance&search=Search&field.status%3Alist=New&field.status%3Alist=Incomplete&field.status%3Alist=Confirmed&field.status%3Alist=Triaged&field.status%3Alist=In+Progress&field.status%3Alist=Fix+Committed&field.assignee=&field.bug_reporter=&field.omit_dupes=on&field.has_patch=&field.has_no_package=
[08:10] <joris_> wrong url, sorry
[08:12] <BenC> joris_: are you trying 32-bit or 64-bit kernel?
[08:13] <joris_> 32bit
[08:13] <BenC> Try 64-bit
[08:13] <fabbione> hey BenC 
[08:14] <BenC> hey fabbione
[08:14] <joris_> (hmmz, I can't seem to find my own bugreport on launchpad..)
[08:15] <joris_> bug id #132577
[08:16] <joris_> BenC: do you mean to install an x86_64 optimized kernel, or switching the entire distro to 64bit?
[08:16] <BenC> well, you have to do the entire distro
[08:16] <joris_> ouch
[08:16] <BenC> but you could just do a kernel, but it wont be easy
[08:17] <joris_> it's supposed to become a fat server (for thin clients) for a school... they'll need some 32bit apps like flash
[08:18] <joris_> BenC: apt-pinning feisty/amd64 for linux-image*?
[08:18] <fabbione> no you can't use pinning for this
[08:18] <BenC> this is taking a .deb by hand and dpkg-deb extract/control -> build
[08:19] <BenC> and having to continue doing it for security updates
[08:19] <joris_> hmm... not fun
[08:19] <BenC> you can't use a chroot for the 32-bit thin clients?
[08:19] <joris_> is it a known problem? is it worth the effort to try to bugfix this?
[08:19] <fabbione> joris_: are you using LTSP ?
[08:20] <fabbione> or some manually crafted thin client installation?
[08:20] <BenC> it's not a bug...just 32-bit can only handle but so much (the slowdown on -server is a bug though)
[08:20] <joris_> BenC: possibly yes, but I'm having enough trouble getting LTSP up and running without doing an arch transposition
[08:20] <joris_> fabbione: no, edubuntu ltsp :)
[08:20] <fabbione> joris_: ok. i suggest you wait one hour or so and talk to ogra
[08:21] <fabbione> joris_: i think he did put some work into running an amd64 server with 32bit thin client for flash and stuff
[08:21] <joris_> aha
[08:21] <joris_> he'll be on here?
[08:21] <fabbione> he is no kernel expert but he is the LTSP guru
[08:21] <joris_> nice :)
[08:21] <fabbione> in #edubuntu or #ubuntu-devel
[08:21] <joris_> I'll see if I can remotely reinstall the machine to amd64
[08:21] <fabbione> but he is not awake yet for what i can see
[08:22] <fabbione> i'd recommend to talk to ogra first
[08:22] <fabbione> and see what's the best way to handle it
[08:22] <joris_> well, I don't know yet if going to amd64 will fix the lack of performance
[08:34] <BenC> joris_: you could try booting an amd64 livecd and see what it would do
[08:35] <BenC> pretty sure it would handle the memory a lot better
[08:37] <mjg59> joris_: Your BIOS doesn't set MTRRs for the upper memory
[08:37] <mjg59> So it's all flagged as uncacheable, and performance sucks
[08:37] <mjg59> It's unlikely that using a 64-bit kernel will help her
[08:37] <mjg59> e
[08:37] <BenC> ah, there's a better answer
[08:38] <mjg59> We really need PAT support in Linux, but nobody's written an implementation the maintainer is happy with
[08:45] <joris_> mjg59: hmmm
[08:46] <joris_> mjg59: that's not good
[08:46] <joris_> and this is why I recommended using a server board, but they wanted to save 100 bucks
[08:47] <joris_> mjg59: the effect is really surprisingly strong btw
[08:47] <mjg59> Yes, it will be
[08:47] <mjg59> The machine will be basically unusable
[08:47] <joris_> it's not like a 10% slowdown, it's more like a 95% slowdown
[08:47] <joris_> it is indeed
[08:56] <joris_> mjg59: anything I can try to objectively measure this?
[08:57] <mjg59> joris_: Not really - it'll depend on workloads and where in memory stuff gets allocated
[08:58] <mjg59> The bottom ~4GB is probably flagged cacheable, but the kernel will be loaded higher
[08:58] <mjg59> So if your code is in the cacheable region and doesn't make any syscalls, it'll probably run fairly fast
[08:59] <joris_> hmmm
[09:00] <joris_> without programming C there is no way to put a benchmark util in upper or lower memory, I presume
[09:01] <Mithrandir> take out half the memory and see if it improves vastly?
[09:01] <mjg59> There's no way to do it at all
[09:01] <mjg59> You're at the mercy of the kernel in terms of where your app ends up
[09:02] <joris_> Mithrandir: that's what happens with the desktop kernel, presumably
[09:02] <joris_> mjg59: ok :(
[09:02] <mjg59> It's a genuine failing in Linux to implement PAT, but it's also a BIOS issue to fail to set the MTRRs sanely
[09:02] <Mithrandir> joris_: presumably, yes.
[09:02] <mjg59> You can boot with different values of mem= to find the maximum you can get away with
[09:03] <mjg59> joris_: Adding the output of cat /proc/mtrr to the bug would be helpful
[09:03] <joris_> mjg59: is there any logic in the values to try?
[09:03] <joris_> mjg59: will do so
[09:03] <mjg59> joris_: Look at /proc/mtrr. Figure out the highest address that's flagged write-back or write-through.
[09:03] <mjg59> That's the maximum amount of RAM you can use
[09:03] <joris_> okay
[09:04] <joris_> as soon as the machine finishes installing sysinfo (half an hour and counting)
[09:09] <joris_> mjg59: it's attached
[09:09] <mjg59> joris_: Thanks - what was the bug number, again?
[09:09] <joris_> https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/132577
[09:10] <joris_> what does write-combining mean?
[09:12] <mjg59> joris_: Looks like you're not going to get more than 3584MB
[09:12] <mjg59> joris_: http://en.wikipedia.org/wiki/Write-combining :)
[09:13] <joris_> ouch :(
[09:13] <mjg59> The mtrrs simply don't cover more than that
[09:16] <kraut> moin
[09:18] <joris_> mjg59: do you know off hat what unit/syntax does the kernel mem= parameter accept?
[09:19] <joris_> 'mem=xyzM' ?
[09:19] <mjg59> Yeah
[09:20] <joris_> mem=3584M it is then
[09:21] <mjg59> Might end up needing to be slightly lower than that
[09:21] <mjg59> But give that a go first
[09:22] <joris_> okay, here goes nothing
[09:24] <joris_> that worked :)
[09:24] <mjg59> Excellent
[09:25] <joris_> it's most likely an intel 965-based motherboard
[09:26] <mjg59> Yeah
[09:26] <mjg59> All you can really do at this point is check for a bios update, I'm afraid
[09:27] <joris_> yep... makes sense :/
[09:27] <mjg59> Or wait for PAT support
[09:27] <joris_> I'll break the bad news
[02:31] <zul> morning
[03:05] <lamont> morning zul
[03:22] <zul> hi lamont how goes it?
[03:22] <lamont> generally pretty well
[03:23] <zul> good
[04:27] <instabin|work> Is any one working on getting the nvidia 100.14.11 drivers in to gutsy
[04:31] <infinity> Yes.
[10:42] <NativeAngels> hello
[10:42] <NativeAngels> is there anyone in here who knows about unrealirc and neostats
[10:42] <mjg59> NativeAngels: This sounds like the wrong place to ask
[10:43] <NativeAngels> i know
[10:43] <NativeAngels> sorry
[10:44] <verwilst> hellow!
[10:44] <NativeAngels> hello
[10:44] <verwilst> i'm building the -xen kernel for amd64
[10:44] <verwilst> i did an apt-get source linux-source-2.6.22
[10:44] <verwilst> and then debuild
[10:44] <verwilst> but this will take aaaages :)
[10:44] <verwilst> is there an easy way to only build the -xen kernel?
[10:44] <verwilst> ):
[10:45] <verwilst> it's done "build-generic  build-server  custom-build-rt  custom-source-rt" so far :)
[10:45] <verwilst> btw any reason why -xen is i386-only?
[10:45] <verwilst> and not amd64?
[11:14] <JanC> verwilst: because it doesn't compile on amd64 AFAIK  :)
[11:14] <verwilst> oh?
[11:14] <verwilst> we'll soon know =-
[11:14] <verwilst> :)
[11:14] <verwilst> i'm compiling it now
[11:15] <JanC> I might be wrong, but I'm sure there must be a good reason
[11:16] <verwilst> i could really use an amd64 version of the -xen though :)
[11:16] <verwilst> the 2.6.18 from xensource has ext3 corruption
[11:16] <verwilst> as i experienced :p
[11:16] <JanC> Xen patches seem to be constantly outdated compared to current kernels anyway  :)
[11:17] <verwilst> yeah
[11:17] <verwilst> maybe i should just use a 32bit system instead of a 64bit..
[11:17] <verwilst> but 64bit is a lot faster imo
[11:17] <verwilst> does the -generic have pae?
[11:23] <JanC> hm, what's the kernel config option for PAE again?
[11:24] <JanC> anyway, there are -server kernels too
[11:25] <verwilst> i need to use -xen, stupid me :)
[11:25] <verwilst> 32bit, with -xen
[11:25] <verwilst> can i go over 4GB RAM with it?
[11:27] <JanC> I have no -xen kernels installed
[11:30] <JanC> I guess they support > 4 GiB of RAM if the patch allows for it