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

> On Sep 2, 2015, at 10:30 AM, Anton Shterenlikht <mexas at bris.ac.uk>
wrote:
> 
> The kernel limits I have in /boot/loader.conf
> are following this PR:
> 
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=156900
> 
> #kern.dfldsiz=536748032 # default soft limit for process data
> #kern.dflssiz=536748032 # default soft limit for stack
> # hard limits
> #kern.maxdsiz=536748032 # hard limit for process data
> #kern.maxssiz=536748032 # hard limit for stack
> #kern.maxtsiz=536748032 # hard limit for text size
> 
> If I leave these in, then with Marcel's patch
> I get to mountroot> prompt, and then panic.
To be clear: with the limits and without my patch you
can?t even boot right?
> 
> If I remove these, then I can boot.
> 
> If I try booting with -s, then I get to a hang at
> "Entering /boot/kernel?:
Is this with or without limits?
And is this with or without patch?

> 
> /boot/kernel.old/kernel text=0x1110710 data=0xdfce8+0xa54f8
syms=[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.
> 
> Is it worth investigating what limit value will boot?
I?m inclined to say that it?s 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?m willing to make
is for the size of the array that holds relocations. If
it made things better, I?ll commit it. If it didn?t, then
I?m not going to commit it.

Anything more involved will take more time than I?m
willing to put into ia64 at this time...

Sorry,

--
Marcel Moolenaar
marcel at xcllnt.net



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL:
<http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20150903/07ad797e/attachment.bin>

>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