=== cmagina is now known as cmagina-away [07:24] xnox, grouper with avahi really? === smb` is now known as smb [07:34] morning .* [07:39] smb, moin [07:48] apw, Today's S at least lets you change time+date and privacy settings... win. :) [07:49] smb, sounds like a big improvement :) [07:50] Absolutely. I won't turn mad being in a different tz than my installation is. :-P === fmasi_afk is now known as fmasi === fmasi is now known as fmasi_afk === fmasi_afk is now known as fmasi === vanhoof_ is now known as vanhoof [10:05] Does anyone else find their kernel hanging processes in schedule() for minutes at a time? [10:35] Ah. Probably not, because no one's crazy enough to btrfs. === jpds is now known as Guest46086 === fmasi is now known as fmasi_lunch === cmagina-away is now known as cmagina === Quintasan_ is now known as Quintasan === fmasi_lunch is now known as fmasi === broder_ is now known as broder === ssweeny` is now known as ssweeny [13:52] * henrix_ -> really late lunch [13:54] rtg, turns out it is linux-signed skew ... cause i cannot make one of those to match ... arrgle [13:55] apw, hmm, gotta love that. how come there is skew ? [13:56] cause i am making a test kernel, and i cannot make a real signed one, ever [13:56] ah, doh! does it work OK with an archive kernel ? === henrix_ is now known as henrix === nightwish is now known as wrayan === lilstevie_ is now known as lilstevie === rbasak_ is now known as rbasak [14:19] rtg: bjf: the EFI patchset is now queued for 3.5.y. i'll probably be sending it out for review tomorrow or friday, so early next week i should have a release with them [14:19] henrix, ack [14:19] henrix, ack, sounds good === psivaa-afk is now known as psivaa === cmagina is now known as cmagina-away === shadeslayer_ is now known as shadeslayer [14:40] bjf: no more -proposed for SRU kernels, just series name, right? (e.g. precise instead of precise-proposed) [14:40] ppisati, correct === cmagina-away is now known as cmagina === manjo` is now known as manjo [14:41] bjf: and, did you do any modification to kteam-tools/maintscripts/verify-release-ready? [14:42] ppisati, it should be fixed so that it doesn't require -proposed any longer [14:42] bjf: but it complains here in another way [14:42] bjf: http://paste.ubuntu.com/5861831/ [14:44] ppisati, seems pretty obvious from that error message what your problem is :-) [14:44] bjf: "Error: n"? :) [14:45] ppisati, which kernel are you working on ? [14:45] bjf: i'm rebasing lucid/omap4 on top of lucid/master [14:46] ack [14:51] ppisati, when was the last time you worked on that? [14:51] bjf: last release [14:51] bjf: ~two weeks ago [14:51] not lucid === cmagina is now known as cmagina-away [14:51] bjf: sorry, i meant precise [14:55] ppisati, it "just works" for me [14:56] bjf: let me try again === shadeslayer is now known as Guest33135 === yofel_ is now known as Guest48668 === ferai is now known as Guest73696 === Guest33135 is now known as shadeslayer === masACC is now known as maswan [15:35] * apw has to run and do some family bits in about 5 m ... laters [15:49] ppisati, are you building bootable kernels for armhf with saucy gcc-4.8 ? None of the nexus kernels are being built with gcc-4.8 [15:50] rtg: actually i had problems yesterday with a kernel not booting, but i thought it was my mistake in the .config since i was compiling vanilla [15:51] ppisati, perhaps you should step back to gcc-4.7 ? [15:51] rtg: i can give it a try === JayF_ is now known as JayF [16:16] apw: reminder about -lowlatency :) === Guest48668 is now known as yofel === fmasi is now known as fmasi_afk [16:34] rtg: you are right, same kernel src&.config [16:35] rtg: with 4.7 it boots, with 4.8 it hangs [16:35] ppisati, works with 4.7 ? [16:35] OK [16:35] rtg: yep [16:35] rtg: but my 4.7 was armel [16:35] [ 0.000000] Linux version 3.6.11 (flag@luxor) (gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-1ubuntu1) ) #21 SMP Wed Jul 10 18:15:43 CEST 2013 [16:36] this is what i have: [16:36] [flag@luxor linux-2.6]$ dpkg -l | grep gcc-arm-linux-gnueabi [16:36] ii gcc-arm-linux-gnueabi 4:4.7.2-1 amd64 The GNU C compiler for armel architecture [16:36] ii gcc-arm-linux-gnueabihf 4:4.8.1-1 amd64 The GNU C compiler for armhf architecture [16:37] ppisati, can you build with 4.7 armhf ? do you have the right HW ? [16:37] rtg: if i can find the toolchain, yes [16:38] I'm pretty sure there is a 4.7 armhf in saucy [16:38] funny [16:39] [flag@luxor linux-2.6]$ which arm-linux-gnueabi-gcc [16:39] /usr/bin/arm-linux-gnueabi-gcc [16:39] [flag@luxor linux-2.6]$ dpkg -S /usr/bin/arm-linux-gnueabi-gcc [16:39] gcc-arm-linux-gnueabi: /usr/bin/arm-linux-gnueabi-gcc [16:39] [flag@luxor linux-2.6]$ arm-linux-gnueabi-gcc -v [16:39] ... [16:39] gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-1ubuntu1) [16:39] 4.7.3 gcc in a 4.7.2-1 gcc-arm-linux-gnueabi package [16:40] apw: GAH! middle of a git bisect upstream between 3.7 and 3.8, it suddenly dumped into a 3.1 version. [16:41] * hallyn looks at git bisect log and tries to restart with last known good+bad [16:45] ppisati, so, does that mean the 4.7 cross compiler is not a hard float compiler ? does it matter for the kernel if its armel or armhf ? [16:45] rtg: IIRC we are still using armel on mobile [16:45] ogra_: ^ [16:45] ? [16:46] the armel builds live in their own universe [16:46] (and use a bionic toolchain) [16:46] i dont think we have any glibc armel cross compiler anymore [16:48] (there is gcc-arm-linux-androideabi, but thats not something anyone should use) === cmagina-away is now known as cmagina [17:06] apw, rtg: This config check is failing on powerpc saucy 3.10.0 [17:06] check-config: FAIL: (arch armel armhf &/ value CONFIG_GPIO_TWL4030 y) | value CONFIG_GPIO_TWL4030 m | !exists CONFIG_GPIO_TWL4030 [17:08] BenC, I wonder why ? that option shouldn't even exist for ppc, does it ? [17:08] I've set CONFIG_GPIO_TWL4030=m to get around it, but it appears to be faulty nonetheless [17:09] Setting it to y/n gives the check failure though [17:09] BenC, right. start a bug and assign apw to it. the config checker uses a completely (to me) inscrutable language. [17:10] rtg: It prompts for all four flavours, but I wanted to set it to "is not set" [17:10] config checker is black magic that I fail to comprehend as well [17:10] BenC, you could always just patch that line out of the config checker. its not like it changes that much. [17:11] I'm perfectly happy not having to touch the enforce file, even if it means having a useless module enabled :) [17:11] yeah, it wouldn't ever get insmod'd anyways [17:11] ogra_: i believe we have all three cross-toolchains. === kees_ is now known as kees [17:12] xnox, i belive armel was dropped for arm64 [17:12] (there might be a toolcahin, but i think there is no gcc for it anymore) [17:12] ogra_: right there is no 4.8 armel cross. [17:14] rtg: ppisati: ogra_: i believe that kernels for mobile are compiled natively using armhf toolchain, android userspace is compiled using armel-v5-bionic based toolchain. We have armel/armhf/arm64 4.7 cross compilers in saucy, and 4.8 armhf/arm64 [17:14] https://launchpad.net/ubuntu/+source/gcc-4.7-armel-cross [17:14] https://launchpad.net/ubuntu/+source/gcc-4.7-armhf-cross [17:14] https://launchpad.net/ubuntu/+source/gcc-4.7-arm64-cross [17:15] ... and matching for 4.8 [17:15] for mobile we are sticking with 4.7 for now, as kernels fail to boot / userspace gets borked with 4.8. [17:15] yeah [17:15] xnox, the native gcc-4.8 armhf compiler does not produce a bootable kernel for any of the Nexus devices. [17:16] rtg: correct. so 4.7 one is used instead. [17:16] xnox, actually, we use 4.6 on at least one device [17:16] /o\ [17:16] rtg: it's a shame.... [17:17] xnox, are we just gonna end up ignoring the fact that 4.8 is broken for this dev cycle ? [17:18] rtg: android open source project / cynogenmod / linaro should first make a toolchain & bring up bootable kernels with gcc-4.8. Until that happens, there is no intension to invest any engineering effort in doing this bring up. [17:19] rtg: linaro is supposedly working on 4.8 bring up, but they are still default to gcc4.7 across the board for "stable" stuff. [17:19] xnox, ppisati has pointed out that we can't use it for the distro kernels either. [17:19] distro armhf kernels* [17:20] rtg: well.... all of our distro armhf kernels are at various stages of decay. Is any one of those flavours at the same major version as amd64/i386 kernels? [17:21] xnox, of course. the omap series, vexpress, and some others. mostly those that use device tree blobs [17:22] rtg: "ignoring the fact that 4.8 is broken for this dev cycle" sounds a bit weird to me. "ignore the fact that old kernels do not support building with gcc-4.8, and target devices are not ported to newer kernels, and instead frozen in-time by their manufacturers" [17:22] damned if I know if they even work, though [17:22] rtg: I guess we should care to build armhf generic most recent kernel for calxeda and friends. [17:23] xnox, exactly. I think calxeda _does_ work, though I'd have to make sure with ppisati first. [17:23] rtg: we have two rigs available and before they go into production, could test kernels on them, I guess. [17:24] rtg: but i think, everyone now knows that it's fact of life that ac100/panda/$(nexus devices) are shipping old kernels and cannot be build with gcc4.8. [17:25] rtg: correct, 4.7 arm[el|hf] are ok, 4.8 armhf is bad [17:25] xnox, agreed. Then I'm gonna mark ricardo's bugs complaining about gcc-4.8 "won't fix" [17:25] it needs to be armhf in any case [17:25] we dont have an armel archive anymore :) [17:25] ppisati, gcc-4.8 fails even on calxeda ? [17:26] you would have to do a lot of tricks to actually cheat that into the archive [17:26] rtg: didn't test calxeda, omap4 only [17:26] what do you do with omap4 anyway ? [17:27] we still use the quantal kernel for it [17:27] ogra_: i test toolchain :) [17:27] ppisati, well, I guess it makes no difference if it works or not. it fails on omap, so we have to use an older compiler regardless. [17:27] and that wont change [17:27] ah [17:27] ogra_: btw, [flag@luxor ~]$ arm-linux-gnueabi-gcc -v [17:27] ogra_: gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-1ubuntu1) [17:27] yeah, 4.7 [17:27] [flag@luxor ~]$ dpkg -S arm-linux-gnueabi-gcc [17:27] we dropped armel from 4.8 for arm64 [17:27] gcc-arm-linux-gnueabi: /usr/bin/arm-linux-gnueabi-gcc [17:28] ogra_: so we have bot armel and armhf for 4.7 [17:28] right [17:28] ogra_: and armhf only with 4.8 [17:28] yeah [17:28] yes. [17:28] ok so [17:28] both 4.7 are good [17:28] 4.8 armhf is bad [17:28] (and arm64 with both 4.7 & 4.8) [17:28] rtg: where is that bug? =) [17:29] xnox, bug #1176255 and #1181046 [17:29] Launchpad bug 1181046 in linux-manta (Ubuntu) " linux-manta keeps rebooting when built with gcc 4.7 or 4.8" [Undecided,New] https://launchpad.net/bugs/1181046 [17:29] Launchpad bug 1176255 in linux-mako (Ubuntu) "linux-mako fails to boot when built with gcc 4.8" [High,New] https://launchpad.net/bugs/1176255 [17:30] I don't we bothered making a bug for the other platforms [17:30] hmpf [17:30] someone could at least have added the ram console dump [17:30] rtg: mark those bug as affecting project "gcc-linaro" =) [17:31] * ogra_ needs to write a wikipage how to debug android boots without serial console [17:31] I'll create a meta bug, make those other duplicates, and reference all of the relevant packages. [17:32] but first, I'm gonna eat lunch 'cause I'm starving. [17:32] * rtg -> lunch [17:32] a ram console dump is the least bit that should be attached to kernel boot bugs [17:34] ppisati: Building the ARM generic kernel with 4.8 breaks, or do you mean that ti-omap4/3.5.0 breaks? [17:34] ppisati: The latter seems entirely reasonable, the former would be a bug. [17:35] infinity: buidling a vanilla kernel (3.6 omap2_defconfig in this case) hangs on boot when cross compiled with 4.8 armhf [17:36] infinity: same src & .config with 4.7 is ok [17:36] ppisati: I don't much care about 3.6, we've moved on to 3.10... [17:37] ppisati: Hence why I asked about the "ARM generic kernel". [17:37] infinity: i do care about a toolchain that can't compile a kernel, dunno about you [17:37] Old kernels need old compilers is not a new situation. And could be cherry-picked to hell to fix, if we're still shipping ancient kernels in an LTS. [17:37] ppisati: Can't compile a kernel we don't ship? We have no 3.6 omap kernels in the archive, last I checked. [17:38] No toolchain can compile all kernel sources. The kernel plays pretty fast and loose with GCC misfeatures, and they tend to need to be of a similar vintage to be happy. This has been true for literally decades. [17:38] infinity: someone else reported that it can't compile a supported kernel with 4,8, isn't it enough? [17:39] ppisati: no. [17:39] ppisati: If we need to keep 4.6 to compile our crappy old Android kernels, so be it. [17:39] ppisati: If 3.10 compiles and boots fine with 4.8, that sort of proves the bug has been addressed upstream, and if we cared, we could cherrypick the kernel fixes to our Android kernels. [17:40] So, the question is, do we care? [17:40] In almost no way does any of this constitute a GCC bug. [17:40] no, we dont [17:40] (for the android kernels) [17:40] ogra_: doko may disagree. :P [17:40] then he can ask for it [17:40] from a phonedations POV we dont :) [17:41] ppisati: supported means - we will make a package available that will work. supported - doesn't mean we will backport frankenstein changes from recent kernels back to something 6 kernel releases back make it compile with optimized 4.8 toolchain, do benchmarks and conclude that it doesn't gain us anything. === thomi_ is now known as thomi [17:42] infinity: doko, had a sad moment that 4.8 didn't work with kernels, and went on to upload 4.7 point release update into saucy. [17:42] Now, it's probably entirely valid that if the only toolchain that can cross these old kernels is 4.6, we might need to reintroduce the 4.6-cross packages. [17:43] infinity: well most work with 4.7 fine, one seems to need 4.6 (the oldest kernel). [17:45] Meh. Kay, if it's just the one, people can suffer and build that natively. [17:45] I assume that's the platform still stuck on 3.1, for whatever reason. [17:45] infinity: it's not like that kernel will ever change though.... so it has already been build once...... [17:45] xnox: You don't watch rtg's uploads, clearly. He seems to upload Android kernels more often than mainline. :P [17:45] maguro: 3.0.0; grouper: 3.1.10; manta/mako 3.4.0 [17:45] (But I suppose once the config syncing and other bits are sorted, he'll stop) [17:45] infinity, 3.1 ? modern stuff :P [17:45] maguro (omap4) uses 3.0 [17:46] root@ubuntu-phablet:/# uname -r [17:46] 3.0.0-3-maguro [17:46] infinity: i guess it might make a little sense to poke the 4.6 one and see if can be patched up to use 4.7 (maybe somebody in cynogenmod et al did it already) [17:46] Ironic, given all the years we supported omap4. [17:46] yeah [17:46] well, its alll about the binary blobs [17:49] ogra_: by the way, I solved my fetching sources problem with: chdist + python-apt magic [17:49] haha [17:49] hacks FTW :) [17:49] nice one though [17:50] ogra_: it's slightly better than PULL_LP_BIN [17:50] * ogra_ hopes nobody ever looks deeply into ubuntu-touch-initrd-generic [17:50] it does funny things too [17:50] ogra_: cause, my hacks should work on the distro builder as well. [18:00] infinity: one can always compile those kernel in the last release that had gcc-4.6-cross and then copy up..... [18:00] * xnox hides === ssweeny` is now known as ssweeny [18:33] apw: I plead for help. http://paste.ubuntu.com/5862473/ [18:34] does the fact that it was testing a merge point confuse git-bisect afterward? [18:34] (I tested that on tangerine as well as my precise builder, so it's not just the git version) [18:35] hallyn, you can't bisect across a non-linear space. [18:36] at least, not very easily [18:36] I thought Linus' tree was supposed to always be bisectable [18:36] hallyn, Linus's tree is, but not Ubuntu [18:36] ok - I'll take a different approach. [18:36] this is on Linus' tree [18:37] hallyn, what is HEAD in your example ? [18:37] at which point? [18:37] right nwo it is c5482bbd9607bf38cbc952eacaa429e6ba3160a0 [18:37] the starting value for 'git bisect start' [18:38] rtg: that shouldn't matter right? it's been different, but with the same result - it takes the git bisect good and bad values to start with [18:38] I guess it makes no difference really. [18:38] right [18:38] all right - was hoping there was some magic pixie dust i didn't knwo about to fix it. i guess i'll just focus on changes to kernel/{exit,signal}.c, which are few [18:39] I've got my eye on af4b8a83add95ef40716401395b44a1b579965f4 pidns: Wait in zap_pid_ns_processes until pid_ns->nr_hashed [18:43] hallyn, maybe its because those SHA1 IDs are merge commits [18:45] rtg: I just would expect git bisect to DTRT... (maybe it *did* do the right thing, but that's not how I see it) [18:45] hallyn, sometimes git still surprises me [18:45] s/surprises/disappoints/ in this case :) [18:46] rtg: thanks. i'll track it down by hand - ttyl [19:25] i was right, that's the bad commit. [19:25] apw: ^ the signal weirdness was introduced there (af4b8a83add95ef40716401395b44a1b579965f4 pidns: Wait in zap_pid_ns_processes until pid_ns->nr_hashed) [19:26] just fyi, since i KNOW you're losing sleep over it :) [19:26] apw: Sarvatt: FYI been running 3.10 with intel_pstate=disable, so far no major problem detected and heat, cpu management , battery back to previous values [19:26] thanks [19:30] FernandoMiguel: I've been running a kernel using intel_pstate with the changes on https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1188647/comments/6 and not having any problems -- http://kernel.ubuntu.com/~sarvatt/intel_pstate/ [19:30] Ubuntu bug 1188647 in linux (Ubuntu) "Please change intel_pstate default to disable" [High,Fix committed] [19:30] but i haven't been tracking battery usage, just heat [19:43] ah, maybe i see the problem [19:57] * rtg -> EOD === yofel is now known as Guest395 === hyperair is now known as Guest96566 === ashams is now known as Guest64962 === Guest395 is now known as yofel === larsdues1ng is now known as larsduesing === cmagina is now known as cmagina-away === cmagina-away is now known as cmagina === stgraber_ is now known as stgraber === larsdues1ng is now known as larsduesing === cmagina is now known as cmagina-away [22:08] * cooloney waves at apw ogasawara smb bjf vanhoof [22:11] hi cooloney [22:11] cooloney: bu yao! :) [22:17] vanhoof: how's going? you're a busy man! [22:19] cooloney: not too bad, busy as always :) ... how about you? [22:19] vanhoof: very good. i'm working on V4L2 camera stuff on Tegra. [22:20] vanhoof: hope to meet you guys somewhere [22:21] cooloney: I'll be in the bay area later this month I think [22:21] cooloney: come pick me up from sfo :) [22:21] cool, let's hangout. [22:22] +1 [22:22] sure, i will drive my lamborghini [22:24] cooloney: gucci leather? [22:26] cooloney, does the camera work ? [22:29] cooloney, I hear Lamborghini's don't have AC ... [22:29] oh, manjo, you are always ask the key question [22:29] they do [22:30] vanhoof and manjo, you know, I mean there is a bus from SFO named Lamborghini, not that one you guys expect [22:30] lol [22:30] cooloney: don't toy with my emotions :) [22:30] why drive a 250k car when you can ride in a 1/2 mil bus [22:31] cooloney, now I see the logic in your v4l camera device [22:32] also I have bike named Maserati, if you guys wanna ride [22:32] motor or foot powered ? [22:32] cooloney: with pedals? [22:32] :) [22:32] does it go ding ding ? [22:34] oh, one pedal works and the other not [22:36] manjo: it always goes dingding except the bell. === kentb is now known as kentb-out [22:36] cooloney, you are always full of surprises ! [22:37] manjo: will you come with vanhoof this time? [22:37] vanhoof, am I going with you to CA ? [22:38] cooloney, peons don't get to go I think ... [22:41] cooloney, are you going to plumbers in NO this sept ? [22:52] manjo: probably not. if it is in bay area, i might go. === elmo_ is now known as elmo === cmagina-away is now known as cmagina === cmagina is now known as cmagina-away