[10:56] <kraut> moin
[04:20] <calc> BenC: do you know if the realtek ALC268 support is supposed to be in upstream kernel yet? i don't see it in there yet, just on the alsa git repo you told me about before
[04:25] <BenC> calc: if you can get the patch and test it, I can include it in our kernel
[04:26] <calc> ok i'll try to work on that soon
[04:28] <zul> BenC: how you add new modules to lum?
[04:29] <zul> I mean do you just plop in a new directory update the Makefile and add the Kconfig?
[04:36] <BenC> zul: add the directory and/or source, update Makefile, and update debian/config/*
[04:36] <BenC> zul: if applicable, update debian/d-i/ module lists too (for like network and storage controllers
[04:36] <BenC> )
[04:37] <zul> okies, i was thinking of adding the xen drivers that xensource ships and some other drivers as well
[04:44] <enseven> Hi, I on a Ubuntu system with 2 AMD 64bit CPUs, each dual core, with one 2GB memory section vor each CPU, like the TYAN Thunder h2000M (S3992) board. Which type of kernel do I have to use? And is Ubuntu aware of the two shared memory design of the system?
[04:49] <BenC> zul: are these guest drivers?
[04:49] <zul> BenC: correct
[04:49] <kylem> bloody backseat drivers.
[04:50] <BenC> enseven: use the Ubuntu 64-bit (amd64, Core2Duo) release
[04:50] <BenC> zul: Shouldn't these be built with the xen guest kernel instead?
[04:50] <zul> BenC: its seperate in the xen tree 
[04:51] <zul> its for the full paravarilized guests
[04:56] <enseven> BenC: Thanx. Can this release handle the two distinct shared memory sections, that are shared between the two cores on each cpu? Can one process allocate memory from only one or both CPUs? Where can threads of one process run? On the same core, on the same cpu or on either cpu?
[04:57] <BenC> enseven: I think you're overcomplicating this :)
[04:58] <BenC> enseven: the kernel handles shared mem between cores and memory allocation and threading on cores, and is aware of these things
[04:58] <BenC> you don't have to do anything special
[04:59] <enseven> benc: that's fine
[04:59] <enseven> benc: what about the memory a process can allocate and where threads can run?
[04:59] <BenC> what about it?
[05:00] <BenC> processed don't decide where they get memory from, they request it, and the kernel allocates it
[05:00] <BenC> processes even
[05:00] <BenC> the kernel is smart enough to allocate from certain portions of memory based on which cpu a process is running from, for better performance
[05:01] <BenC> which cpu a thread runs on is generally handled by the kernel scheduler, again, not by the process
[05:01] <BenC> although you can force these things, It's not often you ever need to
[05:03] <enseven> benc: Ok, so a process can get as much memory is available on both cpus, but gets first what is on the cpu it is running.
[05:04] <BenC> enseven: how that all happens is complete black magic, and I wouldn't worry yourself about it too much
[05:04] <enseven> benc: I just wonder if such a system is performing well for a database server ...
[05:05] <enseven> benc: ... that has one process for each client and some threads ...
[05:06] <enseven> ... and if the whole memory can be used with a good performance, not only half of it.
[05:06] <BenC> enseven: I'd be more worried about the disk IO than the threading and memory allocation
[05:06] <BenC> enseven: of course the whole memory can be used...that's why they have things like MMU's
[05:08] <enseven> benc: disk IO is planed to be done by a dual 4G Fibre-Channel link to a RAID system with 16 FC-Disks. 
[05:09] <BenC> only thing to do is install it and benchmark it then :)
[05:10] <enseven> benc: Ok. I am very looking forward to that. :-)
[05:10] <enseven> benc: thanks again.
[05:12] <BenC> enseven: np
[07:45] <calc> i think i found the one thing more insane to build than OOo... the default ubuntu kernel package
[07:46] <zul> yep should have tried it breezy
[07:47] <calc> i think its going to have taken ~ 3hr or so to build
[07:47] <zul> our you building everything?
[07:47] <zul> doh...s/our/are/
[07:47] <calc> i was doing a test build, probably could have done something special to not have it build so much, lol
[07:48] <johanbr> crimsun: Hi. A few weeks ago, I told you I'd look into the bluetooth headset pairing problems I had and I've now done so. Do you have a few minutes?
[07:48] <calc> i need to verify a sound patch works with the ubuntu kernel
[07:48] <calc> real    179m7.724s
[07:48] <calc> user    143m47.179s
[07:48] <calc> sys     13m10.349s
[07:48] <calc> ouch
[07:51] <calc> i can see why benc wants to drop bigiron now
[07:52] <calc> and 9GB of diskspace to build
[07:53] <BenC> calc: fakeroot debian/rules binary-generic
[07:54] <calc> ah :)
[07:54] <HawkeV> any developer types about?
[07:56] <calc> going much faster now ;) esp with ccache primed
[08:13] <calc> binary-generic 17m4s  not too bad
[08:13] <calc> < 10% of original build time :)
[11:15] <calc> BenC: the fix from alsa git isn't enough apparently
[11:15] <calc> i'm going to try using a diff from realtek's alsa version and see how it does
[11:23] <calc> fsck
[11:23] <calc> realtek's driver no longer has 268 support
[11:23] <calc> wth
[11:25] <calc> ok i guess they removed their 268 since alsa added partial 268 support
[11:26] <calc> apparently the alsa 268 support isn't complete i get the full mixer (i think) but no sound
[12:10] <BenC> calc: have you tried something like model=3stack for snd-hda-intel module?
[12:10] <BenC> calc: is this hda?
[12:11] <calc> yea its hda
[12:11] <calc> i'm pretty sure i tried 3stack also
[12:12] <calc> yep tried 3stack as well as auto
[12:12] <calc> it looks to setup the mixer right or close to right