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:
>>
>> Fra
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 bumped
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 impl
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?
>>>
Hi,
On 22.07.2017 17:08, Eugene M. Zheganin wrote:
is this weird error "cannot destroy: already exists" related to the
fact that the zvol is faulty ? Does it indicate that metadata is
probably faulty too ? Anyway, is there a way to destroy this dataset ?
Follow-up: I sent a similar zvol of th
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 NF
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 /va
Hi,
I cannot destroy a zvol for a reason that I don't understand:
[root@san1:~]# zfs list -t all | grep worker182
zfsroot/userdata/worker182-bad1,38G 1,52T 708M -
[root@san1:~]# zfs destroy -R zfsroot/userdata/worker182-bad
cannot destroy 'zfsroot/userdata/worker182-bad': dataset a
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 to
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 co
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 guar
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 s
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 desired
18 matches
Mail list logo
