[01:48] <bryceh> JFo, mind putting lp #507148 on the kernel team radar?
[01:49] <JFo> I don't mind at all bryceh 
[01:50] <JFo> done bryceh 
[01:51] <bryceh> thanks
[01:51] <JFo> np
[03:54] <MTecknology> How hard is it to add the ext4 defrag patches?
[03:54] <MTecknology> I just migrated this system from a dying drive. I'd like to reinstall all the packages, then run the defrag, then let my mind tell me it's as good as a fresh install
[09:31] <akheron> do ubuntu kernels support xen domU like debian kernels?
[09:43] <smb> akheron, I am not doing xen really, but I thought that was what the -virtual flavours are for
[09:44] <akheron> ahh, ok
[11:00] <akheron> smb: I don't see the XEN config options in -virtual
[11:02] <smb> akheron, Were you looking in the git repo or in the files installed in /boot?
[11:03] <akheron> in /boot/config-*
[11:04] <akheron> and it confuses me that -generic-pae and -virtual conflict/replace each other
[11:04] <smb> akheron, Well, virtual is basically made from generic-pae
[11:06] <akheron> what do you mean by "made from"?
[11:06] <smb> akheron, Hm, its strange. common.ubuntu sets a lot of XEN options and those should tickle down to generic-pae
[11:07] <smb> akheron, Basically build generic-pae and rename some things in the package
[11:07] <akheron> ok
[11:07] <akheron> smb: is this new behaviour in lucid kernels?
[11:07] <akheron> I'm using karmic
[11:07] <akheron> I mean the XEN options in common.ubuntu
[11:14] <akheron> smb: did you get my last lines?
[11:14] <smb> akheron, No. seems to irc horkage happened
[11:14] <akheron> 13:07 < akheron> smb: is this new behaviour in lucid kernels?
[11:14] <akheron> 13:07 < akheron> I'm using karmic
[11:14] <akheron> 13:07 < akheron> I mean the XEN options in common.ubuntu
[11:14] <smb> oh those
 No, was the same in Karmic. Or I should say it is like that in Karmic and I would need to compare that in Lucid. There have been other changes
 I looked in the sources of the git repo. You only see the generated file in /boot
 But its not as I would expect it. 
 I think I need a bit more time to figure that out
[11:15] <akheron> ok
[11:21] <smb> akheron, Hm, seems X86_TSC is not set in the generic-pae config which then turns off XEN. Dammit this looks too familiar. apw didn't we talk about that some time ago. And sort of tried to figure if PAE naturally implies TSC (and I believe to remember it did)...?
[11:22] <akheron> what's TSC?
[11:22] <apw> yes thats familiar
[11:23] <apw> i think it occurs because 486 doesn't support TSC or something
[11:23] <apw> smb ^^
[11:24] <smb> It must be something like that as it is set to =y in common
[11:24] <apw> i rmember writing the problem up somewhere
[11:24] <smb> apw, What was the acronym thingy again timestamp something?
[11:24] <akheron> time stamp counter, it seems
[11:25] <akheron> wikipedia ftw :)
[11:25] <apw> hrm no idea :)  but its a clock tick counter
[11:25] <smb> akheron, Yeah, wiki sounds reasonable there
[11:26] <apw> now where the heck has that gone
[11:26] <akheron> "The Time Stamp Counter is a 64-bit register present on all x86 processors since the Pentium", so it's not in 486
[11:26] <apw> yeah and thering lies the rub
[11:26] <smb> apw, Yes, I think I remember, we wondered whether we should move the base cpu to M586*somthing and what that would mean
[11:27] <akheron> PAE is in Pentium Pro
[11:27]  * apw watches mutt search his email
[11:27] <apw> i think we did work out that you couldn't get PAE without TSC
[11:27] <akheron> so, to me it seems that PAE implies TSC
[11:27] <apw> yep, i think that was the concensus of the discussion, now where _IS_IT_
[11:28] <akheron> :)
[11:28] <smb> So with PAE only in pentium pro it seemed save to lift the M486 up as you would not get it running without.
[11:28] <smb> And apparently we got lost at that stage
[11:30] <tjaalton> is there a known bug about nfs4/krb5 mounts getting hung after the krb tickets getting expired, and refreshing not helping?
[11:30] <tjaalton> on lucid
[11:30] <apw> tjaalton, not that i am aware of
[11:30] <tjaalton> apw: ok, I'll try .33rc7 to see if it's there too
[11:31] <apw> ta
[11:31] <tjaalton> 'ps' gets stuck too, this is from dmesg http://pastebin.ubuntu.com/372406/
[11:31] <tjaalton> but probably just a resulf of the bigger problem
[11:32] <smb> apw, I guess we should speak with that to John. (the m586/xen enablement)
[11:32] <apw> smb yeah, cannot find it at the moment
[11:38] <leleobhz> i want to try linux 2.6.32 because i want to know if a bug in my sata controller was fixed
[11:38] <leleobhz> is better try kernel-ppa or use lucid kernel via apt-pinning
[11:38] <leleobhz> ?
[14:31] <apw> leleobhz, the lucid kernel is more likely to match your system so i'd try that
[14:31] <apw> Keybuk, about?
[14:31] <Keybuk> apw: sure
[14:31] <leleobhz> apw, ok
[14:31] <leleobhz> thanks! ill try
[14:31] <apw> Keybuk, was wondering if we would have expected graphs for bootspeed today?
[14:31] <apw> don't seem to have results since the 1st
[14:34] <Keybuk> apw: installer broken in a new and different way
[14:34] <apw> bah
[14:35] <apw> its those foundations guys, cannot be trusted :)
[14:38] <tgardner> apw, I'd still like some -preempt boot times as  well
[14:39] <apw> hrm, thats 64 bit only right?
[14:39] <apw> tgardner, ^^
[14:40] <apw> if so i can't test that on the 'reference' platform as its 32 bit only
[14:40] <tgardner> apw, yep, I need to respond on the mailing list to allesio about 32 bit issues.
[15:19] <MTecknology> How hard is it to add the ext4 defrag patches? I  just migrated this system from a dying drive. I'd like to reinstall all the packages, then run the defrag, then let my mind tell me it's as good as a fresh install.
[15:27] <bjf> ##
[15:27] <bjf> ## Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
[15:27] <bjf> ##      agenda: https://wiki.ubuntu.com/KernelTeam/Meeting
[15:27] <bjf> ##
[15:46]  * leleobhz think ubuntu kernel dont like HP machines.
[15:46] <leleobhz> bonding module give-me a panic
[16:19] <apw> MTecknology, couldn't say how big they are ... never looked
[16:19] <apw> leleobhz, file a bug :/
[16:20] <leleobhz> apw, i think to get a decent trace i must enable a serial console
[16:20] <leleobhz> and i dont have a way now
[16:20] <leleobhz> the calltrace is too big
[16:21] <apw> annoying
[16:21] <apw> you can change the font size perhaps on VT-1
[16:22] <apw> consolechars -f /usr/share/consolefonts/Uni1-VGA8.psf.gz
[16:22] <apw> something like that
[16:22] <leleobhz> well, is a fb 1024x720 :p
[16:22] <leleobhz> and the trace runs at least 4 pages
[16:22] <leleobhz> ill see if serial port tell-me something
[16:23] <leleobhz> ah, kernel told-me vga= is deprecated. where can i find the new way to set fb?
[16:26] <Sarvatt> try video=resolution
[16:27] <leleobhz> WxHxB?
[16:27] <Sarvatt> WxH works at least
[16:27] <leleobhz> nice
[16:27] <Sarvatt> video=1280x800 or whatever
[16:28] <Sarvatt> are you using KMS? you can change resolutions with fbset too
[16:29] <leleobhz> Sarvatt, radeon
[16:29] <leleobhz> i dont know if its usable
[16:30] <Sarvatt> were you using lucid?
[16:34] <leleobhz> Sarvatt, karmic
[16:34]  * leleobhz wasnt happy with alpha until now
[16:35] <bjf> leleobhz, what model HP is it?
[16:35] <corecode> the newer linux kernels come with tools, specifically "perf"
[16:35] <corecode> i can't seem to find a package containing it
[16:35] <corecode> what's the opinion on how to package that?
[16:35] <leleobhz> bjf, dc5750
[16:36] <Sarvatt> hmm, I read the scrollback, I think you're more likely hitting a problem because the lucid kernel has radeon KMS enabled by default and the karmic userspace doesn't handle it too well, you might want to use the mainline ppa kernel instead or boot with radeon.modeset=0 appended to the kernel command line in grub
[16:37] <leleobhz> Sarvatt, im not running lucid kernel now
[16:37] <leleobhz> i found a strange issue with ubuntu kernel
[16:37] <leleobhz> in this HP, the installer only runs well with noapic, nolapic and noapic
[16:38] <leleobhz> with installed kernel everything goes ok
[16:39] <Sarvatt> MTecknology: the ext4 defrag stuff was merged during the 2.6.29-rc phase I think? either that or 2.6.30, either way its been there for a long time now and works here, just have to compile e4defrag yourself
[16:47] <leleobhz> where here i can find information about linux bridge?
[16:58] <Sarvatt> hmm, wonder why e4defrag isnt included in our e2fsprogs actually
[16:59] <bjf> ##
[16:59] <bjf> ## Meeting starting now
[16:59] <bjf> ##
[17:00]  * smb rushes in
[18:28] <mirsal> apw, ping
[18:29] <apw> hi
[18:38] <mirsal> apw, oh, hi, I have a little question about aufs and this bug: #517151
[18:38] <mirsal> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/517151
[18:38] <ubot3> Malone bug 517151 in linux "aufs module build fails with CONFIG_AUFS_DEBUG in linux-source-2.6.31" [Undecided,In progress] 
[18:38] <apw> bug #517151 ubbotu
[18:39] <mirsal> apw, what's the right thing to to ? :p
[18:39] <apw> so are you changing the config or building with the stock config
[18:40] <apw> and how are you building it
[18:41] <mirsal> apw, I think the stock config doesn't include CONFIG_AUFS_DEBUG
[18:42] <mirsal> apw, I did it with a plain old make
[18:42] <apw> so you seem to have determined that should you want to turn that on there is a bug in the source back there
[18:43] <apw> is the code similar in lucid?
[18:44] <mirsal> apw, no, you synced with an upstream snapshot, everything is fine in lucid
[18:44] <apw> #include <asm/system.h>
[18:44] <apw> #include <linux/bug.h>
[18:44] <apw> #include <linux/init.h>
[18:44] <mirsal> yes exactly
[18:44] <apw> well it is actually similar, in that its like how your patch chagnes it
[18:46] <apw> mirsal, well i think that your patch is fine as a patch for the issue, though its not clean why anyone would want to turn on that DEBUG
[18:46] <mirsal> yes, that's my question actually: as the patch in lucid replaces the whole driver with an updated version, how should it be handled in karmic
[18:46] <mirsal> ok
[18:46] <apw> you will find resistance to fixing it i suspect as it doens't fix anything we build, and adds risk, and any consumer of it can just apply the patch to their source
[18:47] <mirsal> apw, ok, actually I don't really care, I'm just looking for low hanging fruits in the kernel bug list in order to learn
[18:49] <mirsal> right, if someone wants to debug AUFS they surely can apply a small patch
[18:49] <apw> so i think you should cleanup your patch and attach it with your signoff to the bug
[18:49] <apw> and then also send it to the kernel-team list
[18:50] <apw> 'we' will then either apply it, or suggest that its not worth it, and then we can close the bug won't fix with the reasoning
[18:50] <apw> and you are off the hook :)
[18:50] <mirsal> ok, thanks :)
[18:50] <apw> but the work you did looks good, even if it doesn't go anywhere in the kernel, as the reader can see how to fix it themselves and allows us to close the bug one way ot the other
[18:51] <mirsal> :)
[18:51] <apw> good job, thanks
[18:56] <tgardner> apw, I cannot see any substantive difference in CONFIG_M586TSC and CONFIG_M586. they both set the same karmic compiler flag
[18:57] <tgardner> ah, it enables X86_TSC
[19:04] <apw> yep that is meant to be the only difference
[19:04] <apw> obviously that would allow us then to re-enable XEN on top
[19:09] <tgardner> apw, frankly, I don't see that as very risky
[19:09] <tgardner> definitely do it for Lucid.
[19:09] <apw> cool, that was my feeling 
[19:10] <smb> Would we care enough for Karmic?
[19:10] <tgardner> smb, likely for the pae flavour
[19:10] <tgardner> perhaps generic as well
[19:11] <apw> i think that some of the more brain dammaged things we support with generic dont have TSC
[19:11] <tgardner> apw, thats only in the 386 flavour.
[19:11] <smoser> apw, jjohansen did you sort out the linux-meta-ec2 ? issue ?
[19:12] <smb> I'd vote for generic-pae. We all think there should be nothing that has PAE but not TSC
[19:12] <apw> smoser, under control yes
[19:12] <tgardner> smb, actually, it _can't_ be PAE without TSC
[19:12] <apw> that was my reading of the info for sure
[19:13]  * smb nods
[19:13] <tgardner> so, does taht eman we only support Xen with -pae ?
[19:13] <tgardner> that mean*
[19:13] <smb> Xen only supports itself with TSC
[19:13] <apw> its the -virtual flavour that is for xen
[19:13] <apw> and thats made from -pae
[19:13] <tgardner> and we build -virtual from -pae on i386
[19:14] <apw> smoser, pushed
[19:14] <apw> s/pushed/uploaded
[19:14] <smoser> apw, thanks.
[19:15] <smb> tgardner, So we currently only have no Xen enabled in -virtual because X86_TSC is not set because of M586TSC not being used
[19:15] <apw> smoser, was an oversight on my part, i uploaded the kernel before travelling back
[19:15] <tgardner> correct
[19:15] <smb> tgardner, Sorry, I was trying to make a statement there
[19:16] <apw> so the fun will be getting the XEN config options 
[19:16] <apw> back ...
[19:16] <smb> Guess we all agree then we want to enable it. 
[19:16] <smb> apw, Not so bad
[19:17] <smb> apw, Just enable CONFIG_586TSC in the flavour and the XEN stuff is in common
[19:17] <apw> oh handy ... good
[19:17] <smb> apw, it was just removed whenever you ran config
[19:17] <apw> got you makes sense
[19:17] <apw> i'll get that done then, do we need a bug?  only for karmic i guess
[19:17] <smb> apw, Now we only need to remember ... bah, you were faster
[19:18] <smb> Maybe there was one in the beginning...
[19:18] <apw> i'll do it now
[19:20] <apw> smb, see if you can find a bug on it :)
[19:20] <apw> Bug #453073 is mentioned in the original email i had
[19:20] <ubot3> Malone bug 453073 in linux "linux-image-virtual (i386): many modules missing on Karmic" [High,Fix released] https://launchpad.net/bugs/453073
[19:20] <jjohansen> is it worth fixing for karmic?
[19:23] <smb> apw, That one probably not :) it should be fixed
[19:23] <apw> yeah i see that now :)
[19:23] <smb> jjohansen, maybe cheap enough. or do you think pointing them at ec2 is fixed enough?
[19:24] <jjohansen> ugh, I would like to keep the use of the ec2 kernel to an absolute minimum
[19:24] <jjohansen> so yeah lets do this for karmic then
[19:26] <smb> apw, akheron might have one as he was asking this morning
[19:26] <smb> Not sure he is still around 
[19:31] <akheron> smb: ???
[19:31] <smb> akheron, Just wondering whether you had reported the missing Xen support as a bug.
[19:32] <akheron> no
[19:32] <akheron> should I?
[19:32] <smb> akheron, Ok, I guess apw will do that now (or has done)
[19:32] <akheron> ok
[19:33] <apw> smb, i haven't as yet, as it wasn't clear we are doing this for karmic
[19:33] <apw> if the decision is yes for karmic then we should file a bug
[19:33] <smb> It felt it is yes.
[19:33] <apw> if someone gets that filed, i'll get my email in there straight after
[19:34] <smb> okok, I will do it
[19:34] <apw> :)
[19:34]  * apw lets smb get some karma
[19:39] <smb> apw, bug 519448
[19:39] <ubot3> Malone bug 519448 in linux "No XEN domU support in 32bit virtual flavour" [Wishlist,Triaged] https://launchpad.net/bugs/519448
[19:39] <apw> smb, thanks ... i am soooo lazy
[19:39]  * smb knows :-P
[19:45] <apw> smb, ok pushed to the kernel-team list
[19:45] <apw> smb, also nom'd for karmic for you
[19:46] <smb> apw, Ok cool
[19:50] <smb> apw, The patch for bug 516325 seems to be in your tree (coming from 2.6.32.7) but not released yet. Should I leave the Lucid task as commited or set it to released (as you probably soonish will do)
[19:50] <ubot3> Malone bug 516325 in linux "ACPI: enable C2 and Turbo-mode on Nehalem notebooks on A/C" [Unknown,Fix released] https://launchpad.net/bugs/516325
[19:52] <apw> as its not released i should hack the history to add it
[19:52] <corecode> hey
[19:52] <corecode> any opinion on how to package the tool "perf" that comes with the kernel sources?
[19:52] <smb> apw, Ok, so I put it into committed state and assign it to you
[19:52] <apw> ack
[21:24] <akgraner> bjf, ping got a sec for some SCaLE testing talk?
[21:35] <JFo> akgraner, I suspect he may still be at lunch
[21:36] <JFo> he stepped out a few moments ago
[21:36] <akgraner> JFo, no worries thx
[21:36] <JFo> :)
[21:38] <bjf> akgraner, i'm here
[21:39] <akgraner> bjf, on Friday after 12 the testing area will be in place so you can start testing after noon ..
[21:40] <bjf> akgraner, cool, we get in on Thursday
[21:40] <bjf> akgraner, will we be able to get in early to setup and test our testing setup?
[21:40] <akgraner> the drop won't be in place til noon
[21:41] <bjf> akgraner, ok
[21:41] <akgraner> :-(
[21:41] <akgraner> will you be able to use the sticks at all this time?  if that is the case you can test outside the ubucon area
[21:41] <bjf> akgraner, it is how it is.. we'll make out fine
[21:42] <akgraner> we'll have wireless there but not a drop
[21:42] <bjf> akgraner, we are taking a bunch of sticks, just in case we have network issues, we can still test
[21:42] <akgraner> sweet - I have asked for a table outside the ubucon are for you all 
[21:43] <akgraner> and you will have a dedicated test area right outside the main event on Sat
[21:43] <akgraner> so people pass you going into the venue
[21:44] <akgraner> and if you want you can even have someone at the Ubuntu Booth with sticks as well :-)
[21:45] <bjf> akgraner, sounds good
[21:45] <akgraner> great!  thx  let me know if you need more info or anything
[21:46] <akgraner> hope that helps
[21:47] <bryceh> bjf, pst --- https://wiki.ubuntu.com/X/Testing/NouveauEvaluation
[21:47] <bryceh> bjf, finally I finished writing this up
[21:54] <bjf> bryceh, thanks!
[21:57] <crimsun> bjf: please bump the c-o-d karmic builds to -19 so that Ronald can verify the fix for #519066
[21:58] <bjf> crimsun, will do
[21:58] <crimsun> thanks
[22:36] <Q-FUNK> ogasawara: hi!
[22:38] <Q-FUNK> ogasawara: was a decision reached on Bug  #396286     ?
[22:38] <ubot3> Malone bug 396286 in linux "[Geode LX] [OLPC] 2.6.31-generic: kernel panic near the end of initramfs" [High,In progress] https://launchpad.net/bugs/396286
[22:40] <ogasawara> Q-FUNK: hi, I believe smb was working on that.  I can check with him tomorrow about current status.
[22:41] <Q-FUNK> ogasawara: please see my comment at the bottom.
[22:43] <Q-FUNK> ogasawara: I mainly wanted to know whether my proposal to merge his simple patch into the stock lucid kernel was accepted.
[22:43] <ogasawara> Q-FUNK: I don't know the current status of the patch smb wrote, so will have to wait to check with him tomorrow.
[22:43] <Q-FUNK> ogasawara: despite the fact that it's not a proper fix, but that it nonetheless allows this hardware to boot,
[22:44] <Q-FUNK> ogasawara: alright. :)
[22:53] <bjf> crimsun, new karmic c-o-d available
[22:56] <crimsun> bjf: thanks, I'll follow up with Ronald
[23:27] <bdmurray> JFo: bug 517151 has a patch
[23:27] <ubot3> Malone bug 517151 in linux "aufs module build fails with CONFIG_AUFS_DEBUG in linux-source-2.6.31" [Undecided,In progress] https://launchpad.net/bugs/517151
[23:28] <JFo> bdmurray, yessir, it is on the radar
[23:29] <bdmurray> JFo: awesome, I'll unsub the ubuntu-reviewers team then
[23:30] <JFo> thank you :)
[23:39] <bdmurray> maybe the ubuntu-reviewers team should just ignore kernel bugs if you are on top of them...
[23:40] <bdmurray> JFo: ^ do you have your own monitoring system for bugs with patches?
[23:41] <JFo> I do
[23:41] <JFo> I have a url I use
[23:42] <JFo> https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bugs?field.has_patch=on
[23:42] <JFo> I do a review in our weekly meeting for them
[23:42] <bdmurray> JFo: I have a script that subscribes a team to bugs with new patches.  I could special case the linux package and have it subscribe you maybe? and not the team
[23:43] <JFo> that sounds perfect
[23:43] <JFo> bdmurray, one of my upcoming bug days will be bugs with patches attached
[23:43] <JFo> but subscribing me would work fine
[23:50] <bdmurray> JFo: okay, you've been subscribed to bug 492056
[23:50] <ubot3> Malone bug 492056 in linux "Saitek X52 Joystick does not work" [Medium,Triaged] https://launchpad.net/bugs/492056
[23:51] <JFo> thank you