[13:49] <rtg> bjf, have you ever looked at this (from LKML) ? '[LTP] [ANNOUNCE] The Linux Test Project has been released for APRIL 2014'
[13:50] <rtg> arges, you might be interested as well ^^
[13:51] <arges> rtg: cool are we going to update our autotests?
[13:51] <bjf> rtg, i've run LTP from time to time
[13:51] <rtg> arges, its a bit early to say 
[13:51] <bjf> arges, we update our tests somewhat regularly
[13:52] <rtg> bjf, is that the same LTP that originated at IBM ?
[13:52] <bjf> rtg, i'd have to look but i assume so
[13:52] <rtg> and that we are already using ?
[13:52] <arges> rtg: yes, in fact robbiew worked on it for a while
[13:53] <arges> https://github.com/linux-test-project/ltp/search?q=robbie&ref=cmdform
[13:53] <rtg> well then, just ignore me.
[15:38] <bjf> jsalisbury, you know when we spam all the open bugs for a series at certain times and ask for verification the bugs exist? i think we should do that with trusty bugs now that we've released
[15:39] <jsalisbury> bjf, sounds like a good idea.  I'll run the script
[16:09] <infinity> BenC: Should I take your title change on 1301501 as a hint that you're ready for me to go hunting git tags and upload?
[16:10] <BenC> infinity: yessir
[16:10] <infinity> BenC: Fully build-tested, so I don't have to do it again? :P
[16:10] <BenC> infinity: indeedy
[16:11] <infinity> BenC: Alright.  Let's see if we can get this in and soketested today, so I can release it with the rest of the kernels (ish).
[16:11] <BenC> I’m prepared to soke test it on your command
[16:12] <infinity> bjf: How many more saucy kernels are planned?  When is Ben off the hook? :)
[16:12] <bjf> infinity, support until 14.04.1 sooo ...
[16:13] <bjf> infinity, 4 more?
[16:13] <infinity> Kay.
[16:13] <infinity> Almost there.
[16:18] <BenC> Woot
[16:18]  * BenC reads that as “When will infinity have to stop bugging lazy ass Ben for builds”
[16:22] <infinity> BenC: Yes, that. :)
[16:25] <infinity> BenC: Building.  If it fails, I blame you.
[16:31] <jsalisbury> rtg, is there  ppc machine I can use to test a kernel?  Or maybe someone I can ask to test a kernel for me?
[16:31] <jsalisbury> rtg, I want to test my COMMAND_LINE_SIZE patches before I send them upstream
[16:32] <rtg> jsalisbury, infinity and BenC are powerpc dudes. I don't have any local PPC resources.
[16:33] <BenC> jsalisbury: What’s the change do?
[16:33] <jsalisbury> rtg, ok, thanks.
[16:33] <jsalisbury> BenC, The ppc specific change is to increase the size of COMMAND_LINE_SIZE to 2048 from 512
[16:34] <jsalisbury> BenC, But I also have other patches that change COMMAND_LINE_SIZE from defines to kernel config options
[16:34] <BenC> Is it just a change in config option or actual code?
[16:34] <BenC> Ah
[16:34] <jsalisbury> BenC, yeah, it's not a config option currently, so that is the other change
[16:34] <BenC> jsalisbury: If you send the patch(es) to bcollins@ubuntu.com, I’ll check them out over the weekend
[16:34] <jsalisbury> BenC, powerpc currently pulls the value from asm-generic
[16:35] <jsalisbury> BenC, great, thanks!  They build and boot fine on x86, just want to check powerpc, since it has the size increase change as well.
[16:36] <BenC> I assume this is for things like preseeding?
[16:40] <jsalisbury> BenC, COMMAND_LINE_SIZE increase is for bug: 1306677 .  The change to have it a config option is to allow a cleaner way to change the size for all architectures without directly changing defines in the code.
[16:40] <ubot2> Launchpad bug 1306677 in linux (Ubuntu Trusty) "[PPC64EL] kernel command line gets truncated at 512" [Critical,Fix committed] https://launchpad.net/bugs/1306677
[16:40] <infinity> BenC: Yeah, it's for crazy people who think a massive cmdline is a good idea. ;)
[16:40] <BenC> PPC64EL…definitely crazy people :)
[16:41] <infinity> jsalisbury: OOI, did you scour the tree for other arches where it might be hardcoded and make sure the CONFIG bit applies to all of arch/*?
[16:41] <infinity> jsalisbury: That's likely going to be a prereq for upstream inclusion.
[16:41] <jsalisbury> infinity, yes, I modified it for all arches
[16:42] <infinity> jsalisbury: Shiny.
[16:42] <infinity> Sounds like a worthwhile change.
[16:42] <jsalisbury> infinity, :-)  I did leave asm-generic alone for now though
[16:43] <infinity> (The config option sounds like a worthwhile change, that is, I'm entirely refusing to have an opinion on the lunacy of people needing more than 512 chars to start with)
[16:45] <jsalisbury> infinity, the size increase for bug 1306677 was due to MaaS needing a larger command line to pass iscsi targes and cloud-init parameters
[16:45] <ubot2> Launchpad bug 1306677 in linux (Ubuntu Trusty) "[PPC64EL] kernel command line gets truncated at 512" [Critical,Fix committed] https://launchpad.net/bugs/1306677
[16:45] <infinity> jsalisbury: Oh, I know the reasoning, I still think it's nutty.
[16:45] <jsalisbury> infinity, ack
[16:46] <jsalisbury> BenC, I sent the patches to your email.   Thanks for the help!
[16:46] <infinity> jsalisbury: Either way, making it a global CONFIG means we can be nutty on our own with minimal effort, so yay.
[16:46] <BenC> jsalisbury: Got them
[16:46] <BenC> jsalisbury: FWIW, I think the CONFIG option should default to 512
[16:46] <BenC> 256 sounds a little low
[16:47] <infinity> Wouldn't either of those be a regression on x86?
[16:47] <infinity> Which, I assume, was previously hardcoded to 2048?
[16:47] <infinity> Or was that a local Ubuntu patch?
[16:47] <jsalisbury> BenC, yeah, I just kept all of the values what they are currently set to for the initial patch
[16:47] <BenC> NM, I see
[16:47] <BenC> You have a default for each arch
[16:47] <infinity> jsalisbury: Oh, you have it default to different things for different arches?  That's... Confusing.
[16:48] <BenC> It is. I would have suspected you moved it to init/Kconfig or kernel/Kconfig and unify them to some sane default
[16:48] <infinity> I guess if the help text is clear on that, it makes some sense to avoid surprises on upgrades.
[16:48] <infinity> But moving from 256/512 to 2048 isn't likely to really cause anyone problems.
[16:48] <jsalisbury> infinity, yes, each arch has it's own default.  However, some just use asm-generic for a default like sh and powerpc was as well.
[16:48] <infinity> And those three people can set it back down again. :P
[16:49] <BenC> Hehe
[16:49] <infinity> jsalisbury: I'm not the maintainer who will have to review this (and, given that it's generic, that may well end up being Linus), but my gut feeling is the same as Ben's, it should just be truly generic.
[16:50] <jsalisbury> infinity, Yeah, I figured I'd get some feedback from upstream and have a version or two to re-send
[16:50] <infinity> Almost no one is so memory-contrained that losing 1.5k matters, and those sorts of people will be so happy to have a config twiddle now that they won't care that the default changed, IMO.
[16:52] <jsalisbury> BenC, infinity, setting them all to one default in init/Kconfig would really simplify the patch.  Maybe I should send that as a v1
[16:52] <BenC> RFC that idea
[16:52] <apw> BenC, BOOK3E and BOOK3S is that all yours?
[16:53] <BenC> apw: book3e is (book3s is things like IBM and PowerMac)
[16:54] <jsalisbury> BenC, ack. 
[16:54] <apw> BenC, ok, so we have an oddy in boot3e with 3.15-rc, in that the BOOK3E code specifically references __end_interrupts but that code is only present when BOOK3S is enabled as well
[16:54] <jsalisbury> BenC, infinity, Thanks for the feedback!
[16:54] <apw> BenC, do i assume BOOK3S should be enabled as well, or is something more fundamental ill
[16:55] <BenC> apw: Can’t enable both…I’ll check the build and see
[16:55] <infinity> jsalisbury: I would like to assume (but possibly incorrectly) that that memory is freed at runtime anyway, and the representation in /proc/cmdline is truncated to the actual length of the provided string, not padded out to the max.
[16:56] <infinity> jsalisbury: If that's not true, some people might actually whine about losing 1.5k at runtime but, like I said, having a CONFIG option makes it trivial for them to fix too, so meh.
[16:57] <jsalisbury> infinity, I don't actually know off hand, but that is something I will now check and provide in the RFC
[16:58] <BenC> apw: In case it isn’t apparent, the megaraid_sas patch I had is now upstream in 3.15-rc
[16:58] <infinity> BenC: Does anyone ever intend to revisit why 3e and 3s can't coexist in a single build?  Will it take locking a Freescale engineer and an IBM engineer in a room until they write the early init code required to make it work?
[16:59] <BenC> infinity: benh proclaims it nearly impossible to do sanely, so I’ve abandoned all hope
[16:59] <infinity> BenC: People said that about the crazy x86 early init rewrites too, and then someone did it.
[17:00] <BenC> infinity: I’ll wait for someone with that sort of lack of sanity to crop up…I am not he, and I doubt he sits behind a desk at fsl or ibm :)
[17:00] <infinity> BenC: I'm guessing "nearly impossible" just means "no one has the time to make it a priority", which is fair, but unfortunate for people like us who build 5 flavours when we could probably have 2 or 3.
[17:00] <infinity> BenC: Speaking of, can any of your flavours go away yet, or are you still supporting all 3?
[17:01] <BenC> infinity: I’m personally not opposed to the -e500 going away (we need -e500mc and powerpc64-emb)
[17:01] <infinity> BenC: Is e500 effectively dead hardware from your end?
[17:01] <infinity> BenC: rtg would be thrilled to drop e500 if you don't care.  We're really only carrying it for you anyway.
[17:01] <BenC> For us, yes, but it does exist
[17:02] <BenC> I doubt anyone would ever notice
[17:02] <infinity> Sure, but like I said, we're only really carrying those flavours for servergy anyway.  I doubt anyone runs those kernels on other whacky fsl hardware.
[17:02] <BenC> It was for our P-Cubed platform, but we’re looking at something with e500mc or e6500 for that now anyway
[17:02]  * rtg rips out -e500 with no hesitation
[17:02]  * BenC hears the screams of tiny soft-float SoC’s crying out in pain
[17:03] <infinity> Heh.
[17:03] <infinity> BenC: Wait, e500 was sf?  Did you do awful trapping and emulation tricks, cause our userspace is hf...
[17:04] <infinity> If so, good riddance, I say.  The performance must have been awful anyway.
[17:04] <BenC> infinity: mathemu in kernel…but most e500’s are hard float (e500v2)
[17:05] <BenC> I doubt anyone using an e500 was concerned with performance
[17:06] <infinity> BenC: Also seems like a lousy target for a general purpose OS, thogh.
[17:06] <infinity> So, yeah.  Let's just drop it if you guys no longer have a product based on it and have a carefactor approaching zero.
[17:07] <BenC> infinity: It’s not. We were only doing to support it from the perspective of getting developer boards out to the masses as cheaply as possible, while still having some of the features of our SoC (security off-load engines and such)
[17:11] <BenC> apw: Build started…if it succeeds, I’ll need your wip config to find out what the diff is
[17:12] <BenC> But it’s definitely BOOK3E=y and BOOK3S is not set
[17:12] <BenC>   LD      vmlinux
[17:12] <BenC>   SYSMAP  System.map
[17:12] <BenC> And it linked
[17:12] <infinity> BenC: Fun.  Was that upstream sources, or our git?
[17:13] <BenC> apw: I think I see why…it’s referenced in kvm…let me turn that one
[17:13] <BenC> infinity: upstream, but I think it’s a config option
[17:13] <infinity> BenC: Right.  Well, ubuntu-utopic/master-next would likely get you what apw is playing with.
[17:14] <apw> indeed that one
[17:14] <apw> BenC, the code in question is under CONFIG_RELOCATABLE
[17:16] <apw> __after_prom_start is what is referencing it
[17:17] <BenC> Probably just need to wrap it’s use in CONFIG_PPC_BOOK3S, but I’ll make sure
[17:18] <apw> BenC, thanks
[17:19] <apw> BenC, well the code seems to have been made 3E specific already, but ...
[17:19] <BenC> apw: Well, that was successful…KVM enabled and RELOCATABLE is as well
[17:20] <BenC> #if defined(CONFIG_RELOCATABLE) && defined(CONFIG_PPC_BOOK3S)
[17:20] <BenC>         /* On relocatable kernels interrupts handlers and our code
[17:20] <BenC>            can be in different regions, so we don't patch them */
[17:20] <BenC>         if ((ulong)inst < (ulong)&__end_interrupts)
[17:20] <BenC>                 return;
[17:20] <BenC> #endif
[17:20] <BenC> apw: Does the code look like that to you?
[17:20] <apw> nope this is assembly which is barfing,
[17:20] <apw> #ifdef CONFIG_PPC_BOOK3E
[17:20] <apw>         LOAD_REG_ADDR(r3, __end_interrupts)
[17:20] <apw>         LOAD_REG_ADDR(r11, _stext)
[17:21] <BenC> What file is that in?
[17:21] <apw> arch/powerpc/kernel/head_64.S:494
[17:21] <apw> which is definatly not taking BOOK3S into account
[17:21] <BenC> Ah, this is on 64-bit
[17:21] <BenC> I was building 32-bit
[17:22] <apw> i was building the powerpc64-emb flavour indeed
[17:24] <BenC> apw: Are there sauce patches against that file?
[17:24] <BenC> apw: If so, ditch them all and I’ll revisit them next week to review if anything needs to be added back
[17:27] <apw> c39b6bb book3e/kexec/kdump: recover "r4 = 0" to create the initial TLB
[17:27] <apw> 0d11d6c book3e/kexec/kdump: introduce a kexec kernel flag
[17:27] <apw> b745be4 book3e/kexec/kdump: create a 1:1 TLB mapping
[17:27] <apw> 6805359 powerpc/book3e: support CONFIG_RELOCATABLE
[17:27] <apw> BenC, according to git, i'll have a look see if any of them are bust
[17:28] <BenC> apw: Please remove them all. They don’t even accomplish what they are there for anyway
[17:28] <BenC> I’m hoping the actual fixes are upstream by now, but I wont be able to test right now
[17:28] <apw> BenC, ack will do that and re-test and let you know
[17:28] <BenC> Thanks
[17:30] <rtg> apw, think I've got powerpc-e500 ripped out, patches pushed.
[17:30]  * rtg -> lunch
[17:31] <apw> rtg, ripped out as in gone, or as in "genericised"
[17:36] <BenC> apw: adios
[17:36] <apw> laters
[17:37] <BenC> apw: I mean e500 is adios :)
[17:37] <apw> /home/apw/build/ubuntu-utopic/ubuntu-utopic/arch/powerpc/kernel/head_64.S:460: Error: cannot emit PC relative BFD_RELOC_PPC64_HIGHEST relocation against __end_interrupts
[17:37] <apw> BenC, heh ... i see, and removing those patches just made teh wrror change
[17:37] <BenC> apw: Disable RELOCATABLE on powerpc64-emb
[17:38] <apw> ack
[17:50] <apw> BenC, with RELOCATABLE off, i get all new errors:
=== sz0 is now known as sz0`
[17:50] <apw> /home/apw/build/ubuntu-utopic/ubuntu-utopic/arch/powerpc/kernel/exceptions-64e.S:738:(.text+0x19526): relocation truncated to fit: R_PPC64_ADDR16_HI against symbol `interrupt_base_book3e' defined in .text section in arch/powerpc/kernel/built-in.o
[17:50] <BenC> apw: Is that an error or warning?
[17:51] <BenC> apw: If you can leave things as-is (before removing the old sauce patches) I’ll work on it tonight so it doesn’t hold you up
[17:52] <apw> BenC, tim has the flavour disabled right now, so its not stopping him i don't think
[17:53] <apw> BenC, and they seem to be the only things which account for the link failure which terminates the build
=== sz0` is now known as sz0
[17:53] <BenC> Ok
=== mjg59` is now known as mjg59
=== sz0 is now known as sz0`
[22:38] <infinity> BenC: Still around?
[23:00] <infinity> BenC: If you're around, that kernel should be in -proposed now, if you want to give it a quick smoketest so I can release it.