[03:20] <BenC> apw: success
[10:56] <apw> kees, poke me tommorrow, i am off today
[12:59]  * henrix -> lunch
[13:24] <caribou> rtg: Regarding hpwdt, it's already in ./config/config.common.ubuntu for Q & R; should I mark it "Fix released" ?
[13:25] <rtg> caribou, too late
[13:25] <caribou> rtg: :-) didn't refresh quick enough
[13:25] <BenC> apw: cjwatson says you two talked about the lack of arch-all builds for linux-ppc…what was the verdict?
[13:25] <caribou> rtg: thanks
[13:42] <bambee> hi , on quantal, with a core i7 ivy bridge (Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09) ) I always get this error in dmesg
[13:43] <bambee> [19327.764996] [drm:drm_gem_create_mmap_offset] *ERROR* failed to allocate offset for bo 0
[13:43] <bambee> my screens change from a normal mode to black... randomly...
[13:43] <bambee> any ideas?
[13:44] <bambee> It worked just fined on precise
[13:44] <apw> BenC, ok i believe you need to switch the architecture:all things to :powerpc
[13:44] <bambee> it's a regression introduced in quantal
[13:44] <apw> and then there is a switchable
[13:44]  * smb slaps apw
[13:45] <apw> smb, i know, shhh
[13:45] <rtg> apw, you're already out of bed? I thought you fancied a lie in today.
[13:45] <apw> BenC, I believe it is do_common_headers_indep should be false
[13:46] <apw> BenC, you should be able to test that on a local build building binary-arch
[13:46] <BenC> apw: Ah
[13:46] <BenC> thanks
[13:47] <apw> BenC, do_flavour_header_package turns it on and off, and do_common_headers_indep says if it is :all or :<arch>
[13:47] <apw> rtg, i am not here, you cannot see me, your meds are affecting your eyesight
[13:47] <rtg> apw who ?
[13:47] <apw> rtg, i am really doing my tax return which is so much less stressfull
[13:48] <smb> arrrrrgh
[13:48] <smb> At least now its understandable why you cannot resist irc
[13:48] <apw> exactly ... anything is better than that
[13:49] <smb> apw, Already wearing the paper suit?
[13:51] <apw> smb, yep, socks paired the whole 9 yards; thinking of painting the wall using my toothbrush
[13:51] <smb> :)
[14:08] <smb> rtg, Ok, I think if the v01 on the IVRS table means what I think it means, I only have a v1 iommu
[14:16] <rtg> smb, I can always drop that patch until it can get properly tested.
[14:19] <smb> rtg, No, actually I think it should be ok as it is creating a new module that in theory should only be used on affected hw and since it is sru it won't survive stable testing without verification (normally)
[14:19] <rtg> smb, that presumes that stable testing has a xen host
[14:21] <smb> rtg, Actually I think that even is independent of Xen. Though I am not sure how much these things are used normally. At least we would expect whoever filed the bug to have the hardware and let us know
[14:33] <xnox> ogasawara: at uds, in passing, I've asked you if it would be possible to pull some patches and build experimental kernels for me. The condition was "do the patches apply cleanly".
[14:33] <xnox> well they do.
[14:34] <ogasawara> xnox: sure, send me an email with the list of patches and I'll build you a test kernel
[14:34] <xnox> I pushed them to git@github.com:xnox/linux.git the ubuntu-raring-master-f2fs which is on top of ubuntu-raring master
[14:34] <xnox> or I can format patches.
[14:35] <xnox> ogasawara: awesome. thanks.
[14:35] <ogasawara> xnox: sweet, I'll just build from your tree
[14:36] <ogasawara> xnox: I'm assuming you need an amd64 build?
[14:36] <xnox> ogasawara: I want it for i386, amd64, armhf (panda, ac100, nexus7)
[14:36] <ogasawara> xnox: ack
[14:37] <xnox> ogasawara: the last three being most important, as it's the new flash filesystem  I want to play with and I have that hardware available.
[14:45] <xnox> ogasawara: send the "pull & build" request to your work email.
[14:45] <ogasawara> xnox: thanks
[14:45] <xnox> ogasawara: thank you =))))
[14:54] <rtg> bjf, can you try a kernel from http://kernel.ubuntu.com/~rtg/3.7-rc5.1 on your Lexington Emerald Ridge again ? 
[15:12] <rtg> ogasawara, can you do some smoke testing on http://kernel.ubuntu.com/~rtg/3.7-rc5.1 ?
[15:12] <ogasawara> rtg: yep, will do
[15:12] <rtg> 'tanks
[15:16] <bjf> rtg, will do
[15:22] <cking> me too 
[15:23] <rtg> cking, thanks
[15:25] <rtg> bjf, I'm seeing similar pcpu_alloc faults on an AMD server
[15:28] <cking> rtg, what kind of hardware shall I exercise this on, I've got plenty to chose from
[15:28] <rtg> cking, I suppose whatever doesn't require a signed kernel
[15:31] <rtg> cking, I'm starting a bisect for 'PERCPU: allocation failed' because its starting to show up more often
[15:32]  * cking wonders what's tickling this bug
[15:33] <rtg> cking, multiple CPUs perhaps ?
[15:33] <cking> hrm
[15:33] <rtg> this is a 2-way AMD. bjf saw it on a 4-way Romley
[15:34]  * cking will expercise it on a bunch of SMP kit
[15:34] <cking> expercise? exercise, doh
[15:35] <rtg> cking, I didn't even notice until you corrected it :) you see what you expect to see.
[15:38] <smb> rtg, Do the percpu messages say something more (like which module)? Sounds like something doing bigger dynamic percpu variable allocations...
[15:40] <rtg> smb, [    7.261175] kvm: Could not allocate 304 bytes percpu data. So it might be https://lkml.org/lkml/2012/10/11/198
[15:42] <smb> rtg, Hm, maybe. Hmm, maybe depending on the maximum possible cpus not the available ones... Otherwise it sounds weird that your 2way has the same issue with it than the 40core box...
[15:43] <smb> But at least the same problem with kvm module now loading automatically...
[15:44] <rtg> smb, I'll try it with that commit reverted
[15:48]  * smb wodners what version weed some people smoke,,,
[15:49] <rtg> smb, drifting in your window ?
[15:49] <smb> rtg, more on my keyboard. While wondering about the 2.6.0 version
[15:50] <smb> rtg, fwiw I don't see the same on Quantal running on my 4 core i7
[15:53] <ogasawara> rtg: works on my test kit here which are a mix of amd64 and i386 and ranging from full raring installs, quantal installs, and precise+enablement stack installs.  I did quick boot tests, pings out to the network, audio, and suspend/resume on the laptops.
[15:54] <rtg> ogasawara, did you check dmesg for PERCPU allocation failures ?
[15:54] <ogasawara> rtg: yep, I didn't see any, but I did see an interesting error on my adamo which is a Precise + enablement stack -> "Request for unknown module key 'Magrathea: Glacier signing key: d
[15:54] <ogasawara> 185d6ac223b0843daf202524618aa134d085f80' err -11"
[15:55]  * ogasawara back in 20
[15:58] <rtg> ogasawara, dkms ?
[16:00] <rtg> smb, reverting e9bda3b3d0ce775afe15eaf71922d342cc74991c didn't fix it. guess I'll use some mainline kernels to do a gross bisect.
[16:01] <smb> rtg, Hm, ok. Though it was so tempting to think about it as the allocation size just was exactly the same
[16:04]  * smb cannot believe do-release-upgrade was broken that badly in Quantal (or even is for the textual version)
[16:05]  * cking can't seem to trigger any PERCPU issues as yet
[16:09] <jsalisbury> **
[16:09] <jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
[16:09] <jsalisbury> **
[16:17] <ogasawara> rtg: it shouldn't be dkms related on this laptop, I'll try and see if I can track down the root cause.
[16:17] <rtg> ogasawara, did it fail to load, or just complain ?
[16:18] <ogasawara> rtg: just complained.  everything seems to be running fine as far as I can tell.
[16:18] <rtg> ogasawara, prolly OK to ignore it then
[16:25] <janimo> rtg, all kernel packages should depend on linux-firmware?
[16:26] <rtg> janimo, no. why do you think so ?
[16:26] <janimo> rtg, just that the dep got autogenerated it seems in the nexus7 package as well
[16:26] <rtg> linux-firmware is seeded for our install images
[16:26] <janimo> rtg, also because maybe some usb wifi or other peripherals can be used on any system
[16:27] <rtg> janimo, which is why it is seeded
[16:28] <janimo> Depends: linux-image-3.1.10-7-nexus7, linux-firmware
[16:28] <janimo>  in linux-image-nexus7
[16:28] <janimo> I need to see where that came from then
[16:48] <bjf> rtg, i am not getting those errors any longer on the emerald ridge. still no console though
[16:50] <rtg> bjf, I'm finding it on this AMD as far back as Quantal. I've yet to find a kernel where it doesn't happen.
[17:00] <jsalisbury>  ** Ubuntu Kernel Team Meeting Happening Now in #ubuntu-meeting
[17:06] <cking> blink and you've missed it
[17:06] <jsalisbury> :-)
[17:07] <xnox> wow. Ubuntu kernel meetings are really rt meetings.
[17:23]  * smb offline for tinkering...
[17:27] <ppisati> rtg: (quantal-amd64)ppisati@tangerine:~/ubuntu-raring$ dpkg-buildpackage -us -uc
[17:27] <ppisati> [snip]
[17:27] <ppisati> dpkg-checkbuilddeps: Unmet build dependencies: libunwind8-dev libaudit-dev
[17:28] <ppisati> doesn't happen when building armhf tough
[17:28] <rtg> ppisati, why wouldn't you use a raring chroot ?
[17:28] <ppisati> ah
[17:28] <rtg> ppisati, and armel is gone
[17:28] <ppisati> right, we are in raring...
[17:28] <rtg> for raring
[17:28] <ppisati> nevermind
[17:28] <ppisati> yeah, saw that
[17:47]  * ppisati -> EOD
[18:02]  * rtg bisects between 3.5.0-rc1 and 3.5.0-rc2 for PERCPU allocation failures
[18:19]  * rtg -> lunch
[18:40] <infinity> Hrm.  Have we finally reached a critical mass of "too many kernel SRUs to QA in a timely fashion", or did UDS (and recovering from it) just throw off the cadence a bit?
[18:41] <henrix> infinity: i believe the delay is due to bug #1076963
[18:41] <ubot2> Launchpad bug 1076963 in Launchpad itself "SPPH.getPublishedBinaries timing out" [Critical,Triaged] https://launchpad.net/bugs/1076963
[18:41] <bjf> infinity, there were other factors, we'll get caught up i think
[18:43] <infinity> rtg / janimo: (looking at backscroll) all image metapackages absolutely do depend on linux-firmware...
[18:44] <infinity> rtg / janimo: Which seems correct, so I'm not sure what Jani's question was about.
[18:44] <janimo> infinity, it was just a curiosity really, thanks
[18:45] <infinity> janimo: Mmkay.  On a platform where you definitely knew you didn't need any of the firmware, dropping that dep from your meta would be fine.  Though, that's clearly not the case for nexu7, where we're doing weird things like attaching all sorts of USB thingees to it. :P
[18:46] <infinity> (And, realistically, won't be the case for any kernel we support as a generic computing device, as opposed to some phone/tablet preinstalled mojo)
[18:46] <janimo> infinity, I agree,
[18:51] <infinity> henrix / bjf: Alright, cool.  Was more a curiosity thing than anything else.  And wondering if you guys needed to multiply at some point. ;)
[20:37] <arges> sforshee, hi
[20:38] <arges> sforshee, re: 922906. Those set of 9 patches are in linux-next, do i need to wait until they land in Linus' tree to SRU?
[20:38] <sforshee> arges, that's usually preferred but not mandatory
[20:39] <sforshee> arges, they've been in linux-next for several releases though, something needs to be done to get the ball rolling upstream too
[20:39] <arges> sforshee, ok. what can I do to get the ball rolling?
[20:39] <sforshee> I suppose ping Eric Paris and ask why he hasn't asked Linus to pull them
[20:39] <arges> ok
[20:41]  * rtg hates it when a bisect fails to produce a reasonable result
[20:47]  * rtg -> EOD
[20:50] <arges> sforshee, any idea where that tree is? is this on kernel.org? i'm assuming its something fsdevel?
[20:57] <sforshee> arges, I found it earlier ... just a second
[20:57] <sforshee> arges, http://git.infradead.org/users/eparis/notify.git
[20:57] <arges> sforshee, awesome thanks. i couldn't find it via google and the usual places
[20:58] <sforshee> arges, within the linux-next repo there's a file called Next/Trees that shows all the repos that linux-next pulls from
[20:58] <arges> ah
[21:11] <vanhoof> ogasawara: hola
[21:11] <ogasawara> vanhoof: konichiwa, call?
[21:11] <vanhoof> ogasawara: sure you free?
[21:11] <ogasawara> vanhoof: ya, gimme 1min
[23:04] <darkxst> currently vmware/vmplayer fail to install on raring due to a moved file (version.h) in the kernel headers, would it be acceptable to work around this with adding a symlink in the headers package  until vmware catch up with the changes?
[23:14] <jjohansen> apw, ogasawara: https://lkml.org/lkml/2012/11/12/446, this may be affecting our lower memory images (/me is thinking arm)
[23:20] <apw> jjohansen, thanks ... P and up huh
[23:21] <jjohansen> yeah: apparently it took quite the effort for google to track that one down
[23:58] <apw> jjohansen, if they are seeing it, then "low memory" may be not as low as we might think