=== BenC [n=bcollins@debian/developer/bcollins]  has joined #ubuntu-kernel
=== rodarvus [n=rodarvus@ubuntu/member/rodarvus]  has joined #ubuntu-kernel
=== wordsofglass [n=ecbowen@cpe-024-211-192-157.nc.res.rr.com]  has joined #ubuntu-kernel
[03:28] <wordsofglass> hi, i just compiled a kernel according to the FAQ and comp is a lot faster, but mounting extra drives wont work, it tells me they're mounted or the folder is busy; i do have all the fs-types compiled into the kernel
[03:29] <wordsofglass> not sure if this is the place to ask
[03:38] <infinity> It's not.
[03:39] <infinity> This isn't a support channel, but rather a kernel development channel.
[03:39] <infinity> (For Ubuntu-specific kernel development, obviously)
[03:40] <wordsofglass> sorry, i realized after looking at the channel list categories
[03:40] <wordsofglass> support vs devel team channels
=== zul_ [n=chuck@CPE0006258ec6c1-CM000a73655d0e.cpe.net.cable.rogers.com]  has joined #ubuntu-kernel
=== wordsofglass [n=ecbowen@cpe-024-211-192-157.nc.res.rr.com]  has left #ubuntu-kernel ["Leaving"] 
[06:53] <lifeless> hi
[06:54] <lifeless> any chance of us enabling the callgraph option, which oprofile needs to get callgraph data ?
=== tuxmaniac [n=aanjhan@unaffiliated/tuxmaniac]  has joined #ubuntu-kernel
=== pschulz01 [n=paul@eth6067.sa.adsl.internode.on.net]  has joined #ubuntu-kernel
[07:05] <crimsun> lifeless: For Dapper/Edgy? What needs to be tweaked? The callgraph patch on oprofile.sf.net seems to already be in ubuntu-dapper.git, and oprofile is modularised.
[07:06] <lifeless> well
[07:06] <lifeless> I'm not an oprofile expert
[07:06] <lifeless> but when I follow the faq info for getting callgraph data
[07:06] <lifeless> it generates no parents/children
[07:07] <lifeless> (this is using dapper)
[07:10] <crimsun> sorry, I don't have any experience with it either
=== tuxmaniac [n=aanjhan@unaffiliated/tuxmaniac]  has joined #ubuntu-kernel
=== Lure [n=lure@ubuntu/member/lure]  has joined #ubuntu-kernel
=== allee [n=ach@dialin-212-144-131-214.pools.arcor-ip.net]  has joined #ubuntu-kernel
=== lloydinho [n=andreas@rosinante.egmont-kol.dk]  has joined #ubuntu-kernel
=== doko_ [n=doko@dslb-088-073-081-023.pools.arcor-ip.net]  has joined #ubuntu-kernel
=== pschulz01 [n=paul@202.174.42.5]  has joined #ubuntu-kernel
=== tuxmaniac [n=aanjhan@unaffiliated/tuxmaniac]  has joined #ubuntu-kernel
=== rodarvus [n=rodarvus@ubuntu/member/rodarvus]  has joined #ubuntu-kernel
=== pschulz01 [n=paul@202.174.42.5]  has joined #ubuntu-kernel
=== zul [n=chuck@ubuntu/member/zul]  has joined #ubuntu-kernel
[02:25] <zul> hey
=== TheMuso [n=luke@ubuntu/member/themuso]  has joined #ubuntu-kernel
=== pschulz01 waves
=== BenC [n=bcollins@debian/developer/bcollins]  has joined #ubuntu-kernel
=== Keybuk [n=scott@quest.netsplit.com]  has joined #ubuntu-kernel
=== kbyrd [n=Miranda@mailout1.vmware.com]  has joined #ubuntu-kernel
=== kbyrd [n=Miranda@mailout1.vmware.com]  has joined #ubuntu-kernel
=== tuxmaniac [n=aanjhan@unaffiliated/tuxmaniac]  has joined #ubuntu-kernel
=== rodarvus [n=rodarvus@ubuntu/member/rodarvus]  has joined #ubuntu-kernel
=== lfittl [n=lfittl@85-125-147-132.dynamic.xdsl-line.inode.at]  has joined #ubuntu-kernel
=== tuxmaniac [n=aanjhan@unaffiliated/tuxmaniac]  has joined #ubuntu-kernel
=== Lure [n=lure@ubuntu/member/lure]  has joined #ubuntu-kernel
=== lfittl [n=lfittl@85-125-147-132.dynamic.xdsl-line.inode.at]  has joined #ubuntu-kernel
=== rodarvus [n=rodarvus@ubuntu/member/rodarvus]  has joined #ubuntu-kernel
=== jwest- [n=jwest@ner-as16722.alshamil.net.ae]  has joined #ubuntu-kernel
=== allee [n=ach@dialin-212-144-130-129.pools.arcor-ip.net]  has joined #ubuntu-kernel
=== rodarvus [n=rodarvus@ubuntu/member/rodarvus]  has joined #ubuntu-kernel
[08:34] <doko> BenC: will the xfs corruption bug be fixed in the dapper kernel?
[08:34] <BenC> doko: If I recall the bug report, there was no clear and simple update to fix that bug
[08:35] <BenC> basically meant backporting the entire xfs tree
[08:35] <doko> ouch
[08:36] <doko> BenC: so the answer is yes, or maybe later?
[08:37] <BenC> doko: the answer is "not unless the fix becomes a lot easier"
[08:37] <BenC> I'm a little reluctant to backport an entire fs
[08:37] <zul> you can do it!
[08:37] <zul> heh
[08:38] <kbyrd> infinity: ping.
[08:41] <kbyrd> ok, anyone: infinity has said that he would include the vmware-player-kernel package into the l-r-m build for edgy. What would be the deadline for that? 
[08:42] <BenC> kbyrd: I'll probably be able to get to it with the next kernel upload
[08:42] <BenC> it's an ABI bump anyway, so perfect time to do that
[08:43] <BenC> kbyrd: is there a place to download stock tarball's for this?
[08:44] <kbyrd> Cool. But, we're considering releasing vmware-server as a deb, and we would have a vmware-server-kernel package too. So, I need to know when I have to get that to you.
[08:45] <kbyrd> BenC: about the tarball, there isn't a stock tarball of just the modules (it's not a separate installer for us normall). But, the current package includes the source and makefiles. 
[08:45] <BenC> ok, I'll pull from that
[08:46] <kbyrd> But, last time I talked to someone. the l-r-m build isn't going to include our modules, it's going to build the entire package. The reason for this is that we actually need to have two packages: vmware-player-kernel and vmware-server-kernel.
[08:47] <kbyrd> They can't co-exist.
[08:47] <kbyrd> You guys don't have vmware-server-* yet. But in my version, they conflict with vmware-player-*
[08:50] <kbyrd> So, I still need to get a deadline for handing off vmware-server-kernel to you all to be included in edgy.
[08:51] <BenC> the sooner you get them to me, the sooner I'll get it done :)
[08:52] <BenC> basically I'll keep vmware-player-kernel in l-r-m package proper, and build vmware-server-kernel in separate package
[08:52] <BenC> l-r-m package will provide vmware-player-kernel to satisfy any deps
[08:53] <BenC> hmm, wait
[08:53] <BenC> they'll both need to be separate packages
[08:54] <BenC> but I can do that easily
=== jwest- [n=jwest@ner-as23865.alshamil.net.ae]  has joined #ubuntu-kernel
[09:45] <BenC> mdz: ping
[09:45] <mdz> BenC: pong
[09:46] <BenC> mdz: I'm in the middle of running an extensive benchmark test on -386 vs. -686 on my UP P4 2Ghz system
[09:47] <BenC> I'm going to do the same on my Athlon64 UP system with -amd64-generic vs. -amd64-k8
[09:47] <BenC> and the same on my SMP xeon
[09:48] <BenC> just to see if these alt kernels are giving us _any_ performance improvement (and my bet is that they aren't)
[09:49] <mdz> BenC: thank you, it's high time we had some hard data to work with
[09:50] <mdz> BenC: SMP/dual-core support out of the box in Edgy would be valuable
[09:51] <BenC> good thing is that most systems with SMP/dual-core fall into the amd64 category, so they already get it, but with Intel's CoreDuo coming out, that will change
[09:53] <BenC> $ cat /proc/version_signature 
[09:53] <BenC> Ubuntu 2.6.17-7.19-amd64-xeon
[09:53] <BenC> that's going to be a useful little file
[09:54] <mdz> indeed indeed
[09:56] <mjg59> BenC: Coming out? There's been shipping Core Duo hardware since February...
[09:57] <BenC> mjg59: I meant CoreDuo2, sorry
[09:57] <mjg59> BenC: Core Duo 2 is amd64
[09:57] <BenC> CoreDuo 2 is emt64
[09:57] <mjg59> Well
[09:58] <mjg59> The scheduling is close enough, surely?
[09:58] <BenC> oh, I get what you mean now :)
[09:58] <mjg59> Heh
[09:58] <mjg59> Yes, the ones where we're losing are the original core duos
[09:58] <BenC> I thought some of the CoreDuo2 was 32-bit still
[09:58] <BenC> maybe I need to reread the docs
[10:01] <BenC> I know there's CoreDuo2 - emt64, and CoreDuo2 - ia64
=== kylem_ looks at BenC.
[10:02] <mjg59> BenC: Pretty certain there's no ia64 ones
[10:03] <BenC> damnit, you ppl are going to make me open this powerpoint on windows, aren't you? :)
=== BenC goes to recheck his facts
[10:03] <kylem_> it probably says "Dual Core Itanium2"
[10:05] <BenC> it was all convoluted into a big PPT file, so it's understandable if I got all the 100 name combinations mixed up
[10:05] <kylem_> :)
=== mdz [n=mdz@studiocity-motorola-bsr1-70-36-194-85.vnnyca.adelphia.net]  has joined #ubuntu-kernel
=== kbyrd [n=Miranda@mailout1.vmware.com]  has joined #ubuntu-kernel
[10:11] <mdz> mjg59: regarding our discussion about the ondemand governor, will it only appear in available_governors if it works properly? or do we need to be cleverer than that?
[10:12] <mdz> it seems to work OK on the systems I have access to, so I don't know what the other case looks like
[10:12] <mjg59> mdz: We need to be cleverer than that
[10:12] <mjg59> Hm. At least, I think so.
[10:12] <mjg59> It might be cleverer than I think
[10:12] <mjg59> The failure will be that attempting to set the governer to ondemand will fail
[10:13] <mjg59> In that case, we probably want to fall back to powernowd
[10:13] <mdz> oh, that's easy enough then
=== allee [n=ach@dialin-145-254-253-252.pools.arcor-ip.net]  has joined #ubuntu-kernel
=== Lure [n=lure@ubuntu/member/lure]  has joined #ubuntu-kernel
=== rodarvus [n=rodarvus@ubuntu/member/rodarvus]  has joined #ubuntu-kernel
=== Lure [n=lure@ubuntu/member/lure]  has joined #ubuntu-kernel
=== zul [n=chuck@ubuntu/member/zul]  has joined #ubuntu-kernel
[11:49] <zul> hey
=== lfittl [n=lfittl@85-125-147-132.dynamic.xdsl-line.inode.at]  has joined #ubuntu-kernel