[00:05] <infinity> apw: Diffing powerpc64-smp/powerpc and generic/ppc64el configs is an interesting read.
[00:06] <infinity> apw: I'd expect them to be nearly identical except for default CPU twiddles and maybe some PS3 crap.
[00:55] <miseria> "crimen legal es diabolico; crimen ilegal es satanico. ¿donde esta el terrorista?: hay uno, es inmortal y se llama tiempo" bienvenidos: http://castroruben.com *temo_a_un_ser_sin_rival*
[07:58] <ppisati> moin
[08:49] <apw> infinity, yep, the config is a mess, and we all know how much fun a review is
[08:52]  * apw yawns the yawn of mondayness
[08:53]  * infinity still needs the elusive sleep of Sunday nightness before he can get to Monday yawning.
[09:14] <infinity> zequence: lowlatency SRU ping.
[09:14] <infinity> BenC: ppc SRU ping.
[10:27] <apw> ppisati, hey ... you boneblack config patches, could you look at repeating those for unstable ?
[10:27] <ppisati> apw: i'll do
[10:48] <ppisati> apw: done, let me do a test build and i'll send it
[11:09] <zequence> infinity: All kernels uploaded and waiting to build
[11:10] <ppisati_> apw: actually T/unstable FTBFS - http://paste.ubuntu.com/6986421/
[11:11] <ppisati_> apw: DRM_MSM
[11:13] <apw> ppisati_, oh yeah so it does, you fixing that or i can put it on my list for later
[11:13] <ppisati_> apw: doing it, else i can't test my bbone config changes there
[11:14] <apw> ppisati_, ack
[11:14] <ppisati> apw: actually T/unstable FTBFS
[11:15] <apw> ppisati, it build on x86 for me
[11:15] <apw> well 45m ago it did
[11:16] <apw> ppisati, ok i have just pushed a few pulled forward changes to unstable
[11:16] <apw> ppisati, not sure they would affect you but do match what i build-tested on x86 successfully
[11:17] <apw> (pulled forward == a resync with changes falling into master-next)
[11:17] <apw> (pulled forward == a resync with changes falling into master-next)
[11:18] <apw> ppisati_, did you see my msg about pshing ?
[11:18] <ppisati_> apw: failed building armhf
[11:19] <ppisati_> apw: just saw it, i'll rebase
[11:23] <apw> ppisati_, i expect it'll do that same, but worth a try indeed
[11:24] <apw> henrix, i am futzing with some android cves to try and get them off of our non-android view
[11:24] <apw> henrix, so prepare for carnage when the tooling loses its mind over what i added
[11:25] <henrix> apw: ack, thanks. i'm not doing any cve work this morning, so feel free to break everything :)
[11:26] <ppisati_> and another one...
[11:28] <ppisati_> http://paste.ubuntu.com/6986491/
[11:30] <rick_h> morning all, I'm working on getting trusty working on an air and it worked once, but then updates killed it and reinstalls aren't helping. It dies in boot at "Booting SMP configuration" per https://www.dropbox.com/s/behviox991o01o1/2014-02-23%2016.15.15.jpg
[11:30] <rick_h> any ideas I can use to follow up/file a bug?
[11:31] <ppisati_> that's weird
[11:32] <rick_h> that's a boot where I edited the grub stanza to not be quiet, noapic, and nomoseset (though it's intel graphics and all the stuff I see around nomodeset is nvidia/ati stuff)
[11:32] <apw> ppisati_, isn't bad_udelay meant to be missing, and something like a range check failure
[11:32] <ppisati_> bah
[11:33] <apw> rick_h, sounds bad ... which air is it?  file a bug with working kernel you had, and mention the broken one, though i thought we had a bunch of airs working ok around here
[11:33] <ppisati_> at least bbone doesn't break anything
[11:33] <rick_h> apw: it's a 2013 11". More details here http://askubuntu.com/questions/425267/issue-booting-14-04-on-macbook-air
[11:34] <rick_h> apw: I can't get it to work again, even on the -8 kernerl. I thought the upgrade to the -11 was what killed it but I've reinstalled off the same usb media 3 times and can't get it to boot once after install
[11:34] <rick_h> it's got me confused as the very first time I installed and rebooted it worked. I installed updates and it broke. I thought it was something with grub, but seems more kernelish
[11:35] <apw> rick_h, could easily be, apple don't want you running linux so they don't help keep it working
[11:35] <apw> rick_h, have you tried like a saucy live cd ?
[11:35] <apw> live image
[11:36] <rick_h> apw: no, the live image for trusty works. I used that to go back and do the reinstalls. I also used it to try to update-grub on it and see if something was off that a grub reset would fix
[11:36] <rick_h> so I can boot reliably off of that daily iso each time
[11:36] <rick_h> just not after install is completed
[11:36] <apw> and which kernel does the daily iso have in it
[11:37] <rick_h> good call, /me goes to get it and boot it again
[11:38] <apw> rick_h, i would also say try booting it nr_cpus=1 on the kernel command line
[11:38] <apw> never know might make it start at least
[11:38] <rick_h> apw: k, will do
[11:39] <apw> rick_h, and if you do another install when the install is finished but before you reboot one needs to see what kernel that has
[11:39] <apw> you should be able to open a terminal C-A-t stylee, and check the linux-image-* package version
[11:40] <apw> on your disk, by mounting it up and chrooting in
[11:42] <rick_h> the daily iso I've got is using 3.13.0-8 <IP_ADDRESS>.12
[11:42] <rick_h> that's what works repeatedly to get the installs up
[11:43] <rick_h> and that's what's installed as well.
[11:45] <apw> if you don't install updates during the install then it would definatly stay the saem
[11:45] <rick_h> yea
[11:46] <rick_h> trying the single cpu thing now
[11:46] <rick_h> is that a "set nr_cpus=1" or does that go in the linux stanza?
[11:46] <apw> well if that is the last thing it says on boot, then it has to most likely be a kernel issue, or a bootloader init issue, so i would file a bug against 'linux' to start with, and let us know the bug number so we can see if someone has the same h/w you do
[11:46] <rick_h> apw: rgr
[11:47] <apw> no it is a kernel command line change, so where like 'quiet debug'
[11:47] <apw> splash wahtever
[11:48] <rick_h> cool, that boots
[11:48] <rick_h> well got to the init list
[11:48] <rick_h> there we go, lightdm asking for password
[11:49] <rick_h> apw: ok, thanks. from this install I can run XXX to file the bug so it grabs my hardware info?
[11:49] <apw> 'ubuntu-bug linux' from the command line
[11:50] <apw> and include the cpu hack which got you booting
[11:50] <infinity> Of course, the first thing people will ask is to upgrade to the latest kernel and try again, so that might be worth doing now. :P
[11:51] <apw> there being a new kernel on there :)
[11:52] <rick_h> heh, networkless atm booo
[11:55] <apw> henrix, ok that seems to have worked right, panic over
[11:55] <henrix> apw: cool, and looks like 2 cves are now gone from the matrix
[11:56] <apw> henrix, yeah, finally got those to go away
[11:57] <ppisati_> apw: bbone changes for T/unstable sent, i'll let you deal with the FTBFSs
[11:58] <apw> ppisati_, thanks
[12:22] <rick_h> apw: thanks, filed bug with notes #1284085. Had to file from the liveusb boot because of the wireless issue, but it had the same kernel so hopefully ok
[12:23] <apw> bug #1284085
[12:23] <ubot2`> Launchpad bug 1284085 in linux (Ubuntu) "unable to boot after install on 2013 macbook air" [Undecided,New] https://launchpad.net/bugs/1284085
[12:24] <apw> rick_h, you should try updating that kernel to -12 and see if that works any better
[12:25] <rick_h> apw: I'll try to find a way to update it.
[12:26] <rick_h> check out the latest daily iso, maybe it's in tere
[12:44] <apw> ppisati_, is it you who does the ti-omap4 updates for SRU ?
[12:46] <apw> rick_h, and i assume you have tried booting without the noacpi option
[12:54] <rick_h> apw: correct, it still hangs at that SMP section
[13:19] <psivaa> apw: just noticed, running command 'top' takes up about 2.3% cpu with Linux ubuntu-phablet 3.4.0-4-mako #25. would someone be able to take a look why this could be?
[13:22] <apw> psivaa, is that a lot ?
[13:23] <apw> takes .7 on my big laptop
[13:23] <psivaa> apw: it appears so. we check for 97.5% idle time *using top command
[13:24] <apw> you run top to find out if the box is idle?
[13:24] <psivaa> so top itself taking up 2.3+ will always make that test fail
[13:24] <psivaa> apw: yes, we run top about 10 times with some time interval to see if the system has settled down before running other autopilot tests
[13:25] <apw> psivaa, was it ever anything other than 2.3% or could it be that what this is doing on a lame cpu like that will always be 2.3%
[13:26]  * cking wonders how much cpu top uses nowadays on these devices...
[13:26] <ogra> apw, it was below that in the past ... we have a test called systemsettle that runs top 10 times in a row, the average idle needs to be better than 97.5%
[13:26] <psivaa> apw: so this behaviour is only after a new kernel update. earlier we used to have someting like http://q-jenkins.ubuntu-ci:8080/job/trusty-touch-mako-smoke-daily/27/artifact/clientlogs/ubuntu_weather_app/topbefore.log/*view*/
[13:27] <ogra> it used to be better until the switch to android 4.4
[13:27] <psivaa> about .1%
[13:27] <apw> anyhow, it seems to me a daft way to get the idle time, when it is reported in /proc/stat
[13:28]  * ogra didnt write the test ...
[13:28]  * apw didn't write the test either
[13:28] <ogra> but i can see that it massively degraded since the weekend
[13:28] <apw> yes, but perhaps that isn't top
[13:28] <ogra> there are other processes too that expose higher CPU load though
[13:28] <ogra> (pulse mainly)
[13:28] <ogra> but that top jumped that high is also significantly noticeable
[13:29]  * apw laughs, pulse on a phone, yeah ... lets do that
[13:29] <ogra> ofono needs it
[13:29] <ogra> (well, telepathy does)
[13:29]  * apw still laughs
[13:29] <apw> pulse that machine eater here
[13:29] <cking> ogra, so which ones of these have changed, considering you have output from top it should be obvious?
[13:29] <ogra> it used to behave too for the last 200 images :P
[13:35] <ogra> you would have to flip the whole android stack
[13:35] <ogra> which makes the testing moot
[13:37] <apw> there is only 197,000 lines of change between the two
[13:37] <ogra> ah, easy then
[13:37] <ogra> ping me back for dinner about the responsible line please
[13:37] <ogra> :P
[13:37] <apw> ogra, so what phablet-flash incantation do i need to get the image that is showing this
[13:38] <ogra> phablet-flash is dead ... you want ubuntu-device-flash
[13:38] <apw> ok, what ubuntu-device-flash incantation do i need
[13:38] <ogra> ubuntu-device-flash -channel=trusty-proposed -bootstrap=true
[13:38] <apw> and ... where does it come from
[13:38] <ogra> on mako, manta or flo ...
[13:38] <apw> given my lovely shiney updated 20m ago trusty box doesn't have it
[13:38] <ogra> either trusty archive or for pre-trusty from the phablet-team ppa
[13:39] <ogra> ogra@styx:~/Devel/branches/rootstock-ng$ apt-cache policy ubuntu-device-flash|grep 500
[13:39] <ogra>         500 http://archive.ubuntu.com/ubuntu/ trusty/universe amd64 Packages
[13:39] <ogra> should be in universe
[13:40] <apw> ogra, so if my phone has a -3 and is therefore pre this change yes?
[13:40] <apw> psivaa, what top incation do you use to get this 2.3% number
[13:40] <ogra> system-image-cli -i
[13:40] <ogra> check the image version
[13:40] <ogra> 202 was the last android 4.2 one
[13:41] <ogra> you should see something like 206 if your device is recent
[13:41] <apw> 153
[13:41] <ogra> wow
[13:41] <ogra> thats ancient
[13:41] <apw> so, this is pre the change to 4.4 right? and top says top is taking 2.3%
[13:42] <apw> though that is from looking at the screen and not at however how ps... is doing it
[13:42] <apw>  2613 root      20   0    2556   1128    732 R  2.3  0.1   0:01.06 top
[13:42] <ogra> https://jenkins.qa.ubuntu.com/job/trusty-touch-mako-smoke-daily/79/artifact/clientlogs/ubuntu_calculator_app/topafter.log/*view*/
[13:42] <ogra> there you see that it bups up to 36% at times
[13:43] <apw> there is little supprise at that, have you seen just how much output this thing produces
[13:44] <ogra> this is from image 196: https://jenkins.qa.ubuntu.com/job/trusty-touch-mako-smoke-daily/64/artifact/clientlogs/ubuntu_calculator_app/topafter.log/*view*/
[13:44] <ogra> for comparison
[13:44] <ogra> and it was constantly like this
[13:45] <ogra> hmm, in faxct
[13:45] <ogra> apw, i see the 37% there as well at times ... i wonder if psivaa is just hunting fleas here
[13:46] <ogra> (btw the test was written by asac ... not sure why he didn parse /proc instead)
[13:48]  * ogra waits for psivaa to come back
[13:48] <ogra> i dont really think it is tops fault
[13:54] <apw> top is a very cpu intensive thing, it is doing 3 or file open and reads per process on your system for every single sample
[13:54] <apw> ogra, ubuntu-device-flash seems to just hang anyhow, is there a trick to this new undocumented interface?
[13:57] <ogra> apw, no, its the same thing in green^Wgo
[13:58] <ogra> just a rewrite of the python tool in go ...
[13:58] <ogra> it should behave and function no different than phablet-flash did (less racy though)
[14:01] <ogra> psivaa, so looking at older logs, top always spiked to something like 36% inbeteen
[14:01] <ogra> so i dont think this is something new
[14:07] <psivaa> ogra: aiui when the settle test starts to run, 'top' always takes about 20% +, but then it settles down to .1% ish soon enough so that it dint influence the test
[14:07] <psivaa> but now it stays on 2.+ %
[14:07] <ogra> psivaa, i see it even on 196 spike to 36% during the run
[14:13] <psivaa> ogra: would you mind pasting the top log please. i am only seeing that on the first iteration it goes to some large value and then on the comes down
[14:14] <ogra> psivaa, https://jenkins.qa.ubuntu.com/job/trusty-touch-mako-smoke-daily/64/artifact/clientlogs/music_app/topbefore.log/*view*/
[14:15] <ogra> at least three times in there
[14:15] <ogra> *during* the tests ... not at the beginning or end
[14:18] <psivaa> ogra: yea i see that. but the test will pass as soon as we see at least one top run where the idle time goes above 97.5
[14:18] <ogra> psivaa, right, i just think it isnt an issue with top
[14:19] <ogra> it doesnt behave differently
[14:20] <psivaa> ogra: ok, yea, i was only concerned that it stayed at a constant level 2.3 % in the current image when it was only spiking in the past. probably something else then
[14:36] <apw> psivaa-afk-bbl, ogra, ok this is accounted for by a change to what is reported in /proc/stat (which is consumed by top)
[14:36] <ogra> aha
[14:37] <apw> basically when the machine is idle, cpus are turned off complely, in the previous kernel the offline cpus counted as 100% idle, now the do not
[14:37] <apw> they no longer exist when off, so if you busy the one online cpu it counts more
[14:38] <ogra> yeah
[14:38] <ogra> we need to adjust the test
[14:38] <ogra> (and someone should re-write it to not use top)
[15:39] <BenC> infinity: building
[15:55] <psivaa> apw: ogra ack, thanks
[16:35] <apw> ogra, ok so phone in either the bootloader or recovery, flash does nothing obvious, so i cannot tell if it is doing it, or not, though if i remove the phone it doens't notice so i assume not
[16:36] <ogra> apw, complaints go to sergiusens
[16:36] <ogra> :)
[16:36] <ogra> apw, the code is go at least :)
[16:37]  * apw gives up, 2 hours is enough, someone else can do the testing
[16:37] <sergiusens> apw, there's a landing in the train with hints
[16:37] <apw> sergiusens, but how do i diagnose it right now
[16:37] <sergiusens> apw, what are you running?
[16:37] <apw> ubuntu-device-flash -channel=trusty-proposed -bootstrap=true -device=mako
[16:37] <sergiusens> apw, are you in the android bootloader?
[16:38] <apw> device cause without it pukes about getprops being missing
[16:38] <sergiusens> no need to use device flag
[16:38] <apw> sergiusens, looks like the bootloader to me, the green thing on its back
[16:38] <apw> it pukes without the device flag
[16:38] <sergiusens> apw, does it say fastboot mode on the screen?
[16:38] <apw> or does nothing
[16:38] <apw> sergiusens, in red, yes
[16:39] <sergiusens> apw, ok, might be a bug in the flags package which I'm changing (still under review)
[16:39] <sergiusens> apw, run it like ubuntu-device-flash --channel trusty-proposed --bootstrap
[16:40] <apw> sergiusens, ok so i pulled out the usb and put it back in, after booting it to the bootloader, and it has done something
[16:40] <apw> so i suspect there is an ordering issue here
[16:41] <sergiusens> apw, can you strace it?
[16:41] <apw> sergiusens, it looks to have done whatever it was meant to and exited now
[16:42] <apw> and the phione is doing something plausible.  so it seems lpugging in the phone then moving it to bootloader does not work
[16:42] <apw> replugging it once in bootloader seems to have unstuck it
[16:42] <sergiusens> apw, I tried that though
[16:42] <sergiusens> apw, let me try again and see if I can reproduce
[16:43] <apw> beyond me, hopfully you put some hints in there that tell you what it is trying so you can tell :)
[23:20] <hallyn> apw: sforshee: hi, any new thoughts on the overlayfs xattr patch?
[23:56] <infinity> BenC: \o/