truck...@freebsd.org (Don Lewis) writes:
>On 22 Jul, David Wolfskill wrote:
>> Back when I was doing sysadmin stuff for a group of engineers, my
>> usual approach for that sort of thing was to use amd (this was late
>> 1990s - 2001) to have maps so it would set up NFS mounts if the
>> file system
pz-freebsd-sta...@ziemba.us ("G. Paul Ziemba") writes:
>I bumped it from the default 4 to 5 in /boot/loader.conf:
> kern.kstack_pages=5
>and that prevented this crash. Uptime 5.5 hours at this point (instead of
>1.5 minutes).
% uname -m
amd64
Crashed the next day. 75 kernel stack frames,
On Sat, Jul 22, 2017 at 10:51:42PM -0700, Don Lewis wrote:
> > The stack is aligned to a 4096 (0x1000) boundary. The first access to a
> > local variable below 0xfe085cfa5000 is what triggered the trap. The
> > other end of the stack must be at 0xfe085cfa9000 less a bit. I don't
> > know
On 22 Jul, To: pz-freebsd-sta...@ziemba.us wrote:
> On 22 Jul, G. Paul Ziemba wrote:
>> My previous table had an error in the cumulative size column
>> (keyboard made "220" into "20" when I was plugging into the hex
>> calculator), so thet stack is 0x200 bigger than I originally thought:
>>
>>
On 22 Jul, G. Paul Ziemba wrote:
> My previous table had an error in the cumulative size column
> (keyboard made "220" into "20" when I was plugging into the hex
> calculator), so thet stack is 0x200 bigger than I originally thought:
>
> Frame Stack Pointer sz cumu function
> -
My previous table had an error in the cumulative size column
(keyboard made "220" into "20" when I was plugging into the hex
calculator), so thet stack is 0x200 bigger than I originally thought:
Frame Stack Pointer sz cumu function
- - ---
On Sat, Jul 22, 2017 at 01:12:29PM -0700, Don Lewis wrote:
> On 21 Jul, G. Paul Ziemba wrote:
> >>Your best bet for a quick workaround for the stack overflow would be to
> >>rebuild the kernel with a larger value of KSTACK_PAGES. You can find
> >>teh default in /usr/src/sys//conf/NOTES.
I
On 22 Jul, David Wolfskill wrote:
> On Fri, Jul 21, 2017 at 04:53:18AM +, G. Paul Ziemba wrote:
>> ...
>> >It looks like you are trying to execute a program from an NFS file
>> >system that is exported by the same host. This isn't exactly optimal
>> >...
>>
>> Perhaps not optimal for the
On 21 Jul, G. Paul Ziemba wrote:
> truck...@freebsd.org (Don Lewis) writes:
>
>>On 21 Jul, G. Paul Ziemba wrote:
>>> GENERIC kernel r321349 results in the following about a minute after
>>> multiuser boot completes.
>>>
>>> What additional information should I provide to assist in debugging?
>>>
On Fri, Jul 21, 2017 at 04:53:18AM +, G. Paul Ziemba wrote:
> ...
> >It looks like you are trying to execute a program from an NFS file
> >system that is exported by the same host. This isn't exactly optimal
> >...
>
> Perhaps not optimal for the implementation, but I think it's a
> common
truck...@freebsd.org (Don Lewis) writes:
>On 21 Jul, G. Paul Ziemba wrote:
>> GENERIC kernel r321349 results in the following about a minute after
>> multiuser boot completes.
>>
>> What additional information should I provide to assist in debugging?
>>
>> Many thanks!
>>
>> [Extracted from
On 22.07.2017 16:57, Konstantin Belousov wrote:
>>From this description, I would be not even surprised if your machine
> load fits into the kstacks cache, despite cache' quite conservative
> settings. In other words, almost definitely your machine is not
> representative for the problematic load.
On Sat, Jul 22, 2017 at 03:37:30PM +0700, Eugene Grosbein wrote:
> On 22.07.2017 15:00, Konstantin Belousov wrote:
> > On Sat, Jul 22, 2017 at 02:40:59PM +0700, Eugene Grosbein wrote:
> >> Also, I've always wondered what load pattern one should have
> >> to exhibit real kernel stack problems due
On 22.07.2017 15:00, Konstantin Belousov wrote:
> On Sat, Jul 22, 2017 at 02:40:59PM +0700, Eugene Grosbein wrote:
>> Also, I've always wondered what load pattern one should have
>> to exhibit real kernel stack problems due to KVA fragmentation
>> and KSTACK_PAGES>2 on i386?
> In fact each stack
On Sat, Jul 22, 2017 at 02:40:59PM +0700, Eugene Grosbein wrote:
> Also, I've always wondered what load pattern one should have
> to exhibit real kernel stack problems due to KVA fragmentation
> and KSTACK_PAGES>2 on i386?
In fact each stack consumes 3 contigous pages because there is also
the
22.07.2017 14:05, Konstantin Belousov wrote:
> On Sat, Jul 22, 2017 at 12:51:01PM +0700, Eugene Grosbein wrote:
>> Also, there is https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219476
>
> I strongly disagree with the idea of increasing the default kernel
> stack size, it will cause systematic
On Sat, Jul 22, 2017 at 12:51:01PM +0700, Eugene Grosbein wrote:
> Also, there is https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219476
I strongly disagree with the idea of increasing the default kernel
stack size, it will cause systematic problems for all users instead of
current state where
On Fri, Jul 21, 2017 at 10:42:42PM -0700, Don Lewis wrote:
> Your best bet for a quick workaround for the stack overflow would be to
> rebuild the kernel with a larger value of KSTACK_PAGES. You can find
> teh default in /usr/src/sys//conf/NOTES.
Or set the tunable kern.kstack_pages to the
22.07.2017 12:42, Don Lewis wrote:
> The double fault is a pretty good indication that you overflowed the
> kernel stack. Having ~40 frames on the stack when the fault happened is
> consistent with that.
>
> It looks like you are trying to execute a program from an NFS file
> system that is
On 21 Jul, G. Paul Ziemba wrote:
> GENERIC kernel r321349 results in the following about a minute after
> multiuser boot completes.
>
> What additional information should I provide to assist in debugging?
>
> Many thanks!
>
> [Extracted from /var/crash/core.txt.NNN]
>
> KDB: stack backtrace:
>
20 matches
Mail list logo
