[00:15] herton: Oh, you could do it too, sure. :) [01:35] herton: How often does shankbot poll the PPA? [02:16] infinity, once an hr. [02:18] bjf: Thanks. [02:49] bjf: Hrm, I'm missing some subtle nuance then, cause linux/hardy has been built and published for well over an hour, but the bug has no promote-to-proposed confirmed. Weird. [03:02] bjf: And it finally got around to it. Maybe I'm just impatient. [03:17] if I am using the linux-generic-lts-quantal kernel in Precise, am I able to use any of the lbm-cw packages in the repository? are the kernel modules compiled specifically only for other kernel versions? [03:38] tyr: no you can't, are you using linux-backports-modules-cw-3.6-precise-generic? that's the only one newer than the lts backports kernel [03:38] the lbm-cw packages are compiled against 3.2 kernel updates each time [03:51] so there's none that are compiled against kernel 3.5? [08:50] * apw yawns === henrix_ is now known as henrix [11:24] smb, there is no good reason to not build the DM delay and flakey personalities is there? [11:27] apw, Hm, don't think really. They become modules I suspect and then will only be used if someone actually builds a target with them. Which pretty much is another painful and manual process. [11:27] smb, that fits my thinking too, thanks [11:38] tjaalton, Not sure how/where/what exactly to report but I noticed on my sdp that using the quantal X stack and kernel on Precise running from a SSD is booting pretty fast and comes up ok but when rebooting or shutting down I see a dialogue telling me the system would only run in low-graphics mode (and it definitely was not doing that) [11:39] smb, so you see a new X server with "you are in low graphics mode", doe that have to be acknowledged or does the reboot/shutdown complete [11:39] smb: I guess it's plymouth's fault [11:39] apw, It does go on but if you are quick you could confirm the first screen [11:40] smb, and do you get the 'dots' if you confirm it ? [11:40] it has some hardcoded checks for 'i915'.. [11:40] apw, No, I get the second dialogue asking me what "other" config to use. And I was not quick enough to click before that was shot down [11:41] smb, ok :) [11:42] tjaalton, We had been wondering whether X may go away too quickly because other people with that combo but slower disks do not see that [11:42] tjaalton, Or I did something wrong when pulling the new stacks... [11:43] smb, i think file a bug against plymouth and see what happens [11:43] smb, and mention it to slangasek [11:43] * smb thinks what happens will be a response saying "you are running crack" [11:44] But anyway, I will try [11:44] smb, it is going to be a supported combination ... [11:45] right, and I haven't seen that bug with quantal [11:45] though I sometimes get the same dialog when it boots up [11:48] smb, any idea whether it makes sense to have CONFIG_VIRTIO_MMIO_CMDLINE_DEVICES turned on [11:49] apw, Err, not really have an idea what that would be... [11:53] apw, Sounds very useful for crashing your system when unaware but interesting create unusual setups... [11:58] smb, yeah, i think as it is on i will leave it alone ... even if it is a bit scarey [12:00] apw, True and probably there are more evil things that you can do when you can modify the kernel command-line... === psivaa is now known as psivaa_lunch [12:07] slangasek, tjaalton I filed bug 1086345 for the x-lts-quantal oddity I see. If there is more I should do, please let me know [12:07] Launchpad bug 1086345 in plymouth (Ubuntu) "Quantal-LTS-stack: Showing low-resolution screen on shutdown/reboot" [Undecided,New] https://launchpad.net/bugs/1086345 [12:19] cking, i assume we have SLUB_DEBUG turned on for a reason ... [12:20] apw, hrm, can't recall exactly when we enabled that [12:21] apw, ogasawara: pushed -rc8. build testing. [12:23] apw I would be more concerned if SLUB_DEBUG_ON was enabled, that turns it on by default [12:24] cking, SLUB_DEBUG on, i believe _ON is off [12:25] apw, if we are concerned about the performance penalty of SLUB_DEBUG I can look at that [12:25] cking, i was more interested to know it was a concious decision [12:26] apw, it wasn't a conscious decision that I can recall [12:26] then ... low low on your list, perhaps test it [12:27] apw, if it's not on for previous releases we should disable it for the moment I reckon [12:32] cking, apw, I believe it has been always enabled on our config (SLUB_DEBUG), it's helpful to debug some memory corruption cases passing slub_debug on commandline, like double frees, I recall it being useful once to me [12:32] but not sure about the performance impact, if it has some then probably should be disabled [12:32] in which case, let me assess the overhead, if its is unnoticeable then it's a useful to have feature [12:33] cking, herton, works for me [12:34] what is the procedure to get an account on kernel.ubuntu.com ? [12:38] xnox, beg #is via an RT ticket. [12:39] rtg: sounds like a good plan =) [12:39] thanks. [12:50] rtg, that commit you mentioned yesterday (bc78c57), do you saw a problem it fixes? I can forward to stable [12:53] herton, no specific problem. I was looking at backporting TRIM support for md arrays and noticed that its likely a good bug fix. [12:53] rtg, ok, will ask for inclusion === psivaa_lunch is now known as psivaa [13:06] * henrix -> lunch [13:14] * apw wanders out to get some fresh air [13:24] is there any ppa with 3.7 for 12.10? or are rarings kernels OK on 12.10 perhaps? [13:25] smb: thanks, subscribed === yofel_ is now known as yofel [13:36] Konstigt, there are raring kernels for 12.04 at https://launchpad.net/~ubuntu-x-swat/+archive/r-lts-backport [13:37] rtg: I was thinking we should upload today. lemme know if your test build was successful and I can test on some kit here and then prep the upload. [13:41] ogasawara, I've got x86en built on tangerine. lemme stash it on zinc in a sec and I'll give you an URL [13:42] kees: i'm getting a build error on arm platforms for precise regarding your "seccomp: forcing auditing of kill condition" commit [13:42] kees: https://pastebin.canonical.com/79684/ [13:42] kees: any suggestion? [13:43] henrix, you might be a bit early in the day for him [13:43] rtg: ah, right :) [13:44] ogasawara, cking, apw: http://kernel.ubuntu.com/~rtg/3.7-rc8.1/ [13:44] rtg: ack [13:44] rtg, want me to exercise this on a bunch of machines? [13:45] cking, please [13:45] * cking rummages around for some H/W [13:57] does anyone know the rational for not having CONFIG_AUDITSYSCALL on arm configs? [13:57] i believe this is what is causing the build failure [13:57] ppisati, ^^ [13:58] henrix: hold on [13:58] ppisati: thanks [14:01] henrix: config AUDITSYSCALL bool "Enable system-call auditing support" depends on AUDIT && (X86 || PPC || S390 || IA64 || UML || SPARC64 || SUPERH) [14:02] henrix: ARM was not supported back then [14:02] ppisati: heh, ok. i should have checked that myself :) [14:02] ppisati: thanks. [14:24] rtg, kernel seems good on atom n450, ivybridge + sandybridge H/W, will exercise it on some AMD kit now [14:26] cking, ack. thanks [15:02] ogasawara, cking,apw: I'm gonna have to respin Raring with arges ticket_spinlock (fsnotify) patches. [15:02] rtg, tested on a bunch of older kit too (AMD, etc) works fine, boots, S3, S4, audio, network [15:02] ah, more to test :-) [15:02] rtg: ack [15:02] rtg: previous build tested fine on my kit here [15:03] rtg ack [15:03] cking, yeah, the ticket_spinlock tests might require more manula USB plugging, etc [15:03] ack [15:03] rtg, there is a script that reproduces the issue easily. I've tested this set of patches with that but would like to do more testing [15:04] rtg, cking : in addition do some performance tests if we can. [15:04] arges, such as? [15:04] cking, not really sure : ) have to think of something fs notify related [15:05] rtg, I am removing the ubuntu nexus tree from its former location in hwe/ , no objections right? [15:05] * janimo goes to update the wiki as well [15:07] janimo, go ahead [15:13] arges, the point is that fsnotify is in the way of _all_ operations if its enabled [15:13] arges, so if you ask for "read/write" notification for instance [15:13] which isn't common but is possible [15:15] apw, yea I think I can look at the test case, and try to write something [15:15] apw, start time, inotify_add_watch , access file/directory, inotify_rm_watch [15:18] yeah [15:18] arges, with multiple read/writers in there [15:32] ogasawara, cking, arges, apw: http://kernel.ubuntu.com/~rtg/3.7-rc8.2/ for the fanotify version [15:32] rtg, downloading [15:32] rtg: ack [15:34] brb [15:36] * rtg relocates... [15:42] rtg: thanks but I have 12.10/Quantal [15:43] Konstigt, you can still install the kernel debs from either archive, but you won't get automagic updates via meta packages. [15:48] * ogasawara back in 20 [15:49] rtg: aha, so the kernel isn't really bound to the release and vice versa. so then just downloading the needed files from http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.7-rc8-raring/ should work. [15:49] Konstigt, yep [15:50] the 'raring' part simply means that it was built using the raring config. I think all mainline are built using the Precise toolchain. [15:50] they are built using the previous LTS' tool chain [15:50] so, either Lucid or precise [15:50] yes [15:51] thanks [15:51] (in theory it would also use hardy, but ... i don't think we every make things that old) [15:52] ** [15:52] ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting [15:52] ** [15:52] its tuesday _again_ ? [15:53] heh [15:53] apw, Its _that_ late again, too [15:53] seemingly indeed [15:55] bjf, smb, it looks like bug 1034099 is due to commit ffaf6a1e73719e0250fce7b52015187180a77fe9 [15:55] Launchpad bug 1034099 in linux (Ubuntu Quantal) "Kernel panic with ulatencyd on kernel 3.2.0-29-generic" [High,In progress] https://launchpad.net/bugs/1034099 [15:55] jsalisbury, Yeah, somehow I stopped worrying when I saw that... [15:57] smb, is that commit something we can revert ? If so, I can submit an SRU request. [15:58] jsalisbury, Gosh I should read better (commit != comment)... [15:58] smb, its this SAUCE: [15:58] commit ffaf6a1e73719e0250fce7b52015187180a77fe9 [15:58] Author: Stefan Bader [15:58] Date: Tue Jul 3 15:01:58 2012 +0200 [15:58] UBUNTU: SAUCE: sched: Fix race in task_group() [16:00] Oh f**k, I would not want that reverted but there was something messed up by it and I really cannot say right now what exactly it was [16:00] rtg, that kernel works OK on a bunch of laptops, atom, sandybridge, ivybridge, amd64. however my sharkbay desktop gets video corruption and seems to lock up (tried it now 4 times) [16:01] cking, does the kernel in .1 have teh same issue ? [16:01] rtg, yep [16:01] cking, ok, so at least it wasn't introduced by the fanotify patches [16:01] I didn't get around to test it until just now 'cos I was exercising it on a bunch of other tests [16:02] cking, sharkbay is haswell? [16:02] cking, does the sharkbay work with ogasawara's Oneiric haswell pile ? [16:02] cking, i don't think all of ogasawara's haswell patches are in raring [16:02] smb, the bug affects precise and quantal. I'll find out if it also affects raring. [16:02] rtg: all the haswell patches I pulled won't land until 3.8 opens [16:03] bjf yes, rtg no, but it used to work on earlier raring kernels [16:03] huh [16:03] indeed, huh. [16:03] I'm gonna ignore it for now [16:03] sorry, that was not clear [16:04] no, as in I never sucessfully tested this box last week, so no, I am not sure, but it was booting fine on earlier 3.7 kernels [16:04] jsalisbury, I thought I had someone with a boot oops because of that and thought at that point some additional upstream change was found... [16:05] * cking wonders if this is going to be the last -rc for 3.7 [16:06] cking, mebbe [16:06] jsalisbury, Do we have this one pulled: commit fd8ef11730f1d03d5d6555aa53126e9e34f52f12 [16:06] Author: Mike Galbraith [16:06] Date: Mon Dec 3 06:25:25 2012 +0100 [16:06] Revert "sched, autogroup: Stop going ahead if autogroup is disabled" [16:07] ... stupid question as that was in the precise tree.. [16:07] smb, nope [16:12] Hm, ok seems something from 3.7-rc8... [16:14] jsalisbury, So can we instead try the other revert which should be queued for stable afaics [16:15] * smb curses and rushes over to the other irc meeting [16:17] smb, so put your patch back and then apply fd8ef11730f1d03d5d6555aa53126e9e34f52f12 [16:17] jsalisbury, Yeah, which reverts the other thing actually [16:17] smb, got it. thanks [16:24] smb, I ran into an issue when cherry-picking commit: fd8ef11730f1d03d5d6555aa53126e9e34f52f12 [16:24] smb, git diff says: [16:24] * Unmerged path kernel/sched/auto_group.c [16:24] * Unmerged path kernel/sched/auto_group.h [16:25] smb, I can manually revert commit 800d4d3 without an issue [16:25] jsalisbury, clean your tree first ? [16:25] rtg, I did a fresh clone [16:25] of the precise tree on tangerine [16:25] jsalisbury, Oh well, could be because Peter was bored and renamed most of the files about 3.5 [16:26] so things moved from kernel into kernel/sched [16:27] smb, ahh. Can I just do the revert of commit 800d4d3 myself, and have that tested? [16:27] smb, Or I can just fix things up after the cherry pick [16:27] wonder whether the lazy fixup of git format-patch , git am -> fail , patch < works [16:29] jsalisbury, just reverting the change would work as well for testing. Mainly its to have the upstream changelog (but that could be done later) [16:29] smb, ack [16:34] rtg, remind me the nature of the USB_OTG badness when enabled on x86 [16:39] apw, I think its because there _isn't_ an OTG on x86 platforms. [16:41] Oh hey, do I get to drop my UAPI hacks from glibc after the next linux upload? Did that land? [16:42] apw, this must be for you? ^^ [16:42] Either of you. :P [16:42] rtg: I expect you to know every line of the every kernel rc. Sheesh. [16:45] UAPI: strip the _UAPI prefix from header guards during header installation [16:45] infinity, thats what you are hoping for i believe [16:46] v3.7-rc8~27^2~6 [16:46] which is in ^^ .... ie in -rc8 and our next upload [16:46] apw: That'd be the one. [16:47] bjf, sconklin smb: is kernel team going to be using UTAH in their testing? (perhaps smb can provide some more context) [16:48] rtg: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1084640 [16:48] Launchpad bug 1084640 in linux (Ubuntu Raring) "linux: 3.7.0-5.13 -proposed tracker" [Medium,In progress] [16:48] rtg: in the future, you'd just run create-tracking-bug or whatever it's called and it'll shove the changelog entry for you [16:50] smb: not in our team testing environment for the foreseeable future. the QA team does theirs differently, and may use it for their kernel tests [16:50] sconklin, i thought we had like a shim between utah and our tests so we use the same tests in both environments; right? [16:51] (but not using it indeed) [16:52] apw: the same tests can be run in both environments, all the kernel tests are under autotest client. Different ways of calling them are used in QU and out team [16:52] smb, in a word, no [16:53] bjf, Ok, I can pass this on next week. :) [16:53] Or... hggdh ^ [16:53] smb, is there some feature of utah that would make me want to do so ? [16:53] bjf, I am merely the messenger here. No personal interest really in doing one or the other [16:53] smb, should i talkto arosales directly? [16:54] bjf, Actually it was hggdh asking through arosales [16:55] bjf, Or I ping you before the next server-team meeting to join the fun on irc. :) [16:55] well, that's just damn odd [16:56] smb, not sure i can handle that much fun .. but sure [16:57] bjf, Maybe it brings a bit of the scary happy face back. :) [16:57] lol [16:57] apw, both raring branches pushed. I'm just gonna wait to upload until my armhf test build is done. [16:58] about 30 minutes I expect [16:58] rtg, ack === jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues December 11th, 2012 - 17:00 UTC || If you have a question just ask, and do wait around for an answer! [17:18] * ppisati goes out for a bit [17:24] rtg: is raring master-next supposed to build right now? [17:24] (from last night actually) [17:24] hallyn, yep. are you having issues ? [17:25] hallyn, just pushed -rc8 this AM [17:25] yeah seemed to complain about a missing file, [17:25] ok i'll merge that, thanks [17:25] far prefereable anyway [17:25] hallyn, hmm, I've been building it pretty regular [17:26] rtg: I got gcc: error: lib/oid_registry.c: No such file or directory [17:26] hallyn, in a PPA, right ? [17:27] apw and I have encountered that same error. restarting the build makes it go away. [17:28] rtg: yeah ppa.. huh. ok thanks :) [17:36] hallyn, has to be a missing dep in the kernel makefiles somewhere [17:37] apw, the PPA's are -j1 aren't they ? [17:38] * apw would have thought not, we check the number of CPUs don't we in the packaging [17:39] apw, ifeq ($(wildcard /CurrentlyBuilding),).... [17:39] oh, that has changed [17:40] apw, indeed, you are correct. [17:43] rtg, am pretty sure you did that :) [17:43] apw, you're prolly right. [17:57] rtg, actually that /CurrentlyBuilding is about whether we make udebs and the like, and i added that to speend up normal builds [17:57] rtg, but its years old [17:57] apw, we _used_ to use it to determine parallelsim. it likely is still that way in hardy [17:58] ahh ... :) [17:58] apw, Iv'e been playing with parallel builds in lib, but can't get it to break. [17:58] wierd [17:58] i wonder if it is also used from outside of lib without deps [17:58] they do that kind of thing sometimes ... #include ../xxx/foo.c [17:58] and the like [17:59] apw, perhaps during the headers install phase ? [17:59] seems odd, but ... [18:00] apw, you'd think it would complain about not being able to find oid_registry_data.c (which is generated) [18:05] i need to see a full log which has this in [18:06] rtg/hallyn if you get one again do download the log before restarting it [18:06] apw, there isn't a lot of info in it [18:06] i want to see the order things occured [18:06] if you have one [18:13] apw: i haven't restarted the one so you can get the log from this morning, [18:14] apw: https://launchpadlibrarian.net/124867223/buildlog_ubuntu-raring-amd64.linux_3.7.0-5.13ubuntu1userns2_FAILEDTOBUILD.txt.gz [18:23] $(obj)/oid_registry.c: $(obj)/oid_registry_data.c [18:23] rtg, that is wrong isn't it ? [18:24] note the $(obj)/oid_registry.c ... that file is in $(src)/ [18:24] apw, I was just trying to figure that out. gonna build with V=1 [18:24] so i think that apparent dependancy is non-effective [18:24] apw, seems reasonable. why would it _ever_ work ? [18:25] they are likely started in the right order by luck [18:25] so as long as we are doing things in the stack which take a while it will finish [18:25] as the execution engine in make is limiting self to 10 builds or whatever [18:26] yeah i think that line should be: [18:26] $(src)/oid_registry.c: $(obj)/oid_registry_data.c [18:26] and i think that should fix it, if you can reproduce it [18:26] yeah, just changed it. gonne give it awhirl [18:27] apw, well, it didn't break 'make M=lib -j' [18:28] heh [18:29] rtg, though i am slightly unsure if it should be $(obj)/oid_registry.o: in reality [18:30] that actually makes more sense rule wise [18:30] as you do not remake the oid_registry.c, it is the same, but you do remake the .o [18:31] rtg, no [18:31] rtg, the .c does depend on it, cause you need it made before the other .c is usable [18:31] rtg, so .c is right [18:32] apw, I think either is correct [18:32] * apw gets a headache [18:32] yeah cause you write [18:33] foo.o: foo.c bar.h [18:33] and that is what we are trying to write here [18:33] you don't write [18:33] foo.o: foo.c [18:33] foo.c: foo.h [18:34] apw, '$(obj)/oid_registry.o: $(obj)/oid_registry_data.c $(src)/oid_registry.c' ? [18:34] there is an implicit rule for the first oid_registry.c [18:34] so you don't need that i don't believe [18:34] $(obj)/oid_registry.o: $(obj)/oid_registry_data.c [18:34] apw, on;y if the rule is '::'. right ? [18:35] that sounds reasonable [18:35] $(obj)/oid_registry.o:: $(obj)/oid_registry_data.c [18:36] that seems to work. [18:36] rtg, there are no examples of :: in the kernel Makefiles, so i susspect they are avoiding them [18:36] so if your '$(obj)/oid_registry.o: $(obj)/oid_registry_data.c $(src)/oid_registry.c' works i would use that [18:36] bjf, smb: I have no problems with the kernel tests being out of UTAH. This was a question arosales asked me and smb [18:36] apw, maybe I'll have lunch first and then send something upstream. [18:36] rtg ack [18:37] * rtg -> lunch [18:53] rtg: apw: weird, I just fetched raring master-next, but it does not have 3.8... [18:56] rtg: the dev_change_net_namespace patch was just applied by dmiller to the netdev tree, fwiw [18:56] hallyn, 3.8 ? v3.7-rc8 you mean ? [18:59] bjf, w [18:59] bjf, am i reading this right that this week is prep week for SRUs ? [18:59] apw, saved [18:59] apw, yup! [19:00] bjf, is slightly confusing because it is listed as the 'week of the 6th' ... thanks [19:00] apw, where do you see it? on the interlock schedule? [19:01] yeah on the interlock schedule RR/ReleaseInterlock on the wiki [19:01] apw: oh, i misread then. i was thinking it was going to be 3.8 [19:01] thanks [19:01] silly me :) [19:01] apw, yes, that's because releases happen on thursdays so the calendar goes from thursday to thursday [19:01] apw, it was/is a release manager thing [19:03] bjf, my head is made to hurt by it ... thanks [19:09] bjf, is henrix on the hook for kernel prep this week ? [19:09] apw: i am [19:09] apw, yes, something in particular you are interested in? [19:09] i may have something urgent for precise [19:10] can we spin that one last ? [19:10] apw: well, too late now :) but we can respin it if required [19:13] apw: do you have any idea about when you may have something? i can ping you on thursday about this [19:13] henrix, i hope to have it out for review in the AM, and should know the testing is confirmed (we have tested but waiting on the reporter) by EOD tommorrow i hope [19:14] apw: ok, cool. let me know about it. [19:15] henrix, will do, and thanks [19:15] np [19:15] henrix, and do remember to ping me :/ [19:15] apw: heh, i will [19:22] ogasawara, rtg, ok i have just pushed the first slab of 3.7 config review updates to raring [19:22] apw, ack [19:22] it builds to udebs for me on x86 and armhf, ymmv [19:26] apw: ack, thanks === henrix is now known as henrix_ [19:56] apw, 'PATCH 3.7-rc8] lib/Makefile: Fix oid_registry build dependency' fired upstream [20:28] rtg nice [20:29] apw, the double colon rule was wrong by the way. [20:34] rtg, heh good to know [20:35] what did you go with in the end [20:35] apw, just the simplest change, e.g., .o [20:35] pushed it to raring master-next [20:35] ahh great [20:36] apw, Howell introduced it in -rc1 with the signed modules patch set (I think) [20:36] rtg hence it feels like a new issue [20:37] yep [20:41] * rtg bugs out for the day [20:47] * apw wanders off too [22:46] BenC, i am doing some config cleanup work on master, i also have the equivalent in the works for PPC for once you are rebased to -5. i'll get a pull request to you, so feel free to ignore the config fixes on master i'll do them [22:48] apw: rebased and uploaded on -5 already [22:52] BenC, sweet, then i'll get the config fixes done tommorrow and out to you [23:08] apw: thanks