=== shuduo-afk is now known as shuduo [04:30] apw: the one on xenial is skl/kbl/bxt [08:56] tjaalton, hmm i don't think i know what those three all are; skylate, erm [09:04] If one would not know better one would guess keyboard failure [09:13] apw: heh, kabylake and broxton (aka apollo lake) [09:26] tjaalton, those i have not even heard of [09:27] tjaalton, ok so i am seeing lockups on resume in what feels like graphics and some visual corruption occasionally in icons in firefox, on broadwell [09:27] tjaalton, with the xenial kernel -12 at least, i just upgraded to -13 and have not been on it long enough to know if it is sad too [09:29] apw: ok, is the corruption right from the start, or only after a resume or such? check dmesg if so [09:30] there could be a gpu hang and recovery isn't complete [09:30] tjaalton, you know how these bugs are you are never quite sure till they happen a few times, i currently feel, only after a resume [09:30] right [09:30] but i'd not want to swear to it in court. i will check dmesg if i see such corruption again on -13 [09:32] cool [09:52] * apw wonders if xnox has tested his second debug kernel yet [11:38] apw, not yet [11:45] apw, i did not hit any of those printk... http://paste.ubuntu.com/15400970/ unless i'm not collecting them at all. [11:48] xnox, literally none of them, which is perplexing [11:48] xnox, that is the generic kernel not an apw build [11:48] [ 0.008770] Linux version 4.4.0-13-generic (buildd@z13-012) (gcc version 5.3.1 20160225 (Ubuntu 5.3.1-10ubuntu2) ) #29-Ubuntu SMP Fri Mar 11 19:30:41 UTC 2016 (Ubuntu 4.4.0-13.29-generic 4.4.5) [11:48] boom [12:01] apw, http://paste.ubuntu.com/15400999/ [12:02] apw, btw the .debs are suspiciously the same as I tested yesterday, you didn't bump version number timestamp at all? [12:02] xnox, yes, they would have had new times [12:03] it downloaded for me as linux-image-4.4.0-14-generic_4.4.0-14.30lp1557250v201603151737_s390x.deb.1 hence i don't think so. [12:03] http://people.canonical.com/~apw/lp1557250-xenial/ has timestamps 17:41 from yesterday, which is from before i left, no?! [12:04] xnox, i mean i cannot make a build with the same time, so if it is the same time, that is not a new build, its is ... erm ... wrong [12:04] xnox, ok something is screwey, the only safe thing for me to do is rebuild it [12:05] xnox, oh i think i may have built a wrong branch and pushed binaries but useless ones for another bug, sigh, be 10m [12:09] more coffee [12:10] xnox, ok some actually new binaries pushing, sigh, sorry about the confusion there, should be up in ... now [12:11] ack [12:25] apw, http://paste.ubuntu.com/15401110/ [12:25] [ 0.734265] Loading compiled-in X.509 certificates [12:25] [ 0.734266] x509_cert_parse called [12:25] [ 0.735100] x509_check_signature -> -448754944 [12:25] [ 0.735101] preparse -> ret=-74 [12:29] xnox, ta ... [12:38] xnox, ... and again [13:19] apw, [13:19] [ 0.715208] Loading compiled-in X.509 certificates [13:19] [ 0.715209] x509_cert_parse called [13:19] [ 0.715230] APW: crypto_shash_finup 0 [13:19] [ 0.715231] APW: RSA_verify_signature called [13:19] [ 0.716088] APW: public_key_verify_signature ret=-74 [13:19] [ 0.716089] x509_check_signature -> -74 [13:19] [ 0.716090] preparse -> ret=-74 [13:19] http://paste.ubuntu.com/15401110/ [13:20] wrong paste. [13:20] i mean [13:20] http://paste.ubuntu.com/15401255/ [13:20] (yeah thats the 1234 build) [14:17] xnox, ok making progress, its tricky to add all teh debug we need in one run [14:17] xnox, as we jump through callbacks where there are 3-4 options [14:17] RSA_verify_signature was one of those [15:24] Hi guys, do you think Kernel 4.5 is still coming as default for Ubuntu 16.04? [15:24] no [15:25] ogra_: I know for now it is on Kernel 4.4, can that decision change until Final? [15:25] nope ... 4.4 is an LTS kernel ... [15:25] ogra_: ok, tnx :) [15:26] there will be hwe kernels later ... like you can alwas use newer kernels on ubuntu LTS releases... [15:26] ogra_: 3.13 on 14.04 wasn't a LTS kernel too... [15:27] yeah, that means that the ubuntu kernel team needs to maintain this version for 5 years themselves [15:28] if you can have a kernel that is upstream maintained instead it means you free developers for other work [15:28] I see [15:29] yes, then probably the right decision is to keep 4.4 :D [15:29] it will just make the 4.10 (or whatever will be current at 16.10 release) hwe kernel better ;) [15:39] tyrog, yeah waht ogra said [15:39] apw: Fine as 4.4 should be very stable when 16.04 Final is released ;) [15:40] tyrog, yeah we try and hold back a bit for these lts' than we would in an interim one, and that upstream is doing stable for 4.4 is a major boon [15:47] xnox, another test kernel for you, i hope [15:50] tyrog, if you want things in 16.04 kernel, make those things to be backported to 4.4. into stable tree, or other trees. Backports of bits & pieces of 4.5 drivers are in our 4.4 kernel... [15:51] or e.g. bugfixes should be taken into stable tree. === shuduo is now known as shuduo-afk [16:35] apw, http://paste.ubuntu.com/15402573/ [16:35] 1424 kernel [17:22] xnox, another one uploading ... [18:04] apw, off by one?! http://paste.ubuntu.com/15403281/ [18:04] xnox, hrm ... odd ... indeed [18:05] there is extra garbage on non-s390x? because it's using.... weird encoding?! [18:05] anyway, i should stop guessing and go back in fixing something useful. [18:10] i'll poke seom more indeed [18:58] xnox, antoher kernel pushing, this one might work or it might explodes, that will be interesting [19:34] apw, thank you for powerpc kernel?! [19:34] xnox, the last s390x is the same one, that is for someone else :) [19:34] is the same contents as the ppx [19:34] ppc [19:34] ack. [19:34] will test 1848 kernel [19:34] ta [19:37] fail [19:37] http://paste.ubuntu.com/15403933/ [19:37] missing prefix, hence off-by-one? [19:37] did we check by the way that e.g. powerpc loads the cert fine? [19:38] i guess we don't have powerpc (big endian) machines to test the kernels on, do we? [19:40] yes, a powerpc BE also fails in the same way [19:40] bah this is an endian issue, and i need to think about how to fix it ... prolly will punt it at anton :) [19:42] because the cert is read in host-endian order, rather than little-endian order. [19:42] we should be able to find upstream regression too. [19:42] cause we had powerpc forever. [19:43] xnox, its not quite like that, its handled in an endian sensible way, its not handling the packing right it seems [19:43] debugging it is tricky [19:43] https://bugs.launchpad.net/ubuntu-mate/+bug/1541151 [19:43] Launchpad bug 1541151 in ubuntu-mate "16.04 PPC, unable to boot: "Problem Loading in-kernel X.509 Certificate (-74)"" [Undecided,New] [19:46] why would that not be able to boot [19:46] that does not prevent booting [19:46] also [19:46] https://lists.debian.org/debian-powerpc/2016/02/msg00010.html [19:47] i don't believe the mate issue is actually related, but ... [19:47] it's a data point that in alpha the bug was present. [19:47] i don't believe that is the reason the system does not boot [19:47] but it is clearly there for a long time [19:48] should i open kernel.org bug? [19:48] which we would never notice because it is benign [19:48] xnox, for the moment no, i am working on it [19:48] ok. [19:56] apw: antonb and benh should be around (and maybe even awake shortly) ... mpe might already be, I can never remember where he lives. [19:56] ack [20:06] xnox, another one pushing now for testing if you are about [20:09] apw, patch looks plausible. [20:11] xnox, yeah, plausible, but i bet wrong again :) [20:25] xnox, fun ? [21:09] apw, http://paste.ubuntu.com/15404387/ [21:09] not sure about the size length reversion. [21:10] xnox, so made no differance at all ? [21:11] apw, well we don't know. you have reverted the size compare, so we don't know if a later [1] check succeeds or not. [21:11] i'd like a kernel without the 0008 patch [21:12] ack [21:17] xnox, uploading now ... [21:17] ... and done [21:27] apw, so your fix didn't help as per previous stuff. it may have helped with something/somewhere else. [21:27] http://paste.ubuntu.com/15404438/ [21:28] hmmm [21:29] xnox, ok i need to dump the thing en-toto [21:37] apw, in the mean time, i win - LD [M] /home/ubuntu/linux/debian/build/build-generic/zfs/module/zfs/zfs.ko [21:38] xnox, heheh, if you have it building, we might have some tests somewhere [21:45] apw, can you test-build s390x kernel proper for me with https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1519814 ? [21:45] Launchpad bug 1519814 in linux (Ubuntu Xenial) "spl/zfs fails to build on s390x" [Medium,Triaged] [21:45] xnox, yep in a few [21:46] i only got it to do ./debian/rules build to complete. And i have tried to fake the patch to mimic other commits you people do in a strange way. [21:54] ok [21:54] as it is zfs i'llneed to upload it to a PPA [21:59] yeap. [22:00] i bet abi checker or some such will tell me to shove my zfs back were it was [22:02] xnox, likely [22:04] xnox, ok pushing a possible fix found for the signature problem ifyou could test [22:04] and done [22:06] i just don't want to even know anything about limbs in the kernel [22:09] [ 0.678605] Loaded X.509 cert 'Build time autogenerated kernel key: 8d0653ca20551eb8f7822151a14011cc64a15ed4' [22:09] we are good. [22:09] http://paste.ubuntu.com/15404698/ [22:09] apw, ^ [22:09] \o/ [22:10] xnox, sweet, i'll apply that then for the next upload [22:10] xnox, and i'll upload your zfs to a ppa [22:11] apw, cooling having that 509 and zfs fixed would be nice for the beta next week. [22:12] apw, which / where is the ppa upload? [22:12] or shall i call it a night [22:18] xnox, i am uploading it now, will send you a link [22:23] xnox, https://launchpad.net/~canonical-kernel-team/+archive/ubuntu/bootstrap/+packages [22:24] tah [22:24] should be about 30m [22:28] xnox, ok that sig fix now pushed to master-next for the upload, i'll wait on your testing for the zfs one [22:52] xnox, ok its uploading binaries now [22:58] xnox, well the linux-image has the .ko's you would want to find in there ... [22:58] xnox, let me know if it explodes in your face or not [23:00] why do we have zfs-dkms and zfs in the kernel? [23:00] shouldn't we retire zfs-dkms package from zfsutils package? [23:03] apw, the module loads [23:04] xnox, we make the kernel modules from the dkms package [23:04] huh?! [23:04] and the kernel provides that package, so we can drop it from the kernel [23:05] * xnox is confused.... anyway. [23:05] the module loads. [23:05] xnox, we need to fix this in the -dkms package to do this right, and update the kernel from it [23:06] but that is all deatails, if it works that would be interesting to us [23:06] ok. [23:06] well, i have upstream pull request open too. [23:06] yeah so that is good [23:06] Package zfsutils-linux is not available, [23:06] right. [23:07] yes, that will be a problem [23:08] apw, do kernel people manage zfs-linux or may i upload it? [23:09] xnox, cking nominally looks after the delta to debian [23:09] xnox, bug i don't see any problem uploading a simple delta like enabling s390x for it [23:10] why do we only compile on 64-bit arches? [23:10] * xnox thought upstream totally supports 32bit arches.... [23:14] xnox, mostly for support coverage, if you are using zfs it is unlikely to be 32bit [23:15] apw, well, the question did come up as to why it's not available on 32bit. [23:15] uploaded into https://launchpad.net/~xnox/+archive/ubuntu/nonvirt/+packages [23:15] with arch:any, to see what happens. [23:15] dkms module is arch:all, so no reason not to attempt to compile the user space tools. [23:16] plus e.g. i hope that 32bit tools, can be used on 64bit kernel, for example. [23:16] yep [23:16] lets hope that [23:20] xnox, kaboom [23:21] apw, so..... this is not module building is it? [23:22] but tools exploading?! [23:22] yep the tools going blammo, something about VTOCs [23:23] oh i think i am meant to either define _SUNOS_VTOC_8 or _SUNOS_VTOC_16