#ubuntu-s390x 2017-11-02
<cpaelzer> jfh: xnox: hey have you seen this on artful: http://paste.ubuntu.com/25871628/ ?
<cpaelzer> I'm on a rather old kernel 4.11 in Artful, so I reboot now
<cpaelzer> it might all be solved for ages but I wanted to ask to be sure
<xnox> cpaelzer, not sure. Is this lpar, z/vm, or kvm?
<cpaelzer> usually I remember ASCE differences with KVM, but this seems to pop up every now and then without a guest running
<cpaelzer> in lpar
<xnox> cpaelzer, are crypto CPACF (?!) instructions enabled in the HMC? and yeah 4.11 is not supported, so do check if you can reproduce with final kernels (4.13?)
<cpaelzer> I'll keep the dmesg up after the reboot is complete and IFF it shows again with the most recent kernel I'll file a bug
<cpaelzer> xnox: as you see I'm already on repro with 4.13
<cpaelzer> :-)
<cpaelzer> why would cpacf matter in this case, but well I can check
<jfh> cpaelzer: well, there are customer w/o CPACF (even if not many), so that should not be required ...
<cpaelzer> I'm on the default with both cpacf checkboxes set
<cpaelzer> the error is on a wrong ASCE which I only would connect with KVM - remember the old home/secondary setting
<cpaelzer> but as I said no guests required
<jfh> ^but didn't saw that so far - tried CDK on s390x on a artful machine last week which is causing heavy load and didn't came across this so far ...
<cpaelzer> I have another one on 4.13.0-16-generic without this issue
<jfh> cpaelzer: which LPAR are you using?
<cpaelzer> so lets assume it was just the too old kernel for now
<cpaelzer> s1lp5
<jfh> cpaelzer: settings look good ... (anyway, if you want to check if the system is really able to use CPACF just install libica-utils and run icainfo - but looks like 4.13 is fine anyway ...)
<cpaelzer> I never asked about cpacf, just referred to xnox question
<cpaelzer> but thanks for the double check jfh
<cpaelzer> and in any case this dmesg entry might still look known to e.g. hca - any known issue Heiko?
<hca> cpaelzer: that looks like a branch into nowhere-land ... if you would happen to know what was mapped at 0x3ff817064e0 then that might give you an idea
<hca> but this doesn't have to do anything with cpacf and/or kvm
<cpaelzer> hca: I don't know what was around that addr
<cpaelzer> hca: thanks for confirming my thoughts on what is not related
<cpaelzer> hca: if it happens again I'll look at the addr
<cpaelzer> hca: always gpr14 to look at?
<cpaelzer> need to find my old docs what usually is in 14
<hca> is this included in your kernel: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1708399
<hca> ?
<ubottu> Launchpad bug 1708399 in linux (Ubuntu Zesty) "kernel panic -not syncing: Fatal exception: panic_on_oops" [High,Fix released]
<cpaelzer> yes that would have been in
<cpaelzer> on the kernel I had
<cpaelzer> I really think this was just an too-old-non-released-kernel issue, don't spend too much cycles on it if it is not "ah that is Foo"
<hca> cpaelzer: gpr14 contains the return address if a function gets called
<cpaelzer> I found my  old s390x ELF spec pdf in the meantime
<cpaelzer> thanks
#ubuntu-s390x 2017-11-03
<borntraeger> do the cloud images have a default password for console login? "ubuntu" + "passw0rd" was documented some years ago, but this does not work when running the artful cloud image on kvm on z
<jfh> borntraeger: you may use smoser's script here to set a user and pw: http://bazaar.launchpad.net/~smoser/+junk/backdoor-image/view/head:/backdoor-image
<borntraeger> jfh, but that implies that the image "as-is" has no way to login via the hardware console. correct?
<jfh> borntraeger: well, looks like - the primary idea was to be used in an OpenStack context with keys ...
