Re: [OmniOS-discuss] [developer] ENABLE_PERL64

2016-06-03 Thread Garrett D'Amore 
i dont recall seeing this before.  what is the status and history and how can i 
help?

Sent from my iPhone

> On Jun 3, 2016, at 12:49 PM, Dan McDonald  wrote:
> 
> 
>> On Jun 3, 2016, at 3:48 PM, Garrett D'Amore  wrote:
>> 
>> I just wish we could excise all perl from the gate.  Its an unending source 
>> of headaches.
> 
> Someone wanna pitch the final N innings of this?
> 
>http://cr.illumos.org/~webrev/0xffea/intrd-kernel-04/
> 
> Dan
> 
> 
> 
> ---
> illumos-developer
> Archives: https://www.listbox.com/member/archive/182179/=now
> RSS Feed: https://www.listbox.com/member/archive/rss/182179/21239177-3604570e
> Modify Your Subscription: 
> https://www.listbox.com/member/?member_id=21239177_secret=21239177-2d0c9337
> Powered by Listbox: http://www.listbox.com
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] [developer] ENABLE_PERL64

2016-06-03 Thread Dan McDonald 

> On Jun 3, 2016, at 3:48 PM, Garrett D'Amore  wrote:
> 
> I just wish we could excise all perl from the gate.  Its an unending source 
> of headaches. 

Someone wanna pitch the final N innings of this?

http://cr.illumos.org/~webrev/0xffea/intrd-kernel-04/

Dan

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] [developer] ENABLE_PERL64

2016-06-03 Thread Garrett D'Amore 
I just wish we could excise all perl from the gate.  Its an unending source of 
headaches. 

Sent from my iPhone

> On Jun 3, 2016, at 12:25 PM, Andy Stormont  
> wrote:
> 
> Hi Richard,
> 
> There’s a cleaner way to handle optional compiles: do it on the dependency 
> line:
> 
>> install: $(ROOTPERLEXT) $(ROOTPERLMOD)
>> $(ENABLE_PERL64)install: $(ROOTPERLEXT64) $(ROOTPERLMOD64)
> 
> That way you don’t need to prefix all of the 64bit variable with 
> $(ENABLE_PERL64).
> 
> - Andy
> 
> 
>> On 3 Jun 2016, at 19:33, Richard PALO  wrote:
>> 
>> Rather frustrated on omnios after 'onu' to vanilla upstream (that is, non 
>> illumos-omnios based) 
>> gate builds because of the native omnios multi arch perl environment.
>> 
>> What typically happens is, for example, intrd chokes with:
>>> Can't locate Sun/Solaris/Kstat.pm in @INC (@INC contains: 
>>> /usr/perl5/site_perl/5.16.1/i86pc-solaris-thread-multi-64 
>>> /usr/perl5/site_perl/5.16.1 
>>> /usr/perl5/vendor_perl/5.16.1/i86pc-solaris-thread-multi-64 
>>> /usr/perl5/vendor_perl/5.16.1 
>>> /usr/perl5/5.16.1/lib/i86pc-solaris-thread-multi-64 /usr/perl5/5.16.1/lib 
>>> .) at /usr/lib/intrd line 66.
>> 
>> so attached is an attempt to get the gate to build supporting optional 
>> multiarch based upon an
>> adaptation of illumos-omnios/master.
>> 
>> To build with this via bldenv.sh, I updated my illumos.sh with:
>>> export PERL_VERSION=5.16.1
>>> export PERL_ARCH=i86pc-solaris-thread-multi-64int
>>> export PERL_PKGVERS=
>>> export ENABLE_PERL64=
>>> export PERL_ARCH64=i86pc-solaris-thread-multi-64
>> 
>> where the last two are the only changes thus far for omnios users building 
>> the gate.
>> 
>> with 'sh bldenv.sh -d illumos.sh' and cd usr/src/cmd/perl  I can now
>>> dmake clobber ; dmake install
>> cleanly with, or without the ENABLE_PERL64= environment variables.
>> 
>> It would be cool to see how hipster or others fare with this...
>> 
>> I would like to mention that since both hipster and omnios have at least 
>> perl 5.16.1,
>> I believe there is perhaps only smartos that still has something prior in 
>> illumos-extra.
>> Perhaps this is a good time to set PERL_VERSION by default to 5.16.1 or, 
>> better, to 5.22
>> 
>> So? Thanks in advance for feedback.
>> I'm running on this now.
>> --
>> 
>> Richard PALO
>> 
>> <0001-ENABLE_PERL64-multiarch-builds.patch>
> 
> 
> 
> ---
> illumos-developer
> Archives: https://www.listbox.com/member/archive/182179/=now
> RSS Feed: https://www.listbox.com/member/archive/rss/182179/21239177-3604570e
> Modify Your Subscription: 
> https://www.listbox.com/member/?member_id=21239177_secret=21239177-2d0c9337
> Powered by Listbox: http://www.listbox.com
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] ixgbe: breaking aggr on 10GbE X540-T2

2016-06-03 Thread Stephan Budach 

Am 03.06.16 um 15:42 schrieb Fábio Rabelo:

Hi to all

A question:

This are the board you used ?

https://www.supermicro.com/products/motherboard/Xeon/C600/X10DRi-T4_.cfm

If so, this board uses Intel X540, and this issue are only with Intel
X550 chips !


Fábio Rabelo

Yes, this is the board I got. Actually, it's a  X10DRi-T4+

Cheers,
Stephan
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] ixgbe: breaking aggr on 10GbE X540-T2

2016-06-03 Thread Fábio Rabelo 
Hi to all

A question:

This are the board you used ?

https://www.supermicro.com/products/motherboard/Xeon/C600/X10DRi-T4_.cfm

If so, this board uses Intel X540, and this issue are only with Intel
X550 chips !


Fábio Rabelo

2016-06-03 10:20 GMT-03:00 Stephan Budach :
> Hi Dale,
>
> Am 17.05.16 um 20:55 schrieb Dale Ghent:
>
> On May 17, 2016, at 8:30 AM, Stephan Budach  wrote:
>
> I have checked all of my ixgbe interfaces and they all report that now flow
> controll is in place, as you can see:
>
> root@zfsha01colt:/root# dladm show-linkprop -p flowctrl ixgbe0
> LINK PROPERTYPERM VALUE DEFAULTPOSSIBLE
> ixgbe0   flowctrlrw   no no no,tx,rx,bi
> root@zfsha01colt:/root# dladm show-linkprop -p flowctrl ixgbe1
> LINK PROPERTYPERM VALUE DEFAULTPOSSIBLE
> ixgbe1   flowctrlrw   no no no,tx,rx,bi
> root@zfsha01colt:/root# dladm show-linkprop -p flowctrl ixgbe2
> LINK PROPERTYPERM VALUE DEFAULTPOSSIBLE
> ixgbe2   flowctrlrw   no no no,tx,rx,bi
> root@zfsha01colt:/root# dladm show-linkprop -p flowctrl ixgbe3
> LINK PROPERTYPERM VALUE DEFAULTPOSSIBLE
> ixgbe3   flowctrlrw   no no no,tx,rx,bi
>
> I then checked the ports on the Nexus switches and found out, that they do
> have outbound-flowcontrol enabled, but that is the case on any of those
> Nexus ports, including those, where this issue doesn't exist.
>
> Optimally you would have flow control turned off on both sides, as the
> switch still expects the ixgbe NIC to respond appropriately. To be honest,
> the only time to use ethernet flow control is if you are operating the
> interfaces for higher-level protocols which do not provide any sort of
> direct flow control themselves, such as FCoE. If the vast majority of
> traffic is TCP, leave it to the TCP stack to manage any local congestion on
> the link.
>
> /dale
>
> I just wanted to wrap this up… I recently swapped that old Sun server with a
> new Supermicro X10-type, which has 4 10 GbE NICs on board, installed OmniOS
> r018 and my RSF-1 cluster software on it. Configured my two LACP
> aggregations and there hasn't been any issue since.
> So, either it's something on the old server - it's a Sun Fire X4170M2 - or
> something on the Intel cards.
>
> Cheers,
> Stephan
>
>
> ___
> OmniOS-discuss mailing list
> OmniOS-discuss@lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] ixgbe: breaking aggr on 10GbE X540-T2

2016-06-03 Thread Stephan Budach 

Hi Dale,

Am 17.05.16 um 20:55 schrieb Dale Ghent:

On May 17, 2016, at 8:30 AM, Stephan Budach  wrote:


I have checked all of my ixgbe interfaces and they all report that now flow 
controll is in place, as you can see:

root@zfsha01colt:/root# dladm show-linkprop -p flowctrl ixgbe0
LINK PROPERTYPERM VALUE DEFAULTPOSSIBLE
ixgbe0   flowctrlrw   no no no,tx,rx,bi
root@zfsha01colt:/root# dladm show-linkprop -p flowctrl ixgbe1
LINK PROPERTYPERM VALUE DEFAULTPOSSIBLE
ixgbe1   flowctrlrw   no no no,tx,rx,bi
root@zfsha01colt:/root# dladm show-linkprop -p flowctrl ixgbe2
LINK PROPERTYPERM VALUE DEFAULTPOSSIBLE
ixgbe2   flowctrlrw   no no no,tx,rx,bi
root@zfsha01colt:/root# dladm show-linkprop -p flowctrl ixgbe3
LINK PROPERTYPERM VALUE DEFAULTPOSSIBLE
ixgbe3   flowctrlrw   no no no,tx,rx,bi

I then checked the ports on the Nexus switches and found out, that they do have 
outbound-flowcontrol enabled, but that is the case on any of those Nexus ports, 
including those, where this issue doesn't exist.

Optimally you would have flow control turned off on both sides, as the switch 
still expects the ixgbe NIC to respond appropriately. To be honest, the only 
time to use ethernet flow control is if you are operating the interfaces for 
higher-level protocols which do not provide any sort of direct flow control 
themselves, such as FCoE. If the vast majority of traffic is TCP, leave it to 
the TCP stack to manage any local congestion on the link.

/dale
I just wanted to wrap this up… I recently swapped that old Sun server 
with a new Supermicro X10-type, which has 4 10 GbE NICs on board, 
installed OmniOS r018 and my RSF-1 cluster software on it. Configured my 
two LACP aggregations and there hasn't been any issue since.
So, either it's something on the old server - it's a Sun Fire X4170M2 - 
or something on the Intel cards.


Cheers,
Stephan

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss