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?
>>>
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
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
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
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
17 matches
Mail list logo
