rtgbjf, have you ever looked at this (from LKML) ? '[LTP] [ANNOUNCE] The Linux Test Project has been released for APRIL 2014'13:49
rtgarges, you might be interested as well ^^13:50
argesrtg: cool are we going to update our autotests?13:51
bjfrtg, i've run LTP from time to time13:51
rtgarges, its a bit early to say 13:51
bjfarges, we update our tests somewhat regularly13:51
rtgbjf, is that the same LTP that originated at IBM ?13:52
bjfrtg, i'd have to look but i assume so13:52
rtgand that we are already using ?13:52
argesrtg: yes, in fact robbiew worked on it for a while13:52
rtgwell then, just ignore me.13:53
bjfjsalisbury, 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 released15:38
jsalisburybjf, sounds like a good idea.  I'll run the script15:39
infinityBenC: 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:09
BenCinfinity: yessir16:10
infinityBenC: Fully build-tested, so I don't have to do it again? :P16:10
BenCinfinity: indeedy16:10
infinityBenC: 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
BenCI’m prepared to soke test it on your command16:11
infinitybjf: How many more saucy kernels are planned?  When is Ben off the hook? :)16:12
bjfinfinity, support until 14.04.1 sooo ...16:12
bjfinfinity, 4 more?16:13
infinityAlmost there.16:13
* BenC reads that as “When will infinity have to stop bugging lazy ass Ben for builds”16:18
infinityBenC: Yes, that. :)16:22
infinityBenC: Building.  If it fails, I blame you.16:25
jsalisburyrtg, 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
jsalisburyrtg, I want to test my COMMAND_LINE_SIZE patches before I send them upstream16:31
rtgjsalisbury, infinity and BenC are powerpc dudes. I don't have any local PPC resources.16:32
BenCjsalisbury: What’s the change do?16:33
jsalisburyrtg, ok, thanks.16:33
jsalisburyBenC, The ppc specific change is to increase the size of COMMAND_LINE_SIZE to 2048 from 51216:33
jsalisburyBenC, But I also have other patches that change COMMAND_LINE_SIZE from defines to kernel config options16:34
BenCIs it just a change in config option or actual code?16:34
jsalisburyBenC, yeah, it's not a config option currently, so that is the other change16:34
BenCjsalisbury: If you send the patch(es) to bcollins@ubuntu.com, I’ll check them out over the weekend16:34
jsalisburyBenC, powerpc currently pulls the value from asm-generic16:34
jsalisburyBenC, great, thanks!  They build and boot fine on x86, just want to check powerpc, since it has the size increase change as well.16:35
BenCI assume this is for things like preseeding?16:36
jsalisburyBenC, 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
ubot2Launchpad bug 1306677 in linux (Ubuntu Trusty) "[PPC64EL] kernel command line gets truncated at 512" [Critical,Fix committed] https://launchpad.net/bugs/130667716:40
infinityBenC: Yeah, it's for crazy people who think a massive cmdline is a good idea. ;)16:40
BenCPPC64EL…definitely crazy people :)16:40
infinityjsalisbury: 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
infinityjsalisbury: That's likely going to be a prereq for upstream inclusion.16:41
jsalisburyinfinity, yes, I modified it for all arches16:41
infinityjsalisbury: Shiny.16:42
infinitySounds like a worthwhile change.16:42
jsalisburyinfinity, :-)  I did leave asm-generic alone for now though16:42
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:43
jsalisburyinfinity, the size increase for bug 1306677 was due to MaaS needing a larger command line to pass iscsi targes and cloud-init parameters16:45
ubot2Launchpad bug 1306677 in linux (Ubuntu Trusty) "[PPC64EL] kernel command line gets truncated at 512" [Critical,Fix committed] https://launchpad.net/bugs/130667716:45
infinityjsalisbury: Oh, I know the reasoning, I still think it's nutty.16:45
jsalisburyinfinity, ack16:45
jsalisburyBenC, I sent the patches to your email.   Thanks for the help!16:46
infinityjsalisbury: Either way, making it a global CONFIG means we can be nutty on our own with minimal effort, so yay.16:46
BenCjsalisbury: Got them16:46
BenCjsalisbury: FWIW, I think the CONFIG option should default to 51216:46
BenC256 sounds a little low16:46
infinityWouldn't either of those be a regression on x86?16:47
infinityWhich, I assume, was previously hardcoded to 2048?16:47
infinityOr was that a local Ubuntu patch?16:47
jsalisburyBenC, yeah, I just kept all of the values what they are currently set to for the initial patch16:47
BenCNM, I see16:47
BenCYou have a default for each arch16:47
infinityjsalisbury: Oh, you have it default to different things for different arches?  That's... Confusing.16:47
BenCIt is. I would have suspected you moved it to init/Kconfig or kernel/Kconfig and unify them to some sane default16:48
infinityI guess if the help text is clear on that, it makes some sense to avoid surprises on upgrades.16:48
infinityBut moving from 256/512 to 2048 isn't likely to really cause anyone problems.16:48
jsalisburyinfinity, 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
infinityAnd those three people can set it back down again. :P16:48
infinityjsalisbury: 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:49
jsalisburyinfinity, Yeah, I figured I'd get some feedback from upstream and have a version or two to re-send16:50
infinityAlmost 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:50
jsalisburyBenC, infinity, setting them all to one default in init/Kconfig would really simplify the patch.  Maybe I should send that as a v116:52
BenCRFC that idea16:52
apwBenC, BOOK3E and BOOK3S is that all yours?16:52
BenCapw: book3e is (book3s is things like IBM and PowerMac)16:53
jsalisburyBenC, ack. 16:54
apwBenC, 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 well16:54
jsalisburyBenC, infinity, Thanks for the feedback!16:54
apwBenC, do i assume BOOK3S should be enabled as well, or is something more fundamental ill16:54
BenCapw: Can’t enable both…I’ll check the build and see16:55
infinityjsalisbury: 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:55
infinityjsalisbury: 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:56
jsalisburyinfinity, I don't actually know off hand, but that is something I will now check and provide in the RFC16:57
BenCapw: In case it isn’t apparent, the megaraid_sas patch I had is now upstream in 3.15-rc16:58
infinityBenC: 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:58
BenCinfinity: benh proclaims it nearly impossible to do sanely, so I’ve abandoned all hope16:59
infinityBenC: People said that about the crazy x86 early init rewrites too, and then someone did it.16:59
BenCinfinity: 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
infinityBenC: 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
infinityBenC: Speaking of, can any of your flavours go away yet, or are you still supporting all 3?17:00
BenCinfinity: I’m personally not opposed to the -e500 going away (we need -e500mc and powerpc64-emb)17:01
infinityBenC: Is e500 effectively dead hardware from your end?17:01
infinityBenC: rtg would be thrilled to drop e500 if you don't care.  We're really only carrying it for you anyway.17:01
BenCFor us, yes, but it does exist17:01
BenCI doubt anyone would ever notice17:02
infinitySure, 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
BenCIt was for our P-Cubed platform, but we’re looking at something with e500mc or e6500 for that now anyway17:02
* rtg rips out -e500 with no hesitation17:02
* BenC hears the screams of tiny soft-float SoC’s crying out in pain17:02
infinityBenC: Wait, e500 was sf?  Did you do awful trapping and emulation tricks, cause our userspace is hf...17:03
infinityIf so, good riddance, I say.  The performance must have been awful anyway.17:04
BenCinfinity: mathemu in kernel…but most e500’s are hard float (e500v2)17:04
BenCI doubt anyone using an e500 was concerned with performance17:05
infinityBenC: Also seems like a lousy target for a general purpose OS, thogh.17:06
infinitySo, yeah.  Let's just drop it if you guys no longer have a product based on it and have a carefactor approaching zero.17:06
BenCinfinity: 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:07
BenCapw: Build started…if it succeeds, I’ll need your wip config to find out what the diff is17:11
BenCBut it’s definitely BOOK3E=y and BOOK3S is not set17:12
BenC  LD      vmlinux17:12
BenC  SYSMAP  System.map17:12
BenCAnd it linked17:12
infinityBenC: Fun.  Was that upstream sources, or our git?17:12
BenCapw: I think I see why…it’s referenced in kvm…let me turn that one17:13
BenCinfinity: upstream, but I think it’s a config option17:13
infinityBenC: Right.  Well, ubuntu-utopic/master-next would likely get you what apw is playing with.17:13
apwindeed that one17:14
apwBenC, the code in question is under CONFIG_RELOCATABLE17:14
apw__after_prom_start is what is referencing it17:16
BenCProbably just need to wrap it’s use in CONFIG_PPC_BOOK3S, but I’ll make sure17:17
apwBenC, thanks17:18
apwBenC, well the code seems to have been made 3E specific already, but ...17:19
BenCapw: Well, that was successful…KVM enabled and RELOCATABLE is as well17:19
BenC#if defined(CONFIG_RELOCATABLE) && defined(CONFIG_PPC_BOOK3S)17:20
BenC        /* On relocatable kernels interrupts handlers and our code17: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
BenCapw: Does the code look like that to you?17:20
apwnope this is assembly which is barfing,17:20
apw#ifdef CONFIG_PPC_BOOK3E17:20
apw        LOAD_REG_ADDR(r3, __end_interrupts)17:20
apw        LOAD_REG_ADDR(r11, _stext)17:20
BenCWhat file is that in?17:21
apwwhich is definatly not taking BOOK3S into account17:21
BenCAh, this is on 64-bit17:21
BenCI was building 32-bit17:21
apwi was building the powerpc64-emb flavour indeed17:22
BenCapw: Are there sauce patches against that file?17:24
BenCapw: If so, ditch them all and I’ll revisit them next week to review if anything needs to be added back17:24
apwc39b6bb book3e/kexec/kdump: recover "r4 = 0" to create the initial TLB17:27
apw0d11d6c book3e/kexec/kdump: introduce a kexec kernel flag17:27
apwb745be4 book3e/kexec/kdump: create a 1:1 TLB mapping17:27
apw6805359 powerpc/book3e: support CONFIG_RELOCATABLE17:27
apwBenC, according to git, i'll have a look see if any of them are bust17:27
BenCapw: Please remove them all. They don’t even accomplish what they are there for anyway17:28
BenCI’m hoping the actual fixes are upstream by now, but I wont be able to test right now17:28
apwBenC, ack will do that and re-test and let you know17:28
rtgapw, think I've got powerpc-e500 ripped out, patches pushed.17:30
* rtg -> lunch17:30
apwrtg, ripped out as in gone, or as in "genericised"17:31
BenCapw: adios17:36
BenCapw: 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_interrupts17:37
apwBenC, heh ... i see, and removing those patches just made teh wrror change17:37
BenCapw: Disable RELOCATABLE on powerpc64-emb17:37
apwBenC, with RELOCATABLE off, i get all new errors:17:50
=== sz0 is now known as sz0`
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.o17:50
BenCapw: Is that an error or warning?17:50
BenCapw: 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 up17:51
apwBenC, tim has the flavour disabled right now, so its not stopping him i don't think17:52
apwBenC, and they seem to be the only things which account for the link failure which terminates the build17:53
=== sz0` is now known as sz0
=== mjg59` is now known as mjg59
=== sz0 is now known as sz0`
infinityBenC: Still around?22:38
infinityBenC: 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.23:00

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!