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

>From kostikbel at gmail.com Thu Aug 27 18:22:37 2015
>
>On Thu, Aug 27, 2015 at 01:12:16PM +0100, Anton Shterenlikht wrote:
>> ia64 stable/10 r286315 boots, but 
>> r286316 hangs at "Entering /boot/kernel/kernel".
>> 
>> Please advise
>
>To state an obvious thing.  The commit which you pointed to, changes
>the code which is not executed at that early kernel boot stage.  The
>revision cannot cause the consequences you described.
yes, I'm surprised too.
>I think that you either have build-environment issue which randomly pops
>up, or there is some other boot-time issue which is sporadic.  The only
>suggestion I have, try many boots with kernels which look either good
>or bad, I would be not surprised if statistic would be completely
>different from binary good/bad outcome.
>
>Otherwise, I do not have an idea.
>
I doubt it's a random or a sporadic issue.
I did a bisection, as suggested, during which
I built world/kernel on 7 revisions, and when I
narrowed it down to <50, a further 4 kernels.
All kernels <=286315 boot, all kernels >= 286316
do not. I think if it were something random,
it wouldn't be such a clear cut picture.

What about my loader.conf:

# cat /boot/loader.conf 
zfs_load="YES"
# soft limits
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
                        # processes may not exceed these limits.
# 

My memory:

real memory  = 8589934592 (8192 MB)
avail memory = 8387649536 (7999 MB)

I'll try disabling all these settings in loader.conf
and see if makes a difference.
But these settings have been there for a few years
with no problems.

Anton

On Fri, Aug 28, 2015 at 11:30:18AM +0100, Anton Shterenlikht
wrote:
> >From kostikbel at gmail.com Thu Aug 27 18:22:37 2015
> >
> >On Thu, Aug 27, 2015 at 01:12:16PM +0100, Anton Shterenlikht wrote:
> >> ia64 stable/10 r286315 boots, but 
> >> r286316 hangs at "Entering /boot/kernel/kernel".
> >> 
> >> Please advise
> >
> >To state an obvious thing.  The commit which you pointed to, changes
> >the code which is not executed at that early kernel boot stage.  The
> >revision cannot cause the consequences you described.
> 
> yes, I'm surprised too.
> 
> >I think that you either have build-environment issue which randomly
pops
> >up, or there is some other boot-time issue which is sporadic.  The only
> >suggestion I have, try many boots with kernels which look either good
> >or bad, I would be not surprised if statistic would be completely
> >different from binary good/bad outcome.
> >
> >Otherwise, I do not have an idea.
> >
> 
> I doubt it's a random or a sporadic issue.
> I did a bisection, as suggested, during which
> I built world/kernel on 7 revisions, and when I
> narrowed it down to <50, a further 4 kernels.
> All kernels <=286315 boot, all kernels >= 286316
> do not. I think if it were something random,
> it wouldn't be such a clear cut picture.
> 
> What about my loader.conf:
> 
> # cat /boot/loader.conf 
> zfs_load="YES"
> # soft limits
> 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
>                         # processes may not exceed these limits.
> # 
> 
> My memory:
> 
> real memory  = 8589934592 (8192 MB)
> avail memory = 8387649536 (7999 MB)
> 
> I'll try disabling all these settings in loader.conf
> and see if makes a difference.
> But these settings have been there for a few years
> with no problems.
In the initial range you mentioned, there were some changes related to the
handling of the userspace stacks.  But again, the problem occurs too early
for a userspace-related modification to affect the outcome.

Might be, try the latest stable/10 kernel with the problematic revision
r286316 reversed ?  This might add more points to the Marcel' note about
some static relocation table processed early.

>From mexas at bristol.ac.uk Fri Aug 28 11:34:20 2015
>
>What about my loader.conf:
>
># cat /boot/loader.conf 
>zfs_load="YES"
># soft limits
>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
>                        # processes may not exceed these limits.
># 
>
>My memory:
>
>real memory  = 8589934592 (8192 MB)
>avail memory = 8387649536 (7999 MB)
>
>I'll try disabling all these settings in loader.conf
>and see if makes a difference.
>But these settings have been there for a few years
>with no problems.
>
>Anton
yes, this does help:

# uname -a
FreeBSD  10.2-PRERELEASE FreeBSD 10.2-PRERELEASE #12 r286316: Thu Aug 27
11:03:44 BST 2015     root at
mech-as28.men.bris.ac.uk:/usr/obj/usr/src/sys/GENERIC  ia64
#

I guess I now need to check if
it's zfs of the limits.

Anton

To add a very small (useless) data point to this, I have an atom device 
that, very occasionally, hangs before the boot stage (at the little 
slash, prior to the daemon boot menu offering you the chance to select 
another kernel etc).

I haven't worked out the rhyme or reason yet, so its probably a red 
herring, but its frustrated me when i have to dig out the monitor and 
keyboard again. At least it did with 10.1-release, yet to have it happen 
with stable.

Cheers,
Joe

On 28/08/2015 8:30 PM, Anton Shterenlikht wrote:
> >From kostikbel at gmail.com Thu Aug 27 18:22:37 2015
>> On Thu, Aug 27, 2015 at 01:12:16PM +0100, Anton Shterenlikht wrote:
>>> ia64 stable/10 r286315 boots, but
>>> r286316 hangs at "Entering /boot/kernel/kernel".
>>>
>>> Please advise
>> To state an obvious thing.  The commit which you pointed to, changes
>> the code which is not executed at that early kernel boot stage.  The
>> revision cannot cause the consequences you described.
> yes, I'm surprised too.
>
>> I think that you either have build-environment issue which randomly
pops
>> up, or there is some other boot-time issue which is sporadic.  The only
>> suggestion I have, try many boots with kernels which look either good
>> or bad, I would be not surprised if statistic would be completely
>> different from binary good/bad outcome.
>>
>> Otherwise, I do not have an idea.
>>
> I doubt it's a random or a sporadic issue.
> I did a bisection, as suggested, during which
> I built world/kernel on 7 revisions, and when I
> narrowed it down to <50, a further 4 kernels.
> All kernels <=286315 boot, all kernels >= 286316
> do not. I think if it were something random,
> it wouldn't be such a clear cut picture.
>
> What about my loader.conf:
>
> # cat /boot/loader.conf
> zfs_load="YES"
> # soft limits
> 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
>                          # processes may not exceed these limits.
> #
>
> My memory:
>
> real memory  = 8589934592 (8192 MB)
> avail memory = 8387649536 (7999 MB)
>
> I'll try disabling all these settings in loader.conf
> and see if makes a difference.
> But these settings have been there for a few years
> with no problems.
>
> Anton
>
> _______________________________________________
> freebsd-stable at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe at
freebsd.org"