freebsd stable - Sep 2015 - ia64 stable/10 r286316: hang at Entering /boot/kernel/kernel

>From marcel at 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

On Thursday, September 03, 2015 05:30:35 PM Anton Shterenlikht
wrote:
> >From marcel at 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 at wemm.org; peter at FreeBSD.org; peter at yahoo-inc.com;
KI6FJV
UTF-8: for when a ' or ... just won\342\200\231t do\342\200\246
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part.
URL:
<http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20150906/4a33e0c2/attachment.bin>