[00:04] Has anyone run into the bug with realtech nic cards where they lose inbound traffic when under load? [00:06] 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. === jk__ is now known as jk- === panda is now known as Guest38046 [07:54] * apw yawns [07:54] hey apw [07:55] jk-, morning [07:55] apw: fairly early there, no? [07:55] jk-, just before 8 yeah [07:56] hi, is natty not supposed to provide an automatic upgrade form 2.6.39 to 3.0? [07:56] oops, I meant oneiric [07:57] micahg, yes it will once we are sure we've gotten all the issues sorted out [07:57] like it renedering your whole machine unupgradable [07:58] ah, ok :), just wanted to make sure it was known and not an oversight, thanks! [07:58] 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] k, great, will leave you people to work now :) [08:48] morning ppisati [08:53] apw: morning [08:55] ppisati, how goes the CVE for arm slog? [08:56] (slog == slow never ending horrible) [08:59] apw: i took a break, i think we have enough kernels to test for now :) [08:59] that is for sure [08:59] they must hate you in #u-arm [08:59] apw: never said it, but i think so :) [09:14] cking, morning [09:36] apw, hiya [09:36] cking, how ya doing [09:38] 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] woh, how much [09:39] ..replacement gearbox and possibly replacement clutch = 4 figure sum === cjwatson_ is now known as cjwatson [09:40] cking, oww [09:41] 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] cking, hard decision indeed [09:41] sell one of your kids, that'll offset it [09:42] 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] 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] 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] apw: Ah, understood. -- Thank you very much for your help. [10:43] who posts to the kernel team blog? [10:43] or rather who among the people posting to kernel team blog are ubuntu members :-) [11:04] nigelb, i would think that everyone who posts to the kernel team blog (on voices yes) is an ubuntu member, why ? [11:05] apw: http://nigelb.me/ubuntu/2011/06/10/cleaning-up-the-planet.html [11:06] nigelb, are we needing to have an owner for it then? [11:07] apw: yes [11:08] apw: Just an Ubuntu member to own the feed [11:08] nigelb, well i guess either pgraner, tim or myself are the obvious choices [11:08] apw: whats your Launchpad ID? I'll put your ID in :-) [11:09] nigelb, apw [11:09] 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] yay, regression in lucid-proposed kills intel wifi :/. bug 796336 [11:14] Launchpad bug 796336 in linux "2.6.32-33-generic iwlagn firmware broken" [Undecided,Confirmed] https://launchpad.net/bugs/796336 [11:14] and it seems to be a stupid one-liner that tgardner had doubts about months ago [11:16] jwi, could be, i've retagged it appropriatly [11:17] 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] so commit "iwlagn: Support new 5000 microcode." turns into "break 5000 stuff in funny ways" [11:18] and what was the one liner that rtg wasn't happy with ? [11:18] that commit [11:19] see https://lkml.org/lkml/2011/4/27/416 [11:21] (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] jwi, having read all that i am unsure why this would even affect lucid [11:24] jwi, we have the old firmware still [11:24] and the old driver shouldn't even see the new one [11:24] apw: ah, thats because iwlagn is broken in multiple ways :) [11:24] jwi, and they are [11:25] 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] so thats why falling back to the older firmware files doesnt work - this should be fixed for maverick+, too [11:26] ok so could you document that in the bug, that'd make things easier [11:28] sounds like the new firmware is a mistake in lucid given all this, hmm [11:28] right, i was hoping to get some confirmation first from intel on whether that firmware actually *has* the new format [11:28] nope, the firmware is fine. it's the driver that shouldnt claim to support it - because it doesnt [11:29] jwi, but then as the driver doesn't support it one could argue that its pointless having it on the machine [11:29] compat-wireless... [11:29] which if it needs it should carry the firmware there and avoid the mai [11:29] main kernel modules seeing it [11:30] definitely - but i don't think that's the standard procedure for compat-wireless? [11:31] 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] apw: hm, see tgardner's #2 in bug 653854 (which is currently sitting in lucid-proposed). [11:33] 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] 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] be good to confirm it is a format issue, we may be able to short circuit the load in lucid kernel [11:35] as an expedient fix [11:55] 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] jwi, sounds good thanks, will slap people when they wake up [12:12] 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] Breaks on older versions would be more appropriate. [12:14] although, actually, I don't see why you need to bother [12:14] it only breaks when you try to upgrade libc to a newer version after rebooting to the new kernel [12:14] 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] 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] 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] you'll need to think about it for backports to lucid, but maybe by then it will be 3.0.x anyway [12:16] yeah i suspect so [12:24] dunno if it's more pain to compile a kernel on a panda board, or roll your own cross toolchain [12:25] ppisati: why do you need to do either? [12:26] amitk: trying to see if i can reproduce a problem we have with latest linaro toolchain [12:27] 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] amitk: doing both of them [12:28] amitk: and somehow my panda doesn't like my usb disk [12:28] amitk: i hopne it's not the disk that is failing [12:55] apw, do you have a moment? [13:02] diwic, yep, wassup [13:03] 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] ok how does it fail ? [13:03] cherry-pick yes [13:04] -s to sign, and -x for the upstream reference in the pick [13:04] let me pastebin it for you [13:04] ack [13:04] http://pastebin.canonical.com/48405 [13:05] diwic, so there are conflicts it seems? [13:06] diwic, which tree are you in ? [13:06] that by its name would be an upstream tree no ? [13:06] apw, linux-2.6 [13:06] apw, but feel free to suggest another one if you think that's more appropriate [13:06] i'd be expecting you to do the cherry-pick in the one you want to apply it to ? [13:07] apw, for reference, here's his message: https://lists.ubuntu.com/archives/kernel-team/2011-May/015710.html [13:08] so i assume you made all three originally with a git format-patch -3 sort of thing [13:08] apw, sort of [13:08] he is suggestng you are missing the s-o-b and (cherry picked from xxxxx) lines in the first two [13:09] and the easiest way to get those is just to cherry-pick the patch [13:09] which you do in the destination branch [13:09] so I must first apply them there and *then* cherry-pick them, right? [13:10] and I apply them with git am? [13:11] 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] you can simply checkout the destaination brnach and git cherry-pick them into it [13:11] the cherry-pick finds extracts and applied them in one motion [13:12] so cherry-pick moves them between two branches in a repo [13:12] but isn't this two different repos, one linux-2.6 and one ubuntu-natty repo? [13:13] 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] hrm [13:17] 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] or should I clone with reference there as well? [13:18] I have the same reference btw [13:23] 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] diwic, you can safely clone with reference therre as well [13:32] and yep after the cherry-pick you would format-patch as normal [13:59] sforshee, hey ... morning [13:59] apw, hi [13:59] sforshee, i think you were involved in the linux-firmware updates for 'all releases' ? [13:59] seems we have a regression due to the iwlagn firmware on lucid-proposed [14:00] https://launchpad.net/bugs/796336 [14:00] Ubuntu bug 796336 in linux "2.6.32-33-generic iwlagn firmware broken" [Undecided,Triaged] [14:00] apw, I thought the only thing that was updated was ralink firmware [14:01] 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] 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] how do i request a pocket copy? [14:07] linux-fsl-imx51 2.6.31-609.26 from c-k-t ppa [14:07] i guess an email it's enough [14:12] apw: its about the kernel thats in -proposed, not linux-firmware. the api-5 ucode was moved to -updates back in april ... [14:13] sforshee, down't worry about that issue, i'll look at it, seems its not at all what i thought originally [14:14] apw, ack [14:20] 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] 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] Launchpad bug 793437 in linux "Unusable Slowness In 2.6.38-8" [Undecided,Confirmed] https://launchpad.net/bugs/793437 [14:31] chadhogg, my best guess would be https://wiki.ubuntu.com/Kernel/KernelBisection [14:31] chadhogg, using maverick and a Natty kernel on top of that could also be interesting b [14:31] perhaps [14:33] 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] ogasawara, i am liking [Acked] [15:07] apw: I am too [15:07] i shall take that on [15:31] bjf: you're in london tomorrow right? [15:32] bjf: I was gonna get the IRC meeting notes prepped [15:33] ogasawara: i'm there now [15:33] ogasawara: i could probably run it from here [15:34] ogasawara: you want a copy of my runes? [15:34] bjf: sure, just in case. [15:34] bjf: so I'll let you handle it tomorrow but I'll be on standby [15:37] ogasawara: wfm, runes sent [15:37] bjf: thanks [15:58] 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] Launchpad bug 796336 in linux "2.6.32-33-generic iwlagn firmware broken" [Undecided,Triaged] https://launchpad.net/bugs/796336 [15:59] 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] sconklin1, updates kernel for lucid [16:00] yep, got it [16:00] well we've never tested so well either [16:00] so ... its hard to be sure how much is new and how much is normal [16:00] fair point [16:01] 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] s/real/read [16:02] I'll investigate === sconklin1 is now known as sconklin [16:04] * ogasawara back in 20 [17:29] * ppisati -> gym [19:50] * jjohansen -> lunch === yofel_ is now known as yofel === PascalFR is now known as boxershort [22:04] 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 === bryceh is now known as bryce === bryce is now known as bryceh === bryceh is now known as bryce