=== yofel_ is now known as yofel
[00:49] <JFo> thanks kees, you're like the uncle who always give fruitcake as a present. :-P
[00:51] <JFo> ogasawara, are you still around?
[00:51] <JFo> might want to have a look at that: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/731878
[00:51] <JFo> looks nasty to me
[00:58] <kees> JFo: haha :)
[02:31] <jjohansen> back on later
[07:38] <fairuz> morning
=== smb` is now known as smb
=== _LibertyZero is now known as LibertyZero
[08:33] <smb> TeTeT, It would be good if we can get more info about the host system (what distro/release/kernel version) and possible special setup into the many interrupts/xen bug (if this has not mysteriously resolved itself...)
[08:34] <smb> Oh and good morning by the way. :-P
[08:34] <TeTeT> smb: it hasn't. I'll get you the info asap. Morning ;)
[08:36] <smb> TeTeT, To bad... :) Oh and usually (at least in the CenOS installs I use) there are example configurations (including hvm) in /etc/xen. Those may help to find out which values could be changed and what the defaults are supposed to be.
[08:43] <smb> cking, \o
[08:43] <cking> smb, o/
[09:31] <TeTeT> smb: customer attached the sosreport from the RHEL host, hope that has all the needed info
[09:32] <smb> TeTeT, I will hope and see. Have you asked them about the mac addr and prossible acpi activation?
[09:33] <TeTeT> smb: he saw your comment and said it should be all fine, but I will dig into that again
[09:35] <smb> TeTeT, Ok thanks. The mac address was just to be sure. But acpi is definitely not good. If there is a dmesg of the dom0 in the data added I'll see whether this is there the same or not.
[09:46] <Daviey> smb, Is someone looking at bug 731878 ?
[09:46] <Daviey> ah, i see kees mentioned it to JFo last night.
[09:47] <smb> Daviey, my crystal orb looks a bit hazy at the moment.
[09:50] <smb> Daviey, I saw the mailing list thread but did not look myself. And as the bot seems to be MIA again it is not always clear from the scrollback what was discussed
[10:58] <Daviey> smb, sorry for being vague.. unity crashed and i missed your response
[10:58] <Daviey> smb, the scrollback looked like kees just raised it to JFo's attention
[10:59] <Daviey> Another question.. Would someone on the kernel team mind commenting on the patch attached to bug 722185 please? :)
[11:30] <Daviey> Also, bug 707003 (sorry for flooding you chaps)
[11:36] <aakshay> while running driver (module), the kernel messages are not passing to /var/log/messages. please help
[11:39] <ogra_> diwic, poke
[11:40] <diwic> ogra_, peek
[11:40] <ogra_> diwic, do you have an opinion about bug 746023 ? i see you discussed it on the pulse ML
[11:41] <ogra_> hmm, no bugbot ?
[11:41] <ogra_> https://bugs.launchpad.net/ubuntu/+source/alsa-lib/+bug/746023
[11:42] <ogra_> indeed we would love to have that patchset in before release, but i dont know the code enough to judge the impact on other platforms than UCM based ones
[11:42] <diwic> ogra_, in terms of stability and risk, I prefer not applying them...
[11:42] <ogra_> do you think they could impact anything beyond UCM ?
[11:42] <ogra_> (the only thing i see there is the udev changes)
[11:46] <aakshay> fairuz, where the kernel messages are stored? 
[11:47] <diwic> ogra_, so if we decide to apply them - have we tested them? How can we ensure stability of these patches?
[11:47] <ogra_> diwic, do you think they would affect anything outside of UCM 
[11:47] <ogra_> they have been tested by TI as i understand and only omap4 makes use of UCM atm
[11:47] <ogra_> my worry is the impact on non UCM stuff that i cant really judge
[11:48] <ogra_> (tested by TI indeed means tested on omap4 only)
[11:48] <diwic> ogra_, as I understand it udev-detect would load module-alsa-jack-detect as well
[11:48] <ogra_> right
[11:51] <diwic> ogra_, so bring me up a little, what's the minimum we can apply this to if we have to?
[11:52] <diwic> ogra_, I mean, can we ifdef the udev changes to the ARM image e g
[11:52] <ogra_> ah, yeah, thats would be an option ... 
[11:52] <ogra_> we could ifdef the world indeed ;)
[11:54] <diwic> ogra_, w
[11:55] <diwic> ogra_, how many images do we have and do we need this on all of them?
[11:55] <ogra_> we wouldnt do that image based but arch based 
[11:55] <ogra_> (since ifdef will only work at build time)
[11:56] <ogra_> we currently sopport two arm subarches (omap and omap4) but linaro uses our packages for their images too and they have a lot more subarches
[11:58] <fairuz> aakshay: dmesg | tail
[11:58] <fairuz> or tail /var/log/messages
[11:59] <aakshay> fairuz, thanks.. but can i take your minute please.. 
[12:00] <fairuz> aakshay: I have a meeting soon, but just ask
[12:00] <aakshay> fairuz, in the code i wrote yesterday, the module_init and exit are being called simultaneously.
[12:00] <fairuz> aakshay: module_init is called when you do insmod
[12:01] <aakshay> fairuz, the printk message is "<1>Inserting memory moduleRemoving the memory module
[12:01] <aakshay> "
[12:01] <ogra_> diwic, would you mind commenting on the bug ? i have to present it to the release team and possibly also ask TI for changes (before beta2)
[12:01] <fairuz> while module_exit is called when you do rmmod
[12:01] <diwic> ogra_, hmm
[12:01] <aakshay> fairuz, yes but when i do insmod, this output is given "<1>Inserting memory moduleRemoving the memory module
[12:01] <aakshay> "
[12:01] <diwic> ogra_, what would you like me to write? 
[12:01] <fairuz> aakshay: Check your code 
[12:01] <ogra_> heh, your opinion on the possible impact if we apply them
[12:02] <aakshay> fairuz, ok.. i am checking it. will back to you.. :p
[12:02] <aakshay> thanks
[12:02] <aakshay> :)
[12:03] <ogra_> diwic, luke just asks for adding the right FFe's, i would like some statements about the code and possible impact
[12:04] <diwic> ogra_, I talked to him this morning and he too was concerned about the size (as in the broader meaning of size) of the patches 
[12:04] <diwic> ogra_, and I told him to ping you about it :-)
[12:04] <ogra_> he didnt say that oj the bug nor in the ping he left for me on IRC
[12:04] <ogra_> *on
[12:05] <diwic> ogra_, do you have hardware you can test on?
[12:05] <ogra_> "Could you please action bug 746023? A lot of these patches introduce new functionality, and IMO need an FFE. Thanks."
[12:05] <ogra_> trhats what i had 
[12:05] <ogra_> yes, the arm team as well as the linaro team have panda boatds
[12:05] <ogra_> *boards
[12:06] <ogra_> testing on the target platform isnt an issue (and i also tend to belive it works okayish if TI tells me they tested, my main concern is teh impact on non TI HW) 
[12:06] <diwic> ogra_, so can you be specific about what we need to bring in? Comment #4 is contradictory to comment #5.
[12:07] <ogra_> well TI wants all of them indeed, i dont know if we can get away with less
[12:07]  * diwic would love to have an Ubuntu that works a little better than okayish :-/
[12:07] <ogra_> okayish on the panda wrt sound would be much more than we released on maverick 
[12:08] <ogra_> (due to the same issue btw, the TI alsa patches came to late)
[12:08] <ogra_> in maverick there is no sound at all on omap4 in the release image and only partial fixes in maverick-updates
[12:09] <ogra_> so having it working "okayish" on omap4 while not breaking the rest of the world is acceptable for me atm
[12:09] <ogra_> the rest of the world bit is what i'm concerned about
[12:09] <ogra_> and what i cant judge as a non asla guy
[12:09] <ogra_> *alsa
[12:11] <diwic> ogra_, the patches in the tarball are similar but not identical to those posted on the ML - that's why I ask which one is the one to apply
[12:11] <ogra_> ah
[12:11] <diwic> ogra_, they are overlapping
[12:11] <ogra_> well, we would take the tarball ones 
[12:12] <ogra_> i thought they are the same given alejandros comment
[13:00] <smb> Daviey, Patch in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/722185 looks ok imo but seems to need to get upstreamed properly.
[13:00] <smb> Daviey, https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/707003 ppisati looks like being on that one
[13:01] <Daviey> smb, thanks!
[13:01] <Daviey> smb, would you mind commenting on the former please?
[13:01] <smb> Daviey, about to do
[13:02] <Daviey> I assumed you have pre-canned responses for situations like this :)
[13:02] <Daviey> thanks
[13:02] <smb> Daviey, Nah, that would be far to effective
[13:04] <Daviey> smb, lol
[13:23] <TeTeT> if I want to package a binary module, how do I best get it into the kernel's dependency tree - simply call depmod -a from postinst, or is there a better way?
[13:25] <smb> TeTeT, The best way would be to have at least some parts that can be public, and then to make a dkms package. Well actually the best way would be not to have a binary only module to package...
[13:35] <TeTeT> smb: problem is the vendor only distributes a binary module. Right now it is copied into /lib/modules. I at least want to package it, this motivates my question on how to best add it to the module dependencies. I completely agree with your assessment though
[13:39] <smb> TeTeT, For depmod you probably want to use one of its options to limit it to the running kernel (or the one into which /lib/module path you install). That from a postinst should be ok. Good luck with the rabbit (abi) chase, though. But I guess you are aware of that joy
[13:40] <TeTeT> smb: yeah, the customer won't install every Lucid kernel for sure
[13:43] <smb> TeTeT, Its more a courtesy thing. depmod -a updates all the dependencies for all currently installed kernels. But your package would only add to one version, so one does not want to unnecessarily update stuff that has not changed.
[13:44] <smb> TeTeT, Actually reading the man page again, I am wrong
[13:45] <smb> TeTeT, So depmod -a is actually ok
[13:46] <smb> if you install for the current kernel, otherwise depmod -a <version>
[13:47] <TeTeT> smb: so it would be depmod -a <version>, as during install time most likely the kernel is not correct
[13:48] <smb> TeTeT, Yes, sounds like the safer bet
[13:52] <smb> tgardner, ogasawara I am likely #99 but just as a note that this is going round as a Natty regression https://bugs.launchpad.net/ubuntu/+source/linux/+bug/731878. Following the latest thread reference it does not seem to be resolved yet upstream.
[13:57] <tgardner> smb, what do you mean you are #99 ?
[13:57] <smb> tgardner, Assuming I am not the first one to tell you but #99 (iow people are already chasing you)
[13:58] <smb> ITs just a random number that came to my mind
[13:58] <tgardner> smb, oh, you are the 99'th person to hassle me about this. I get it.
[13:59] <smb> tgardner, Yeah, sorry I guess my humor does not translate that well atm. Guess I need apw back to give me more training. :)
[13:59] <tgardner> smb, we all miss him :)
[14:00] <smb> After nearly two weeks in Scottland we'll have to find out whether *we* still understand him. :-P
[14:04] <ogasawara> smb: yep thanks, it's top of my list to dig into this morning
[14:06] <smb> ogasawara, Cool. :) As far as I understood the mail thread someone recently added to the bug upstreams answer seems to be a sort of: "WTF, what are you doing?"
=== sconklin-gone is now known as sconklin
[14:44] <tgardner> ogasawara, re: bug #731878. perhaps we should produce a test kernel with c191a836a908d1dd6b40c503741f91b914de3348 reverted to make sure that is the root of the issue. the upstream discussion seems to have ground to a halt.
[14:45] <ogasawara> tgardner: we must be on the same page, that's exactly what I'm doin right now
[14:45] <tgardner> ogasawara, cool
[14:46] <tgardner> ogasawara, you should assign someone the bug in order to let the world at large know we are paying attention.
[14:46] <ogasawara> tgardner: I'll assign myself to it
=== doko_ is now known as doko
[15:33] <JFo> ogasawara, did you see my ping about bug 731878?
[15:34] <ogasawara> JFo: yep, already posted a comment to the bug
[15:34] <JFo> or whomever can look for that matter
[15:34] <JFo> ok cool
[15:34] <JFo> should have refreshed it :)
[15:35] <JFo> and now that I read back a bit I see smb was discussing it... le sigh
[15:36] <smb> JFo, So many things going on while one does not look.
[15:36] <JFo> smb, true
[15:36] <JFo> to many in some cases :)
[15:37] <JFo> rather too*
[15:37] <JFo> would someone mind taking a look at bug 712625?
[15:37] <smb> Indeed. Sometimes I am scared to log back into irc. Too much info crushing down
[15:37] <JFo> Dustin assigned it to me, but I missed it somehow
[15:38] <JFo> smb, a description of my daily life
[15:38]  * kirkland waves at JFo 
[15:38] <JFo> that is why there are times when I just don't look at it
[15:38] <JFo> hi kirkland :) sorry about neglecting this bug
[15:40] <ogasawara> kirkland: do you by chance know between which two specific natty kernel versions the regression appeared?
[15:53] <tseliot> smb: hi, do you know who I can ping about wifi driver issues?
[15:53] <smb> tseliot, I usually try tgardner ... ;-P
[15:54] <tseliot> smb: thanks
[15:59] <ogasawara> kirkland: and I assume this still remains even with the latest 2.6.38-8.41 kernel?
[16:01] <kirkland> ogasawara: let me check, i've been afraid to try for weeks and weeks
[16:03] <kirkland> ogasawara: \o/  doesn't appear to still be valid
[16:03] <kirkland> ogasawara: i'll mark fix-released
[16:03] <ogasawara> kirkland: sweet
[16:04] <bjf> ogasawara, good job, looks like you deserve a beer :-)
[16:04] <ogasawara> woot!
=== robbiew1 is now known as robbiew
[16:22] <JFo> ogasawara, kirkland sorry I let that one sit for so long :-/ I should have seen it.
=== herton is now known as herton_lunch
[17:14] <ogasawara> tgardner: it's like you're reading my mind today
[17:16] <tgardner> ogasawara, hmm, thats a bit disturbing, isn't it :)
[17:16] <ogasawara> hehe
[17:17] <tgardner> I assume you refer to reverting that socket patch?
[17:17] <ogasawara> tgardner: yep
[17:17] <ogasawara> tgardner: you wrote exactly what I was planning to do
=== diwic is now known as diwic_afk
[17:18] <tgardner> ogasawara, good. at least I'm not out in left field.
[17:19] <ogasawara> I might was well revert it in master-next for now, just so we don't forget
[17:19] <tgardner> yep
[17:57] <tgardner> bjf, what kind of BW do you get from zinc over your FIOS connection? I've tried 2 different providers, the best I'm getting on a clone is 200 KiB/s
[17:58] <bjf> tgardner, how are you testing ?
[17:58] <bjf> tgardner, i'll do the same here so you can compare
[17:58] <tgardner> bjf, just doing a repo fetch
[18:01] <bjf> tgardner 650728.93 bytes/sec   that was an rsync
[18:01] <tgardner> bjf, that seems reasonable.
[18:02] <tgardner> bjf, I'm using a GNet server with a 35 Mbps connection and am getting 100KB/s. Bresnan shows similar. Its starting to harsh my buzz.
[18:03] <bjf> tgardner, heh, i can understand that
=== herton_lunch is now known as herton
=== sforshee is now known as sforshee-lunch
[18:10] <JFo> <-lunch
[18:20] <Sarvatt> tgardner: 1.36M/s on a server in NY with a 100mbps connection
[18:22] <tgardner> Sarvatt, must be some common segment between Bresnan and 360Net thats causing the slowdown.
=== diwic_afk is now known as diwic
=== sforshee-lunch is now known as sforshee
[19:09]  * tgardner --> lunch
[19:21]  * jjohansen1 -> lunch
[19:50] <ogasawara> tgardner: bug 745947, are you planning to change CONFIG_FB_VESA back to =y for the server flavour? Or just release note it?  or wait and discuss with apw when he gets back?
[19:52] <tgardner> ogasawara, cjwatson argues that its a debian-installer bug, so I put the ball back in his court
[19:52] <ogasawara> tgardner: ok cool, then I'll leave it be
[19:52] <tgardner> ogasawara, https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/745947/comments/29
[19:53] <ogasawara> bah, foiled by not refreshing the bug
=== timblechmann is now known as tim
[20:07] <tgardner> bjf, whats left before karmic  2.6.31-23.75 gets promoted to -updates ?
[20:07] <bjf> tgardner, let me look
[20:09] <bjf> tgardner, there is nothing from the cert./qa team about testing
[20:09] <tgardner> bjf, are they gonna test either karmic or dapper?
[20:09] <bjf> tgardner, yes, they have committed to testing all supported series
[20:10] <bjf> tgardner, and they have done so the past couple of cycles
[20:10] <tgardner> bjf, ok. I was just reviewing all the LP bugs I have open. many of them will close when these kernels get promoted.
=== hggdh_ is now known as hggdh
[20:21] <JFo> ogasawara, it is good to know that I wasn't the only one affected by that today :)
[20:23] <ogasawara> JFo: just prepping for the release meeting tomorrow, how are your bug handling work items coming?
[20:23] <JFo> not bad, but not as fast as I'd hoped
[20:24] <ogasawara> JFo: still think you'll be able to close them out by release?
[20:24] <JFo> should do, I don't see why not. The only thing that keeps hanging me is being distracted by crazy bugs, but that is my fault
=== sconklin is now known as sconklin-gone