| === Kiall_ is now known as Kiall | ||
| === bandit5432 is now known as led-bandit | ||
| smb | morning | 07:23 |
|---|---|---|
| ikepanhc | smb: good morning | 07:37 |
| * smb waves to ikepanhc | 07:38 | |
| ikepanhc | smb: usually how long it takes you to review config for new flavour? | 07:38 |
| ikepanhc | smb: I feel I lose lots of hair these two days | 07:38 |
| smb | ikepanhc, I cannot say anything about "usual" as I usually do not add new flavours. But just look at apw who does config reviews a lot... :) | 07:41 |
| apw | ikepanhc, new flavour configs suck, i usually use that scripting we discussed before, make the table and see what all goes purple | 07:47 |
| ikepanhc | apw: lots go purple.... | 07:48 |
| smb | breath! | 07:48 |
| * ikepanhc tries breathing | 07:48 | |
| ikepanhc | apw: btw, how is the policy in that script generated? | 07:50 |
| apw | ikepanhc, i tend to take whole swathes and shove them over othe top. like we know that HID all needs to to match so thats easy | 07:50 |
| ikepanhc | apw: that will be awesome | 07:51 |
| apw | the script implements a policy which is our 'written' policy. we discuss the policy at UDS each year and then apply it, the script just implements my interpretation of those rules | 07:51 |
| ikepanhc | some config, e.g. CONFIG_NET_DSA, policy shows m, but y in all flavour | 07:51 |
| apw | with any exceptions documented | 07:51 |
| apw | ikepanhc, some of those are indeed wrong still, that one we mentioned at uds and determined we wanted it built-in cause it is a network protocol and we have a standing exception for those | 07:52 |
| apw | so that just needs annotating in the tool and i have a WI for that | 07:52 |
| ikepanhc | WI? wiki? | 07:52 |
| apw | WI == work-item on a blueprint | 07:53 |
| apw | ppisati, how does it request it | 09:50 |
| ppisati | [ 2267.022766] soc_bind_dai_link::865 dname: snd-soc-dummy-dai lname:omap-hdmi-audio-dai | 09:51 |
| ppisati | [ 2267.031005] omap-hdmi-audio omap-hdmi-audio: CPU DAI omap-hdmi-audio-dai not registered | 09:52 |
| ppisati | [ 2267.039581] omap-hdmi-audio omap-hdmi-audio: snd_soc_register_card failed (-517) | 09:52 |
| ppisati | [ 2267.047515] platform omap-hdmi-audio: Driver omap-hdmi-audio requests probe deferral | 09:52 |
| ma1 | Hi | 09:58 |
| ma1 | I am using ubuntu 11.10 on pandaboard es with kernel version 3.1.0-1282-omap | 09:59 |
| ma1 | i want to recompile the kernel | 10:00 |
| ma1 | i downloaded the kernel source code using git | 10:00 |
| ma1 | but the problem is the kernel version is different | 10:01 |
| ma1 | the kernel version of downloaded code is 3.0.30 | 10:01 |
| ma1 | but i need 3.1.0-1282-omap | 10:01 |
| ma1 | so, how to get the desired kernel version? | 10:02 |
| ogra_ | you surely dont use a kernel called -omap on the panda (thats for omap3) | 10:02 |
| ogra_ | but rather -omap4 ;) | 10:03 |
| ppisati | and we never released a 3.1.x kernel | 10:03 |
| ppisati | btw | 10:03 |
| ma1 | sorry | 10:03 |
| ma1 | its 3.1.0-1282-omap4 | 10:04 |
| ppisati | is it a debian packaged or a vanilla kernel? | 10:04 |
| ogra_ | yeah, i bet that kernel comes from a PPA | 10:04 |
| ppisati | in the fist case | 10:04 |
| ppisati | fdr debian/rules clean binary-$something | 10:04 |
| ppisati | in the second: | 10:04 |
| ppisati | make $something_defconfig | 10:04 |
| ppisati | make uImage | 10:04 |
| ma1 | ppisati: ogra_: sorry, i didn't understand | 10:05 |
| ma1 | i think the 3.1.0-1282-omap4 came from TI PPA | 10:06 |
| ogra_ | right, so talk to the PPA owners where to find the kernel source ;) | 10:06 |
| ogra_ | the guys in here only maintain kernels that are in the official ubuntu archive | 10:07 |
| ogra_ | the TI PPA kernel is maintained by TI | 10:07 |
| ma1 | ogra_: sorry for disturbance...but i am newbie in this area | 10:07 |
| ma1 | so lots of mistakes on my side | 10:08 |
| ogra_ | yeah, its not easy to understand | 10:08 |
| ogra_ | well, is it a mistake to not understand an overly complex setup ? | 10:08 |
| ogra_ | :) | 10:08 |
| ogra_ | dont worry ;) | 10:08 |
| ma1 | orga_: sorry...i didn't got you? | 10:09 |
| ma1 | ogra_: i will talk to TI PPA owners about the kernel source......can you tell me one thing more??? | 10:09 |
| ogra_ | i said its not a mistake on your side, there are just way to many kernels for omap4 which makes it complex | 10:10 |
| ma1 | oh... | 10:10 |
| ogra_ | (there is the TI PPA kernel, then there is a linaro kernel package as well and there is the official package in the ubuntu archive) | 10:10 |
| ma1 | ogra_: Thanks...just one thing more? | 10:11 |
| ogra_ | shoot | 10:11 |
| * ogra_ will answer if he can :) | 10:11 | |
| ma1 | I want to recompile the kernel for debugging a buggy kernel module? | 10:12 |
| ma1 | any suggestions? | 10:12 |
| ma1 | like what options should i enable? | 10:12 |
| ogra_ | for the official kernel there should be a package with debug symbols builtin ... but i have no idea if TI builds such a package | 10:12 |
| ma1 | as i told you that i am newbie....so really don't know that recompiling a kernel to debug the module is the right way or not? | 10:14 |
| ma1 | what you say? | 10:14 |
| ogra_ | not with official ubuntu kernels, there you can just install a ddeb (debug deb package) | 10:14 |
| ogra_ | these usually have all debugging enabled ... | 10:14 |
| ma1 | hmmmm.... | 10:15 |
| ma1 | so i think it is much better to ask this about TI Kernel guys? | 10:16 |
| ogra_ | ask them if they have a ddeb for their kernel before thinking about recompiling | 10:16 |
| ma1 | hmmm | 10:16 |
| ogra_ | that will save you hours :) | 10:16 |
| ma1 | orga_: Great Great Thanks | 10:17 |
| ma1 | for your time and help | 10:17 |
| ogra_ | np :) | 10:17 |
| * ppisati -> brb | 10:26 | |
| * ppisati -> out to get some food | 10:56 | |
| === yofel_ is now known as yofel | ||
| apw | ogra_, i don't think PPAs buildd ddebs by default | 11:24 |
| ogra_ | apw, no, but i know that TI was looking for a solution for this | 11:24 |
| apw | ogra_, not renaming them to ddeb would work | 11:25 |
| ogra_ | (hosting a ddeb somewhere else or getting an exception for thier PPA etc) | 11:25 |
| cking | bah, overheated again | 11:25 |
| apw | ogra_, there is a special in the kernel to move it to .ddeb in the first place, they could just comment that out | 11:25 |
| ogra_ | well, i'll tell ndec :) | 11:26 |
| ogra_ | they might even have that package already somewhere | 11:26 |
| * cking --> food | 12:00 | |
| apw | bjf[afk], infinity, i have verified that hyper-v patch and updated the bug to indicate that (good) testing | 12:46 |
| * henrix reboots | 12:46 | |
| tgardner | apw, prolly outghta send out an announcement with that ti-omap4 meta package upload ? | 12:51 |
| ogra_ | did you break something ? | 12:52 |
| tgardner | ogra_, its the first Quantal 3.4 uplaod | 12:52 |
| apw | tgardner, ahh those normally go out with the linux-ti-omap4 upload, so i'd assumed it was done | 12:52 |
| tgardner | apw, so I don't get that. I think the announcement should go out with the meta package, 'cause tahts when the kernel is actually referenced. | 12:53 |
| ogra_ | tgardner, well i would say it is expected that we get a newer kernel version with a new dev release | 12:53 |
| tgardner | ogra_, its mostly to let the installer guys know to change the ABI | 12:53 |
| ogra_ | do you announce the first x86 uploads to a new cycle ? | 12:53 |
| ogra_ | ah | 12:53 |
| tgardner | ogra_, yep | 12:53 |
| apw | tgardner, though the announcement is for the installer team as they have to handle the number change and dont use the meta, and for the release team so they know to watch for it and accept it | 12:54 |
| tjaalton | hm, overlayfs is not something that's in mainline kernels? | 12:55 |
| apw | tjaalton, correct | 12:55 |
| tgardner | apw, why isn't the installer build smart enough to use the meta package rather then having to hard code the ABI into the build process ? | 12:55 |
| tjaalton | apw: ok, can't sbuild with one then :P | 12:56 |
| apw | tjaalton, nope, nor if you were using aufs3 either :) | 12:56 |
| apw | tgardner, i have had it explained, but cannot recall | 12:57 |
| apw | tgardner, i suspect it has something to do with the udebs and finding them | 12:57 |
| tjaalton | apw: just testing if this would fix displayport hangs with ivb, but then I realized there should be a quantal kernel bacport on a ppa already | 12:58 |
| tgardner | tjaalton, I uploaded one yesterday to the X backport PPA | 12:58 |
| tjaalton | tgardner: indeed, picking it up now | 12:58 |
| apw | tjaalton, ahh ... fun :) | 13:00 |
| apw | tgardner, all announced up the wazoo | 13:00 |
| tgardner | apw, 'tanks | 13:01 |
| tgardner | apw, so while our pre-inst test for non-pAE works, its way late in the process. by the time it is detected most of the dist-upgrade has already been performed. | 13:02 |
| apw | henrix, how are you generating the contents of the changelog in the lts backports ? | 13:03 |
| henrix | apw: they are generated automagically with the update-from-<serie>-master script | 13:04 |
| apw | henrix, ok cool | 13:04 |
| henrix | apw: i just need to update a few fields after that (bug tracking #, timestamp, ) | 13:04 |
| tgardner | apw, actually, the changelog is copied from the master branch IIRC | 13:04 |
| apw | tgardner, right got it, its not actually a rebase. ... great | 13:05 |
| henrix | tgardner: correct, that's why some of the fields need to be updated i believe | 13:05 |
| tgardner | henrix, the release pocket at least | 13:06 |
| henrix | tgardner: i believe that's handled by the script, but would need to double check | 13:06 |
| tgardner | henrix, yes, it is. | 13:07 |
| apw | ah when git cannot figure out you have a common commit of a sensible location you do get a lot of commits | 13:09 |
| tgardner | apw, prolly all of them | 13:10 |
| apw | 713k of them today | 13:10 |
| apw | 400MB worth .. sigh | 13:10 |
| tgardner | apw, does that put the hurt on your little bitty laptop ? | 13:11 |
| apw | tgardner, my poor link is whining | 13:12 |
| tgardner | apw, BT will be cutting you off at any moment | 13:12 |
| apw | tgardner, heh luckily i am not with the same people as cking else they would be | 13:13 |
| cking | it's not so bad, I just have to share a link with kids and video-on-demand | 13:14 |
| cking | at least I will be running at 20Mbit/sec soon ;-) | 13:14 |
| tgardner | cking, FIOS ? | 13:14 |
| cking | just bog standard cable | 13:15 |
| tgardner | cking, huh. the best I get is 15MB down on bog standard cable | 13:16 |
| cking | well, they *promise* 20Mbit, but I will see when they upgrade me | 13:16 |
| apw | cking, what do you have now, 10? and what do you get with that? | 13:17 |
| cking | apw, 10 all the time until I reach 8GByte of downloads in a day | 13:17 |
| apw | they must hate you :) | 13:17 |
| cking | that's the bonus of living in the sticks | 13:17 |
| * apw wonders if he can download that much in a day | 13:17 | |
| * cking sends apw a magnetic tape full of downloads by FedEx | 13:18 | |
| apw | cking, in theory i can get the 80Mb service from infinity | 13:19 |
| cking | that would be nice | 13:19 |
| ogasawara | tgardner: have you shared with QA about the q kernel is ready for testing in the backports PPA? | 13:19 |
| ogasawara | tgardner: if not, I will | 13:19 |
| cking | apw, pity your wifi is so clogged up in your neighbourhood | 13:19 |
| tgardner | ogasawara, not yet. it had not finished building when I left for the day yesterday. | 13:19 |
| tgardner | ogasawara, I did let bryce know | 13:19 |
| apw | cking, yeah i'd finally be unable to saturate my link over wifi | 13:20 |
| tgardner | ogasawara, I need to bug apw to get it into the daily upload process. | 13:20 |
| cking | apw, you need to relocate your office | 13:21 |
| * apw listens to the cops chase some crims using a copter ... damn they are noisy | 13:21 | |
| cking | or get some wifi proof wallpaper | 13:21 |
| apw | henrix, ok i have no tag in the master repo for the previous release Ubuntu-lts-2.6.38-15.59 release ... any idea what happened there ? | 13:24 |
| henrix | apw: hmm... let me check | 13:24 |
| apw | henrix, perhaps whoever looked it over failed to make one ? | 13:25 |
| henrix | apw: most likely :) | 13:25 |
| apw | can you add it to your checklist to check that it gets made by whoever in the future | 13:25 |
| henrix | apw: that's odd... i do have that tag | 13:25 |
| apw | henrix, you have the tag ? | 13:26 |
| henrix | apw: yep | 13:26 |
| apw | who made it | 13:26 |
| henrix | apw: have you git fetch --tags ? | 13:26 |
| apw | yes but only from origin | 13:26 |
| tgardner | henrix, maybe you forgot to push it ? | 13:26 |
| apw | tgardner, he can't push it, someone has to pull his changes | 13:26 |
| tgardner | apw, oh, right. I did that on purpose didn't I ? | 13:27 |
| henrix | heh | 13:27 |
| apw | yep this is working well, means we review things, and i am sure i'll get bored soon enough | 13:27 |
| apw | hense i have noticed the missing tag for the prev one | 13:27 |
| apw | henrix, so did you make the tag you have or someone else | 13:28 |
| apw | henrix, i'd expect whoever pushed it in to have signed the tag | 13:28 |
| herton | apw, I pushed it I think, it should be there, let me check | 13:28 |
| henrix | apw: i usually tag it, push it into my tree and my sponsor will push the tag to main repo | 13:28 |
| tgardner | henrix, herton or bjf doing that ? | 13:29 |
| * apw feels that actually as there is no other trail of the approval that the approver should sign the tag | 13:29 | |
| henrix | tgardner: well, most of the times herton... but need to check specifically that one :) | 13:29 |
| apw | but either way it isn't upstream right now in the repo as far as i can see | 13:30 |
| herton | tgardner, apw, yep, not tagged. I'm not sure now who pushed it | 13:30 |
| apw | herton, ok will sort it out using his tag | 13:30 |
| tgardner | apw, hmm, I thought we _had_ to sign the tags lest the check scripts kick it back. | 13:30 |
| apw | once git has lost it mind and downloaded 100M to give me his tag | 13:30 |
| apw | we can't push unsigned tags, but no tags | 13:30 |
| apw | they arn't detected | 13:31 |
| tgardner | apw, we can likely enforce that in a maintenance script somewhere. | 13:31 |
| apw | tgardner, herton, i expect shankbot can tell if there is no tag for the upload and refer the source task back to the creator | 13:32 |
| henrix | tgardner: or on the git hooks, when pushing into master...? | 13:32 |
| apw | henrix, yeah we might be able to get that to work too, though then you'd have to do them in the right order | 13:32 |
| tgardner | henrix, as apw pointed out, its difficult for the git hooks to detect that lack of tag, signed or not. | 13:33 |
| * apw quite likes shankbot not moving things to -proposed if its missing | 13:33 | |
| herton | apw, right now the prepare task is a manual process on the tracking bug, not sure if shank bot would be the better place for a check, but could be done | 13:33 |
| apw | herton, well the promote to proposed task waits for it to build etc, it could also wait for the tag as well | 13:34 |
| apw | "tag found waiting on binaries" "binaries found waiting on tag" | 13:34 |
| apw | or somethign | 13:34 |
| herton | yes, that would be ok too | 13:34 |
| tgardner | herton, we'll trust your judgment on that, but it seems like a test that should be performed somewhere. | 13:34 |
| apw | the worry here for instnace is if i hadn't | 13:34 |
| apw | noticed it, we would have lost the head, as it is a rebase head and i am about to slam over it | 13:35 |
| tgardner | yeah, the next garbage collect cycle would have lost it irrevocably | 13:36 |
| ogra_ | tgardner, apw, is it intentional that we only build the omap4 kernel for armhf ? | 13:37 |
| ogra_ | https://launchpad.net/ubuntu/quantal/+source/linux-ti-omap4/3.4.0-201.2 doesnt show an armel build | 13:38 |
| apw | i thought we didn't support armel for q any more | 13:39 |
| tgardner | ogra_, I thought we were dropping armel for Quantal ? | 13:39 |
| ogra_ | not decided yet | 13:39 |
| herton | apw, tgardner: before we push, we have a script that checks for some things, with the missing tag, I guess it was forgotten to be run (kteam-tools/maintscripts/verify-release-ready) | 13:39 |
| ogra_ | and if we keep it we indeed want a kernel | 13:39 |
| herton | *s/with/like | 13:39 |
| apw | ogra_, well then someone needs to communicate better, as it was off until the decision as i'd heard | 13:39 |
| tgardner | ogra_, so what is the story for armel in Quantal ? | 13:40 |
| ogra_ | see the other channel | 13:40 |
| apw | tgardner, either way though i think we have made some armel meta-packages with no binaries | 13:40 |
| tgardner | apw, hmm, maybe. | 13:40 |
| herton | nm, the script will not check if things were not pushed... I'll try to add a check to shank bot | 13:46 |
| henrix | apw: since you'll be pushing into natty lts, can you please add the missing tag? | 13:48 |
| apw | henrix, oh i am working on it feaverishly | 13:49 |
| apw | just git keeps thinking that 300M of stuff is new each time | 13:49 |
| henrix | apw: heh | 13:49 |
| apw | henrix, ok ... pushed both tags and pushed the lts-backport-natty branch too (all for lucid of course) | 13:59 |
| henrix | apw: ack, thanks. will build the src pkgs in a minute | 13:59 |
| apw | tgardner, do we use the 'abi-*' files in /boot for anything else other than the abi comparions ? | 14:00 |
| tgardner | apw, not even sure we use 'em then. I think they are purely informational AFAIK | 14:00 |
| apw | tgardner, well i think thats where we pull 'em to get them into the repo, ok | 14:01 |
| tgardner | apw, perhaps for dkms builds ? | 14:01 |
| apw | tgardner, don't think i've ever seen anything reference them | 14:01 |
| apw | tgardner, just wondered ... cool ... | 14:01 |
| tgardner | apw, neither have I | 14:01 |
| * apw wonders how long his firewall will survive at the current 52c its running at | 14:23 | |
| apw | perhaps putting my machines at the top of the shelves is not the best idea | 14:24 |
| * apw gets it down to 47 by standing the machine upright | 14:25 | |
| ogra_ | open a window ! | 14:27 |
| ogra_ | and the door :) | 14:27 |
| * dileks has a cold but tries to aspirates some air through IRC... pfff pfff | 14:28 | |
| * ogasawara back in 20 | 14:28 | |
| apw | ogasawara, everything is already oen | 14:29 |
| ogra_ | dileks, OMG ... use a virus scanner please ! | 14:29 |
| cking | apw, put it in the fridge | 14:29 |
| dileks | ogra_: hehe | 14:29 |
| apw | cking, cables arn't long enough sadly | 14:30 |
| cking | apw, move the fridge then ;-) | 14:30 |
| ogra_ | ++ | 14:30 |
| apw | its builtin to the kitche | 14:30 |
| apw | its builtin to the kitchen | 14:30 |
| cking | move the kitchen then | 14:30 |
| ogra_ | ++ | 14:30 |
| apw | hmmmm | 14:30 |
| cking | simple | 14:30 |
| apw | *slap* | 14:30 |
| cking | owhc | 14:30 |
| cking | alternatively relocate to a nice cool pub | 14:31 |
| apw | oh oh oh, yes | 14:31 |
| apw | damn the wires don't reach that far either | 14:31 |
| ogra_ | buy wireless wires then | 14:32 |
| apw | i am already being zapped by three APs | 14:32 |
| dileks | any ventilator in the house? | 14:32 |
| apw | i may have to add fannage | 14:32 |
| ogra_ | to wind up the cables ? | 14:33 |
| cking | put a bag of frozen peas on the firewall | 14:33 |
| apw | one of those freezer packs might work | 14:33 |
| cking | passive cooling win | 14:34 |
| jsalisbury | Just shut it off, the Internet is a safe place now a days | 14:34 |
| apw | jsalisbury, who the heck do you work for really :) | 14:34 |
| jsalisbury | heh | 14:34 |
| cking | I suspect he uses windows ;-) | 14:34 |
| apw | ha one of _those_ | 14:36 |
| jsalisbury | windows, nah, os/2 | 14:36 |
| cking | half decent OS then | 14:36 |
| apw | cking, i don't know abuot my firewall, but shoving the freezer block up my jumper has improved my mood | 14:42 |
| cking | glad you shoved it up there rather than somewhere else | 14:43 |
| apw | *slap* | 14:43 |
| * cking wonders why apw is wearing a wolly jumper in the summer heat | 14:43 | |
| apw | knew you'd say that | 14:43 |
| apw | i should have said my geeky t-shirt | 14:43 |
| apw | its having a nice cooling effectg anyhow, well recommended | 14:44 |
| cking | until the skin peels off with frost damage | 14:44 |
| apw | cking, looks like raising the front of the machine by 2in has improved cooling a lot | 14:46 |
| cking | amazing what a bit of air flow can do | 14:47 |
| henrix | anyone with a few idle cycles to give some suggestion on bug #1003309 ? | 14:51 |
| ubot2 | Launchpad bug 1003309 in linux "Boot fails after installing updates, error: “cryptsetup: evms_activate is not available"" [High,Confirmed] https://launchpad.net/bugs/1003309 | 14:51 |
| henrix | it looks like some initramfs thing, not a kernel issue | 14:51 |
| * henrix may be wrong | 14:52 | |
| apw | henrix, ok | 14:53 |
| apw | henrix, so ... when they installed the new kernel the initramfs would have been built then, the initramfs for the older kernel would have been built when it was installed most likely | 14:53 |
| apw | so if any of the tools which are in there such as encryption stuff it would be older, so it could also be a | 14:54 |
| apw | bug in ecryptfs-tools as well | 14:54 |
| * smb grumbles over the installers idea to select every single piece of storage looking like swap as a desired target for a swap partition... | 14:54 | |
| apw | we cuold prove that by rebuilding the old initramfs but would likely kill their good kernel | 14:54 |
| henrix | apw: yeah, it could be | 14:54 |
| henrix | hmm... right. so, he would need to boot from a CD, manually decrypt the fs and install the old version | 14:55 |
| === emma is now known as em | ||
| smb | noo, please update-grub, don't add an entry for every single vm I have on that server... | 15:09 |
| * cking thinks smb is having a bad install day | 15:12 | |
| smb | cking, I fear that will be repeatable everytime I will try to have an additional install on that... Unfortunately the whole installation does not only detect the contents of partitions but also those of the disk images placed into LVs... argl | 15:13 |
| cking | that's a fail | 15:14 |
| smb | The listing of "other" OSes in grub seem to be 10 pages... | 15:16 |
| tgardner | ogasawara, just tested generic-pae -> generic precise to quantal dist-upgrade. appears to work fine. | 15:19 |
| apw | anyone remember who it was who has the Pulsbough, the one with the handoff problems ? | 15:20 |
| tgardner | apw, bug vanhoof | 15:21 |
| vanhoof | tgardner: =P | 15:21 |
| vanhoof | apw: I believe that bug impacts older machine and not the newer ones we've been working with | 15:21 |
| apw | vanhoof, so 1) do you have a amchine with the issue you could test a package, 2) can you tell me which PCI ids are and are not affected ? | 15:22 |
| vanhoof | 1) don't believe so, 2) sure | 15:23 |
| vanhoof | apw: i'll check quickly, I may have been thinking about another bug | 15:27 |
| vanhoof | apw: gimme a few | 15:27 |
| ogasawara | tgardner: nice | 15:36 |
| apw | smb, how do you update your -source chroots? got a script or something, or a link to one? | 15:56 |
| smb | apw, not yet a script. working on it (to exclude non-srource) but got distracted | 15:57 |
| smb | apw, If you go the other way round (saying I know which ones there should be) there was something on the wiki posted | 15:59 |
| smb | https://wiki.ubuntu.com/SecurityTeam/BuildEnvironment | 15:59 |
| Eimann | https://eimann.etherkiller.de/nmz/gre-tunnel | 15:59 |
| Eimann | 1 root 20 0 128m 106m 1308 R 81 1.4 4:58.36 init | 15:59 |
| Eimann | fun :) | 15:59 |
| apw | Eimann, are those related ? | 16:02 |
| Eimann | yes | 16:02 |
| Eimann | 60% sys-time (20% on each core) | 16:02 |
| Eimann | I expected more havoc ;) | 16:02 |
| apw | heh not supprised | 16:03 |
| apw | just how many tunnels do you have there, and am i reading this right that you are pointing them all at yourself ? | 16:03 |
| smb | bjf, FWIW, the 3.2.0-24.39 kernel came up on a kvm vm with emulated disk | 16:08 |
| bjf | smb, thanks | 16:15 |
| tgardner | bjf, also works fine on my Lenovo x120e | 16:20 |
| bjf | tgardner: thanks | 16:20 |
| ikepanhc | bjf: around? | 16:24 |
| bjf | ikepanhc: yup | 16:24 |
| ikepanhc | bjf: I saw a proposed kernel uploaded, this week is kernel prep? | 16:24 |
| ikepanhc | bjf: checked Ubuntu kernel schedule, it says regression testing and on wiki.u.c/QQInterlock, it says kernel prep. | 16:25 |
| bjf | ikepanhc: yes, you can ignore that. it's a kernel with just a single commit in it which won't matter to you. we will have a kernel with a larger set of commits soonish | 16:26 |
| bjf | ikepanhc: this is a kernel prep week | 16:26 |
| bjf | ikepanhc: the start of our next cycle | 16:26 |
| cking | bjf, boot-test works on a Lenovo x220i with btrfs | 16:26 |
| bjf | cking: thanks | 16:26 |
| cking | bjf, any more kind of tests required? | 16:27 |
| ikepanhc | bjf: so, for next sru cycle, when will the proposed tag be made? | 16:27 |
| bjf | cking, not at this time | 16:27 |
| ikepanhc | bjf: I need to draw a deadline for highbank enablement patch | 16:27 |
| tgardner | ikepanhc, its in master-next, so itl go up in the next cycle | 16:28 |
| tgardner | it'll* | 16:28 |
| bjf | ikepanhc: i'm trying to get the 3.2.0-24.39 Precise kernel out of proposed asap. i've just asked henrix to start turning the crank on the next Proposed. | 16:29 |
| bjf | ikepanhc: the git repo should be ready in a few hrs. | 16:29 |
| ikepanhc | tgardner: understood. I would like to check more before first highbank deb built | 16:29 |
| tgardner | ikepanhc, so you don't _know_ that what you sent me was correct ? | 16:30 |
| ikepanhc | tgardner: that's correct | 16:30 |
| ikepanhc | tgardner: but I am not 100% sure after config changed | 16:30 |
| tgardner | ikepanhc, well, thats kind of a fail. are you gonna be able to test that before the next upload ? | 16:31 |
| ikepanhc | tgardner: that's why I am asking when is next upload | 16:32 |
| ikepanhc | tgardner: to be precise, the patch in master-next is fine and the config has been reviewed by calxeda engineer, I've built it and it runs well. | 16:33 |
| tgardner | ikepanhc, well then, whats the issue ? | 16:34 |
| tgardner | it sounds like what you send _is_ correct. | 16:34 |
| tgardner | sent* | 16:35 |
| ikepanhc | but the highbank config in master-next disable lots of function and cause config.common.ubuntu reduce length by 500 lines | 16:35 |
| ikepanhc | so I tried to re-enable those non-SoC related function | 16:36 |
| ikepanhc | I am not 100% sure on that re-enabling | 16:36 |
| Eimann | apw: this will be ~20k Tunnels between a Cisco ASR Router and a linux machine, and this two times | 16:36 |
| tgardner | ikepanhc, but you haven't sent that patch yet. the configs that are currently in master-next are what is gonna get tested. | 16:36 |
| Eimann | I'm trying to figure out how many mGRE and GRE tunnel the ASR can handle | 16:36 |
| ikepanhc | tgardner: that's correct | 16:37 |
| tgardner | ikepanhc, or rather, you sent the patch but told me not to pull it. | 16:37 |
| ikepanhc | tgardner: so, I wonder if I have time to verify it and send it | 16:37 |
| tgardner | ikepanhc, so, you've got time. you can always send another patch in a week or 2 ... | 16:38 |
| tgardner | ikepanhc, I suggest we go with what we know works right now. you can consolidate the configs later. | 16:38 |
| ikepanhc | tgardner: ACK | 16:39 |
| ikepanhc | sounds a fine plan for me | 16:39 |
| * apw reboots for a new kernel | 16:42 | |
| * cking grabs some more food, back in a short while | 16:43 | |
| apw | tgardner, this | 16:46 |
| tgardner | apw, sentence fragment ? | 16:46 |
| apw | tgardner, this kernel, i assume you want it rebuilt and uploaded whenever we tag quantal ? | 16:46 |
| tgardner | apw, ack | 16:47 |
| apw | bjf, argle, this is a new install and doesn't have -propposed enabled ... | 17:00 |
| * apw tries that atgain | 17:11 | |
| apw | bjf, apw@dm:~$ cat /proc/version_signature | 17:14 |
| apw | Ubuntu 3.2.0-24.39-generic 3.2.16 | 17:14 |
| apw | everything looksing fine here other than my typing | 17:14 |
| bjf | apw, cool, thanks | 17:14 |
| === tgardner is now known as tgardner-lunch | ||
| cking | tyhicks, I've sent you the ecryptfs benchmarks with a forward port of that chromium patch set | 17:33 |
| kirkland | cking: is that helping? | 17:33 |
| cking | oh yeah, I'll cc you too | 17:34 |
| cking | sent | 17:34 |
| kirkland | cking: thx | 17:34 |
| cking | kirkland, I'll do more rigorous testing on friday | 17:35 |
| cking | I suspect real I/O will swamp the savings, but we will reduce CPU load, which is a win | 17:37 |
| tyhicks | cking: Did this round of testing include your hack to always force the use of "__driver-cbc-aes-aesni"? | 17:38 |
| cking | tyhicks, nope, no dirty hacks | 17:38 |
| cking | I need to see what encypt core is used to sanity check this, so that will take a little bit more effort | 17:39 |
| cking | ..and I'd like to thoroughly soak test this patch as it is quite a change | 17:40 |
| tyhicks | cking: Ah, ok. So that somewhat explains the lack of difference between aes-ni and aes-generic in the test results. | 17:40 |
| tyhicks | cking: Yeah, it scared me. Which is why I was always waiting to see actual performance improvements before I even considered it. | 17:40 |
| cking | tyhicks, I think so, however the sub 2 TSC ticks per byte is quite an improvement | 17:40 |
| cking | anyhow, I'm going to mull over this and get back to some digging to see if we can shave some more cycles off (if we are not using the correct AES-NI path) on friday | 17:42 |
| tyhicks | cking: Right. So between the async patch and correcting the AES-NI issue, eCryptfs may see a huge performance boost. | 17:42 |
| tyhicks | cking: Nice job! | 17:42 |
| cking | well, if not, just with this patch it seems to be a big win that needs to be now thoroughly soak tested | 17:43 |
| cking | anyhow, /me is calling it a day | 17:44 |
| tyhicks | bye cking! | 17:44 |
| === tgardner-lunch is now known as tgardner | ||
| henrix | tgardner: i am currently working on precise linux-meta pkg. have you referred something about checking/testing your changes on this package some time ago? | 18:07 |
| henrix | tgardner: do you remember anything about this? | 18:08 |
| tgardner | henrix, I'm not really understanding your question. are you wondering about the highbank additions ? | 18:08 |
| henrix | tgardner: well, actually herton told me he remember you had some concerns about some changes you made | 18:09 |
| henrix | tgardner: so, i'm not sure if that's about the highbank :) | 18:09 |
| herton | tgardner, henrix, it has the hwe and current new meta, I took a look now too and seems ok | 18:09 |
| tgardner | henrix, not that I can remember. I'm usually gloriously ignorant of any mistakes that I've made. | 18:10 |
| henrix | heh | 18:10 |
| tgardner | henrix, I've recently added highbank and the hwe meta packages. | 18:10 |
| henrix | tgardner: right, so i took a look and i seems fine to me as well. | 18:10 |
| henrix | tgardner: thanks | 18:11 |
| bjf | jsalisbury: what is the correct url for the reports on cranberry? | 18:28 |
| jsalisbury | bjf: http://reports.qa.ubuntu.com/reports/kernel-bugs/reports/index.html | 18:29 |
| bjf | jsalisbury: thanks, that was confusing, went to http://reports.qa.ubuntu.com and that wasn't where i wanted to be | 18:29 |
| jsalisbury | bjf, hmm, seems there is no way to navigate to our reports from http://reports.qa.ubuntu.com | 18:30 |
| bjf | jsalisbury: is that something you feel like working on with ursinha? | 18:32 |
| jsalisbury | bjf, sure, I'll ping her about it | 18:32 |
| bjf | jsalisbury: maybe it's fodder for the arsenal mailing list | 18:34 |
| jsalisbury | bjf, good thinking ;-) | 18:35 |
| * tgardner -> EOD | 19:45 | |
| jjohansen | sconklin: so I picked up the change for CVE-2010-2525, however CVE-2011-4086, and CVE-2012-1090, want to go from released (2.6.38-15.59~lucid1) to pending (2.6.38-15.59~lucid1) which is wrong since 2.6.38-15.59~lucid1 is the currently released kernel | 21:34 |
| ubot2 | jjohansen: ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem. When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-2525) | 21:34 |
| ubot2 | jjohansen: ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem. When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-4086) | 21:34 |
| ubot2 | jjohansen: The cifs_lookup function in fs/cifs/dir.c in the Linux kernel before 3.2.10 allows local users to cause a denial of service (OOPS) via attempted access to a special file, as demonstrated by a FIFO. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1090) | 21:34 |
| jjohansen | I have reversed those changes, but I think you are going to have to update them in your tree as well | 21:35 |
| sconklin | jjohansen: ok, thanks | 21:35 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!