| quentusrex_ | Has anyone run into the bug with realtech nic cards where they lose inbound traffic when under load? | 00:04 |
|---|---|---|
| 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. | 00:06 |
| === jk__ is now known as jk- | ||
| === panda is now known as Guest38046 | ||
| * apw yawns | 07:54 | |
| jk- | hey apw | 07:54 |
| apw | jk-, morning | 07:55 |
| jk- | apw: fairly early there, no? | 07:55 |
| apw | jk-, just before 8 yeah | 07:55 |
| 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:56 |
| 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:57 |
| 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:58 |
| micahg | k, great, will leave you people to work now :) | 07:59 |
| apw | morning ppisati | 08:48 |
| ppisati | apw: morning | 08:53 |
| apw | ppisati, how goes the CVE for arm slog? | 08:55 |
| apw | (slog == slow never ending horrible) | 08:56 |
| 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 :) | 08:59 |
| apw | cking, morning | 09:14 |
| cking | apw, hiya | 09:36 |
| apw | cking, how ya doing | 09:36 |
| 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:38 |
| cking | ..replacement gearbox and possibly replacement clutch = 4 figure sum | 09:39 |
| === cjwatson_ is now known as cjwatson | ||
| apw | cking, oww | 09:40 |
| 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:41 |
| 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:42 |
| * cking punches mumble into submission | 09:43 | |
| 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:50 |
| 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:56 |
| bullgard4 | apw: Ah, understood. -- Thank you very much for your help. | 09:59 |
| 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 :-) | 10:43 |
| apw | nigelb, i would think that everyone who posts to the kernel team blog (on voices yes) is an ubuntu member, why ? | 11:04 |
| nigelb | apw: http://nigelb.me/ubuntu/2011/06/10/cleaning-up-the-planet.html | 11:05 |
| apw | nigelb, are we needing to have an owner for it then? | 11:06 |
| nigelb | apw: yes | 11:07 |
| 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:08 |
| 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:09 | |
| * apw gets hit boxing gloves on | 11:10 | |
| 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:14 |
| apw | jwi, could be, i've retagged it appropriatly | 11:16 |
| 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:17 |
| apw | and what was the one liner that rtg wasn't happy with ? | 11:18 |
| jwi | that commit | 11:18 |
| jwi | see https://lkml.org/lkml/2011/4/27/416 | 11:19 |
| 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:21 |
| 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:24 |
| 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:25 |
| 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:26 |
| 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:28 |
| 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:29 |
| jwi | definitely - but i don't think that's the standard procedure for compat-wireless? | 11:30 |
| 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:31 |
| 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:33 |
| 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:34 |
| 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:35 |
| 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 | 11:55 |
| 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:12 |
| cjwatson | Breaks on older versions would be more appropriate. | 12:13 |
| 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:14 |
| 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:15 |
| apw | yeah i suspect so | 12:16 |
| ppisati | dunno if it's more pain to compile a kernel on a panda board, or roll your own cross toolchain | 12:24 |
| amitk | ppisati: why do you need to do either? | 12:25 |
| ppisati | amitk: trying to see if i can reproduce a problem we have with latest linaro toolchain | 12:26 |
| 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:27 |
| 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:28 |
| diwic | apw, do you have a moment? | 12:55 |
| apw | diwic, yep, wassup | 13:02 |
| 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:03 |
| 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:04 |
| apw | diwic, so there are conflicts it seems? | 13:05 |
| 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:06 |
| diwic | apw, for reference, here's his message: https://lists.ubuntu.com/archives/kernel-team/2011-May/015710.html | 13:07 |
| 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:08 |
| 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:09 |
| diwic | and I apply them with git am? | 13:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| diwic | hrm | 13:16 |
| 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:17 |
| diwic | I have the same reference btw | 13:18 |
| 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:23 |
| 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:32 |
| 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 | 13:59 |
| 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:00 |
| 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:01 |
| ppisati | how do i request a pocket copy? | 14:06 |
| 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:07 |
| jwi | apw: its about the kernel thats in -proposed, not linux-firmware. the api-5 ucode was moved to -updates back in april ... | 14:12 |
| apw | sforshee, down't worry about that issue, i'll look at it, seems its not at all what i thought originally | 14:13 |
| sforshee | apw, ack | 14:14 |
| 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:20 |
| ubot2 | Launchpad bug 793437 in linux "Unusable Slowness In 2.6.38-8" [Undecided,Confirmed] https://launchpad.net/bugs/793437 | 14:21 |
| 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:31 |
| chadhogg | diwic: thanks; that looks complicated, but I'll give it a try | 14:33 |
| * diwic just sent his activity report to the public kernel-team ML...fortunately there was nothing NDA in it | 14:38 | |
| apw | ogasawara, i am liking [Acked] | 15:07 |
| ogasawara | apw: I am too | 15:07 |
| apw | i shall take that on | 15:07 |
| ogasawara | bjf: you're in london tomorrow right? | 15:31 |
| ogasawara | bjf: I was gonna get the IRC meeting notes prepped | 15:32 |
| bjf | ogasawara: i'm there now | 15:33 |
| bjf | ogasawara: i could probably run it from here | 15:33 |
| 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:34 |
| bjf | ogasawara: wfm, runes sent | 15:37 |
| ogasawara | bjf: thanks | 15:37 |
| 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:58 |
| 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 | 15:59 |
| 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:00 |
| 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:01 |
| sconklin1 | I'll investigate | 16:02 |
| === sconklin1 is now known as sconklin | ||
| * ogasawara back in 20 | 16:04 | |
| * ppisati -> gym | 17:29 | |
| * jjohansen -> lunch | 19:50 | |
| === yofel_ is now known as yofel | ||
| === PascalFR is now known as boxershort | ||
| 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 | 22:04 |
| === bryceh is now known as bryce | ||
| === bryce is now known as bryceh | ||
| === bryceh is now known as bryce | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!