Re: [OmniOS-discuss] [developer] ENABLE_PERL64
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&id_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
> 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
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&id_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
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
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
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