Date: Sun, 06 Sep 2015 23:48:18 -0700 From: Peter Wemm <peter@wemm.org> To: freebsd-stable@freebsd.org, mexas@bris.ac.uk Cc: marcel@xcllnt.net, kostikbel@gmail.com Subject: Re: ia64 stable/10 r286316: hang at Entering /boot/kernel/kernel Message-ID: <1939276.T7b5bOdInc@overcee.wemm.org> In-Reply-To: <201509031630.t83GUZPr056951@mech-as222.men.bris.ac.uk> References: <201509031630.t83GUZPr056951@mech-as222.men.bris.ac.uk>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] On Thursday, September 03, 2015 05:30:35 PM Anton Shterenlikht wrote: > >From marcel@xcllnt.net Thu Sep 3 17:20:42 2015 > > > >To be clear: with the limits and without my patch you > >can=E2=80=99t even boot right? > > yes, this is right. > > >> If I remove these, then I can boot. > >> > >>=20 > >> > >> If I try booting with -s, then I get to a hang at > > > >> "Entering /boot/kernel=E2=80=9D: > >Is this with or without limits? > >And is this with or without patch? > > It seems the patch made no difference. > With the limits I cannot boot with or without the patch. > Without the limits I can boot with or without the patch. > > >> /boot/kernel.old/kernel text=3D0x1110710 data=3D0xdfce8+0xa54f8 = > > > >syms=3D[0x8+0xc29e8+0x8+0xb78f6] > > > >> ?[37m?[44mBooting...?[m > >> Entering /boot/kernel.old/kernel at 0x9ffc000000010500... > >> *********************************************************** > >> * ROM Version : 04.29 > >> * ROM Date : 11/30/2007 > >> * BMC Version : 04.04 > > > >This is not a hang. This is a machine check. > > After this line > > Entering /boot/kernel.old/kernel at 0x9ffc000000010500... > > The machine is not responding. I've left it for hours, > just to be sure. > The following line appears only after a power cycle. > > >> Is it worth investigating what limit value will boot? > > > >I=E2=80=99m inclined to say that it=E2=80=99s best to remove the limits > >altogether and just work with the default. If you need > >different default, add them to your kernel configuration. > >Set MAXTSIZ, DFLDSIZ, MAXDSIZ, DFLSSIZ and MAXSSIZ > >accordingly. > > > >Since you lower maxdsiz and maxssiz from 1G to 512M, > >you can safely leave them as is (unless you tend to have > >runaway processes :-) > > > >You increase maxssiz from 256M to 512M, which you > >probably want to keep doing to make sure you can run > >the same set of processes as you do now. > > > >At this point in time, the only fix I=E2=80=99m willing to make > >is for the size of the array that holds relocations. If > >it made things better, I=E2=80=99ll commit it. If it didn=E2=80=99t, = > >then > >I=E2=80=99m not going to commit it. > > No, I don't think it made any difference. > > >Anything more involved will take more time than I=E2=80=99m > >willing to put into ia64 at this time... > > sure, no problem. > > Anton This thread reminds me of what happened to eris.freebsd.org - removing DDB from the kernel solved it for us in the freebsd.org cluster. The same kernel binary booted on the old 2-cpu itanium machine, just not on the 8-core machine. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV UTF-8: for when a ' or ... just won\342\200\231t do\342\200\246 [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAABCAAGBQJV7TMyAAoJEDXWlwnsgJ4EzQUH/jqqCajSLn3n/JOlDeu7ByUr VY2LTKi83NwXH28qB86EoTStBeF5Ohlg9yqUju4RRfATVGGnXdSWShEZrCX/vtoQ Mk96206CiNXoLRz++jER3gtukrhvWjiZFqm2pyWi/9b+e1nxN/negsqUfA2O8BEa BELsbOpvHgW/TQa5i1pwK4fdJKWuDy8dgT2pZyFUM/Ce33/dFj1fwf8Hdm/f2cpH U51ZuwaiGMmPRl61Lr1iTUG2hIFJv7pUsv3CHdG3gHbqiI3grYlkYgy6WrxO26T/ yFmbyl+p6+/0CdfOqfDBsYgvuYH9o1g4M7PiLHfBVOkJjUOdc9MNM0aUE5Mt2pQ= =Frth -----END PGP SIGNATURE-----help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1939276.T7b5bOdInc>