Re: linux-3.10+: unable to boot 31bit builds

Re: linux-3.10+: unable to boot 31bit builds

[Mike Frysinger]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: multipart/mixed; boundary="--nextPart1423859.M7Oc5BVCEB", Size: 1643 bytes --]

--nextPart1423859.M7Oc5BVCEB
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

On Wednesday 22 January 2014 02:55:36 Heiko Carstens wrote:
> With all three patches within this thread s390 with CONFIG_64BIT=3Dn ipl's
> again, and the 32 bit native statfs64 syscall works as well.

indeed, with those in hand, my system now boots :)

> However I would strongly suggest to use CONFIG_64BIT=3Dy with CONFIG_COMP=
AT=3Dy
> instead for (now) obvious reasons ;)

this VM is meant for development, so if it helps catch bugs like this, i th=
ink=20
i'll keep it as-is.  thanks!
=2Dmike

--nextPart1423859.M7Oc5BVCEB
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)

iQIcBAABAgAGBQJS4A5GAAoJEEFjO5/oN/WBmdEP/iFnfTLmUtcifURlje231qBA
KOfEhcmMO+rP/Tno1xLgkPz1bMQcDWHG8ORLsfv61ZMJumzhqdjd0Xud3nH97iM9
2qMZljIzH+C+ppVSmvgRxkkK4dCX2jWTEavipz6FsUwzZaJJorfMybm/rDYli3Yh
dkgEAPUhjkYjmmzaoaudKugXtp3TOqiJccP14aIsX5C+vY4gWxSPjSh6yfWx/+C4
bVNQwGxM4MwXnjNQG8DY5Uze9X87E+FvAnXZtQa/omTC4zQxK0kqrJJZeoz+r/f8
lX2C0s1vifi0Q4LWbf7ONlioEkWFKy7GxwnbD84rxtpSYd9XdJGeT34NzJGfbR7I
ttXga3KOKV7Wgz+tvh5J3XE1v06KvbGFX3qz7EZi96A/OhReiYcHLArJ7Xj8F1Dy
vmnE3vyK10jO4nf/3jSI5XxC5Mv33j1D0o5HYgvbfACoU5jp17n7skfruwR6nTAL
uv1MTDeTiEUV1Kx720EjytrpwURQUYjl5F85kHXIIYDwmr0859dZJGmWXqCmQDHy
6AaU2NRVszk83qrZncPw3WFj2g6HKgE1SrN7V0Yb6Vv/k70zfe2Hw4QVqxWocWM6
T0aePeqOCJDdQ6QvutrJRnbTfGsk5yGTfu45OuG5h4gkJpvrN35fgaUhh4hAUW3K
sxsgPm65Fo4WPcQv7Jle
=/dvf
-----END PGP SIGNATURE-----

--nextPart1423859.M7Oc5BVCEB--

Re: linux-3.10+: unable to boot 31bit builds

[Sebastian Ott]

Hello,

On Tue, 21 Jan 2014, Heiko Carstens wrote:
> On Tue, Jan 21, 2014 at 12:22:52PM +0100, Heiko Carstens wrote:
> > On Tue, Jan 21, 2014 at 04:57:39AM -0500, Mike Frysinger wrote:
> > > hmm, doesn't seem to work for me.  don't get a crash, just a "virtual machine 
> > > is placed in CP mode due to a SIGP initial C".  whatever that means :).
> > 
> > Ah, that probably happened because the kernel failed to mount the
> > root file system and killed all CPUs before printing a nice error message.
> 
> Ok, that's not correct. Just bisected it down to:
> 
> commit 14556b33f2a5d6a3bc75cd33b709452a31555b25
> Author: Sebastian Ott <sebott@linux.vnet.ibm.com>
> Date:   Sat Apr 13 13:03:54 2013 +0200
> 
>     s390/css: introduce cio_register_early_subchannels
>     
>     Use cio_register_early_subchannels to register early subchannels
>     which are already in use. Call this function before we do the
>     actual subchannel scanning loop. This helps us to get rid of some
>     more special cases regarding the console subchannel.
>     
>     Reviewed-by: Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
>     Signed-off-by: Sebastian Ott <sebott@linux.vnet.ibm.com>
>     Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
> 
> For some non-obvious reason this kills 31 bit with your config under z/VM.
> 

The patch to address this is scheduled for upstream inclusion. Thanks to
both of you for reporting/debugging this!

Regards,
Sebastian

Re: linux-3.10+: unable to boot 31bit builds

[Sebastian Ott]

Hi,

On Wed, 2 Apr 2014, Sebastian Ott wrote:
> On Wed, 2 Apr 2014, Mike Frysinger wrote:
> > On Wed 22 Jan 2014 08:55:36 Heiko Carstens wrote:
> > > On Tue, Jan 21, 2014 at 12:58:36PM +0100, Heiko Carstens wrote:
> > > > On Tue, Jan 21, 2014 at 12:22:52PM +0100, Heiko Carstens wrote:
> > > > > On Tue, Jan 21, 2014 at 04:57:39AM -0500, Mike Frysinger wrote:
> > > > > > hmm, doesn't seem to work for me.  don't get a crash, just a "virtual
> > > > > > machine is placed in CP mode due to a SIGP initial C".  whatever that
> > > > > > means :).> > 
> > > > > Ah, that probably happened because the kernel failed to mount the
> > > > > root file system and killed all CPUs before printing a nice error
> > > > > message.
> > > > 
> > > > Ok, that's not correct. Just bisected it down to:
> > > > 
> > > > commit 14556b33f2a5d6a3bc75cd33b709452a31555b25
> > > > Author: Sebastian Ott <sebott@linux.vnet.ibm.com>
> > > > Date:   Sat Apr 13 13:03:54 2013 +0200
> > > > 
> > > >     s390/css: introduce cio_register_early_subchannels
> > > >     
> > > >     Use cio_register_early_subchannels to register early subchannels
> > > >     which are already in use. Call this function before we do the
> > > >     actual subchannel scanning loop. This helps us to get rid of some
> > > >     more special cases regarding the console subchannel.
> > > >     
> > > >     Reviewed-by: Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
> > > >     Signed-off-by: Sebastian Ott <sebott@linux.vnet.ibm.com>
> > > >     Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
> > > > 
> > > > For some non-obvious reason this kills 31 bit with your config under z/VM.
> > > 
> > > The patch below fixes this for me...
> > > The difference for 64 vs 32 bit was probably that even if cdev->drv was a
> > > NULL pointer, dereferencing cdev->drv->path_event was also NULL by
> > > coincidence. While on 32 bit it is not NULL and the kernel jumped to
> > > somehere...
> > > 
> > > With all three patches within this thread s390 with CONFIG_64BIT=n ipl's
> > > again, and the 32 bit native statfs64 syscall works as well.
> > > 
> > > However I would strongly suggest to use CONFIG_64BIT=y with CONFIG_COMPAT=y
> > > instead for (now) obvious reasons ;)
> > > 
> > > diff --git a/drivers/s390/cio/device_fsm.c b/drivers/s390/cio/device_fsm.c
> > > index c7638c543250..b19ab38a5e9a 100644
> > > --- a/drivers/s390/cio/device_fsm.c
> > > +++ b/drivers/s390/cio/device_fsm.c
> > > @@ -484,7 +484,7 @@ static void ccw_device_report_path_events(struct
> > > ccw_device *cdev) if (mask & cdev->private->pgid_reset_mask & sch->vpm)
> > >  			path_event[chp] |= PE_PATHGROUP_ESTABLISHED;
> > >  	}
> > > -	if (cdev->online && cdev->drv->path_event)
> > > +	if (cdev->online && cdev->drv && cdev->drv->path_event)
> > >  		cdev->drv->path_event(cdev, path_event);
> > >  }
> > 
> > looks like this patch was dropped somewhere ?  i had to re-apply it to my 3.14 
> > build to get it to boot ...
> > -mike
> 
> The commit to fix this is 2253e8d79 (which is included in 3.14). I'll
> try an 31bit build with 3.14.

Indeed...3.14 failed. 2253e8d79 is _not_ included in 3.14 - my git-fu let
me down. I used
$ git describe 2253e8d
v3.14-rc3-169-g2253e8d

and assumed it was in 3.14. I usually use
$ git describe --contains 2253e8d
fatal: cannot describe '2253e8d79237c69086ded391e6767afe16972527'

which should have told me that there is no tag after this commit (since
there is no v3.15-rc1 yet). Sorry for the confusion. You can cherry-pick
2253e8d on top of 3.14 and it'll work.

Regards,
Sebastian