[07:45] <ppisati> hi
[09:04] <apw> ppisati, hi
[09:10] <cking> morning apw
[09:10] <cking> hey, the 3.13.0-16 -proposed kernel breaks my USB on various thinkpads I have
[09:11] <cking> apw, reverting 65482e0c807a50dc3ec9d59a7465801f9c56bf52 seems to fix it on a t440, I'm just going to try it on my x230
[09:12]  * cking reboots to try it out
[09:14] <cking> yup, that fixes it ;-)
[09:46] <apw> cking, BAH
[09:46] <cking> yup
[09:46] <apw> on the broken kernel does enabling threaded irqs make it work again ?
[09:47] <cking> not tried that
[09:47] <apw> be a good data point for when "we" moan about it
[09:48]  * apw has a looks see if unstable builds with the patch on so you can see if this combo works, ie. rtg missed another commit needed
[09:48]  * cking wished it had been tested ;-)
[09:48] <apw> i am sure he boot tested it, but he may not use USB in that combination.  it would have caught me though
[09:49] <cking> it only caught me because of the low-latency vs generic testing I did last evening
[10:08] <cking> threaded irqs make it work
[10:26] <apw> cking, erp
[10:44] <cking> lemme get an x220 rigged up and tested too
[11:31]  * ppisati ponders why some modules are automagically loaded while others are not... 
[11:31] <ppisati> but before that, food!
[11:58] <wmp> hello, i where i can found kernel 3.11.0-16-generic to 12.04?
[11:58] <wmp> server
[12:01] <apw> wmp, you want an older kernel than the one in -updates yes ?
[12:01] <wmp> yes, now i have 3.11.0.-17 and in them is bug
[12:01] <wmp> i 3.11.0-15 works good, so i want check 3.11.0-16 and report
[12:02] <wmp> apw: on 3.11-17 i have degradated raid on normal booting ubuntu, on rescure grub option works good
[12:02] <wmp> on 3.11-15 all works good
[12:06] <apw> wmp, ok there was no -16 for linux-lts-saucy as far as i can see
[12:07] <apw> 3.11.0-15.25~precise1 then 3.11.0-17.31~precise1, and coming soon -18
[12:07] <wmp> ok, so i should report that works on 3.11-15, and dont works  on 3.11.-17?
[12:07] <apw> could you file a bug against linux-lts-saucy saying that indeed, and post the number here
[12:07] <wmp> ok
[12:13] <wmp> apw: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1288703
[12:13] <ubot2`> Launchpad bug 1288703 in linux (Ubuntu) "3.11-17 MDRAID degradaded in normal boot, but on rescure works good" [Undecided,New]
[12:23] <apw> bjf, ^^
[12:23] <apw> cking, ok this ehci issue does not affect my 32bit tester ...
[12:26]  * apw boots up more kit to see if he can find anything to repo. this
[12:37] <wmp> apw: hmmm, maybe i wrong debugging this bug...
[12:37] <wmp> apw: works on 3.11-15 when i set it manual on grub, when i wait to timeot and grub chose this kernel automatical, server dont boot...
[12:41] <cking> apw, let me try it on some other kit then
[12:41] <apw> cking, t'is very odd to me
[12:43] <cking> yep, it would appear that my tests are doubtful, but I will test on other kit and re-do my tests if required
[12:44] <apw> cking, i have some more kit upgrading now to confirm deny
[12:46]  * cking preps some older kit too
[12:48] <apw> smb, have you used schroot copyfiles at all ?
[12:48] <smb> apw, maybe
[12:52] <xnox> Will "[Config] CONFIG_MICROCODE_EARLY=y" fix be applied across all kernels? (that is precise and all hwe kernels?)
[12:52] <apw> xnox, would we normally want to apply this to older kernels?  noone has needed till now?
[12:53] <apw> smb, bah it seems setup.copyfiles is per chroot, so i have to add it to them all, or do it myself
[12:56] <xnox> apw: right, true. intel-microcode only started to want/use early firmware in 13.06, and 13.10 release is a short-lived one.
[12:57] <smb> apw, Not sure I completely understand the context there. I assumed it was the part that automatically copies in some files which seems to be used automatically
[12:59] <apw> smb, i want to add another file ... to copy in
[13:01] <smb> apw, I thin there where at least a copyfiles file per template which contained the files
[13:01] <smb> at least back in P
[13:02] <smb> Like /etc/schroot/default/copyfiles
[14:05] <zequence> apw: I think it's safe to put threadirqs back in. bug 1279081
[14:05] <ubot2`> Launchpad bug 1279081 in linux (Ubuntu Trusty) "linux freezes with threadirqs parameter when rt73usb is loaded" [High,Fix released] https://launchpad.net/bugs/1279081
[14:13] <rtg> apw, pushed 'Revert "UBUNTU: SAUCE: allow IRQs to be irq-threaded by default via config"'
[15:08] <arges> rtg: tc qdisc add dev eth0 root netem delay 80ms
[15:08] <arges> btw
[15:23] <infinity> BenC: Did you do any linux-ppc/saucy smoketesting so I can release those kernels?
[15:25] <wmp> apw: did you remember my problem with raid? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1288703
[15:25] <ubot2`> Launchpad bug 1288703 in linux (Ubuntu) "3.11-17 MDRAID degradaded in normal boot, but on rescure works good" [Undecided,Incomplete]
[15:25] <wmp> LOL, WTF...
[15:43] <BenC> infinity: I did. All appears ok on my end
[15:43] <infinity> BenC: Shiny, thanks.
[16:19] <BenC> infinity: FYI, that need meta as well (I didn't prepare that one, forgot)
[16:21] <infinity> BenC: I did meta and committed and pushed.
[16:21] <BenC> infinity: Thanks
[16:21] <infinity> I think I've done the last couple.
[16:23] <infinity> And that's all the SRUs for this cadence released.  I can sleep soon now. :P
[16:25] <infinity> BenC, zequence: As always, thanks for the work on the community kernels.  Catch you next cycle for more nagging.
[16:26] <BenC> infinity: Thanks for manging my poor response time with diginity and patience :)
[16:28] <infinity> BenC: I really think that one of these days we need to revisit why we need 5(!) flavours instead of 2.
[16:28] <infinity> BenC: I can't help thinking there pretty much has to be a clever way to mangle things in early setup to work for all 32-bit and all 64-bit in two kernel images.
[16:28] <BenC> infinity: Well, powerpc started with 3, so we just need to discuss the extra two, and I can explain them easily :)
[16:28] <infinity> BenC: 2, not 3... powerpc and powerpc64
[16:29] <rtg> _I_ would sure like to reduce the number of powerpc flavours
[16:29] <infinity> BenC: You have 3 extra flavours on top of that.
[16:29] <BenC> infinity: I can go into more detail, but if benh tells me he's not willing to do the work it will take, I assume it will take us mortals several months to accomplish
[16:29] <BenC> infinity: Oh, right
[16:30] <BenC> infinity: -e500 can go away for all I care. But I think it will be important when we get p-cubed out of our imaginations and into a production facility
[16:31] <infinity> If you have no interest in >= trusty booting on e500, patches/pull-requests welcome to tear it out.
[16:32] <infinity> Unless I should parse your sentence as "I don't care now, but I will again later".
[16:32] <BenC> infinity: the latter
[16:32] <infinity> Right, okay.  No point removing it just to revert the removal later then...
[16:33] <BenC> infinity: If you feel like a phone call to get into the details, let me know
[16:33] <infinity> I suspect if I replace all of our PPC buildds, rtg while whine a bit less, since sagari-class hardware building 5 flavours still beats armhf building two (by a fair bit).
[16:33] <infinity> BenC: A call between you, me, and Tim wouldn't be a bad idea, when I'm not in China.
[16:33] <infinity> BenC: Better still if I can talk Ben into joining, so we can get the upstream port maintainer view on this.
[16:33] <rtg> infinity, I always cross compile for test builds anyways, so having a porter doesn't help much.
[16:34] <infinity> rtg: Sure, I don't mean test builds, but archive builds.
[16:34] <BenC> infinity: Ok
[16:34] <infinity> rtg: When linux/ppc lands on ross or adare and I notice, I kill it and move it. :P
[16:34] <rtg> infinity, right, I don't care about how long archive builds take. armhf is almost always last.
[16:34] <BenC> infinity: BTW, we actually have metal for our 64-bit (proto) system
[16:35] <infinity> rtg: So, except when testing end-to-end with tools, I imagine a single-flavour build will usually catch most things you care about (this would be more true after a config review, if all flavours are building the same set of drivers).
[16:35] <BenC> One of our engineers ran some spec tests and it was 2-3 times better than the 2 x Xeon i5 machine we compared it against
[16:36] <rtg> infinity, sure I can take short-cuts, but I don't want to _have_ to (other then using the cross compiler)
[16:37] <infinity> rtg: Agreed.  I feel your pain (a lot more), since I test build all of Ben's SRUs on a quad-core 2.5G 970MP.
[16:37] <infinity> I guess at least I'm not doing it on my 750...
[16:37] <rtg> yup, I as least have giant servers to mess with
[16:37] <rtg> at*
[16:39] <infinity> BenC: Is that the Freescale powerpc64-emb thing, or some top secret POWER-based part I'm not allowed to know about yet?
[16:39] <BenC> infinity: The former
[16:40] <BenC> We actually showed off the first hot-off-the-press proto type board at an OpenCompute keynote a few weeks ago with MarkZ
[16:40] <infinity> BenC: So, you really should find some cycles (or contract someone) to get some Freescale IFUNC bits in glibc to optimize string and memory functions a bit.
[16:40] <infinity> BenC: Unless the generic PPC stuff actually runs really well for you.
[16:41] <infinity> BenC: But IBM's been pulling out all the stops upstream to optimize the crap out of POWER4/5/6/7/8
[16:41] <BenC> infinity: I'm aware. We are pushing as much as we can
[16:41] <BenC> We, ourselves are working on getting OpenJDK optimized for our own iron
[16:41] <BenC> That's a customer driven effort
[16:42]  * infinity nods.
[16:42] <BenC> infinity: And I'm happy to see that v8 is making progress :)
[16:42] <infinity> BenC: v8 pretty much Just Works on IBM platforms now.  Has Andrew made any progress on your e500 kit?
[16:43] <BenC> infinity: I'm not sure of his progress, but he was logged into and active on our e500mc dev box for a few weeks
[16:43] <infinity> Cool.  If he gets it working, I'll happily take those patches for trusty.
[16:44] <infinity> And I think you'll probably owe him some fine beverages, given that he's technically your competitor. ;)
[17:39] <manjo> kamal, I have a cpu stress program ... wondering if I can send it to debian ....what would it take?
[17:41] <manjo> kamal, any pointers will help
[19:06] <bjf> manjo, how is yours different than the standard stress ?
[19:06] <manjo> bjf, you mean the tool stress ? 
[19:07] <manjo> bjf, what stress is supposed to be is a load generator, what it does for cpu is call sqrt of a random number 
[19:07] <bjf> manjo, i mean http://linux.die.net/man/1/stress
[19:07] <manjo> bjf, what I have is something that will exercise floating pt and integer code paths and also paths that deal with txt and data cache miss 
[19:18] <apw> manjo, quake ?
[19:18] <manjo> lol
[19:19] <manjo> so the idea is that it could be used with our std cert 
[19:19] <manjo> coz they depend on apt-gettable packages 
[19:20] <manjo> or they think that would be the ideal way ... rather than integrating it and having to maintain it themselves 
[19:41]  * apw deferrs to kamal on the whole thing
[19:45] <kamal> manjo, sounds like you've got a program that hasn't yet been packaged, correct?  somebody would need to package it in order to contribute it to Debian.   cking is also working on getting a new cpustress tool packaged.  touch bases with him, yes?
[19:46] <manjo> kamal, I have it packaged.. and building in a ppa ... but yes I will check with cking on what he is doing .. weirdly we might have the same thing going on 
[19:48] <kamal> manjo, oh, you're one step ahead of me.  good man!  :-)   yeah, lmk what you and cking sort out.
[20:36] <manjo> kamal, talked to cking ... I need a git repo it + cleanup and I can send you a link so you can review it 
[20:37] <cking> it needs some spit-n-polish :-)
[21:51] <hallyn> hm.  'fakeroot debian/rules binary-generic' should give me linux-headers*_all.deb right?
[21:51] <hallyn> (cause it's not.  drat)
[22:20] <bjf> hallyn, fdr binary-headers-generic   ... i think
[22:21] <bjf> hallyn, actually, just binary-headers
[22:22] <bjf> hallyn, so fdr binary-headers
[22:24] <hallyn> bjf: thanks!
[22:49] <hallyn> ok - what about linux-libc-dev? :)
[22:53] <hallyn> binary-arch-headers maybe
[22:53]  * hallyn finally found debian/rules.d :)