[00:04] <quentusrex_> Has anyone run into the bug with realtech nic cards where they lose inbound traffic when under load?
[00:06] <quentusrex_> I have reproduced the issue with 3 different realtech nics and when the CPU has less than 50% idle I get over 10% loss of all udp traffic.
[07:54]  * apw yawns
[07:54] <jk-> hey apw
[07:55] <apw> jk-, morning
[07:55] <jk-> apw: fairly early there, no?
[07:55] <apw> jk-, just  before 8 yeah
[07:56] <micahg> hi, is natty not supposed to provide an automatic upgrade form 2.6.39 to 3.0?
[07:56] <micahg> oops, I meant oneiric
[07:57] <apw> micahg, yes it will once we are sure we've gotten all the issues sorted out
[07:57] <apw> like it renedering your whole machine unupgradable
[07:58] <micahg> ah, ok :), just wanted to make sure it was known and not an oversight, thanks!
[07:58] <apw> micahg, yes its known, the kernel packages are in but not the meta for the moment, while we confirm that the required fixes are out
[07:59] <micahg> k, great, will leave you people to work now :)
[08:48] <apw> morning ppisati 
[08:53] <ppisati> apw: morning
[08:55] <apw> ppisati, how goes the CVE for arm slog?  
[08:56] <apw> (slog == slow never ending horrible)
[08:59] <ppisati> apw: i took a break, i think we have enough kernels to test for now :)
[08:59] <apw> that is for sure
[08:59] <apw> they must hate you in #u-arm
[08:59] <ppisati> apw: never said it, but i think so :)
[09:14] <apw> cking, morning
[09:36] <cking> apw, hiya
[09:36] <apw> cking, how ya doing
[09:38] <cking> not so bad -  however I've just had to pick myself up from the floor after hearing the cost of fixing my poorly car
[09:38] <apw> woh, how much
[09:39] <cking> ..replacement gearbox and possibly replacement clutch = 4 figure sum
[09:40] <apw> cking, oww
[09:41] <cking> the car is worth about the same amount, but to replace it will cost a load more, so I think it's worth it for another 3-4 years on the road
[09:41] <apw> cking, hard decision indeed
[09:41] <apw> sell one of your kids, that'll offset it
[09:42] <cking> heh, I have to pay for somebody to take them off me ;-).  Considering how much one pays for tax and insurance, it's not that much over 3 years.
[09:43]  * cking punches mumble into submission
[09:50] <bullgard4> System Monitor > Processes > tab "Waiting Channel": What is a »waiting channel«? I found: "The address of an event on which the process is waiting”. This definition seems to be poor as I hardly would call for example a poll_schedule-timeout an "address". Can you give a better definition?
[09:56] <apw> bullgard4, well that string is the name in the symbol table for that address, so it is literally an address, sometimes symbolically represented
[09:59] <bullgard4> apw: Ah, understood. --  Thank you very much for your help.
[10:43] <nigelb> who posts to the kernel team blog?
[10:43] <nigelb> or rather who among the people posting to kernel team blog are ubuntu members :-)
[11:04] <apw> nigelb, i would think that everyone who posts to the kernel team blog (on voices yes) is an ubuntu member, why ?
[11:05] <nigelb> apw: http://nigelb.me/ubuntu/2011/06/10/cleaning-up-the-planet.html
[11:06] <apw> nigelb, are we needing to have an owner for it then?
[11:07] <nigelb> apw: yes
[11:08] <nigelb> apw: Just an Ubuntu member to own the feed
[11:08] <apw> nigelb, well i guess either pgraner, tim or myself are the obvious choices
[11:08] <nigelb> apw: whats your Launchpad ID? I'll put your ID in :-)
[11:09] <apw> nigelb, apw
[11:09] <nigelb> apw: heh, after you guys kicked pgraner to QA, he's not obvious choice anymore :-P
[11:09]  * nigelb hides
[11:10]  * apw gets hit boxing gloves on
[11:14] <jwi> yay, regression in lucid-proposed kills intel wifi :/. bug 796336
[11:14] <ubot2> Launchpad bug 796336 in linux "2.6.32-33-generic iwlagn firmware broken" [Undecided,Confirmed] https://launchpad.net/bugs/796336
[11:14] <jwi> and it seems to be a stupid one-liner that tgardner had doubts about months ago
[11:16] <apw> jwi, could be, i've retagged it appropriatly
[11:17] <jwi> i'm pretty sure it is - from reading the code, lucid just doesn't have the code to handle the new firmware file format
[11:17] <jwi> so commit "iwlagn: Support new 5000 microcode." turns into "break 5000 stuff in funny ways"
[11:18] <apw> and what was the one liner that rtg wasn't happy with ?
[11:18] <jwi> that commit
[11:19] <jwi> see https://lkml.org/lkml/2011/4/27/416
[11:21] <jwi> (and yes, it's in maverick-proposed too. that shouldn't break though, the maverick stack seems to be capable of handling the new format)
[11:24] <apw> jwi, having read all that i am unsure why this would even affect lucid
[11:24] <apw> jwi, we have the old firmware still
[11:24] <apw> and the old driver shouldn't even see the new one
[11:24] <jwi> apw: ah, thats because iwlagn is broken in multiple ways :)
[11:24] <apw> jwi, and they are
[11:25] <jwi> it reads the api version from the firmware header - and with new firmware format, that version is 0 (which is < API_MIN = 1). now, instead of trying the other available firmware files, it just quits.
[11:26] <jwi> so thats why falling back to the older firmware files doesnt work - this should be fixed for maverick+, too
[11:26] <apw> ok so could you document that in the bug, that'd make things easier
[11:28] <apw> sounds like the new firmware is a mistake in lucid given all this, hmm
[11:28] <jwi> right, i was hoping to get some confirmation first from intel on whether that firmware actually *has* the new format
[11:28] <jwi> nope, the firmware is fine. it's the driver that shouldnt claim to support it - because it doesnt
[11:29] <apw> jwi, but then as the driver doesn't support it one could argue that its pointless having it on the machine
[11:29] <jwi> compat-wireless...
[11:29] <apw> which if it needs it should carry the firmware there and avoid the mai
[11:29] <apw> main kernel modules seeing it
[11:30] <jwi> definitely - but i don't think that's the standard procedure for compat-wireless?
[11:31] <apw> hmm pretty sure its meant to carry its own firmware, and even has hacks to rename them to ensure non-overlap (the ubuntu packaging thereof)
[11:33] <jwi> apw: hm, see tgardner's #2 in bug 653854 (which is currently sitting in lucid-proposed).
[11:33] <ubot2> Launchpad bug 653854 in linux-firmware "Oct 3 06:01:05 bt kernel: usb 1-7: ath9k_htc: Firmware - ar9271.fw not found Oct 3 06:01:05 bt kernel: ath9k_hif_usb: probe of 1-7:1.0 failed with error -22" [Low,Fix committed] https://launchpad.net/bugs/653854
[11:34] <apw> jwi, i think we've tended to do that as now we have more than one lbm and we'd have to put the firmware in them all if its not compatible
[11:35] <apw> be good to confirm it is a format issue, we may be able to short circuit the load in lucid kernel
[11:35] <apw> as an expedient fix
[11:55] <jwi> apw: alright, poured my guesstimates into the report. i'll follow up if there's any further info from intel, but i'm pretty sure that this is what's going on
[11:55] <apw> jwi, sounds good thanks, will slap people when they wake up
[12:12] <apw> cjwatson, i am thinking that the 3.0 kernel should have an install dependancy on the libc changes you made, given how hard it was for me to get out of the mess, i therefore plan to add those and re-upload before shipping linux-meta ... am i making sense
[12:13] <cjwatson> Breaks on older versions would be more appropriate.
[12:14] <cjwatson> although, actually, I don't see why you need to bother
[12:14] <cjwatson> it only breaks when you try to upgrade libc to a newer version after rebooting to the new kernel
[12:14] <cjwatson> anyone upgrading libc to a newer version at this point is almost certainly going to be upgrading to a version with my fix anyway
[12:15] <cjwatson> so I would just ignore it if I were you
[12:15]  * apw thinks about that ... thats a fair point, so perhaps i will ignore it, thanks
[12:15] <cjwatson> and it won't affect dist-upgrades from older releases since they're unlikely to reboot between upgrading the kernel and upgrading libc (even if the upgrade were somehow to an unfixed version)
[12:15] <cjwatson> you'll need to think about it for backports to lucid, but maybe by then it will be 3.0.x anyway
[12:16] <apw> yeah i suspect so
[12:24] <ppisati> dunno if it's more pain to compile a kernel on a panda board, or roll your own cross toolchain
[12:25] <amitk> ppisati: why do you need to do either?
[12:26] <ppisati> amitk: trying to see if i can reproduce a problem we have with latest linaro toolchain
[12:27] <amitk> ppisati: aah, in that case it is probably easier to native compile the kernel on panda if you have a usb disk connected
[12:28] <ppisati> amitk: doing both of them
[12:28] <ppisati> amitk: and somehow my panda doesn't like my usb disk
[12:28] <ppisati> amitk: i hopne it's not the disk that is failing
[12:55] <diwic> apw, do you have a moment?
[13:02] <apw> diwic, yep, wassup
[13:03] <diwic> apw, I'm trying to follow rtg's instructions but I fail. There is an email ~ 2 weeks back about that I should use "git cherrypick -s -x" but it seems to fail
[13:03] <apw> ok how does it fail ?
[13:03] <apw> cherry-pick yes 
[13:04] <apw> -s to sign, and -x for the upstream reference in the pick
[13:04] <diwic> let me pastebin it for you
[13:04] <apw> ack
[13:04] <diwic> http://pastebin.canonical.com/48405
[13:05] <apw> diwic, so there are conflicts it seems?
[13:06] <apw> diwic, which tree are you in ?
[13:06] <apw> that by its name would be an upstream tree no ?
[13:06] <diwic> apw, linux-2.6
[13:06] <diwic> apw, but feel free to suggest another one if you think that's more appropriate
[13:06] <apw> i'd be expecting you to do the cherry-pick in the one you want to apply it to ?
[13:07] <diwic> apw, for reference, here's his message: https://lists.ubuntu.com/archives/kernel-team/2011-May/015710.html
[13:08] <apw> so i assume you made all three originally with a git format-patch -3 sort of thing
[13:08] <diwic> apw, sort of
[13:08] <apw> he is suggestng you are missing the s-o-b and (cherry picked from xxxxx) lines in the first two
[13:09] <apw> and the easiest way to get those is just to cherry-pick the patch
[13:09] <apw> which you do in the destination branch
[13:09] <diwic> so I must first apply them there and *then* cherry-pick them, right?
[13:10] <diwic> and I apply them with git am?
[13:11] <apw> normally these are upstream commits we want to cherry-pick and as long as you have some remote with them applied in the current repo
[13:11] <apw> you can simply checkout the destaination brnach and git cherry-pick them into it
[13:11] <apw> the cherry-pick finds extracts and applied them in one motion
[13:12] <diwic> so cherry-pick moves them between two branches in a repo
[13:12] <diwic> but isn't this two different repos, one linux-2.6 and one ubuntu-natty repo?
[13:13] <apw> well normally for me at least the former is the --reference'd repo in the latter, and so all of its sha1s are available in ubuntu-natty
[13:16] <diwic> hrm
[13:17] <diwic> but I don't want to change my ubuntu-natty (I want it to track the one on kernel.ubuntu.com), so I start off by cloning it
[13:17] <diwic> or should I clone with reference there as well?
[13:18] <diwic> I have the same reference btw
[13:23] <diwic> and suppose I actually succeed with making these cherry-picks, should I then use format-patch to be able to send them to the list?
[13:32] <apw> diwic, you can safely clone with reference therre as well
[13:32] <apw> and yep after the cherry-pick you would format-patch as normal
[13:59] <apw> sforshee, hey ... morning
[13:59] <sforshee> apw, hi
[13:59] <apw> sforshee, i think you were involved in the linux-firmware updates for 'all releases' ?
[13:59] <apw> seems we have a regression due to the iwlagn firmware on lucid-proposed
[14:00] <apw> https://launchpad.net/bugs/796336
[14:00] <ubot2> Ubuntu bug 796336 in linux "2.6.32-33-generic iwlagn firmware broken" [Undecided,Triaged]
[14:00] <sforshee> apw, I thought the only thing that was updated was ralink firmware
[14:01] <apw> sforshee, the rumour is that it contains also iwlagn abi#5 firmware ... perhaps you could investiate and work out what the reality it ... believe nothing i have said as its all rumours
[14:01] <apw> but that bug is enough to prevent linux-firmware being promoted to -updates till we have it resolved one way or the other
[14:06] <ppisati> how do i request a pocket copy?
[14:07] <ppisati> linux-fsl-imx51 2.6.31-609.26 from c-k-t ppa
[14:07] <ppisati> i guess an email it's enough
[14:12] <jwi> apw: its about the kernel thats in -proposed, not linux-firmware. the api-5 ucode was moved to -updates back in april ...
[14:13] <apw> sforshee, down't worry about that issue, i'll look at it, seems its not at all what i thought originally
[14:14] <sforshee> apw, ack
[14:20] <chadhogg> in hopes that there are more eyes here on a Monday morning than a Sunday afternoon I'll repeat my question from yesterday once, but then not bother you again:
[14:20] <chadhogg> I apologize if this is the wrong venue, but I was hoping to get some real-time feedback on what I could do to continue debugging Launchpad bug 793437
[14:21] <ubot2> Launchpad bug 793437 in linux "Unusable Slowness In 2.6.38-8" [Undecided,Confirmed] https://launchpad.net/bugs/793437
[14:31] <diwic> chadhogg, my best guess would be https://wiki.ubuntu.com/Kernel/KernelBisection
[14:31] <diwic> chadhogg, using maverick and a Natty kernel on top of that could also be interesting b
[14:31] <diwic> perhaps
[14:33] <chadhogg> diwic: thanks; that looks complicated, but I'll give it a try
[14:38]  * diwic just sent his activity report to the public kernel-team ML...fortunately there was nothing NDA in it
[15:07] <apw> ogasawara, i am liking [Acked]
[15:07] <ogasawara> apw: I am too
[15:07] <apw> i shall take that on
[15:31] <ogasawara> bjf: you're in london tomorrow right?
[15:32] <ogasawara> bjf: I was gonna get the IRC meeting notes prepped
[15:33] <bjf> ogasawara: i'm there now
[15:33] <bjf> ogasawara: i could probably run it from here
[15:34] <bjf> ogasawara: you want a copy of my runes?
[15:34] <ogasawara> bjf: sure, just in case.
[15:34] <ogasawara> bjf: so I'll let you handle it tomorrow but I'll be on standby
[15:37] <bjf> ogasawara: wfm, runes sent
[15:37] <ogasawara> bjf: thanks
[15:58] <apw> sconklin1, looks like we have an iwl5000 regression in your -updates kernel, see bug #796336, it appears very much that the patch 'iwlagn: Support new 5000 microcode' which we got from stable upstream is completely inappropriate without the new firmware loader support
[15:58] <ubot2> Launchpad bug 796336 in linux "2.6.32-33-generic iwlagn firmware broken" [Undecided,Triaged] https://launchpad.net/bugs/796336
[15:59] <sconklin1> apw: thanks. I'm getting used to this, unfortunately. We have never had so many things broken from stable updates in as long as I can remember . . .
[15:59] <apw> sconklin1, updates kernel for lucid
[16:00] <sconklin1> yep, got it
[16:00] <apw> well we've never tested so well either
[16:00] <apw> so ... its hard to be sure how much is new and how much is normal
[16:00] <sconklin1> fair point
[16:01] <apw> be good if you could confirm that lucid cannot real those files ... i think not given the error and the code, so i think reverting that commit is appropriate and prolly report it to stable too
[16:01] <apw> s/real/read
[16:02] <sconklin1> I'll investigate
[16:04]  * ogasawara back in 20
[17:29]  * ppisati -> gym
[19:50]  * jjohansen -> lunch
[22:04] <sconklin> GrueMaster: I'm setting up the workflow tools to assign ARM testing to your new team. Should this happen for all of the following packages? linux-mvl-dove, linux-fsl-imx51, linux-ti-omap4