| genkgo | jsalisbury: any more news on the backup issue? you were pretty close last time | 13:16 |
|---|---|---|
| rtg | slangasek, is https://wiki.ubuntu.com/UEFI the most current info ? | 14:02 |
| === cmagina_ is now known as cmagina | ||
| jsalisbury | genkgo, I have one or two more kernels to test and that should tell me the commit | 15:02 |
| genkgo | jsalisbury: alright, any idea yet? | 15:03 |
| jsalisbury | genkgo, the bisect pointed to an ath9k patch, which makes no sense. So I think there is on or two tests I did not let run long enough to fail. | 15:16 |
| genkgo | jsalisbury: ok, will wait for it :) | 15:17 |
| jsalisbury | genkgo, I hope to know today. | 15:17 |
| genkgo | jsalisbury: would be awesome :) | 15:17 |
| leitao | rtg, hello. Can we expect to see LP#1567581 fixed in the next kernel (-19) ? | 16:09 |
| slangasek | rtg: https://wiki.ubuntu.com/UEFI> I haven't checked it lately to know if it's accurate, but there's nothing newer | 17:02 |
| xnox | rtg, apw - i have a n00b question - do we support "vdso" and do we support it on s390x? | 18:36 |
| apw | xnox, we have and use vdso on other arches, i would assume we do also on s390x | 18:38 |
| xnox | apw, | 18:39 |
| xnox | cool. | 18:39 |
| rtg | leitao, it'll make it into the -19 kernel (just committed and pushed) | 18:46 |
| leitao | rtg, good. Any idea when -19 will be released? | 18:48 |
| infinity | xnox: The answer to the first half of your question is found in "ldd /bin/mv" | 18:48 |
| infinity | apw: I don't actually see a vdso on s390x, curiously. | 18:49 |
| xnox | rtg, yackes. does it per-chance also build an unversioned zfcpdump kernel? and are you targeting -19 as an SRU or a release kernel? | 18:49 |
| rtg | leitao, it'll be in the GA kernel. | 18:49 |
| rtg | xnox, -19 should be the release kernel | 18:49 |
| xnox | infinity, thanks. I see that we don't on s390x =/ | 18:50 |
| xnox | what's missing? | 18:50 |
| leitao | rtg, thank you! | 18:50 |
| infinity | A vdso, presumably. :P | 18:50 |
| * xnox has no idea what vdso even is | 18:50 | |
| * xnox summons google | 18:50 | |
| infinity | xnox: vdso is the kernel exporting some libc functions. | 18:50 |
| * xnox types "linux from scratch vdso" | 18:50 | |
| rtg | xnox, I doubt we'll get the zfcpdump kernel built and packaged for release, but apw is working on that. | 18:51 |
| infinity | xnox: A shortcut to hardware-specific functions that are better maintained in the kernel than in glibc, basically. Saves some cycles. | 18:51 |
| infinity | xnox: Not all arches have a vdso, but most do for some time-related functions and such. | 18:51 |
| infinity | xnox: Is this a curiosity thing on your part, or a question from IBM that they should know the answer to? | 18:52 |
| xnox | rtg, apw - from conversation with slangasek - "zfcpdump kernel should probably be build by src:linux and generate linux-zfcpdump package or some such, which ships latest zfcpdump kernel, as a real unversioned file." | 18:52 |
| xnox | infinity, right. looking at manpage there are only three calls. | 18:52 |
| xnox | infinity, reading meeting minutes of a sales call and it has "VDSO?" as a bullet point. | 18:52 |
| xnox | rtg, apw - that way it's always built, always latest (no symlinks no nothing) no separate package | 18:53 |
| xnox | rtg, did you take my compressed kernel image request into -19 or no? | 18:53 |
| * xnox thought there will be no -19 | 18:53 | |
| rtg | xnox, we believe the zfcpdump should be built once from a standalone package and not changed unless there are bugs found. there is no need to keep it up to date except perhaps at major release times. | 18:55 |
| rtg | up to date wrt to the kernel ABI, etc | 18:56 |
| xnox | rtg, slangasek argument is that a separate package is an extra maintainance we don't need nor want. | 18:56 |
| xnox | (separase source package) | 18:56 |
| xnox | but yeah, i'm just the messenger here. | 18:56 |
| xnox | rtg, is the cost having it in src:linux too much? | 18:57 |
| rtg | xnox, there is only a place for _one_ zfcpdump kernel. you cannot have multiple copies as I understand it | 18:57 |
| xnox | rtg, correct and that's what we need and want. IBM confirmed zfcpdump kernel version doesn't matter | 18:58 |
| rtg | so, do you plan to update it ever time linux-source changes ? | 18:58 |
| xnox | and hence we want e.g. src:linux build a package called "linux-zfcpdump" with version number X.Y.Z-ABI such that the largest/latest version kernel is the one that is provided as the zfcpdump kernel image. | 18:58 |
| infinity | rtg: His plan was to generate it unversioned from src:linux | 18:58 |
| infinity | rtg: Like linux-libc-dev. Not tied to ABI. | 18:59 |
| xnox | yeah, that. | 18:59 |
| infinity | That said, who is validating this kernel? | 18:59 |
| infinity | I still think it's silly to have Yet Another Kernel that someone needs to QA and make sure DTRT. | 18:59 |
| rtg | hmm, well I'm gonna leave it up to apw as it is on his work list. I've got other tasks. | 18:59 |
| * rtg ducks the issue | 19:00 | |
| xnox | infinity, so vdso... i don't see it in ldd output on s390x. But i have no idea if that's difinitive way to have it. | 19:04 |
| xnox | rtg, i don't expect that kernel team will need to validate zfcpdump kernel. | 19:04 |
| infinity | xnox: Well, someone needs to validate it. | 19:05 |
| rtg | nxonce we have t working it should not change until perhaps the next release. | 19:05 |
| rtg | xnox, ^^ | 19:05 |
| infinity | Like, someone needs to validate the actual binary. | 19:05 |
| rtg | xnox, pushed your bzImage patch | 19:05 |
| infinity | Which makes a good argument for not revving it on every kernel update, if no one's willing to do so. | 19:06 |
| xnox | rtg, tah. | 19:06 |
| xnox | infinity, ack so automated validation is on me, and then we can fire and forget it and update it automatically. | 19:06 |
| xnox | i suspect they will notice it's not updated and will flag it up. | 19:06 |
| xnox | .. | 19:08 |
| xnox | back to vDSO | 19:08 |
| xnox | we target 3.2 with glibc, vdso things for s390x were introduced in 2.6.29, but I don't see our ld pre-loading those functions from kernel. | 19:08 |
| xnox | infinity, i see object=linux-vdso64.so.1 [0] in LD_DEBUG=all /bin/true output | 19:11 |
| xnox | so it's being done. However, I guess it's not actually used because of bind now & pie on s390x? | 19:13 |
| xnox | as in glibc is getting bound, rather than vdso? | 19:13 |
| infinity | glibc isn't built any differently on s390x. | 19:14 |
| xnox | tah tah | 19:15 |
| xnox | i guess i need to poke a thing which uses one of the vdso symbols. | 19:15 |
| xnox | used codesearch to find that sshfs uses gettimeofday | 19:15 |
| xnox | .... and i should really have run this on s390x | 19:16 |
| xnox | and ldd /usr/bin/sshfs doesn't show vdso. | 19:16 |
| xnox | infinity, right glibc isn't, but our toolchain is. everything is built with bind now. | 19:16 |
| infinity | xnox: Hrm. | 19:17 |
| xnox | WARNING: Unsupported flag value(s) of 0x8000000 in DT_FLAGS_1. | 19:17 |
| xnox | no idea what that is about | 19:17 |
| infinity | xnox: What's the opposite of bind now, if we wanted to test build another glibc? | 19:18 |
| xnox | http://paste.ubuntu.com/15766287/ | 19:18 |
| * infinity wonders if that can even be reverted on the commandline. | 19:18 | |
| xnox | on e.g. amd64 it instead does | 19:19 |
| xnox | 8481: symbol=__vdso_time; lookup in file=linux-vdso.so.1 [0] | 19:19 |
| xnox | 8481: binding file linux-vdso.so.1 [0] to linux-vdso.so.1 [0]: normal symbol `__vdso_time' [LINUX_2.6] | 19:19 |
| infinity | I also wonder if it actually matters. | 19:19 |
| infinity | Since glibc __vdso functions are just ifunc wrappers to linux-vdso anyway. | 19:19 |
| xnox | dunno | 19:19 |
| davmor2 | infinity: pfff this is linux I'm more amazed when you can not do something in the cli :D | 19:19 |
| infinity | davmor2: :P | 19:20 |
| infinity | Undoing compiler options is easy, almost all of them have a negative value to match the positive. | 19:20 |
| infinity | Linker options, not so much. | 19:20 |
| xnox | infinity, opposite of bind now is debian chroot =) | 19:20 |
| * xnox does that. | 19:20 | |
| xnox | infinity, on debian it gets bound to __vdsO_ private libc symbol too. I guess htat's how things are done on s390x. | 19:22 |
| xnox | hence vdso is not shown in ldd output, but clearly is used in LD_DEBUG=all | 19:22 |
| infinity | xnox: Kay. So perhaps a non-bug. | 19:22 |
| xnox | learned something new today. | 19:23 |
| xnox | i was wondering what that magical vdso thing is in the ldd output, and not on disk... =) | 19:23 |
| infinity | vdso is one of the weirdest, ugliest hacks out there. | 19:23 |
| xnox | i was suspecting "oh we are linking kernel into all binaries, let's pretend that makes sense" | 19:23 |
| infinity | We carry gross patches all over the place to cope with it. | 19:23 |
| infinity | Turns out that things like gdb and valgrind don't like you linking to libraries that EXIST ONLY IN YOUR MIND. | 19:24 |
| xnox | "EXIST ONLY IN YOUR MIND." ahah | 19:25 |
| gpiccoli | Him sorry to bother. Where do I find the 4.4.0-19 kernel on git? | 20:45 |
| gpiccoli | I cloned ubuntu-xenial repo, but the most recent tag seems to be Ubuntu-4.4.0-18.34 | 20:45 |
| gpiccoli | s/Him/Hi I'm/g | 20:46 |
| rtg | gpiccoli, 4.4.0-19 has not been uploaded yet, though it is currently staged in master-next | 20:52 |
| gpiccoli | Ok, thanks rtg! So, I can checkout master/next to take a look? | 20:57 |
| rtg | yes, you can get it from git://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/xenial | 20:58 |
| apw | infinity, why didn't we make a real library with a page of nothing in it i wonder ... | 21:01 |
| gpiccoli | rtg, thanks a lot! Worked here, I could check what I was interested =) | 21:05 |
| rtg | gpiccoli, glad to hear it | 21:05 |
| gpiccoli | =) | 21:06 |
| gpiccoli | Thanks | 21:06 |
| flamesage | I'm trying to download v4.6-rc3-wily and it doesn't appear to have hit the mainline ppa? http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.6-rc3-wily/ | 21:30 |
| rtg | flamesage, its got some build problems that we haven't fixed yet | 21:31 |
| flamesage | okay, thanks. | 21:32 |
| === JanC_ is now known as JanC | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!