From fabio at fabiorabelo.wiki.br Mon Sep 1 12:59:31 2014 From: fabio at fabiorabelo.wiki.br (=?UTF-8?Q?F=C3=A1bio_Rabelo?=) Date: Mon, 1 Sep 2014 09:59:31 -0300 Subject: [OmniOS-discuss] LSI SAS3041e-HP In-Reply-To: <1113899755.20140827194755@tierarzt-mueller.de> References: <20140823152213.63df2675@sleipner.datanom.net> <02a401cfbed8$153bfce0$3fb3f6a0$@subrigo.net> <1113899755.20140827194755@tierarzt-mueller.de> Message-ID: Many thanks to all the people ... It is working now, but there is one more tip to share, use an OLD motherboard with good and old BIOS ! Do not try to flash this card in a recent UEFI motherboard or you will get some more headaches .... Thanks again .... my "home storage" are up and running, reports on performance and functionality later ... F?bio Rabelo 2014-08-27 14:47 GMT-03:00 Alexander Lesle : > Hello F?bio, > > first download on the LSI website: > http://www.lsi.com/support/pages/download-results.aspx?component=Storage+Component&productfamily=Legacy+Host+Bus+Adapters&productcode=P00056&assettype=Firmware&productname=LSI+SAS+3041E-R > this two files: > > SAS3041ER_ Package_P21_IR_IT_Firmware_BIOS_for_MSDOS_Windows > http://www.lsi.com/downloads/Public/Host%20Bus%20Adapters/Host%20Bus%20Adapters%20Common%20Files/SAS_SATA_3G_P21/SAS3041ER_%20Package_P21_IR_IT_Firmware_BIOS_for_MSDOS_Windows.zip > SASFlash Quick Reference Guide > http://www.lsi.com/downloads/Public/Obsolete/Obsolete%20Common%20Files/SASFlash_Ref_Guide.zip > > Unzip the first file and copy all the files not the folders on your > USB-Stick - in a new folder e.g. named "sas3041" not more than 8 > letters. > Boot to DOS, switch to c:\sas3041 and first I recommend to do > 'sasflash -list' and write down all infos about the card first. > You know now the Chip Version and the SAS Address. > > Now you can run the 'hbaFlash.bat', select CardType, PCIType, IT-Mode > and Chipversion. > The batch first flash the Firmware and here you get maybe a message that > the ProduktID an VendorID does not match. Type Y to flash anyway. > After flashing Firmware you MUST get the message "Firmware Flash > Successful" > the same with the second flash BIOS you MUST get the successfull > message too and "Finished Processing Commands Successfully". > You have done your card is now in IT-Mode and reflashed to LSI. > > When sasflash breaks and you cant flash the card because it is > branded to HP - you have to erase the card first. > Reboot than 'sasflash -o -e X' X=Parameter > I always use Parameter=6 when I want to reflash to a LSI card. > Do NOT reboot after erase - run the batch file and than set the > SAS Address with 'sasflash -o -sasadd 500x' (x= numbers for SAS address) > You have done. > > Check the driver - see Eric Sproul's recommendation yesterday. > If OmniOS use the driver mpt I would check it out > Parameter=7 to change to mpt_sas. > > Good luck. :) > > am Mittwoch, 27. August 2014 um 00:23 hat u.a. > in mid:CAEekY64ws9mY61aB3otSXduDtrYC3DYjfJ17Zg1SaLxicqrFOw at mail.gmail.com geschrieben: > >> So, how I can flash a 1064E-IR to became a 1064E-IT ? > -- > Mit freundlichem Gruss > Alexander > mailto:groups at tierarzt-mueller.de > eMail geschrieben mit: The Bat! 5.8.8 > unter Windows 7 Pro Service Pack 1 > > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss From vern.bingham at gmail.com Tue Sep 2 12:03:52 2014 From: vern.bingham at gmail.com (Vern Bingham) Date: Tue, 2 Sep 2014 14:03:52 +0200 Subject: [OmniOS-discuss] Building "the rest of" OmniOS Message-ID: <26A7D1D0-7157-45F2-995A-6F39464E9BC4@gmail.com> I wish to rebuild a package ("naming/ldap") on r151006. I carefully followed the instructions given on http://omnios.omniti.com/wiki.php/BuildInstructions . However, if I list the contents of the build subdirectory (./buildctl list), I do not see this package. I can successfully build all packages that appear in the list, but if I try with the package I'm interested in, it (normally) fails with "Unknown package: naming/ldap". How can I add this package source (and others) from the "omnios" publisher that I naively thought would appear automagically in the /omnios-build/build/ sub-directory? Thanks, V. From alexander.r.eremin at gmail.com Tue Sep 2 12:18:59 2014 From: alexander.r.eremin at gmail.com (Alexander Eremin) Date: Tue, 2 Sep 2014 16:18:59 +0400 Subject: [OmniOS-discuss] Building "the rest of" OmniOS In-Reply-To: <26A7D1D0-7157-45F2-995A-6F39464E9BC4@gmail.com> References: <26A7D1D0-7157-45F2-995A-6F39464E9BC4@gmail.com> Message-ID: <7B018F24-2037-4596-B08D-0FD478C66207@gmail.com> naming/ldap comes from illumos Alexander > On 02 ????. 2014 ?., at 16:03, Vern Bingham wrote: > > I wish to rebuild a package ("naming/ldap") on r151006. I carefully followed the instructions given on http://omnios.omniti.com/wiki.php/BuildInstructions . > However, if I list the contents of the build subdirectory (./buildctl list), I do not see this package. > > I can successfully build all packages that appear in the list, but if I try with the package I'm interested in, it (normally) fails with "Unknown package: naming/ldap". > > How can I add this package source (and others) from the "omnios" publisher that I naively thought would appear automagically in the /omnios-build/build/ sub-directory? > > Thanks, > V. > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss From danmcd at omniti.com Tue Sep 2 18:22:56 2014 From: danmcd at omniti.com (Dan McDonald) Date: Tue, 2 Sep 2014 14:22:56 -0400 Subject: [OmniOS-discuss] r151012 is coming... Message-ID: Hello folks! I'm now starting to wind up the r151012 build process. You'll see me dump updates here occasionally. What I'd like to know now is: Any updates you need/want in r151012? If you've been keeping up with my bloody announcements, everything you see there will be landing in r151012. This includes HW goodies like LSI 3008-based 12G SAS (albeit not at optimal performance yet), for example. Once this week's bloody update goes out, there will be a lot of updates to both userspace and in the kernel. I'd like to hear if anyone here has suggestions. I cannot guarantee I will take 'em, but I can at least explain why-not if I don't. Thanks, Dan McD. - OmniOS Engineering From GAlbitz at albitz.biz Tue Sep 2 18:36:06 2014 From: GAlbitz at albitz.biz (Cryptz) Date: Tue, 2 Sep 2014 18:36:06 +0000 Subject: [OmniOS-discuss] r151012 is coming... In-Reply-To: References: Message-ID: <6336c59d9eae4fedbbb1c824cff53782@ALPHA.PSC.Net> really interested in 56gb infiniband, specifically gen 3 mellanox cards. ________________________________________ From: OmniOS-discuss on behalf of Dan McDonald Sent: Tuesday, September 2, 2014 2:22 PM To: omnios-discuss Subject: [OmniOS-discuss] r151012 is coming... Hello folks! I'm now starting to wind up the r151012 build process. You'll see me dump updates here occasionally. What I'd like to know now is: Any updates you need/want in r151012? If you've been keeping up with my bloody announcements, everything you see there will be landing in r151012. This includes HW goodies like LSI 3008-based 12G SAS (albeit not at optimal performance yet), for example. Once this week's bloody update goes out, there will be a lot of updates to both userspace and in the kernel. I'd like to hear if anyone here has suggestions. I cannot guarantee I will take 'em, but I can at least explain why-not if I don't. Thanks, Dan McD. - OmniOS Engineering _______________________________________________ OmniOS-discuss mailing list OmniOS-discuss at lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss From danmcd at omniti.com Tue Sep 2 18:41:21 2014 From: danmcd at omniti.com (Dan McDonald) Date: Tue, 2 Sep 2014 14:41:21 -0400 Subject: [OmniOS-discuss] r151012 is coming... In-Reply-To: <6336c59d9eae4fedbbb1c824cff53782@ALPHA.PSC.Net> References: <6336c59d9eae4fedbbb1c824cff53782@ALPHA.PSC.Net> Message-ID: On Sep 2, 2014, at 2:36 PM, Cryptz wrote: > really interested in 56gb infiniband, specifically gen 3 mellanox cards. I'd need help from Mellanox for that, and it wouldn't be available in the 012 timeframe. If you're a Mellanox-buying customer, let them know that illumos support for their HW will get you to buy more. Dan From lotheac at iki.fi Tue Sep 2 18:41:59 2014 From: lotheac at iki.fi (Lauri Tirkkonen) Date: Tue, 2 Sep 2014 21:41:59 +0300 Subject: [OmniOS-discuss] r151012 is coming... In-Reply-To: References: Message-ID: <20140902184159.GA15289@gutsman.lotheac.fi> On Tue, Sep 02 2014 14:22:56 -0400, Dan McDonald wrote: > What I'd like to know now is: > > Any updates you need/want in r151012? Since you asked - how about this? :) https://github.com/postwait/pkg5/pull/4 -- Lauri Tirkkonen | +358 50 5341376 | lotheac @ IRCnet From danmcd at omniti.com Tue Sep 2 18:45:47 2014 From: danmcd at omniti.com (Dan McDonald) Date: Tue, 2 Sep 2014 14:45:47 -0400 Subject: [OmniOS-discuss] r151012 is coming... In-Reply-To: <20140902184159.GA15289@gutsman.lotheac.fi> References: <20140902184159.GA15289@gutsman.lotheac.fi> Message-ID: <3A4418FB-0F2D-410D-A7A0-D6E0F0C899D2@omniti.com> On Sep 2, 2014, at 2:41 PM, Lauri Tirkkonen wrote: > On Tue, Sep 02 2014 14:22:56 -0400, Dan McDonald wrote: >> What I'd like to know now is: >> >> Any updates you need/want in r151012? > > Since you asked - how about this? :) > https://github.com/postwait/pkg5/pull/4 Yes. I'd have pulled it for THIS WEEK's bloody, but given the shitstorm that happened two weeks ago, I did not. Thanks for the reminder, Dan From valrhona at gmail.com Tue Sep 2 19:13:55 2014 From: valrhona at gmail.com (Valrhona) Date: Tue, 2 Sep 2014 15:13:55 -0400 Subject: [OmniOS-discuss] r151012 is coming... In-Reply-To: <3A4418FB-0F2D-410D-A7A0-D6E0F0C899D2@omniti.com> References: <20140902184159.GA15289@gutsman.lotheac.fi> <3A4418FB-0F2D-410D-A7A0-D6E0F0C899D2@omniti.com> Message-ID: It would be convenient if pkgsrc were installed (not that it's a huge deal to install it, just one more thing to do on a new install). Obviously not all of the packages in that repository will work perfectly, but certain things are very convenient and quick to install. On Tue, Sep 2, 2014 at 2:45 PM, Dan McDonald wrote: > > On Sep 2, 2014, at 2:41 PM, Lauri Tirkkonen wrote: > >> On Tue, Sep 02 2014 14:22:56 -0400, Dan McDonald wrote: >>> What I'd like to know now is: >>> >>> Any updates you need/want in r151012? >> >> Since you asked - how about this? :) >> https://github.com/postwait/pkg5/pull/4 > > Yes. I'd have pulled it for THIS WEEK's bloody, but given the shitstorm that happened two weeks ago, I did not. > > Thanks for the reminder, > Dan > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss From sjorge+ml at blackdot.be Tue Sep 2 19:24:41 2014 From: sjorge+ml at blackdot.be (Jorge Schrauwen) Date: Tue, 02 Sep 2014 21:24:41 +0200 Subject: [OmniOS-discuss] r151012 is coming... In-Reply-To: References: Message-ID: <4bfacd3e462cee26f9b4df4b65b2e6e9@blackdot.be> Can we have qemu-kvm-1.1.2, nahamu has both normal, spice and spice+bardiche working. Having the normal or even better the spice one replacing the current 0.14.x would be really awesome. Regards Jorge On 2014-09-02 20:22, Dan McDonald wrote: > Hello folks! > > I'm now starting to wind up the r151012 build process. You'll see me > dump updates here occasionally. > > What I'd like to know now is: > > Any updates you need/want in r151012? > > If you've been keeping up with my bloody announcements, everything you > see there will be landing in r151012. This includes HW goodies like > LSI 3008-based 12G SAS (albeit not at optimal performance yet), for > example. Once this week's bloody update goes out, there will be a lot > of updates to both userspace and in the kernel. > > I'd like to hear if anyone here has suggestions. I cannot guarantee I > will take 'em, but I can at least explain why-not if I don't. > > Thanks, > Dan McD. - OmniOS Engineering > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss From danmcd at omniti.com Tue Sep 2 19:40:47 2014 From: danmcd at omniti.com (Dan McDonald) Date: Tue, 2 Sep 2014 15:40:47 -0400 Subject: [OmniOS-discuss] r151012 is coming... In-Reply-To: References: <20140902184159.GA15289@gutsman.lotheac.fi> <3A4418FB-0F2D-410D-A7A0-D6E0F0C899D2@omniti.com> Message-ID: <36172C77-7003-4B62-8EED-70A9405CC63C@omniti.com> Something to consider, but not in the timeframe for 012. Thanks, Dan Sent from my iPhone (typos, autocorrect, and all) > On Sep 2, 2014, at 3:13 PM, Valrhona wrote: > > It would be convenient if pkgsrc were installed (not that it's a huge > deal to install it, just one more thing to do on a new install). > Obviously not all of the packages in that repository will work > perfectly, but certain things are very convenient and quick to > install. > >> On Tue, Sep 2, 2014 at 2:45 PM, Dan McDonald wrote: >> >>> On Sep 2, 2014, at 2:41 PM, Lauri Tirkkonen wrote: >>> >>>> On Tue, Sep 02 2014 14:22:56 -0400, Dan McDonald wrote: >>>> What I'd like to know now is: >>>> >>>> Any updates you need/want in r151012? >>> >>> Since you asked - how about this? :) >>> https://github.com/postwait/pkg5/pull/4 >> >> Yes. I'd have pulled it for THIS WEEK's bloody, but given the shitstorm that happened two weeks ago, I did not. >> >> Thanks for the reminder, >> Dan >> >> _______________________________________________ >> OmniOS-discuss mailing list >> OmniOS-discuss at lists.omniti.com >> http://lists.omniti.com/mailman/listinfo/omnios-discuss From danmcd at omniti.com Tue Sep 2 19:43:42 2014 From: danmcd at omniti.com (Dan McDonald) Date: Tue, 2 Sep 2014 15:43:42 -0400 Subject: [OmniOS-discuss] r151012 is coming... In-Reply-To: <4bfacd3e462cee26f9b4df4b65b2e6e9@blackdot.be> References: <4bfacd3e462cee26f9b4df4b65b2e6e9@blackdot.be> Message-ID: I'll consider that IF: 1.) We can build it without needing bardiche. 2.) I need test reports from 010 or preferably bloody showing it works. 3.) A set of diffs that can drop into omnios-build. It's risky changing something like this close to a release. That's why documented testing is so important here. Dan Sent from my iPhone (typos, autocorrect, and all) > On Sep 2, 2014, at 3:24 PM, Jorge Schrauwen wrote: > > Can we have qemu-kvm-1.1.2, nahamu has both normal, spice and spice+bardiche working. > Having the normal or even better the spice one replacing the current 0.14.x would be really awesome. > > Regards > > Jorge > > > >> On 2014-09-02 20:22, Dan McDonald wrote: >> Hello folks! >> I'm now starting to wind up the r151012 build process. You'll see me >> dump updates here occasionally. >> What I'd like to know now is: >> Any updates you need/want in r151012? >> If you've been keeping up with my bloody announcements, everything you >> see there will be landing in r151012. This includes HW goodies like >> LSI 3008-based 12G SAS (albeit not at optimal performance yet), for >> example. Once this week's bloody update goes out, there will be a lot >> of updates to both userspace and in the kernel. >> I'd like to hear if anyone here has suggestions. I cannot guarantee I >> will take 'em, but I can at least explain why-not if I don't. >> Thanks, >> Dan McD. - OmniOS Engineering >> _______________________________________________ >> OmniOS-discuss mailing list >> OmniOS-discuss at lists.omniti.com >> http://lists.omniti.com/mailman/listinfo/omnios-discuss From henson at acm.org Tue Sep 2 20:16:45 2014 From: henson at acm.org (Paul B. Henson) Date: Tue, 2 Sep 2014 13:16:45 -0700 Subject: [OmniOS-discuss] r151012 is coming... In-Reply-To: <36172C77-7003-4B62-8EED-70A9405CC63C@omniti.com> References: <20140902184159.GA15289@gutsman.lotheac.fi> <3A4418FB-0F2D-410D-A7A0-D6E0F0C899D2@omniti.com> <36172C77-7003-4B62-8EED-70A9405CC63C@omniti.com> Message-ID: <20140902201645.GD20693@bender.unx.csupomona.edu> On Tue, Sep 02, 2014 at 03:40:47PM -0400, Dan McDonald wrote: > Something to consider, but not in the timeframe for 012. If pkgsrc (presumably Joyent's pkgin binaries?) were bundled into OmniOS, I would hope they'd be optional packages and not part of the default install. Thanks... > Sent from my iPhone (typos, autocorrect, and all) > > > On Sep 2, 2014, at 3:13 PM, Valrhona wrote: > > > > It would be convenient if pkgsrc were installed (not that it's a huge > > deal to install it, just one more thing to do on a new install). > > Obviously not all of the packages in that repository will work > > perfectly, but certain things are very convenient and quick to > > install. From bfriesen at simple.dallas.tx.us Tue Sep 2 21:21:56 2014 From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn) Date: Tue, 2 Sep 2014 16:21:56 -0500 (CDT) Subject: [OmniOS-discuss] r151012 is coming... In-Reply-To: <20140902201645.GD20693@bender.unx.csupomona.edu> References: <20140902184159.GA15289@gutsman.lotheac.fi> <3A4418FB-0F2D-410D-A7A0-D6E0F0C899D2@omniti.com> <36172C77-7003-4B62-8EED-70A9405CC63C@omniti.com> <20140902201645.GD20693@bender.unx.csupomona.edu> Message-ID: On Tue, 2 Sep 2014, Paul B. Henson wrote: > On Tue, Sep 02, 2014 at 03:40:47PM -0400, Dan McDonald wrote: >> Something to consider, but not in the timeframe for 012. > > If pkgsrc (presumably Joyent's pkgin binaries?) were bundled into > OmniOS, I would hope they'd be optional packages and not part of the > default install. By 'pkgsrc' I assume that they mean the package manager itself, which is able to install other packages. Bob -- Bob Friesenhahn bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ From henson at acm.org Tue Sep 2 21:38:16 2014 From: henson at acm.org (Paul B. Henson) Date: Tue, 2 Sep 2014 14:38:16 -0700 Subject: [OmniOS-discuss] r151012 is coming... In-Reply-To: References: <20140902184159.GA15289@gutsman.lotheac.fi> <3A4418FB-0F2D-410D-A7A0-D6E0F0C899D2@omniti.com> <36172C77-7003-4B62-8EED-70A9405CC63C@omniti.com> <20140902201645.GD20693@bender.unx.csupomona.edu> Message-ID: <20140902213816.GF20693@bender.unx.csupomona.edu> On Tue, Sep 02, 2014 at 04:21:56PM -0500, Bob Friesenhahn wrote: > > If pkgsrc (presumably Joyent's pkgin binaries?) were bundled into > > OmniOS, I would hope they'd be optional packages and not part of the > > default install. > > By 'pkgsrc' I assume that they mean the package manager itself, which > is able to install other packages. Yes, and by "not part of the default install" I mean that the package manager itself would need a 'pkg install' to get installed :). A base pkgsrc bootstrap of just the pieces to install packages is still like a dozen packages... Not everyone is going to use it, so it shouldn't be installed by default... http://omnios.omniti.com/wiki.php/KYSTY # pkg install system/management/pkgin or whatever doesn't seem to be too much trouble for somebody who wants to use it. From jesus at omniti.com Tue Sep 2 21:50:58 2014 From: jesus at omniti.com (Theo Schlossnagle) Date: Tue, 2 Sep 2014 17:50:58 -0400 Subject: [OmniOS-discuss] r151012 is coming... In-Reply-To: <20140902213816.GF20693@bender.unx.csupomona.edu> References: <20140902184159.GA15289@gutsman.lotheac.fi> <3A4418FB-0F2D-410D-A7A0-D6E0F0C899D2@omniti.com> <36172C77-7003-4B62-8EED-70A9405CC63C@omniti.com> <20140902201645.GD20693@bender.unx.csupomona.edu> <20140902213816.GF20693@bender.unx.csupomona.edu> Message-ID: The poses the question: we're already responsible for the correct operation of the pkgadd (SVR4 tools) and pkg(5) IPS tools. I'm not sure that OmniOS wants to be responsible for the correct operation of pkgin (not even opening the can of worms that are the packages that it provides). On Tue, Sep 2, 2014 at 5:38 PM, Paul B. Henson wrote: > On Tue, Sep 02, 2014 at 04:21:56PM -0500, Bob Friesenhahn wrote: > > > > If pkgsrc (presumably Joyent's pkgin binaries?) were bundled into > > > OmniOS, I would hope they'd be optional packages and not part of the > > > default install. > > > > By 'pkgsrc' I assume that they mean the package manager itself, which > > is able to install other packages. > > Yes, and by "not part of the default install" I mean that the package > manager itself would need a 'pkg install' to get installed :). A base > pkgsrc bootstrap of just the pieces to install packages is still like a > dozen packages... Not everyone is going to use it, so it shouldn't be > installed by default... > > http://omnios.omniti.com/wiki.php/KYSTY > > # pkg install system/management/pkgin > > or whatever doesn't seem to be too much trouble for somebody who wants to > use > it. > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > -- Theo Schlossnagle http://omniti.com/is/theo-schlossnagle -------------- next part -------------- An HTML attachment was scrubbed... URL: From bfriesen at simple.dallas.tx.us Tue Sep 2 22:06:53 2014 From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn) Date: Tue, 2 Sep 2014 17:06:53 -0500 (CDT) Subject: [OmniOS-discuss] r151012 is coming... In-Reply-To: References: <20140902184159.GA15289@gutsman.lotheac.fi> <3A4418FB-0F2D-410D-A7A0-D6E0F0C899D2@omniti.com> <36172C77-7003-4B62-8EED-70A9405CC63C@omniti.com> <20140902201645.GD20693@bender.unx.csupomona.edu> <20140902213816.GF20693@bender.unx.csupomona.edu> Message-ID: On Tue, 2 Sep 2014, Theo Schlossnagle wrote: > The poses the question: we're already responsible for the correct operation of the pkgadd (SVR4 tools) and pkg(5) IPS tools. > ?I'm not sure that OmniOS wants to be responsible for the correct operation of pkgin (not even opening the can of worms that > are the packages that it provides). There is also the issue that there are 32-bit and 64-bit versions of the packages and different package manager binaries for each. I installed the 64-bit versions on my OpenIndiana system and learned that they are very 64-bit. For example, the GCC compiler produces 64-bit code by default. Linking behavior is also different. Putting the pkgsrc-installed packages in my executable search path caused stability problems for my software development practices (introduced build problems) and so I have removed it from my executable search path. Bob -- Bob Friesenhahn bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ From sjorge+ml at blackdot.be Tue Sep 2 22:09:42 2014 From: sjorge+ml at blackdot.be (Jorge Schrauwen) Date: Wed, 03 Sep 2014 00:09:42 +0200 Subject: [OmniOS-discuss] r151012 is coming... In-Reply-To: References: Message-ID: Attempt 2, because my mail client is dumb. Oh another one that came to mind... Maybe also move omniti-ms to a versioned repository like and rebuild them every release, we now have stuff with build number over th 060 and 080 range! It's not very clean. The again.. that would require reinstall of all those packages every upgrade which may not be what people want. Regards Jorge On 2014-09-02 20:22, Dan McDonald wrote: > Hello folks! > > I'm now starting to wind up the r151012 build process. You'll see me > dump updates here occasionally. > > What I'd like to know now is: > > Any updates you need/want in r151012? > > If you've been keeping up with my bloody announcements, everything you > see there will be landing in r151012. This includes HW goodies like > LSI 3008-based 12G SAS (albeit not at optimal performance yet), for > example. Once this week's bloody update goes out, there will be a lot > of updates to both userspace and in the kernel. > > I'd like to hear if anyone here has suggestions. I cannot guarantee I > will take 'em, but I can at least explain why-not if I don't. > > Thanks, > Dan McD. - OmniOS Engineering > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss From sjorge+ml at blackdot.be Tue Sep 2 22:11:33 2014 From: sjorge+ml at blackdot.be (Jorge Schrauwen) Date: Wed, 03 Sep 2014 00:11:33 +0200 Subject: [OmniOS-discuss] r151012 is coming... In-Reply-To: References: <4bfacd3e462cee26f9b4df4b65b2e6e9@blackdot.be> Message-ID: <84d603bee18d1fe7be12d090567ce35e@blackdot.be> Attempt nr 2, my mail client is dumb! 1. should not be a problem, it's on my list of things to do (actually first) when looking at the bradiche stuff. 2. I've been running a the one from his smartos dataset on 080 and 010 for a while now. (The pre vnd one) Mostly experimenting around, had not had an issue yet. I will try to switch over my 2 main vm's tomorrow to see how they hold up. 3. Alright, lets forget about it for 012 and I'll see if I can get it to work after I get back from Iceland. Regards Jorge On 2014-09-02 21:43, Dan McDonald wrote: > I'll consider that IF: > > 1.) We can build it without needing bardiche. > > 2.) I need test reports from 010 or preferably bloody showing it works. > > 3.) A set of diffs that can drop into omnios-build. > > It's risky changing something like this close to a release. That's > why documented testing is so important here. > > Dan > > Sent from my iPhone (typos, autocorrect, and all) > >> On Sep 2, 2014, at 3:24 PM, Jorge Schrauwen >> wrote: >> >> Can we have qemu-kvm-1.1.2, nahamu has both normal, spice and >> spice+bardiche working. >> Having the normal or even better the spice one replacing the current >> 0.14.x would be really awesome. >> >> Regards >> >> Jorge >> >> >> >>> On 2014-09-02 20:22, Dan McDonald wrote: >>> Hello folks! >>> I'm now starting to wind up the r151012 build process. You'll see me >>> dump updates here occasionally. >>> What I'd like to know now is: >>> Any updates you need/want in r151012? >>> If you've been keeping up with my bloody announcements, everything >>> you >>> see there will be landing in r151012. This includes HW goodies like >>> LSI 3008-based 12G SAS (albeit not at optimal performance yet), for >>> example. Once this week's bloody update goes out, there will be a >>> lot >>> of updates to both userspace and in the kernel. >>> I'd like to hear if anyone here has suggestions. I cannot guarantee >>> I >>> will take 'em, but I can at least explain why-not if I don't. >>> Thanks, >>> Dan McD. - OmniOS Engineering >>> _______________________________________________ >>> OmniOS-discuss mailing list >>> OmniOS-discuss at lists.omniti.com >>> http://lists.omniti.com/mailman/listinfo/omnios-discuss From danmcd at omniti.com Wed Sep 3 03:07:37 2014 From: danmcd at omniti.com (Dan McDonald) Date: Tue, 2 Sep 2014 23:07:37 -0400 Subject: [OmniOS-discuss] OmniOS "bloody" now updated Message-ID: Pardon the skip of last time's update. A lot has changed here in preparation for the next stable release (r151012). Because of the amount of change, I've pushed out a complete set of updated packages to the bloody repo. This means you'll have to update pkg(5) prior to a full-blown update. If all goes well, there will be no bloody update in two weeks, and in 4-6 weeks, r151012 will show up. If there is a bloody update in two weeks, it will be very close to what becomes r151012, otherwise THIS will be very close to what becomes r151012. I may also choose to update packages very selectively and sproadically between now and r151012 (e.g. updates to timezones or PCI IDs). What's new in this update is: * In userspace: Update unixodbc to 2.3.2 Update swig to 2.0.12 Update sqlite-3 to 3.8.5.0 Update sigcpp to 2.3.2 Update screen to 4.2.1 Update rsync to 3.1.1 Update readline to 6.3 Update simplejson to 3.6.2 Update pycurl to 7.19.5 Update numpy to 1.8.1 Update Mako to 1.0.0 Update M2Crypto to 0.22.3 Update lxml-26 to 3.3.5 Update CherryPy to 3.5.0 Update pv (pipe-viewer) to 1.5.3 Update pcre to 8.35 Update gnu-patch to 2.7.1 Update OpenSSH to 6.6p1 Update NTP to 4.2.7p460 Upgrade libpcap to 1.6.1 Update libidn to 1.29 Update libffi to 3.1 Update less to 458 Update iso-codes to 3.55 Update ISC DHCP to 4.3.1 Update ipmitool to 1.8.14 Upgrade gnu-tar to 1.28 Upgrade gnu-grep to 2.20 Update gmp/gnump to 5.1.3 Update git to 2.0.4 Upgrade gettext to 0.19.2 Update Amazon EC2 API to 1.7.1.0 Update gawk to 4.1.1 Update flex to 2.5.39 Update expat to 2.1.0 Update curl to 7.37.1 Update coreutils to 8.23 Update NSS (3.16.4), NSPR (4.10.6), and ca-bundle. Update bison to 3.0.2 Update gnu-binutils to 2.24 Update bind to 9.10.0-P2 Update bash to 4.3. * And in the illumos part of things: - Removal of ntfsprogs and partd. (If this is something people want, speak now, so we can get it landed somewhere in userland) - Serious header cleanup. No more K&R prototypes (you should've been already, but use ANSI C now, please). - Small mpt_sas bugfixes. (Anyone using 12G yet?) - More man page improvements. Thank you! Dan From esproul at omniti.com Wed Sep 3 04:16:46 2014 From: esproul at omniti.com (Eric Sproul) Date: Wed, 3 Sep 2014 00:16:46 -0400 Subject: [OmniOS-discuss] r151012 is coming... In-Reply-To: References: Message-ID: On Tuesday, September 2, 2014, Jorge Schrauwen wrote: > Attempt 2, because my mail client is dumb. > > Oh another one that came to mind... > Maybe also move omniti-ms to a versioned repository like and rebuild them > every release, we now have stuff with build number over th 060 and 080 > range! It's not very clean. The again.. that would require reinstall of all > those packages every upgrade which may not be what people want. > > That has been discussed, though I'm of the opinion that non-core repos (those supplied as add-ons, beyond the release repo) can freely store versions for multiple releases, simply by establishing an incorporate dependency on "entire" at a branch version matching the release on which the package content was built. This ensures that this package version will only install on one release. This has been the default in the omniti-ms branch of omnios-build for over a year. There are still older packages that were built prior to this change, but all of the recently-updated things act this way. I can also say that Circonus successfully uses this method in our own repos. It's also a simple one-line change if anyone wants it in their own forks/copies: https://github.com/omniti-labs/omnios-build/commit/f9f0f0de Note, though, that omniti-ms packages are updated on OmniTI's own schedule according to internal priorities, so the complete set may not get rolled for every stable release. Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From lotheac at iki.fi Wed Sep 3 06:16:34 2014 From: lotheac at iki.fi (Lauri Tirkkonen) Date: Wed, 3 Sep 2014 09:16:34 +0300 Subject: [OmniOS-discuss] r151012 is coming... In-Reply-To: References: Message-ID: <20140903061634.GB1213@gutsman.lotheac.fi> On Wed, Sep 03 2014 00:16:46 -0400, Eric Sproul wrote: > This ensures that this package version will only install on one > release. Perhaps off-topic, but I'm curious: was this prompted by being bitten by binary incompatibility at some point or are you just being cautious? I'm still happily building stuff in my repo on 151006 and running some of it on 151010... -- Lauri Tirkkonen | +358 50 5341376 | lotheac @ IRCnet From sjorge+ml at blackdot.be Wed Sep 3 08:56:51 2014 From: sjorge+ml at blackdot.be (Jorge Schrauwen) Date: Wed, 03 Sep 2014 10:56:51 +0200 Subject: [OmniOS-discuss] r151012 is coming... In-Reply-To: <84d603bee18d1fe7be12d090567ce35e@blackdot.be> References: <4bfacd3e462cee26f9b4df4b65b2e6e9@blackdot.be> <84d603bee18d1fe7be12d090567ce35e@blackdot.be> Message-ID: Alright, I just switched all my vms to nahamu pre bardiche binaries (copied from smartos). If they hold up I will look into getting some patches. I had a peak at omnios-build and seems messy though. Regards Jorge On 2014-09-03 00:11, Jorge Schrauwen wrote: > Attempt nr 2, my mail client is dumb! > > 1. should not be a problem, it's on my list of things to do (actually > first) when looking at the bradiche stuff. > > 2. I've been running a the one from his smartos dataset on 080 and 010 > for a while now. (The pre vnd one) Mostly experimenting around, had > not had an issue yet. I will try to switch over my 2 main vm's > tomorrow to see how they hold up. > > 3. Alright, lets forget about it for 012 and I'll see if I can get it > to work after I get back from Iceland. > > Regards > > Jorge > > On 2014-09-02 21:43, Dan McDonald wrote: >> I'll consider that IF: >> >> 1.) We can build it without needing bardiche. >> >> 2.) I need test reports from 010 or preferably bloody showing it >> works. >> >> 3.) A set of diffs that can drop into omnios-build. >> >> It's risky changing something like this close to a release. That's >> why documented testing is so important here. >> >> Dan >> >> Sent from my iPhone (typos, autocorrect, and all) >> >>> On Sep 2, 2014, at 3:24 PM, Jorge Schrauwen >>> wrote: >>> >>> Can we have qemu-kvm-1.1.2, nahamu has both normal, spice and >>> spice+bardiche working. >>> Having the normal or even better the spice one replacing the current >>> 0.14.x would be really awesome. >>> >>> Regards >>> >>> Jorge >>> >>> >>> >>>> On 2014-09-02 20:22, Dan McDonald wrote: >>>> Hello folks! >>>> I'm now starting to wind up the r151012 build process. You'll see >>>> me >>>> dump updates here occasionally. >>>> What I'd like to know now is: >>>> Any updates you need/want in r151012? >>>> If you've been keeping up with my bloody announcements, everything >>>> you >>>> see there will be landing in r151012. This includes HW goodies like >>>> LSI 3008-based 12G SAS (albeit not at optimal performance yet), for >>>> example. Once this week's bloody update goes out, there will be a >>>> lot >>>> of updates to both userspace and in the kernel. >>>> I'd like to hear if anyone here has suggestions. I cannot guarantee >>>> I >>>> will take 'em, but I can at least explain why-not if I don't. >>>> Thanks, >>>> Dan McD. - OmniOS Engineering >>>> _______________________________________________ >>>> OmniOS-discuss mailing list >>>> OmniOS-discuss at lists.omniti.com >>>> http://lists.omniti.com/mailman/listinfo/omnios-discuss > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss From vern.bingham at gmail.com Wed Sep 3 09:33:51 2014 From: vern.bingham at gmail.com (Vern Bingham) Date: Wed, 3 Sep 2014 11:33:51 +0200 Subject: [OmniOS-discuss] Building "the rest of" OmniOS In-Reply-To: <7B018F24-2037-4596-B08D-0FD478C66207@gmail.com> References: <26A7D1D0-7157-45F2-995A-6F39464E9BC4@gmail.com> <7B018F24-2037-4596-B08D-0FD478C66207@gmail.com> Message-ID: <0A58FD32-FC94-425A-AACC-9BAAD7C97618@gmail.com> On 2 Sep 2014, at 14:18, Alexander Eremin wrote: > naming/ldap comes from illumos > > Alexander > >> On 02 ????. 2014 ?., at 16:03, Vern Bingham wrote: >> >> I wish to rebuild a package ("naming/ldap") on r151006. I carefully followed the instructions given on http://omnios.omniti.com/wiki.php/BuildInstructions . >> However, if I list the contents of the build subdirectory (./buildctl list), I do not see this package. >> >> I can successfully build all packages that appear in the list, but if I try with the package I'm interested in, it (normally) fails with "Unknown package: naming/ldap". >> >> How can I add this package source (and others) from the "omnios" publisher that I naively thought would appear automagically in the /omnios-build/build/ sub-directory? >> >> Thanks, >> V. Thanks Alexander! I downloaded the Illumos source with "git clone git://github.com/illumos/illumos-gate.git", where I found the source code for the ldap commands, and I am now in the process of building it... From dseira at stackscale.com Wed Sep 3 11:05:19 2014 From: dseira at stackscale.com (David Seira) Date: Wed, 3 Sep 2014 13:05:19 +0200 Subject: [OmniOS-discuss] Aggregation Link fails with flow-control enabled Message-ID: I'm testing the OmniOS for our storage system. I have a server with two 10G intel network card using the driver ixgbe. I've done the following steps: - Create an aggregation interface: dladm create-aggr -d ixgbe0 -d ixgbe1 aggr0 ipadm create-if aggr0 ipadm create-addr -T static -a 1.2.3.4/24 aggr0/v4 - Add a flow-control for the aggregation interface: flowadm add-flow -l aggr0 -a local_ip=1.2.3.4 flow_aggr0 After this, if I shutdown one of the interfaces in the switch I loose the connectivity with the server. It seems that the aggregation doesn't forward the traffic to the other interface. Having one of the ports in the switch down, and without connectivity with the server because of the above issue; If I remove the flow (through the console, of course), the server goes online immediately. If I add the flow again, the server is innacessible again. It seems an incompatibility with the aggreation interfaces and the flow control. I've tested this bug with the r151006 and r151010 releases with the same result. The hardware where I've tested is: - Dell PowerEdge R720 with an Intel X520 dual port 10G/SFP - Dell PowerEdge C6220 with 10G mezzanine dual port Does anyone know what can be the problem? Has anyone experienced a similar issue? Best regards. -- -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandre.lecuyer at gmail.com Wed Sep 3 13:49:42 2014 From: alexandre.lecuyer at gmail.com (Alexandre Lecuyer) Date: Wed, 3 Sep 2014 15:49:42 +0200 Subject: [OmniOS-discuss] r151012 is coming... In-Reply-To: References: Message-ID: Q-in-Q (802.1ad) would be nice ! Regarding LSI 12Gbps, I've been running bloody with a SAS9300-8e and 12Gbps Hitachi drives, no issues so far On 2 September 2014 20:22, Dan McDonald wrote: > Hello folks! > > I'm now starting to wind up the r151012 build process. You'll see me dump > updates here occasionally. > > What I'd like to know now is: > > Any updates you need/want in r151012? > > If you've been keeping up with my bloody announcements, everything you see > there will be landing in r151012. This includes HW goodies like LSI > 3008-based 12G SAS (albeit not at optimal performance yet), for example. > Once this week's bloody update goes out, there will be a lot of updates to > both userspace and in the kernel. > > I'd like to hear if anyone here has suggestions. I cannot guarantee I > will take 'em, but I can at least explain why-not if I don't. > > Thanks, > Dan McD. - OmniOS Engineering > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > -------------- next part -------------- An HTML attachment was scrubbed... URL: From slefevre at indy.rr.com Wed Sep 3 14:05:58 2014 From: slefevre at indy.rr.com (Scott LeFevre) Date: Wed, 03 Sep 2014 10:05:58 -0400 Subject: [OmniOS-discuss] Aggregation Link fails with flow-control enabled In-Reply-To: References: Message-ID: <1409753158.10357.60.camel@exilis.si-consulting.us> Did you configure LACP on your aggr0 or the switch? That's the only way I've been able to get aggregate links to work. -- Scott LeFevre 317-696-1010 On Wed, 2014-09-03 at 13:05 +0200, David Seira wrote: > I'm testing the OmniOS for our storage system. I have a server with > two 10G intel network card using the driver ixgbe. > > > > I've done the following steps: > > > - Create an aggregation interface: > > > dladm create-aggr -d ixgbe0 -d ixgbe1 aggr0 > ipadm create-if aggr0 > ipadm create-addr -T static -a 1.2.3.4/24 aggr0/v4 > > > - Add a flow-control for the aggregation interface: > > > flowadm add-flow -l aggr0 -a local_ip=1.2.3.4 flow_aggr0 > > > After this, if I shutdown one of the interfaces in the switch I loose > the connectivity with the server. It seems that the aggregation > doesn't forward the traffic to the other interface. > > > Having one of the ports in the switch down, and without connectivity > with the server because of the above issue; If I remove the flow > (through the console, of course), the server goes online immediately. > > > If I add the flow again, the server is innacessible again. > > > It seems an incompatibility with the aggreation interfaces and the > flow control. > > > I've tested this bug with the r151006 and r151010 releases with the > same result. > > > The hardware where I've tested is: > > > - Dell PowerEdge R720 with an Intel X520 dual port 10G/SFP > - Dell PowerEdge C6220 with 10G mezzanine dual port > > > Does anyone know what can be the problem? Has anyone experienced a > similar issue? > > > Best regards. > > > -- > > > > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss -------------- next part -------------- An HTML attachment was scrubbed... URL: From danmcd at omniti.com Wed Sep 3 14:07:22 2014 From: danmcd at omniti.com (Dan McDonald) Date: Wed, 3 Sep 2014 10:07:22 -0400 Subject: [OmniOS-discuss] Aggregation Link fails with flow-control enabled In-Reply-To: References: Message-ID: On Sep 3, 2014, at 7:05 AM, David Seira wrote: > > - Add a flow-control for the aggregation interface: > > flowadm add-flow -l aggr0 -a local_ip=1.2.3.4 flow_aggr0 > > After this, if I shutdown one of the interfaces in the switch I loose the connectivity with the server. It seems that the aggregation doesn't forward the traffic to the other interface. > > Having one of the ports in the switch down, and without connectivity with the server because of the above issue; If I remove the flow (through the console, of course), the server goes online immediately. > > If I add the flow again, the server is innacessible again. Silly question --> are you adding properties to the flow (priority or maxbw)? I don't doubt you've a bug, but I'm curious if it's limited to what is in effect a NOP flow, or if it affects a proper flow (where it's enforcing something)? Thanks, Dan From esproul at omniti.com Wed Sep 3 14:17:28 2014 From: esproul at omniti.com (Eric Sproul) Date: Wed, 3 Sep 2014 10:17:28 -0400 Subject: [OmniOS-discuss] r151012 is coming... In-Reply-To: <20140903061634.GB1213@gutsman.lotheac.fi> References: <20140903061634.GB1213@gutsman.lotheac.fi> Message-ID: On Wed, Sep 3, 2014 at 2:16 AM, Lauri Tirkkonen wrote: > On Wed, Sep 03 2014 00:16:46 -0400, Eric Sproul wrote: >> This ensures that this package version will only install on one >> release. > > Perhaps off-topic, but I'm curious: was this prompted by being bitten by > binary incompatibility at some point or are you just being cautious? I'm > still happily building stuff in my repo on 151006 and running some of it > on 151010... Partly it's that we can't predict the future, but there are also forward-compatibility problems that this prevents as well. For example, consider: foo at 1.2-0.151006 - built on 006, might run on later releases foo at 1.3-0.151010 - built on 010, *will not* run on older releases due to libc changes In the absence of an incorporation on entire, the higher component version (1.3) will trump and an 006 system would try to install it, and be broken. This is the more concerning condition, and the reason why the automatic incorporation was added. It occurs to me that instead of an incorporate dependency, a "require" of entire@ would prevent installation on older releases (require is a version floor only) while allowing it to be installed on future releases, which is more likely to work. It's something to think about. Eric From dseira at stackscale.com Wed Sep 3 14:17:50 2014 From: dseira at stackscale.com (David Seira) Date: Wed, 3 Sep 2014 16:17:50 +0200 Subject: [OmniOS-discuss] Aggregation Link fails with flow-control enabled In-Reply-To: References: Message-ID: @Scott In the switch there is configured a Port-Channel between the physical ports. without the flow control the behaviour is as expected; the aggr forward the traffic depending if one port is down or viceversa. @Dan The flow is only configured (for now) for monitoring purpose; no properties are added. In fact, later in the morning, I tested the Solaris 11.1 version and the system works perfectly with the aggr and the flow. It seems a bug in the flow control layer. Thanks, David 2014-09-03 16:07 GMT+02:00 Dan McDonald : > > On Sep 3, 2014, at 7:05 AM, David Seira wrote: > > > > > - Add a flow-control for the aggregation interface: > > > > flowadm add-flow -l aggr0 -a local_ip=1.2.3.4 flow_aggr0 > > > > After this, if I shutdown one of the interfaces in the switch I loose > the connectivity with the server. It seems that the aggregation doesn't > forward the traffic to the other interface. > > > > Having one of the ports in the switch down, and without connectivity > with the server because of the above issue; If I remove the flow (through > the console, of course), the server goes online immediately. > > > > If I add the flow again, the server is innacessible again. > > Silly question --> are you adding properties to the flow (priority or > maxbw)? I don't doubt you've a bug, but I'm curious if it's limited to > what is in effect a NOP flow, or if it affects a proper flow (where it's > enforcing something)? > > Thanks, > Dan > > -- -------------- next part -------------- An HTML attachment was scrubbed... URL: From lotheac at iki.fi Wed Sep 3 15:52:29 2014 From: lotheac at iki.fi (Lauri Tirkkonen) Date: Wed, 3 Sep 2014 18:52:29 +0300 Subject: [OmniOS-discuss] r151012 is coming... In-Reply-To: References: <20140903061634.GB1213@gutsman.lotheac.fi> Message-ID: <20140903155229.GB11131@gutsman.lotheac.fi> On Wed, Sep 03 2014 10:17:28 -0400, Eric Sproul wrote: > Partly it's that we can't predict the future, but there are also > forward-compatibility problems that this prevents as well. For > example, consider: > > foo at 1.2-0.151006 - built on 006, might run on later releases > foo at 1.3-0.151010 - built on 010, *will not* run on older releases due > to libc changes > > In the absence of an incorporation on entire, the higher component > version (1.3) will trump and an 006 system would try to install it, > and be broken. This is the more concerning condition, and the reason > why the automatic incorporation was added. If you are using pkgdepend and your application links against libc, this isn't a problem: it will get a require dep to SUNWcs at the version installed on the build machine at build time. > It occurs to me that instead of an incorporate dependency, a "require" > of entire@ would prevent installation on older > releases (require is a version floor only) while allowing it to be > installed on future releases, which is more likely to work. It's > something to think about. Sure, if you want to be explicit you can do this as well. -- Lauri Tirkkonen | +358 50 5341376 | lotheac @ IRCnet From esproul at omniti.com Wed Sep 3 15:58:23 2014 From: esproul at omniti.com (Eric Sproul) Date: Wed, 3 Sep 2014 11:58:23 -0400 Subject: [OmniOS-discuss] r151012 is coming... In-Reply-To: <20140903155229.GB11131@gutsman.lotheac.fi> References: <20140903061634.GB1213@gutsman.lotheac.fi> <20140903155229.GB11131@gutsman.lotheac.fi> Message-ID: On Wed, Sep 3, 2014 at 11:52 AM, Lauri Tirkkonen wrote: > > If you are using pkgdepend and your application links against libc, this > isn't a problem: it will get a require dep to SUNWcs at the version > installed on the build machine at build time. Of course; that was just an example. There are lots of other situations not covered by pkgdepend though, as I'm sure you know. :) Eric From dan at syneto.net Wed Sep 3 16:01:21 2014 From: dan at syneto.net (Dan Vatca) Date: Wed, 3 Sep 2014 19:01:21 +0300 Subject: [OmniOS-discuss] Building OmniOS master branch Message-ID: Hello everybody, I am trying to compile omniOS from the master branch while running 151010j and compiling the gcc48 package fails when determining dependencies with this message: --- Resolving dependencies The file dependency depend fmri=__TBD pkg.debug.depend.file=libgmp.so.10 pkg.debug.depend.path=lib pkg.debug.depend.path=opt/gcc-4.8.1/lib pkg.debug.depend.path=usr/lib pkg.debug.depend.reason=opt/gcc-4.8.1/libexec/gcc/i386-pc-solaris2.11/4.8.1/cc1 pkg.debug.depend.type=elf type=require delivered in package pkg:/developer/gcc48 at 4.8.1,5.11-0.151011 has paths which resolve to multiple packages under this combination of variants: variant.opensolaris.zone:global variant.arch:i386 variant.opensolaris.zone:nonglobal variant.arch:i386 The actions are: depend fmri=pkg:/developer/gcc48/libgmp-gcc48 at 5.0.5-0.151010 pkg.debug.depend.file=opt/gcc-4.8.1/lib/libgmp.so.10.0.5 pkg.debug.depend.reason=opt/gcc-4.8.1/libexec/gcc/i386-pc-solaris2.11/4.8.1/cc1 pkg.debug.depend.type=elf pkg.debug.depend.via-links=opt/gcc-4.8.1/lib/libgmp.so.10 type=require depend fmri=pkg:/library/gmp at 5.1.2-0.151010 pkg.debug.depend.file=usr/lib/libgmp.so.10.1.2 pkg.debug.depend.reason=opt/gcc-4.8.1/libexec/gcc/i386-pc-solaris2.11/4.8.1/cc1 pkg.debug.depend.type=elf pkg.debug.depend.via-links=usr/lib/libgmp.so.10 type=require The file dependency depend fmri=__TBD pkg.debug.depend.file=libgmp.so.10 pkg.debug.depend.path=lib pkg.debug.depend.path=opt/gcc-4.8.1/lib pkg.debug.depend.path=usr/lib pkg.debug.depend.reason=opt/gcc-4.8.1/libexec/gcc/i386-pc-solaris2.11/4.8.1/cc1plus pkg.debug.depend.type=elf type=require delivered in package pkg:/developer/gcc48 at 4.8.1,5.11-0.151011 has paths which resolve to multiple packages under this combination of variants: variant.opensolaris.zone:global variant.arch:i386 variant.opensolaris.zone:nonglobal variant.arch:i386 The actions are: depend fmri=pkg:/developer/gcc48/libgmp-gcc48 at 5.0.5-0.151010 pkg.debug.depend.file=opt/gcc-4.8.1/lib/libgmp.so.10.0.5 pkg.debug.depend.reason=opt/gcc-4.8.1/libexec/gcc/i386-pc-solaris2.11/4.8.1/cc1plus pkg.debug.depend.type=elf pkg.debug.depend.via-links=opt/gcc-4.8.1/lib/libgmp.so.10 type=require depend fmri=pkg:/library/gmp at 5.1.2-0.151010 pkg.debug.depend.file=usr/lib/libgmp.so.10.1.2 pkg.debug.depend.reason=opt/gcc-4.8.1/libexec/gcc/i386-pc-solaris2.11/4.8.1/cc1plus pkg.debug.depend.type=elf pkg.debug.depend.via-links=usr/lib/libgmp.so.10 type=require The file dependency depend fmri=__TBD pkg.debug.depend.file=libgmp.so.10 pkg.debug.depend.path=lib pkg.debug.depend.path=opt/gcc-4.8.1/lib pkg.debug.depend.path=usr/lib pkg.debug.depend.reason=opt/gcc-4.8.1/libexec/gcc/i386-pc-solaris2.11/4.8.1/f951 pkg.debug.depend.type=elf type=require delivered in package pkg:/developer/gcc48 at 4.8.1,5.11-0.151011 has paths which resolve to multiple packages under this combination of variants: variant.opensolaris.zone:global variant.arch:i386 variant.opensolaris.zone:nonglobal variant.arch:i386 The actions are: depend fmri=pkg:/developer/gcc48/libgmp-gcc48 at 5.0.5-0.151010 pkg.debug.depend.file=opt/gcc-4.8.1/lib/libgmp.so.10.0.5 pkg.debug.depend.reason=opt/gcc-4.8.1/libexec/gcc/i386-pc-solaris2.11/4.8.1/f951 pkg.debug.depend.type=elf pkg.debug.depend.via-links=opt/gcc-4.8.1/lib/libgmp.so.10 type=require depend fmri=pkg:/library/gmp at 5.1.2-0.151010 pkg.debug.depend.file=usr/lib/libgmp.so.10.1.2 pkg.debug.depend.reason=opt/gcc-4.8.1/libexec/gcc/i386-pc-solaris2.11/4.8.1/f951 pkg.debug.depend.type=elf pkg.debug.depend.via-links=usr/lib/libgmp.so.10 type=require The file dependency depend fmri=__TBD pkg.debug.depend.file=libgmp.so.10 pkg.debug.depend.path=lib pkg.debug.depend.path=opt/gcc-4.8.1/lib pkg.debug.depend.path=usr/lib pkg.debug.depend.reason=opt/gcc-4.8.1/libexec/gcc/i386-pc-solaris2.11/4.8.1/lto1 pkg.debug.depend.type=elf type=require delivered in package pkg:/developer/gcc48 at 4.8.1,5.11-0.151011 has paths which resolve to multiple packages under this combination of variants: variant.opensolaris.zone:global variant.arch:i386 variant.opensolaris.zone:nonglobal variant.arch:i386 The actions are: depend fmri=pkg:/developer/gcc48/libgmp-gcc48 at 5.0.5-0.151010 pkg.debug.depend.file=opt/gcc-4.8.1/lib/libgmp.so.10.0.5 pkg.debug.depend.reason=opt/gcc-4.8.1/libexec/gcc/i386-pc-solaris2.11/4.8.1/lto1 pkg.debug.depend.type=elf pkg.debug.depend.via-links=opt/gcc-4.8.1/lib/libgmp.so.10 type=require depend fmri=pkg:/library/gmp at 5.1.2-0.151010 pkg.debug.depend.file=usr/lib/libgmp.so.10.1.2 pkg.debug.depend.reason=opt/gcc-4.8.1/libexec/gcc/i386-pc-solaris2.11/4.8.1/lto1 pkg.debug.depend.type=elf pkg.debug.depend.via-links=usr/lib/libgmp.so.10 type=require --- Dependency resolution failed I can see that the resolver finds the same library in two different paths (in usr/lib and in opt/gcc-4.8.1/lib). Any idea what I might be doing wrong? Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From henson at acm.org Thu Sep 4 01:03:29 2014 From: henson at acm.org (Paul B. Henson) Date: Wed, 3 Sep 2014 18:03:29 -0700 Subject: [OmniOS-discuss] Building OmniOS master branch In-Reply-To: References: Message-ID: <1eab01cfc7dc$0bf21220$23d63660$@acm.org> > From: Dan Vatca > Sent: Wednesday, September 03, 2014 9:01 AM > > I am trying to compile omniOS from the master branch while running 151010j > and compiling the gcc48 package fails when determining dependencies with > this message: >From what I understand, you can only compile bloody if you are running bloody; they do not support compiling the latest development code running a stable release version. It would be nice if you could at least compile omnios-illumos on a stable release, I don't really want to have to run a bloody box just to do some upstream illumos forward development :). From danmcd at omniti.com Thu Sep 4 01:33:27 2014 From: danmcd at omniti.com (Dan McDonald) Date: Wed, 3 Sep 2014 21:33:27 -0400 Subject: [OmniOS-discuss] Building OmniOS master branch In-Reply-To: <1eab01cfc7dc$0bf21220$23d63660$@acm.org> References: <1eab01cfc7dc$0bf21220$23d63660$@acm.org> Message-ID: On Sep 3, 2014, at 9:03 PM, Paul B. Henson wrote: >> From: Dan Vatca >> Sent: Wednesday, September 03, 2014 9:01 AM >> >> I am trying to compile omniOS from the master branch while running 151010j >> and compiling the gcc48 package fails when determining dependencies with >> this message: > > From what I understand, you can only compile bloody if you are running bloody; they do not support compiling the latest development code running a stable release version. For omnios-build this is true. For illumos-omnios by itself, you can build "master" on r151010. > It would be nice if you could at least compile omnios-illumos on a stable release, I don't really want to have to run a bloody box just to do some upstream illumos forward development :). You can/should be able to. Just use /opt/onbld/bin/nightly with an appropriate env file. Want me to share one with the class? Dan From henson at acm.org Thu Sep 4 01:56:32 2014 From: henson at acm.org (Paul B. Henson) Date: Wed, 3 Sep 2014 18:56:32 -0700 Subject: [OmniOS-discuss] Building OmniOS master branch In-Reply-To: References: <1eab01cfc7dc$0bf21220$23d63660$@acm.org> Message-ID: <20140904015632.GG20693@bender.unx.csupomona.edu> On Wed, Sep 03, 2014 at 09:33:27PM -0400, Dan McDonald wrote: > You can/should be able to. Just use /opt/onbld/bin/nightly with an > appropriate env file. Want me to share one with the class? Hmm, I was trying to build it per http://omnios.omniti.com/wiki.php/BuildInstructions, using "cd illumos; ./build.sh", which doesn't sound like what you're describing. So, to build just the latest illumos bits, you should check out illumos-omnios directly and build it using the upstream scripts rather than the omnios build scripts? Yes, an example would be appreciated, or even better a new section on that wiki page labeled "Building the latest illumos-omnios on a stable release" :)? Thanks... From danmcd at omniti.com Thu Sep 4 02:04:11 2014 From: danmcd at omniti.com (Dan McDonald) Date: Wed, 3 Sep 2014 22:04:11 -0400 Subject: [OmniOS-discuss] Building OmniOS master branch In-Reply-To: <20140904015632.GG20693@bender.unx.csupomona.edu> References: <1eab01cfc7dc$0bf21220$23d63660$@acm.org> <20140904015632.GG20693@bender.unx.csupomona.edu> Message-ID: <510FFD8F-D57A-4507-9CE3-A3F6CDB4F1B6@omniti.com> On Sep 3, 2014, at 9:56 PM, Paul B. Henson wrote: > On Wed, Sep 03, 2014 at 09:33:27PM -0400, Dan McDonald wrote: > >> You can/should be able to. Just use /opt/onbld/bin/nightly with an >> appropriate env file. Want me to share one with the class? > > Hmm, I was trying to build it per > http://omnios.omniti.com/wiki.php/BuildInstructions, using "cd illumos; > ./build.sh", which doesn't sound like what you're describing. So, to > build just the latest illumos bits, you should check out illumos-omnios > directly and build it using the upstream scripts rather than the omnios > build scripts? That's what I do. And if you look at the master branch's tools/OmniOS-on-demand.sh, that's what it does too. > Yes, an example would be appreciated, or even better a new section on > that wiki page labeled "Building the latest illumos-omnios on a stable > release" :)? I'll see what I can do. There MAY be flag-day issues I'm forgetting, however. I'm fighting some fires right now trying to get ready for 012's release. I'll be very high-latency for a bit. Dan From henson at acm.org Thu Sep 4 02:12:41 2014 From: henson at acm.org (Paul B. Henson) Date: Wed, 3 Sep 2014 19:12:41 -0700 Subject: [OmniOS-discuss] Building OmniOS master branch In-Reply-To: <510FFD8F-D57A-4507-9CE3-A3F6CDB4F1B6@omniti.com> References: <1eab01cfc7dc$0bf21220$23d63660$@acm.org> <20140904015632.GG20693@bender.unx.csupomona.edu> <510FFD8F-D57A-4507-9CE3-A3F6CDB4F1B6@omniti.com> Message-ID: <20140904021241.GH20693@bender.unx.csupomona.edu> On Wed, Sep 03, 2014 at 10:04:11PM -0400, Dan McDonald wrote: > That's what I do. And if you look at the master branch's > tools/OmniOS-on-demand.sh, that's what it does too. Ah, that didn't exist the last time I played with it :). > I'm fighting some fires right now trying to get ready for 012's > release. I'll be very high-latency for a bit. No worries, this certainly isn't a priority, thanks... From dan at syneto.net Thu Sep 4 07:04:36 2014 From: dan at syneto.net (Dan Vatca) Date: Thu, 4 Sep 2014 10:04:36 +0300 Subject: [OmniOS-discuss] Building OmniOS master branch In-Reply-To: <20140904021241.GH20693@bender.unx.csupomona.edu> References: <1eab01cfc7dc$0bf21220$23d63660$@acm.org> <20140904015632.GG20693@bender.unx.csupomona.edu> <510FFD8F-D57A-4507-9CE3-A3F6CDB4F1B6@omniti.com> <20140904021241.GH20693@bender.unx.csupomona.edu> Message-ID: The thing that I find odd is that dependencies are gathered from the build system and not from the set of packages OmniOS is currently building. If we could find a way to do that, couldn't we have a way to build any version of OmniOS on any other version? -------------- next part -------------- An HTML attachment was scrubbed... URL: From danmcd at omniti.com Thu Sep 4 14:38:57 2014 From: danmcd at omniti.com (Dan McDonald) Date: Thu, 4 Sep 2014 10:38:57 -0400 Subject: [OmniOS-discuss] Building OmniOS master branch In-Reply-To: References: <1eab01cfc7dc$0bf21220$23d63660$@acm.org> <20140904015632.GG20693@bender.unx.csupomona.edu> <510FFD8F-D57A-4507-9CE3-A3F6CDB4F1B6@omniti.com> <20140904021241.GH20693@bender.unx.csupomona.edu> Message-ID: On Sep 4, 2014, at 3:04 AM, Dan Vatca wrote: > The thing that I find odd is that dependencies are gathered from the build system and not from the set of packages OmniOS is currently building. > If we could find a way to do that, couldn't we have a way to build any version of OmniOS on any other version? Modulo flag days, illumos-omnios is built self-contained save for the usr/src/tools portion. The rest of omnios-build isn't, and this comes from the early bootstrapping days. One could spend time allowing this to occur, but given we update bloody pretty much every two weeks now, I'd rather spend time making omnios-build properly generate dependencies and build a dependency graph to dispatch component builds in parallel. Right now, it builds based on bash's associative-array sort... ewww. Dan From danmcd at omniti.com Thu Sep 4 18:57:37 2014 From: danmcd at omniti.com (Dan McDonald) Date: Thu, 4 Sep 2014 14:57:37 -0400 Subject: [OmniOS-discuss] Install ISO issues (was Install issues) In-Reply-To: <8DAA06AB-8D4E-45F0-91D1-06332D954BFB@paskett.org> References: <1408885479.23280.14.camel@exilis.si-consulting.us> <8DAA06AB-8D4E-45F0-91D1-06332D954BFB@paskett.org> Message-ID: <291F352A-8E20-4E8E-8951-48F65A1D6B41@omniti.com> On Aug 25, 2014, at 8:38 PM, Keith Paskett wrote: > Just a note, that I have had the same issue with r151010 hanging after the copyright notice. > I have the issue when booting from CD on several different SunFIre servers. They are X4150s and X4250s. > I have not yet tried on other systems. Multiple people have reported issues with the most recent r151010 install ISO. I'm seeing it, AND I'm seeing it on a newly-spun ISO as well. I've re-respun 151010u for ISO and USB-DD. I believe user "danmcd's" default umask of 077 was causing problems with distro_const. The new 'u' ISOs for 151010 are up on the servers now. Sorry for the inconvenience, back to 151012 for me! Dan From sjorge+ml at blackdot.be Thu Sep 4 19:16:15 2014 From: sjorge+ml at blackdot.be (Jorge Schrauwen) Date: Thu, 04 Sep 2014 21:16:15 +0200 Subject: [OmniOS-discuss] r151012 is coming... In-Reply-To: References: Message-ID: <67393e846b7c968fb837dfff40631ea8@blackdot.be> Hey Dan, As mentioned on IRC, maybe we should bundle vioblk in the ISO/USB/Kayak images. It's in the following package: pkg:/driver/storage/vioblk And we might also include the network drivers pkg:/driver/misc/virtio Thanks Jorge On 2014-09-02 20:22, Dan McDonald wrote: > Hello folks! > > I'm now starting to wind up the r151012 build process. You'll see me > dump updates here occasionally. > > What I'd like to know now is: > > Any updates you need/want in r151012? > > If you've been keeping up with my bloody announcements, everything you > see there will be landing in r151012. This includes HW goodies like > LSI 3008-based 12G SAS (albeit not at optimal performance yet), for > example. Once this week's bloody update goes out, there will be a lot > of updates to both userspace and in the kernel. > > I'd like to hear if anyone here has suggestions. I cannot guarantee I > will take 'em, but I can at least explain why-not if I don't. > > Thanks, > Dan McD. - OmniOS Engineering > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss From jesus at omniti.com Thu Sep 4 20:00:46 2014 From: jesus at omniti.com (Theo Schlossnagle) Date: Thu, 4 Sep 2014 16:00:46 -0400 Subject: [OmniOS-discuss] r151012 is coming... In-Reply-To: <67393e846b7c968fb837dfff40631ea8@blackdot.be> References: <67393e846b7c968fb837dfff40631ea8@blackdot.be> Message-ID: We should just stick those in entire... so... +1. On Thu, Sep 4, 2014 at 3:16 PM, Jorge Schrauwen wrote: > Hey Dan, > > As mentioned on IRC, maybe we should bundle vioblk in the ISO/USB/Kayak > images. > It's in the following package: > pkg:/driver/storage/vioblk > And we might also include the network drivers > pkg:/driver/misc/virtio > > Thanks > > > Jorge > > > On 2014-09-02 20:22, Dan McDonald wrote: > >> Hello folks! >> >> I'm now starting to wind up the r151012 build process. You'll see me >> dump updates here occasionally. >> >> What I'd like to know now is: >> >> Any updates you need/want in r151012? >> >> If you've been keeping up with my bloody announcements, everything you >> see there will be landing in r151012. This includes HW goodies like >> LSI 3008-based 12G SAS (albeit not at optimal performance yet), for >> example. Once this week's bloody update goes out, there will be a lot >> of updates to both userspace and in the kernel. >> >> I'd like to hear if anyone here has suggestions. I cannot guarantee I >> will take 'em, but I can at least explain why-not if I don't. >> >> Thanks, >> Dan McD. - OmniOS Engineering >> >> _______________________________________________ >> OmniOS-discuss mailing list >> OmniOS-discuss at lists.omniti.com >> http://lists.omniti.com/mailman/listinfo/omnios-discuss >> > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > -- Theo Schlossnagle http://omniti.com/is/theo-schlossnagle -------------- next part -------------- An HTML attachment was scrubbed... URL: From sjorge+ml at blackdot.be Thu Sep 4 20:04:40 2014 From: sjorge+ml at blackdot.be (Jorge Schrauwen) Date: Thu, 04 Sep 2014 22:04:40 +0200 Subject: [OmniOS-discuss] r151012 is coming... In-Reply-To: References: <67393e846b7c968fb837dfff40631ea8@blackdot.be> Message-ID: <253ad997f5e0c8dafb9bc4aa868567ff@blackdot.be> lotheac said on IRC virtio is just pulls in vioblk as there is no virtio-net driver. But the vioblk is the important one for installs. But getting it in entire would be nice, that would mean kayak images will have it too :) On 2014-09-04 22:00, Theo Schlossnagle wrote: > We should just stick those in entire... so... +1. > > On Thu, Sep 4, 2014 at 3:16 PM, Jorge Schrauwen > wrote: > Hey Dan, > > As mentioned on IRC, maybe we should bundle vioblk in the ISO/USB/Kayak > images. > It's in the following package: > pkg:/driver/storage/vioblk > And we might also include the network drivers > pkg:/driver/misc/virtio > > Thanks > > Jorge > > On 2014-09-02 20:22, Dan McDonald wrote: > > Hello folks! > > I'm now starting to wind up the r151012 build process. You'll see me > dump updates here occasionally. > > What I'd like to know now is: > > Any updates you need/want in r151012? > > If you've been keeping up with my bloody announcements, everything you > see there will be landing in r151012. This includes HW goodies like > LSI 3008-based 12G SAS (albeit not at optimal performance yet), for > example. Once this week's bloody update goes out, there will be a lot > of updates to both userspace and in the kernel. > > I'd like to hear if anyone here has suggestions. I cannot guarantee I > will take 'em, but I can at least explain why-not if I don't. > > Thanks, > Dan McD. - OmniOS Engineering > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss [1] > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss [1] -- Theo Schlossnagle http://omniti.com/is/theo-schlossnagle [2] Links: ------ [1] http://lists.omniti.com/mailman/listinfo/omnios-discuss [2] http://omniti.com/is/theo-schlossnagle From danmcd at omniti.com Thu Sep 4 20:12:50 2014 From: danmcd at omniti.com (Dan McDonald) Date: Thu, 4 Sep 2014 16:12:50 -0400 Subject: [OmniOS-discuss] r151012 is coming... In-Reply-To: <253ad997f5e0c8dafb9bc4aa868567ff@blackdot.be> References: <67393e846b7c968fb837dfff40631ea8@blackdot.be> <253ad997f5e0c8dafb9bc4aa868567ff@blackdot.be> Message-ID: On Sep 4, 2014, at 4:04 PM, Jorge Schrauwen wrote: > lotheac said on IRC virtio is just pulls in vioblk as there is no virtio-net driver. > But the vioblk is the important one for installs. > > But getting it in entire would be nice, that would mean kayak images will have it too :) osdev3(~/ws/omnios-build)[0]% git diff diff --git a/build/entire/entire.p5m b/build/entire/entire.p5m index e9ccf1f..2ff6be2 100644 --- a/build/entire/entire.p5m +++ b/build/entire/entire.p5m @@ -32,6 +32,7 @@ depend fmri=driver/graphics/drm at 0.5.11,5.11- at PVER@ type=requir depend fmri=driver/i86pc/fipe at 0.5.11,5.11- at PVER@ type=require depend fmri=driver/i86pc/ioat at 0.5.11,5.11- at PVER@ type=require depend fmri=driver/i86pc/platform at 0.5.11,5.11- at PVER@ type=require +depend fmri=driver/misc/virtio at 0.5.11,5.11- at PVER@ type=require depend fmri=driver/network/afe at 0.5.11,5.11- at PVER@ type=require depend fmri=driver/network/amd8111s at 0.5.11,5.11- at PVER@ type=require depend fmri=driver/network/atge at 0.5.11,5.11- at PVER@ type=require @@ -113,6 +114,7 @@ depend fmri=driver/storage/sdcard at 0.5.11,5.11- at PVER@ type=re depend fmri=driver/storage/ses at 0.5.11,5.11- at PVER@ type=require depend fmri=driver/storage/si3124 at 0.5.11,5.11- at PVER@ type=require depend fmri=driver/storage/smp at 0.5.11,5.11- at PVER@ type=require +depend fmri=driver/storage/virtio at 0.5.11,5.11- at PVER@ type=require depend fmri=driver/usb/ugen at 0.5.11,5.11- at PVER@ type=require depend fmri=driver/usb at 0.5.11,5.11- at PVER@ type=require depend fmri=driver/virtualization/kvm at 1.0.3-@PVER@ type=require osdev3(~/ws/omnios-build)[0]% Something like that? Dan From danmcd at omniti.com Thu Sep 4 20:14:00 2014 From: danmcd at omniti.com (Dan McDonald) Date: Thu, 4 Sep 2014 16:14:00 -0400 Subject: [OmniOS-discuss] r151012 is coming... In-Reply-To: References: <67393e846b7c968fb837dfff40631ea8@blackdot.be> <253ad997f5e0c8dafb9bc4aa868567ff@blackdot.be> Message-ID: <3497D043-3828-4B81-82B9-4366476EBB9D@omniti.com> On Sep 4, 2014, at 4:12 PM, Dan McDonald wrote: > > On Sep 4, 2014, at 4:04 PM, Jorge Schrauwen wrote: > >> lotheac said on IRC virtio is just pulls in vioblk as there is no virtio-net driver. >> But the vioblk is the important one for installs. >> >> But getting it in entire would be nice, that would mean kayak images will have it too :) > > > osdev3(~/ws/omnios-build)[0]% git diff > diff --git a/build/entire/entire.p5m b/build/entire/entire.p5m > index e9ccf1f..2ff6be2 100644 > --- a/build/entire/entire.p5m > +++ b/build/entire/entire.p5m > @@ -32,6 +32,7 @@ depend fmri=driver/graphics/drm at 0.5.11,5.11- at PVER@ type=requir > depend fmri=driver/i86pc/fipe at 0.5.11,5.11- at PVER@ type=require > depend fmri=driver/i86pc/ioat at 0.5.11,5.11- at PVER@ type=require > depend fmri=driver/i86pc/platform at 0.5.11,5.11- at PVER@ type=require > +depend fmri=driver/misc/virtio at 0.5.11,5.11- at PVER@ type=require > depend fmri=driver/network/afe at 0.5.11,5.11- at PVER@ type=require > depend fmri=driver/network/amd8111s at 0.5.11,5.11- at PVER@ type=require > depend fmri=driver/network/atge at 0.5.11,5.11- at PVER@ type=require > @@ -113,6 +114,7 @@ depend fmri=driver/storage/sdcard at 0.5.11,5.11- at PVER@ type=re > depend fmri=driver/storage/ses at 0.5.11,5.11- at PVER@ type=require > depend fmri=driver/storage/si3124 at 0.5.11,5.11- at PVER@ type=require > depend fmri=driver/storage/smp at 0.5.11,5.11- at PVER@ type=require > +depend fmri=driver/storage/virtio at 0.5.11,5.11- at PVER@ type=require That "virtio" right above should be "vioblk". Dan From sjorge+ml at blackdot.be Thu Sep 4 20:16:48 2014 From: sjorge+ml at blackdot.be (Jorge Schrauwen) Date: Thu, 04 Sep 2014 22:16:48 +0200 Subject: [OmniOS-discuss] r151012 is coming... In-Reply-To: <3497D043-3828-4B81-82B9-4366476EBB9D@omniti.com> References: <67393e846b7c968fb837dfff40631ea8@blackdot.be> <253ad997f5e0c8dafb9bc4aa868567ff@blackdot.be> <3497D043-3828-4B81-82B9-4366476EBB9D@omniti.com> Message-ID: <8819a45268504e716490e9cfcdfbb834@blackdot.be> seems good to me, although I am not overly familiar with p5m's I usually let build.sh deal with those. On 2014-09-04 22:14, Dan McDonald wrote: > On Sep 4, 2014, at 4:12 PM, Dan McDonald wrote: > >> >> On Sep 4, 2014, at 4:04 PM, Jorge Schrauwen >> wrote: >> >>> lotheac said on IRC virtio is just pulls in vioblk as there is no >>> virtio-net driver. >>> But the vioblk is the important one for installs. >>> >>> But getting it in entire would be nice, that would mean kayak images >>> will have it too :) >> >> >> osdev3(~/ws/omnios-build)[0]% git diff >> diff --git a/build/entire/entire.p5m b/build/entire/entire.p5m >> index e9ccf1f..2ff6be2 100644 >> --- a/build/entire/entire.p5m >> +++ b/build/entire/entire.p5m >> @@ -32,6 +32,7 @@ depend fmri=driver/graphics/drm at 0.5.11,5.11- at PVER@ >> type=requir >> depend fmri=driver/i86pc/fipe at 0.5.11,5.11- at PVER@ type=require >> depend fmri=driver/i86pc/ioat at 0.5.11,5.11- at PVER@ type=require >> depend fmri=driver/i86pc/platform at 0.5.11,5.11- at PVER@ type=require >> +depend fmri=driver/misc/virtio at 0.5.11,5.11- at PVER@ type=require >> depend fmri=driver/network/afe at 0.5.11,5.11- at PVER@ type=require >> depend fmri=driver/network/amd8111s at 0.5.11,5.11- at PVER@ type=require >> depend fmri=driver/network/atge at 0.5.11,5.11- at PVER@ type=require >> @@ -113,6 +114,7 @@ depend >> fmri=driver/storage/sdcard at 0.5.11,5.11- at PVER@ type=re >> depend fmri=driver/storage/ses at 0.5.11,5.11- at PVER@ type=require >> depend fmri=driver/storage/si3124 at 0.5.11,5.11- at PVER@ type=require >> depend fmri=driver/storage/smp at 0.5.11,5.11- at PVER@ type=require >> +depend fmri=driver/storage/virtio at 0.5.11,5.11- at PVER@ type=require > > That "virtio" right above should be "vioblk". > > Dan From rafibeyli at gmail.com Tue Sep 9 07:48:15 2014 From: rafibeyli at gmail.com (Hafiz Rafibeyli) Date: Tue, 9 Sep 2014 10:48:15 +0300 (EEST) Subject: [OmniOS-discuss] znapzend question In-Reply-To: <2090174598.153614.1410248724794.JavaMail.zimbra@cantekstil.com.tr> Message-ID: <499713751.153715.1410248895433.JavaMail.zimbra@cantekstil.com.tr> Hello Tobias, did you try znapzend on Nexenta 4.x?anyway run it on Nexenta? and second question: is znapzend working with volume based(block based) filesystems? regards, Hafiz -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From tobi at oetiker.ch Tue Sep 9 08:54:01 2014 From: tobi at oetiker.ch (Tobias Oetiker) Date: Tue, 9 Sep 2014 10:54:01 +0200 (CEST) Subject: [OmniOS-discuss] znapzend question In-Reply-To: <499713751.153715.1410248895433.JavaMail.zimbra@cantekstil.com.tr> References: <499713751.153715.1410248895433.JavaMail.zimbra@cantekstil.com.tr> Message-ID: Today Hafiz Rafibeyli wrote: > Hello Tobias, > > did you try znapzend on Nexenta 4.x?anyway run it on Nexenta? no > and second question: > > is znapzend working with volume based(block based) filesystems? there should be no problem ... cheers tobi > > regards, > > Hafiz > > > > -- Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland www.oetiker.ch tobi at oetiker.ch +41 62 775 9902 From dan at syneto.net Tue Sep 9 09:20:14 2014 From: dan at syneto.net (Dan Vatca) Date: Tue, 9 Sep 2014 12:20:14 +0300 Subject: [OmniOS-discuss] Building OmniOS master branch In-Reply-To: References: <1eab01cfc7dc$0bf21220$23d63660$@acm.org> <20140904015632.GG20693@bender.unx.csupomona.edu> <510FFD8F-D57A-4507-9CE3-A3F6CDB4F1B6@omniti.com> <20140904021241.GH20693@bender.unx.csupomona.edu> Message-ID: Trying to build master led me to another error when building extra tools while running bloody. This error was due to the fact that the tools are compiled using headers from master illumos-omnios, while linking agains the system installed libc. And this got me thinking if I am running the latest bloody. So I went do download the latest bloody iso, and on the web site there is a little problem: the OmniOS_Text_bloody_20140723.iso does not install the omnios-8e364a8 as written above. Is there a new "bloody" text-install iso that is not yet uploaded? I upgraded after installing the one that's available, and now I can build bloody. This was another part of the answer to my question :) On Thu, Sep 4, 2014 at 5:38 PM, Dan McDonald wrote: > > On Sep 4, 2014, at 3:04 AM, Dan Vatca wrote: > > > The thing that I find odd is that dependencies are gathered from the > build system and not from the set of packages OmniOS is currently building. > > If we could find a way to do that, couldn't we have a way to build any > version of OmniOS on any other version? > > Modulo flag days, illumos-omnios is built self-contained save for the > usr/src/tools portion. The rest of omnios-build isn't, and this comes from > the early bootstrapping days. One could spend time allowing this to occur, > but given we update bloody pretty much every two weeks now, I'd rather > spend time making omnios-build properly generate dependencies and build a > dependency graph to dispatch component builds in parallel. Right now, it > builds based on bash's associative-array sort... ewww. > > Dan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From danmcd at omniti.com Tue Sep 9 14:17:18 2014 From: danmcd at omniti.com (Dan McDonald) Date: Tue, 9 Sep 2014 10:17:18 -0400 Subject: [OmniOS-discuss] Building OmniOS master branch In-Reply-To: References: <1eab01cfc7dc$0bf21220$23d63660$@acm.org> <20140904015632.GG20693@bender.unx.csupomona.edu> <510FFD8F-D57A-4507-9CE3-A3F6CDB4F1B6@omniti.com> <20140904021241.GH20693@bender.unx.csupomona.edu> Message-ID: On Sep 9, 2014, at 5:20 AM, Dan Vatca wrote: > Trying to build master led me to another error when building extra tools while running bloody. This error was due to the fact that the tools are compiled using headers from master illumos-omnios, while linking agains the system installed libc. And this got me thinking if I am running the latest bloody. > So I went do download the latest bloody iso, and on the web site there is a little problem: the OmniOS_Text_bloody_20140723.iso does not install the omnios-8e364a8 as written above. > Is there a new "bloody" text-install iso that is not yet uploaded? No. I don't always update the install ISOs with bloody. That's just how it rolls. There may be one more bloody update, BTW, prior to 012 going out the door. > I upgraded after installing the one that's available, and now I can build bloody. This was another part of the answer to my question :) Dan From dan at syneto.net Wed Sep 10 12:16:28 2014 From: dan at syneto.net (Dan Vatca) Date: Wed, 10 Sep 2014 15:16:28 +0300 Subject: [OmniOS-discuss] Building OmniOS master branch In-Reply-To: References: <1eab01cfc7dc$0bf21220$23d63660$@acm.org> <20140904015632.GG20693@bender.unx.csupomona.edu> <510FFD8F-D57A-4507-9CE3-A3F6CDB4F1B6@omniti.com> <20140904021241.GH20693@bender.unx.csupomona.edu> Message-ID: That is fine. The thing that got me was the mismatch between the uname shown above the download link and what the iso installs. Not a problem though ... On Tue, Sep 9, 2014 at 5:17 PM, Dan McDonald wrote: > > On Sep 9, 2014, at 5:20 AM, Dan Vatca wrote: > > > Trying to build master led me to another error when building extra tools > while running bloody. This error was due to the fact that the tools are > compiled using headers from master illumos-omnios, while linking agains the > system installed libc. And this got me thinking if I am running the latest > bloody. > > So I went do download the latest bloody iso, and on the web site there > is a little problem: the OmniOS_Text_bloody_20140723.iso does not install > the omnios-8e364a8 as written above. > > Is there a new "bloody" text-install iso that is not yet uploaded? > > No. I don't always update the install ISOs with bloody. That's just how > it rolls. There may be one more bloody update, BTW, prior to 012 going out > the door. > > > I upgraded after installing the one that's available, and now I can > build bloody. This was another part of the answer to my question :) > > Dan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chip at innovates.com Wed Sep 10 12:50:59 2014 From: chip at innovates.com (Schweiss, Chip) Date: Wed, 10 Sep 2014 07:50:59 -0500 Subject: [OmniOS-discuss] E5-2600 v3 Haswell Message-ID: I see systems based on Xeon Haswells are shipping now. Has anyone tried OmniOS on any of these yet? What are my chances everything working as expected with OmniOS on these systems if I would order one today? Cheers! -Chip -------------- next part -------------- An HTML attachment was scrubbed... URL: From esproul at omniti.com Wed Sep 10 13:59:35 2014 From: esproul at omniti.com (Eric Sproul) Date: Wed, 10 Sep 2014 09:59:35 -0400 Subject: [OmniOS-discuss] E5-2600 v3 Haswell In-Reply-To: References: Message-ID: On Wed, Sep 10, 2014 at 8:50 AM, Schweiss, Chip wrote: > I see systems based on Xeon Haswells are shipping now. > > Has anyone tried OmniOS on any of these yet? > > What are my chances everything working as expected with OmniOS on these > systems if I would order one today? Pure speculation on my part, as I don't have any kit on hand; just going by the specs I see. I looked over Supermicro's new X10 lineup yesterday (http://www.supermicro.com/products/nfo/Xeon_X10_E5.cfm). You'll be fine with most NIC parts, GbE (typically Intel i350) and 10G (X540). Don't believe the 40G stuff is supported yet, but it has come up on the illumos dev list, though I can't find a link at the moment. C612 SATA ports should "just work" as they are AHCI. LSI SAS3008-based HBAs should work with currently-available bloody and the upcoming r151012 release. Unsure if the RAID-enabled 3108 would work... likely not, but we don't care about RAID parts right? :) NVMe will not work yet (but watch https://www.illumos.org/issues/4053 if you're interested in helping). I'm pretty ignorant when it comes to the various Infiniband options too, so anyone more familiar with that stuff should chime in. Hope that helps, Eric From danmcd at omniti.com Wed Sep 10 14:02:55 2014 From: danmcd at omniti.com (Dan McDonald) Date: Wed, 10 Sep 2014 10:02:55 -0400 Subject: [OmniOS-discuss] E5-2600 v3 Haswell In-Reply-To: References: Message-ID: On Sep 10, 2014, at 8:50 AM, Schweiss, Chip wrote: > I see systems based on Xeon Haswells are shipping now. > > Has anyone tried OmniOS on any of these yet? Not to my knowledge. > What are my chances everything working as expected with OmniOS on these systems if I would order one today? 1.) I'd stick with a GigE mobo instead of a 40GigE one. The i40e driver isn't ported to illumos yet, and I'm not sure if this time we'll get Intel's help. Having said that, there is community interest, but no known driver bits are available. 2.) USB3 isn't supported on illumos yet as well. I don't know if these mobos can have their USB set to USB2 only or not, or whether or not even USB3 is a problem. 3.) Eric covered the SATA ports and the NVMe things. Dan From mark0x01 at gmail.com Thu Sep 11 07:57:09 2014 From: mark0x01 at gmail.com (Mark) Date: Thu, 11 Sep 2014 19:57:09 +1200 Subject: [OmniOS-discuss] Fibre Target problems Message-ID: <541155D5.8080406@gmail.com> I have a Supermicro X7DWN+ based server with 24 x 4Tb SAS disks on a LSI 6G IT mode hba. After configuring a bunch of 10Tb Luns and presenting to a Win2012 server, write is very slow < 6 Mb/sec, and writing causes the Fc link to drop repeatedly. Reads reach about 400Mb/sec. OmniOS version is r151006_057. I've tried two different 4G and an 8G QLogic adapters, via switch or direct, but there is no change in behaviour. Only 1 HBA and path. The odd thing is the exact same hardware and os setup (fct, zpool etc.) works well with OI or Solaris 11/11, with writes getting around 4-500 Mb/sec. I had to start with OI147 and work up, as the later text installer is very buggy. Upgrading OI with qlt installed fails. I'm at a bit of a loss as to a likely cause. Anyone have any pointers ? Some details and log: HBA Port WWN: 2100001b320aba27 Port Mode: Target Port ID: 10100 OS Device Name: Not Applicable Manufacturer: QLogic Corp. Model: QLE2460 Firmware Version: 5.2.1 FCode/BIOS Version: N/A Serial Number: not available Driver Name: COMSTAR QLT Driver Version: 20100505-1.05 Type: F-port State: online Supported Speeds: 1Gb 2Gb 4Gb Current Speed: 4Gb Node WWN: 2000001b320aba27 Link Error Statistics: Link Failure Count: 0 Loss of Sync Count: 0 Loss of Signal Count: 0 Primitive Seq Protocol Error Count: 0 Invalid Tx Word Count: 4 Invalid CRC Count: 0 prtconf value='ISP2432-based 4Gb Fibre Channel to PCI Express HBA' name='subsystem-name' type=string items=1 value='unknown subsystem' Device Minor Nodes:dev=(3,1) dev_path=/pci at 0,0/pci8086,4027 at 7/pci8086,3500 at 0/pci8086,3510 at 0/pci1077,137 at 0:qlt1 echo "*stmf_trace_buf/s" | mdb -k 0xffffff090f7c0000: qlt1,0:0001318: iport is ffffff090f1921b8 :0003718: Imported the LU 600144f09cdd9224000053f56a5c0005 :0003719: Imported the LU 600144f09cdd9224000053f56a5d0006 :0003721: Imported the LU 600144f09cdd9224000053f56a5d0007 :0003722: Imported the LU 600144f09cdd9224000053f56a5e0008 :0003725: Imported the LU 600144f09cdd9224000053f56a5e0009 :0003726: Imported the LU 600144f09cdd9224000053f56a5f000a :0003728: Imported the LU 600144f09cdd9224000053f56a5f000b qlt1,0:0003815: Async event 8010 mb1=f8e8 mb2=c108, mb3=0, mb5=3362, mb6=0 qlt1,0:0003815: Async event 8011 mb1=3 mb2=c108, mb3=0, mb5=3362, mb6=0 qlt1,0:0003815: port state change from 0 to e qlt1,0:0003815: Async event 8014 mb1=ffff mb2=6, mb3=0, mb5=3362, mb6=0 qlt1,0:0003815: Posting unsol ELS 3 (PLOGI) rp_id=e8 lp_id=ef qlt1,0:0003815: Rcvd PLOGI with wrong lportid ef, expecting 0. Killing ELS. qlt1,0:0003815: port state change from e to 4 qlt1,0:0004216: Posting unsol ELS 3 (PLOGI) rp_id=e8 lp_id=ef qlt1,0:0004216: Processing unsol ELS 3 (PLOGI) rp_id=e8 qlt1,0:0004216: Posting unsol ELS 20 (PRLI) rp_id=e8 lp_id=ef qlt1,0:0004216: Processing unsol ELS 20 (PRLI) rp_id=e8 qlt1,0:7247736: Posting unsol ELS 5 (LOGO) rp_id=e8 lp_id=ef qlt1,0:7247736: Processing unsol ELS 5 (LOGO) rp_id=e8 qlt1,0:7247736: handling LOGO rp_id e8. Triggering cleanup :7248836: fct_port_shutdown: port-ffffff090f1920b8, fct_process_logo: unable to clean up I/O. iport-ffffff090f1921b8, icmd-ffffff0931089a00 qlt1,0:7248836: port state change from 4 to 11 :7248836: fct_port_shutdown: port-ffffff090f1920b8, fct_process_logo: unable to clean up I/O. iport-ffffff090f1921b8, icmd-ffffff0931089a00 qlt1,0:7248836: port state change from 11 to 11 :7248836: fct_port_shutdown: port-ffffff090f1920b8, fct_process_logo: unable to clean up I/O. iport-ffffff090f1921b8, icmd-ffffff0931089a00 qlt1,0:7248936: port state change from 11 to 11 :7248936: fct_port_shutdown: port-ffffff090f1920b8, fct_process_logo: unable to clean up I/O. iport-ffffff090f1921b8, icmd-ffffff0931089a00 qlt1,0:7249036: port state change from 11 to 11 :7249036: fct_port_shutdown: port-ffffff090f1920b8, fct_process_logo: unable to clean up I/O. iport-ffffff090f1921b8, icmd-ffffff0931089a00 qlt1,0:7249136: port state change from 11 to 11 qlt1,0:7249136: Killing ELS 5 cond 1 qlt1,0:7249136: Processing sol ELS 5 (LOGO) rp_id=e8 qlt1,0:7249136: handling LOGO rp_id e8. Triggering cleanup qlt1,0:7249236: port state change from 11 to 11 qlt1,0:7249336: port state change from 11 to 11 qlt1,0:7249336: port state change from 11 to 11 qlt1,0:7249436: port state change from 11 to 11 qlt1,0:7249536: port state change from 11 to 11 qlt1,0:7249536: handling LOGO rp_id e8, waiting for cmds to drain qlt1,0:7249636: port state change from 11 to 11 qlt1,0:7249736: port state change from 11 to 11 qlt1,0:7249836: port state change from 11 to 11 qlt1,0:7249936: port state change from 11 to 11 qlt1,0:7250036: port state change from 11 to 11 qlt1,0:7250136: port state change from 11 to 11 qlt1,0:7250236: port state change from 11 to 11 :7250236: fct_port_shutdown: port-ffffff090f1920b8, fct_process_logo: unable to clean up I/O. iport-ffffff090f1921b8, icmd-ffffff091c5549d0 qlt1,0:7250336: port state change from 11 to 11 :7250336: fct_port_shutdown: port-ffffff090f1920b8, fct_process_logo: unable to clean up I/O. iport-ffffff090f1921b8, icmd-ffffff091c5549d0 qlt1,0:7250336: port state change from 11 to 11 :7250336: fct_port_shutdown: port-ffffff090f1920b8, fct_process_logo: unable to clean up I/O. iport-ffffff090f1921b8, icmd-ffffff091c5549d0 qlt1,0:7250436: port state change from 11 to 11 :7250436: fct_port_shutdown: port-ffffff090f1920b8, fct_process_logo: unable to clean up I/O. iport-ffffff090f1921b8, icmd-ffffff091c5549d0 qlt1,0:7250536: port state change from 11 to 11 :7250536: fct_port_shutdown: port-ffffff090f1920b8, fct_process_logo: unable to clean up I/O. iport-ffffff090f1921b8, icmd-ffffff091c5549d0 qlt1,0:7250636: port state change from 11 to 11 :7250636: fct_port_shutdown: port-ffffff090f1920b8, fct_process_logo: unable to clean up I/O. iport-ffffff090f1921b8, icmd-ffffff091c5549d0 qlt1,0:7250736: port state change from 11 to 11 :7250736: fct_port_shutdown: port-ffffff090f1920b8, fct_process_logo: unable to clean up I/O. iport-ffffff090f1921b8, icmd-ffffff091c5549d0 qlt1,0:7250836: port state change from 11 to 11 :7250836: fct_port_shutdown: port-ffffff090f1920b8, fct_process_logo: unable to clean up I/O. iport-ffffff090f1921b8, icmd-ffffff091c5549d0 qlt1,0:7250936: port state change from 11 to 11 :7250936: fct_port_shutdown: port-ffffff090f1920b8, fct_process_logo: unable to clean up I/O. iport-ffffff090f1921b8, icmd-ffffff091c5549d0 qlt1,0:7251136: port state change from 11 to 11 :7251136: fct_port_shutdown: port-ffffff090f1920b8, fct_process_logo: unable to clean up I/O. iport-ffffff090f1921b8, icmd-ffffff091c5549d0 qlt1,0:7251236: port state change from 11 to 11 From mf at osn.de Thu Sep 11 09:25:27 2014 From: mf at osn.de (OSN | Marian Fischer) Date: Thu, 11 Sep 2014 09:25:27 +0000 Subject: [OmniOS-discuss] Fibre Target problems In-Reply-To: <541155D5.8080406@gmail.com> References: <541155D5.8080406@gmail.com> Message-ID: <562C2ABFE2448D4E95E8910A85488708260B0262@HEIMAT.cm3c.local> Hi, do you have Sync=disabled in ZFS / ZPOOL settings? If not, this can cause the slow speed ... Mit besten Gruessen Marian Fischer -- OSN Online Service Nuernberg GmbH http://www.osn.de Bucher Str. 78 Tel: 0911/39905-0 90408 Nuernberg Fax: 0911/39905-55 HRB 15022 Nuernberg, Ust-Id: DE189301263 GF: Joerg Goltermann -----Urspr?ngliche Nachricht----- Von: OmniOS-discuss [mailto:omnios-discuss-bounces at lists.omniti.com] Im Auftrag von Mark Gesendet: Donnerstag, 11. September 2014 09:57 An: omnios-discuss at lists.omniti.com Betreff: [OmniOS-discuss] Fibre Target problems I have a Supermicro X7DWN+ based server with 24 x 4Tb SAS disks on a LSI 6G IT mode hba. After configuring a bunch of 10Tb Luns and presenting to a Win2012 server, write is very slow < 6 Mb/sec, and writing causes the Fc link to drop repeatedly. Reads reach about 400Mb/sec. OmniOS version is r151006_057. I've tried two different 4G and an 8G QLogic adapters, via switch or direct, but there is no change in behaviour. Only 1 HBA and path. The odd thing is the exact same hardware and os setup (fct, zpool etc.) works well with OI or Solaris 11/11, with writes getting around 4-500 Mb/sec. I had to start with OI147 and work up, as the later text installer is very buggy. Upgrading OI with qlt installed fails. I'm at a bit of a loss as to a likely cause. Anyone have any pointers ? Some details and log: HBA Port WWN: 2100001b320aba27 Port Mode: Target Port ID: 10100 OS Device Name: Not Applicable Manufacturer: QLogic Corp. Model: QLE2460 Firmware Version: 5.2.1 FCode/BIOS Version: N/A Serial Number: not available Driver Name: COMSTAR QLT Driver Version: 20100505-1.05 Type: F-port State: online Supported Speeds: 1Gb 2Gb 4Gb Current Speed: 4Gb Node WWN: 2000001b320aba27 Link Error Statistics: Link Failure Count: 0 Loss of Sync Count: 0 Loss of Signal Count: 0 Primitive Seq Protocol Error Count: 0 Invalid Tx Word Count: 4 Invalid CRC Count: 0 prtconf value='ISP2432-based 4Gb Fibre Channel to PCI Express HBA' name='subsystem-name' type=string items=1 value='unknown subsystem' Device Minor Nodes:dev=(3,1) dev_path=/pci at 0,0/pci8086,4027 at 7/pci8086,3500 at 0/pci8086,3510 at 0/pci1077,137 at 0 :qlt1 echo "*stmf_trace_buf/s" | mdb -k 0xffffff090f7c0000: qlt1,0:0001318: iport is ffffff090f1921b8 :0003718: Imported the LU 600144f09cdd9224000053f56a5c0005 :0003719: Imported the LU 600144f09cdd9224000053f56a5d0006 :0003721: Imported the LU 600144f09cdd9224000053f56a5d0007 :0003722: Imported the LU 600144f09cdd9224000053f56a5e0008 :0003725: Imported the LU 600144f09cdd9224000053f56a5e0009 :0003726: Imported the LU 600144f09cdd9224000053f56a5f000a :0003728: Imported the LU 600144f09cdd9224000053f56a5f000b qlt1,0:0003815: Async event 8010 mb1=f8e8 mb2=c108, mb3=0, mb5=3362, mb6=0 qlt1,0:0003815: Async event 8011 mb1=3 mb2=c108, mb3=0, mb5=3362, mb6=0 qlt1,0:0003815: port state change from 0 to e qlt1,0:0003815: Async event 8014 mb1=ffff mb2=6, mb3=0, mb5=3362, mb6=0 qlt1,0:0003815: Posting unsol ELS 3 (PLOGI) rp_id=e8 lp_id=ef qlt1,0:0003815: Rcvd PLOGI with wrong lportid ef, expecting 0. Killing ELS. qlt1,0:0003815: port state change from e to 4 qlt1,0:0004216: Posting unsol ELS 3 (PLOGI) rp_id=e8 lp_id=ef qlt1,0:0004216: Processing unsol ELS 3 (PLOGI) rp_id=e8 qlt1,0:0004216: Posting unsol ELS 20 (PRLI) rp_id=e8 lp_id=ef qlt1,0:0004216: Processing unsol ELS 20 (PRLI) rp_id=e8 qlt1,0:7247736: Posting unsol ELS 5 (LOGO) rp_id=e8 lp_id=ef qlt1,0:7247736: Processing unsol ELS 5 (LOGO) rp_id=e8 qlt1,0:7247736: handling LOGO rp_id e8. Triggering cleanup :7248836: fct_port_shutdown: port-ffffff090f1920b8, fct_process_logo: unable to clean up I/O. iport-ffffff090f1921b8, icmd-ffffff0931089a00 qlt1,0:7248836: port state change from 4 to 11 :7248836: fct_port_shutdown: port-ffffff090f1920b8, fct_process_logo: unable to clean up I/O. iport-ffffff090f1921b8, icmd-ffffff0931089a00 qlt1,0:7248836: port state change from 11 to 11 :7248836: fct_port_shutdown: port-ffffff090f1920b8, fct_process_logo: unable to clean up I/O. iport-ffffff090f1921b8, icmd-ffffff0931089a00 qlt1,0:7248936: port state change from 11 to 11 :7248936: fct_port_shutdown: port-ffffff090f1920b8, fct_process_logo: unable to clean up I/O. iport-ffffff090f1921b8, icmd-ffffff0931089a00 qlt1,0:7249036: port state change from 11 to 11 :7249036: fct_port_shutdown: port-ffffff090f1920b8, fct_process_logo: unable to clean up I/O. iport-ffffff090f1921b8, icmd-ffffff0931089a00 qlt1,0:7249136: port state change from 11 to 11 qlt1,0:7249136: Killing ELS 5 cond 1 qlt1,0:7249136: Processing sol ELS 5 (LOGO) rp_id=e8 qlt1,0:7249136: handling LOGO rp_id e8. Triggering cleanup qlt1,0:7249236: port state change from 11 to 11 qlt1,0:7249336: port state change from 11 to 11 qlt1,0:7249336: port state change from 11 to 11 qlt1,0:7249436: port state change from 11 to 11 qlt1,0:7249536: port state change from 11 to 11 qlt1,0:7249536: handling LOGO rp_id e8, waiting for cmds to drain qlt1,0:7249636: port state change from 11 to 11 qlt1,0:7249736: port state change from 11 to 11 qlt1,0:7249836: port state change from 11 to 11 qlt1,0:7249936: port state change from 11 to 11 qlt1,0:7250036: port state change from 11 to 11 qlt1,0:7250136: port state change from 11 to 11 qlt1,0:7250236: port state change from 11 to 11 :7250236: fct_port_shutdown: port-ffffff090f1920b8, fct_process_logo: unable to clean up I/O. iport-ffffff090f1921b8, icmd-ffffff091c5549d0 qlt1,0:7250336: port state change from 11 to 11 :7250336: fct_port_shutdown: port-ffffff090f1920b8, fct_process_logo: unable to clean up I/O. iport-ffffff090f1921b8, icmd-ffffff091c5549d0 qlt1,0:7250336: port state change from 11 to 11 :7250336: fct_port_shutdown: port-ffffff090f1920b8, fct_process_logo: unable to clean up I/O. iport-ffffff090f1921b8, icmd-ffffff091c5549d0 qlt1,0:7250436: port state change from 11 to 11 :7250436: fct_port_shutdown: port-ffffff090f1920b8, fct_process_logo: unable to clean up I/O. iport-ffffff090f1921b8, icmd-ffffff091c5549d0 qlt1,0:7250536: port state change from 11 to 11 :7250536: fct_port_shutdown: port-ffffff090f1920b8, fct_process_logo: unable to clean up I/O. iport-ffffff090f1921b8, icmd-ffffff091c5549d0 qlt1,0:7250636: port state change from 11 to 11 :7250636: fct_port_shutdown: port-ffffff090f1920b8, fct_process_logo: unable to clean up I/O. iport-ffffff090f1921b8, icmd-ffffff091c5549d0 qlt1,0:7250736: port state change from 11 to 11 :7250736: fct_port_shutdown: port-ffffff090f1920b8, fct_process_logo: unable to clean up I/O. iport-ffffff090f1921b8, icmd-ffffff091c5549d0 qlt1,0:7250836: port state change from 11 to 11 :7250836: fct_port_shutdown: port-ffffff090f1920b8, fct_process_logo: unable to clean up I/O. iport-ffffff090f1921b8, icmd-ffffff091c5549d0 qlt1,0:7250936: port state change from 11 to 11 :7250936: fct_port_shutdown: port-ffffff090f1920b8, fct_process_logo: unable to clean up I/O. iport-ffffff090f1921b8, icmd-ffffff091c5549d0 qlt1,0:7251136: port state change from 11 to 11 :7251136: fct_port_shutdown: port-ffffff090f1920b8, fct_process_logo: unable to clean up I/O. iport-ffffff090f1921b8, icmd-ffffff091c5549d0 qlt1,0:7251236: port state change from 11 to 11 _______________________________________________ OmniOS-discuss mailing list OmniOS-discuss at lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6035 bytes Desc: not available URL: From rafibeyli at gmail.com Thu Sep 11 13:42:34 2014 From: rafibeyli at gmail.com (Hafiz Rafibeyli) Date: Thu, 11 Sep 2014 16:42:34 +0300 (EEST) Subject: [OmniOS-discuss] Hello znapzend question In-Reply-To: References: <499713751.153715.1410248895433.JavaMail.zimbra@cantekstil.com.tr> Message-ID: <365633557.238489.1410442954158.JavaMail.zimbra@cantekstil.com.tr> Hello Tobias, question about znapzend plans, anyway to specify time to run 30d=>1d plan? example: i want run 30d=>1d plan every 23:00,is this possible? i'm using demonize mode Regards, Hafiz ----- Original Message ----- From: "Tobias Oetiker" To: "Hafiz Rafibeyli" Cc: "omnios-discuss" Sent: Tuesday, 9 September, 2014 11:54:01 AM Subject: Re: znapzend question Today Hafiz Rafibeyli wrote: > Hello Tobias, > > did you try znapzend on Nexenta 4.x?anyway run it on Nexenta? no > and second question: > > is znapzend working with volume based(block based) filesystems? there should be no problem ... cheers tobi > > regards, > > Hafiz > > > > -- Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland www.oetiker.ch tobi at oetiker.ch +41 62 775 9902 -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From tobi at oetiker.ch Thu Sep 11 15:31:47 2014 From: tobi at oetiker.ch (Tobias Oetiker) Date: Thu, 11 Sep 2014 17:31:47 +0200 (CEST) Subject: [OmniOS-discuss] Hello znapzend question In-Reply-To: <365633557.238489.1410442954158.JavaMail.zimbra@cantekstil.com.tr> References: <499713751.153715.1410248895433.JavaMail.zimbra@cantekstil.com.tr> <365633557.238489.1410442954158.JavaMail.zimbra@cantekstil.com.tr> Message-ID: Hi Hafiz, Today Hafiz Rafibeyli wrote: > Hello Tobias, > > question about znapzend plans, > > anyway to specify time to run 30d=>1d plan? example: i want run 30d=>1d plan every 23:00,is this possible? there is the --pre-snap-command= which you could abuse to shift things (sleep 23*3600) but otherwhise there is no option for this (yet). cheers tobi > i'm using demonize mode > > Regards, > > Hafiz > > ----- Original Message ----- > From: "Tobias Oetiker" > To: "Hafiz Rafibeyli" > Cc: "omnios-discuss" > Sent: Tuesday, 9 September, 2014 11:54:01 AM > Subject: Re: znapzend question > > Today Hafiz Rafibeyli wrote: > > > Hello Tobias, > > > > did you try znapzend on Nexenta 4.x?anyway run it on Nexenta? > > no > > > > and second question: > > > > is znapzend working with volume based(block based) filesystems? > > there should be no problem ... > > cheers > tobi > > > > > regards, > > > > Hafiz > > > > > > > > > > -- Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland www.oetiker.ch tobi at oetiker.ch +41 62 775 9902 From rafibeyli at gmail.com Thu Sep 11 16:58:50 2014 From: rafibeyli at gmail.com (Hafiz Rafibeyli) Date: Thu, 11 Sep 2014 19:58:50 +0300 (EEST) Subject: [OmniOS-discuss] znapzend question In-Reply-To: References: <499713751.153715.1410248895433.JavaMail.zimbra@cantekstil.com.tr> <365633557.238489.1410442954158.JavaMail.zimbra@cantekstil.com.tr> Message-ID: <307939505.243497.1410454730095.JavaMail.zimbra@cantekstil.com.tr> Tobias , what is a default execute time for day based(30d=>1d) plans? ----- Original Message ----- From: "Tobias Oetiker" To: "Hafiz Rafibeyli" Cc: "omnios-discuss" Sent: Thursday, 11 September, 2014 6:31:47 PM Subject: Re: Hello znapzend question Hi Hafiz, Today Hafiz Rafibeyli wrote: > Hello Tobias, > > question about znapzend plans, > > anyway to specify time to run 30d=>1d plan? example: i want run 30d=>1d plan every 23:00,is this possible? there is the --pre-snap-command= which you could abuse to shift things (sleep 23*3600) but otherwhise there is no option for this (yet). cheers tobi > i'm using demonize mode > > Regards, > > Hafiz > > ----- Original Message ----- > From: "Tobias Oetiker" > To: "Hafiz Rafibeyli" > Cc: "omnios-discuss" > Sent: Tuesday, 9 September, 2014 11:54:01 AM > Subject: Re: znapzend question > > Today Hafiz Rafibeyli wrote: > > > Hello Tobias, > > > > did you try znapzend on Nexenta 4.x?anyway run it on Nexenta? > > no > > > > and second question: > > > > is znapzend working with volume based(block based) filesystems? > > there should be no problem ... > > cheers > tobi > > > > > regards, > > > > Hafiz > > > > > > > > > > -- Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland www.oetiker.ch tobi at oetiker.ch +41 62 775 9902 -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From jhull at jncs.com Thu Sep 11 18:40:18 2014 From: jhull at jncs.com (Jon Hull) Date: Thu, 11 Sep 2014 14:40:18 -0400 Subject: [OmniOS-discuss] E5-2600 v3 Haswell In-Reply-To: References: Message-ID: Hi, On a Supermicro X10DRI with dual E5-2650V3 and 64GB DDR4 2133 RDIMM ram, I was able to install OmniOS r151010u with no noticeable problems. The board has 1g nics and those worked fine (igb). I was supposed to get a 10g version of the board but my boss sold it before I had a chance to test it out. The sata ports worked in ahci mode. I was not able to try the USB3 but there was options in the bios to disable USB3. Not sure if this disables the ports altogether or just makes them USB2. For a pretty basic server board, everything seemed to work right on boot. --Jon Jon Hull jhull at jncs.com Operations Manager J&N Computer Services, Inc. www.jncs.com (855) 333-3482 -----Original Message----- From: OmniOS-discuss [mailto:omnios-discuss-bounces at lists.omniti.com] On Behalf Of Dan McDonald Sent: Wednesday, September 10, 2014 10:03 AM To: Schweiss, Chip Cc: omnios-discuss Subject: Re: [OmniOS-discuss] E5-2600 v3 Haswell On Sep 10, 2014, at 8:50 AM, Schweiss, Chip wrote: > I see systems based on Xeon Haswells are shipping now. > > Has anyone tried OmniOS on any of these yet? Not to my knowledge. > What are my chances everything working as expected with OmniOS on these systems if I would order one today? 1.) I'd stick with a GigE mobo instead of a 40GigE one. The i40e driver isn't ported to illumos yet, and I'm not sure if this time we'll get Intel's help. Having said that, there is community interest, but no known driver bits are available. 2.) USB3 isn't supported on illumos yet as well. I don't know if these mobos can have their USB set to USB2 only or not, or whether or not even USB3 is a problem. 3.) Eric covered the SATA ports and the NVMe things. Dan _______________________________________________ OmniOS-discuss mailing list OmniOS-discuss at lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss From danmcd at omniti.com Thu Sep 11 18:52:41 2014 From: danmcd at omniti.com (Dan McDonald) Date: Thu, 11 Sep 2014 14:52:41 -0400 Subject: [OmniOS-discuss] E5-2600 v3 Haswell In-Reply-To: References: Message-ID: <659B3799-66F0-4491-8F23-84DE1CEA9A6A@omniti.com> On Sep 11, 2014, at 2:40 PM, Jon Hull wrote: > Hi, > On a Supermicro X10DRI with dual E5-2650V3 and 64GB DDR4 2133 RDIMM ram, I was able to install OmniOS r151010u with no noticeable problems. > Oh this is great news. Both that the r151010u disk is working for someone else (older version of it had... brokenness), and that it installs on the Haswell-E platform. > The board has 1g nics and those worked fine (igb). I was supposed to get a 10g version of the board but my boss sold it before I had a chance to test it out. The "10g" may actually be a 40g with 4x 10G ports. If it's the part I'm thinking about, it's the "i40e", which illumos does not yet support. Do you know what 1GigE "igb" part it is? Is it I350, or something newer? > The sata ports worked in ahci mode. As they should. Excellent. (How many do you get?) > I was not able to try the USB3 but there was options in the bios to disable USB3. Not sure if this disables the ports altogether or just makes them USB2. It *should* just make them USB2, and I'm glad the BIOS lets you disable that. We don't have USB3 in illumos yet either. > For a pretty basic server board, everything seemed to work right on boot. This is a dual-socket board, you said? I'd be interested to know if you see any odd latencies - I've seen {Sandy,Ivy} Bridge-E boards occasionally exhibit odd latencies with 10GigE, but it was very difficult to characterize and reproduce. Nonetheless, this is good news! Thanks, Dan From tobi at oetiker.ch Thu Sep 11 21:06:14 2014 From: tobi at oetiker.ch (Tobias Oetiker) Date: Thu, 11 Sep 2014 23:06:14 +0200 (CEST) Subject: [OmniOS-discuss] znapzend question In-Reply-To: <307939505.243497.1410454730095.JavaMail.zimbra@cantekstil.com.tr> References: <499713751.153715.1410248895433.JavaMail.zimbra@cantekstil.com.tr> <365633557.238489.1410442954158.JavaMail.zimbra@cantekstil.com.tr> <307939505.243497.1410454730095.JavaMail.zimbra@cantekstil.com.tr> Message-ID: Today Hafiz Rafibeyli wrote: > Tobias , > > what is a default execute time for day based(30d=>1d) plans? midnight localtime cheers tobi -- Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland www.oetiker.ch tobi at oetiker.ch +41 62 775 9902 From ales at ovca.be Fri Sep 12 05:52:06 2014 From: ales at ovca.be (Ales) Date: Fri, 12 Sep 2014 07:52:06 +0200 Subject: [OmniOS-discuss] Emulex 10Gbit adapter speeds Message-ID: <54128A06.5020503@ovca.be> Hey guys (and girls), I've got a few servers with and Emulex OneConnect 10Gb (I think it's OCe11102 chipset based), running on OmniOS (08 and 010) an Linux (OpenSuSE). Out of the box the performance is pretty shitty but once you tweak the windows sizes and buffers it takes off. But here's what's bothering me, I can reach 9,2Gbit/s on linux but only around 6.3Gbit/s on OmniOS. The machines are identical dual xeons E5-2630 so the CPU power isn't an issue (loaded with SSDs). I'm testing my through put with iperf and netperf both show similar speeds. Below are my tweaks to the netstack an I'd really like your input on 10Gbit tweaks to reach the full potential. ipadm set-prop -p recv_buf=87380 tcp ipadm set-prop -p send_buf=87380 tcp ipadm set-prop -p send_buf=87380 udp ipadm set-prop -p recv_buf=87380 udp (both enabled by default but it never hurts) ndd -set /dev/tcp tcp_wscale_always 1 ndd -set /dev/tcp tcp_tstamp_if_wscale 1 ndd -set /dev/tcp tcp_recv_hiwat 1048576 ndd -set /dev/tcp tcp_xmit_hiwat 1048576 ndd -set /dev/udp udp_max_buf 16777216 ndd -set /dev/tcp tcp_max_buf 16777216 ndd -set /dev/tcp tcp_cwnd_max 8388608 ndd -set /dev/tcp tcp_time_wait_interval 10000 ndd -set /dev/tcp tcp_conn_req_max_q 8000 ndd -set /dev/tcp tcp_conn_req_max_q0 300000 P.S. The MTU is 1500, I can't use jumbo frames due to support (or lack of) on endclients. But doesn't seem to bother linux. The speeds reached are TCP, UDP floats around 4,5-5Gbit/s From dan at syneto.net Fri Sep 12 13:19:15 2014 From: dan at syneto.net (Dan Vatca) Date: Fri, 12 Sep 2014 16:19:15 +0300 Subject: [OmniOS-discuss] sed on bloody crashes when compiling cdrtools Message-ID: I'm compiling omnios bloody and I get this crash during cdrtools compilation: make: Warning: Ignoring DistributedMake -j option <------>==> MAKING SYMLINKS in ./RULES/ sh: line 1: 14171: Memory fault(coredump) mksh: Fatal error: The command `uname -s | sed 'y%ABCDEFGHIJKLMNOPQRSTUVWXYZ, /\\()"%abcdefghijklmnopqrstuvwxyz,------%'' returned status `0' This creates a core with this stack trace: root at bloody:/var/cores# mdb core.sed.6628 Loading modules: [ libc.so.1 ld.so.1 ] > ::walk thread | ::findstack -v stack pointer for thread 1: 80462a8 [ 080462a8 libc.so.1`_UTF8_mbsnrtowcs+0x2d() ] 080462d8 libc.so.1`mbsrtowcs_l+0x35(0, 804736c, 0, 0, fee01a00, 8067da7) 08046308 libc.so.1`mbsrtowcs+0x42(0, 804736c, 0, 0, 0, 0) 08047388 compile_tr+0x132(8067d61, 806a274, 0, fefcac10, fee10048, 38) 08047be8 compile_stream+0x7b8(806a260, 8047c7c, 8047c48, 80531a8, 1, 8047d60) 08047c08 compile+0x10(0, 3, 0, 0, 3, feffb0a4) 08047c48 main+0x1a8(8047c3c, fef72668, 8047c70, 805251b, 2, 8047c7c) 08047c70 _start+0x83(2, 8047d5c, 8047d60, 0, 8047da8, 8047dbd) Did anyone else run into this? -------------- next part -------------- An HTML attachment was scrubbed... URL: From derek at umiacs.umd.edu Fri Sep 12 13:30:50 2014 From: derek at umiacs.umd.edu (Derek Yarnell) Date: Fri, 12 Sep 2014 09:30:50 -0400 Subject: [OmniOS-discuss] NFSv4 client soft lockups Message-ID: <5412F58A.3060800@umiacs.umd.edu> Hi, I am wondering if anyone else has experience running NFSv4 from OmniOS to RHEL (6.5) clients. We are running it with sec=krb5p and are getting these errors (soft lockups) at the end of this mail across all the nodes causing them to be unresponsive after. The OmniOS server doesn't report anything wrong in the logs. I have submitted a ticket to Red Hat about this already but since it happens on all my RHEL clients at once and references the same OmniOS server (172.19.0.98) then it may have something to do either Omni NFS server or the interoperability of the RHEL NFSv4 client and the Omni NFSv4 server. Thanks, derek Sep 11 23:00:54 nauseated kernel: BUG: soft lockup - CPU#5 stuck for 67s! [172.19.0.98-man:12273] Sep 11 23:00:54 nauseated kernel: Modules linked in: aesni_intel ablk_helper cryptd lrw gf128mul glue_helper aes_x86_64 aes_generic cbc cts nfs lockd fscache nfs_acl autofs4 rpcsec_gss_krb5 auth_rpcgss sunrpc ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4 iptable_filter ip_tables ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables ipv6 power_meter microcode iTCO_wdt iTCO_vendor_support dcdbas serio_raw lpc_ich mfd_core sg i7core_edac edac_core bnx2 ext4 jbd2 mbcache sr_mod cdrom sd_mod crc_t10dif pata_acpi ata_generic ata_piix mptsas mptscsih mptbase scsi_transport_sas dm_mirror dm_region_hash dm_log dm_mod [last unloaded: speedstep_lib] Sep 11 23:00:54 nauseated kernel: CPU 5 Sep 11 23:00:54 nauseated kernel: Modules linked in: aesni_intel ablk_helper cryptd lrw gf128mul glue_helper aes_x86_64 aes_generic cbc cts nfs lockd fscache nfs_acl autofs4 rpcsec_gss_krb5 auth_rpcgss sunrpc ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4 iptable_filter ip_tables ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables ipv6 power_meter microcode iTCO_wdt iTCO_vendor_support dcdbas serio_raw lpc_ich mfd_core sg i7core_edac edac_core bnx2 ext4 jbd2 mbcache sr_mod cdrom sd_mod crc_t10dif pata_acpi ata_generic ata_piix mptsas mptscsih mptbase scsi_transport_sas dm_mirror dm_region_hash dm_log dm_mod [last unloaded: speedstep_lib] Sep 11 23:00:54 nauseated kernel: Sep 11 23:00:54 nauseated kernel: Pid: 12273, comm: 172.19.0.98-man Not tainted 2.6.32-431.29.2.el6.x86_64 #1 Dell Inc. PowerEdge R610/0F0XJ6 Sep 11 23:00:54 nauseated kernel: RIP: 0010:[] [] nfs4_run_state_manager+0x38d/0x620 [nfs] Sep 11 23:00:54 nauseated kernel: RSP: 0018:ffff88042b249e90 EFLAGS: 00000206 Sep 11 23:00:54 nauseated kernel: RAX: ffff88042b249fd8 RBX: ffff88042b249ee0 RCX: 0000000000000034 Sep 11 23:00:54 nauseated kernel: RDX: 000000000000115b RSI: ffff880429e7ed90 RDI: ffffffffa0247568 Sep 11 23:00:54 nauseated kernel: RBP: ffffffff8100bb8e R08: f000000000000000 R09: fbb8191d81fb3e00 Sep 11 23:00:54 nauseated kernel: R10: 0000000000000001 R11: 0000000000000000 R12: ffff88042b249ee0 Sep 11 23:00:54 nauseated kernel: R13: ffffffff8100bb8e R14: ffffffffffffff10 R15: ffffffffa0247568 Sep 11 23:00:54 nauseated kernel: FS: 0000000000000000(0000) GS:ffff880028240000(0000) knlGS:0000000000000000 Sep 11 23:00:54 nauseated kernel: CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b Sep 11 23:00:54 nauseated kernel: CR2: 00000000006e19b8 CR3: 000000042b026000 CR4: 00000000000007e0 Sep 11 23:00:54 nauseated kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 Sep 11 23:00:54 nauseated kernel: DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Sep 11 23:00:54 nauseated kernel: Process 172.19.0.98-man (pid: 12273, threadinfo ffff88042b248000, task ffff8804299b9540) Sep 11 23:00:54 nauseated kernel: Stack: Sep 11 23:00:54 nauseated kernel: 0000000000000286 00000000000003fb ffff880429e7ecf9 ffff880429e7ed00 Sep 11 23:00:54 nauseated kernel: ffff88042b249ee0 ffff88042a5e1898 ffff88042b249ef8 ffffffffa02f5300 Sep 11 23:00:54 nauseated kernel: ffff880429e7ec00 ffff88042cc89500 ffff88042b249f40 ffffffff8109abf6 Sep 11 23:00:54 nauseated kernel: Call Trace: Sep 11 23:00:54 nauseated kernel: [] ? nfs4_run_state_manager+0x0/0x620 [nfs] Sep 11 23:00:54 nauseated kernel: [] ? kthread+0x96/0xa0 Sep 11 23:00:54 nauseated kernel: [] ? child_rip+0xa/0x20 Sep 11 23:00:54 nauseated kernel: [] ? kthread+0x0/0xa0 Sep 11 23:00:54 nauseated kernel: [] ? child_rip+0x0/0x20 Sep 11 23:00:54 nauseated kernel: Code: 89 df e8 f7 8b 00 00 e9 e3 fc ff ff 66 90 48 89 df e8 d8 e4 ff ff 48 83 bb f8 00 00 00 00 0f 84 f7 fc ff ff f0 41 0f ba 2c 24 00 <19> c0 85 c0 0f 84 df fc ff ff e9 e1 fc ff ff 0f 1f 40 00 41 81 Sep 11 23:00:54 nauseated kernel: Call Trace: Sep 11 23:00:54 nauseated kernel: [] ? nfs4_run_state_manager+0x0/0x620 [nfs] Sep 11 23:00:54 nauseated kernel: [] ? kthread+0x96/0xa0 Sep 11 23:00:54 nauseated kernel: [] ? child_rip+0xa/0x20 Sep 11 23:00:54 nauseated kernel: [] ? kthread+0x0/0xa0 Sep 11 23:00:54 nauseated kernel: [] ? child_rip+0x0/0x20 -- Derek T. Yarnell University of Maryland Institute for Advanced Computer Studies From danmcd at omniti.com Fri Sep 12 14:28:40 2014 From: danmcd at omniti.com (Dan McDonald) Date: Fri, 12 Sep 2014 10:28:40 -0400 Subject: [OmniOS-discuss] sed on bloody crashes when compiling cdrtools In-Reply-To: References: Message-ID: <83B1E61C-DDC9-4EB9-8B30-94FC4DD6DB29@omniti.com> On Sep 12, 2014, at 9:19 AM, Dan Vatca wrote: > I'm compiling omnios bloody and I get this crash during cdrtools compilation: > > make: Warning: Ignoring DistributedMake -j option > <------>==> MAKING SYMLINKS in ./RULES/ > sh: line 1: 14171: Memory fault(coredump) > mksh: Fatal error: The command `uname -s | sed 'y%ABCDEFGHIJKLMNOPQRSTUVWXYZ, /\\()"%abcdefghijklmnopqrstuvwxyz,------%'' returned status `0' > > This creates a core with this stack trace: > root at bloody:/var/cores# mdb core.sed.6628 > Loading modules: [ libc.so.1 ld.so.1 ] >> ::walk thread | ::findstack -v > stack pointer for thread 1: 80462a8 > [ 080462a8 libc.so.1`_UTF8_mbsnrtowcs+0x2d() ] > 080462d8 libc.so.1`mbsrtowcs_l+0x35(0, 804736c, 0, 0, fee01a00, 8067da7) > 08046308 libc.so.1`mbsrtowcs+0x42(0, 804736c, 0, 0, 0, 0) > 08047388 compile_tr+0x132(8067d61, 806a274, 0, fefcac10, fee10048, 38) > 08047be8 compile_stream+0x7b8(806a260, 8047c7c, 8047c48, 80531a8, 1, 8047d60) > 08047c08 compile+0x10(0, 3, 0, 0, 3, feffb0a4) > 08047c48 main+0x1a8(8047c3c, fef72668, 8047c70, 805251b, 2, 8047c7c) > 08047c70 _start+0x83(2, 8047d5c, 8047d60, 0, 8047da8, 8047dbd) > > Did anyone else run into this? No, but I'm off bloody for now... (trying to bringup 012 and 013), and trying to beat back serious IPS problems I accidentally introduced. Can you reproduce this crash with just the command listed above all by itself? Dan From dan at syneto.net Fri Sep 12 15:03:17 2014 From: dan at syneto.net (Dan Vatca) Date: Fri, 12 Sep 2014 18:03:17 +0300 Subject: [OmniOS-discuss] sed on bloody crashes when compiling cdrtools In-Reply-To: <83B1E61C-DDC9-4EB9-8B30-94FC4DD6DB29@omniti.com> References: <83B1E61C-DDC9-4EB9-8B30-94FC4DD6DB29@omniti.com> Message-ID: Yes. And it also reproduces with a simple transliteration. But it does go awry only with /usr/bin/sed, not with /usr/gnu/bin/sed. Replacements also work just fine. root at bloody:/var/cores# ls root at bloody:/var/cores# env HZ= SHELL=/usr/bin/bash TERM=xterm LC_ALL=en_US.UTF-8 PAGER=/usr/bin/less -ins MAIL=/var/mail/root PATH=/usr/gnu/bin:/usr/bin:/usr/sbin:/sbin PWD=/var/cores LANG=en_US.UTF-8 TZ=Europe/Bucharest SHLVL=1 HOME=/root LOGNAME=root OLDPWD=/root _=/usr/gnu/bin/env root at bloody:/var/cores# uname -a SunOS bloody 5.11 omnios-fa65b1e i86pc i386 i86pc root at bloody:/var/cores# *echo "x" | /usr/bin/sed 'y%,%,%'* Segmentation Fault (core dumped) root at bloody:/var/cores# ls core core.sed.971 root at bloody:/var/cores# pstack core.sed.971 core 'core.sed.971' of 971: /usr/bin/sed y%,%,% feeb67b9 _UTF8_mbsnrtowcs (0, 80474fc, ffffffff, 0, 0, 3) + 2d feea8d8b mbsrtowcs_l (0, 80474fc, 0, 0, fee01a00, 8067d66) + 35 feea8dcf mbsrtowcs (0, 80474fc, 0, 0, 0, 0) + 42 08053f2b compile_tr (8067d61, 806a274, 0, fee10268, 58, fee10048) + 132 08054939 compile_stream (806a260, 8047e18, 8047dd8, 80531a8, 1, 8047ee1) + 7b8 08054af0 compile (0, 3, fef6ec80, 0, 100, feffb0a4) + 10 080531b3 main (8047dcc, fef72668, 8047e0c, 805251b, 2, 8047e18) + 1a8 0805251b _start (2, 8047ed4, 8047ee1, 0, 8047ee8, 8047eec) + 83 root at bloody:/var/cores# echo "a" | /usr/bin/sed 'y%a%b%' Segmentation Fault (core dumped) root at bloody:/var/cores# echo "a" | /usr/gnu/bin/sed 'y%a%b%' b root at bloody:/var/cores# echo "x" | /usr/bin/sed 's%,%,%' x On Fri, Sep 12, 2014 at 5:28 PM, Dan McDonald wrote: > > On Sep 12, 2014, at 9:19 AM, Dan Vatca wrote: > > > I'm compiling omnios bloody and I get this crash during cdrtools > compilation: > > > > make: Warning: Ignoring DistributedMake -j option > > <------>==> MAKING SYMLINKS in ./RULES/ > > sh: line 1: 14171: Memory fault(coredump) > > mksh: Fatal error: The command `uname -s | sed > 'y%ABCDEFGHIJKLMNOPQRSTUVWXYZ, /\\()"%abcdefghijklmnopqrstuvwxyz,------%'' > returned status `0' > > > > This creates a core with this stack trace: > > root at bloody:/var/cores# mdb core.sed.6628 > > Loading modules: [ libc.so.1 ld.so.1 ] > >> ::walk thread | ::findstack -v > > stack pointer for thread 1: 80462a8 > > [ 080462a8 libc.so.1`_UTF8_mbsnrtowcs+0x2d() ] > > 080462d8 libc.so.1`mbsrtowcs_l+0x35(0, 804736c, 0, 0, fee01a00, 8067da7) > > 08046308 libc.so.1`mbsrtowcs+0x42(0, 804736c, 0, 0, 0, 0) > > 08047388 compile_tr+0x132(8067d61, 806a274, 0, fefcac10, fee10048, 38) > > 08047be8 compile_stream+0x7b8(806a260, 8047c7c, 8047c48, 80531a8, 1, > 8047d60) > > 08047c08 compile+0x10(0, 3, 0, 0, 3, feffb0a4) > > 08047c48 main+0x1a8(8047c3c, fef72668, 8047c70, 805251b, 2, 8047c7c) > > 08047c70 _start+0x83(2, 8047d5c, 8047d60, 0, 8047da8, 8047dbd) > > > > Did anyone else run into this? > > No, but I'm off bloody for now... (trying to bringup 012 and 013), and > trying to beat back serious IPS problems I accidentally introduced. > > Can you reproduce this crash with just the command listed above all by > itself? > > Dan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chip at innovates.com Fri Sep 12 15:05:54 2014 From: chip at innovates.com (Schweiss, Chip) Date: Fri, 12 Sep 2014 10:05:54 -0500 Subject: [OmniOS-discuss] NFSv4 client soft lockups In-Reply-To: <5412F58A.3060800@umiacs.umd.edu> References: <5412F58A.3060800@umiacs.umd.edu> Message-ID: Is you RHEL 6.5 client a virtual machine? If so this message is a red herring to your problem. See the VMware KB article: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1009996 I run all NFSv4 from CentOS 6.5 to OmniOS, but do not use kerberos. It's been rock solid. -Chip On Fri, Sep 12, 2014 at 8:30 AM, Derek Yarnell wrote: > Hi, > > I am wondering if anyone else has experience running NFSv4 from OmniOS > to RHEL (6.5) clients. We are running it with sec=krb5p and are getting > these errors (soft lockups) at the end of this mail across all the nodes > causing them to be unresponsive after. The OmniOS server doesn't report > anything wrong in the logs. I have submitted a ticket to Red Hat about > this already but since it happens on all my RHEL clients at once and > references the same OmniOS server (172.19.0.98) then it may have > something to do either Omni NFS server or the interoperability of the > RHEL NFSv4 client and the Omni NFSv4 server. > > Thanks, > derek > > Sep 11 23:00:54 nauseated kernel: BUG: soft lockup - CPU#5 stuck for > 67s! [172.19.0.98-man:12273] > Sep 11 23:00:54 nauseated kernel: Modules linked in: aesni_intel > ablk_helper cryptd lrw gf128mul glue_helper aes_x86_64 aes_generic cbc > cts nfs lockd fscache nfs_acl autofs4 rpcsec_gss_krb5 auth_rpcgss sunrpc > ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4 iptable_filter ip_tables > ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack > ip6table_filter ip6_tables ipv6 power_meter microcode iTCO_wdt > iTCO_vendor_support dcdbas serio_raw lpc_ich mfd_core sg i7core_edac > edac_core bnx2 ext4 jbd2 mbcache sr_mod cdrom sd_mod crc_t10dif > pata_acpi ata_generic ata_piix mptsas mptscsih mptbase > scsi_transport_sas dm_mirror dm_region_hash dm_log dm_mod [last > unloaded: speedstep_lib] > Sep 11 23:00:54 nauseated kernel: CPU 5 > Sep 11 23:00:54 nauseated kernel: Modules linked in: aesni_intel > ablk_helper cryptd lrw gf128mul glue_helper aes_x86_64 aes_generic cbc > cts nfs lockd fscache nfs_acl autofs4 rpcsec_gss_krb5 auth_rpcgss sunrpc > ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4 iptable_filter ip_tables > ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack > ip6table_filter ip6_tables ipv6 power_meter microcode iTCO_wdt > iTCO_vendor_support dcdbas serio_raw lpc_ich mfd_core sg i7core_edac > edac_core bnx2 ext4 jbd2 mbcache sr_mod cdrom sd_mod crc_t10dif > pata_acpi ata_generic ata_piix mptsas mptscsih mptbase > scsi_transport_sas dm_mirror dm_region_hash dm_log dm_mod [last > unloaded: speedstep_lib] > Sep 11 23:00:54 nauseated kernel: > Sep 11 23:00:54 nauseated kernel: Pid: 12273, comm: 172.19.0.98-man Not > tainted 2.6.32-431.29.2.el6.x86_64 #1 Dell Inc. PowerEdge R610/0F0XJ6 > Sep 11 23:00:54 nauseated kernel: RIP: 0010:[] > [] nfs4_run_state_manager+0x38d/0x620 [nfs] > Sep 11 23:00:54 nauseated kernel: RSP: 0018:ffff88042b249e90 EFLAGS: > 00000206 > Sep 11 23:00:54 nauseated kernel: RAX: ffff88042b249fd8 RBX: > ffff88042b249ee0 RCX: 0000000000000034 > Sep 11 23:00:54 nauseated kernel: RDX: 000000000000115b RSI: > ffff880429e7ed90 RDI: ffffffffa0247568 > Sep 11 23:00:54 nauseated kernel: RBP: ffffffff8100bb8e R08: > f000000000000000 R09: fbb8191d81fb3e00 > Sep 11 23:00:54 nauseated kernel: R10: 0000000000000001 R11: > 0000000000000000 R12: ffff88042b249ee0 > Sep 11 23:00:54 nauseated kernel: R13: ffffffff8100bb8e R14: > ffffffffffffff10 R15: ffffffffa0247568 > Sep 11 23:00:54 nauseated kernel: FS: 0000000000000000(0000) > GS:ffff880028240000(0000) knlGS:0000000000000000 > Sep 11 23:00:54 nauseated kernel: CS: 0010 DS: 0018 ES: 0018 CR0: > 000000008005003b > Sep 11 23:00:54 nauseated kernel: CR2: 00000000006e19b8 CR3: > 000000042b026000 CR4: 00000000000007e0 > Sep 11 23:00:54 nauseated kernel: DR0: 0000000000000000 DR1: > 0000000000000000 DR2: 0000000000000000 > Sep 11 23:00:54 nauseated kernel: DR3: 0000000000000000 DR6: > 00000000ffff0ff0 DR7: 0000000000000400 > Sep 11 23:00:54 nauseated kernel: Process 172.19.0.98-man (pid: 12273, > threadinfo ffff88042b248000, task ffff8804299b9540) > Sep 11 23:00:54 nauseated kernel: Stack: > Sep 11 23:00:54 nauseated kernel: 0000000000000286 00000000000003fb > ffff880429e7ecf9 ffff880429e7ed00 > Sep 11 23:00:54 nauseated kernel: ffff88042b249ee0 ffff88042a5e1898 > ffff88042b249ef8 ffffffffa02f5300 > Sep 11 23:00:54 nauseated kernel: ffff880429e7ec00 ffff88042cc89500 > ffff88042b249f40 ffffffff8109abf6 > Sep 11 23:00:54 nauseated kernel: Call Trace: > Sep 11 23:00:54 nauseated kernel: [] ? > nfs4_run_state_manager+0x0/0x620 [nfs] > Sep 11 23:00:54 nauseated kernel: [] ? kthread+0x96/0xa0 > Sep 11 23:00:54 nauseated kernel: [] ? child_rip+0xa/0x20 > Sep 11 23:00:54 nauseated kernel: [] ? kthread+0x0/0xa0 > Sep 11 23:00:54 nauseated kernel: [] ? child_rip+0x0/0x20 > Sep 11 23:00:54 nauseated kernel: Code: 89 df e8 f7 8b 00 00 e9 e3 fc ff > ff 66 90 48 89 df e8 d8 e4 ff ff 48 83 bb f8 00 00 00 00 0f 84 f7 fc ff > ff f0 41 0f ba 2c 24 00 <19> c0 85 c0 0f 84 df fc ff ff e9 e1 fc ff ff > 0f 1f 40 00 41 81 > Sep 11 23:00:54 nauseated kernel: Call Trace: > Sep 11 23:00:54 nauseated kernel: [] ? > nfs4_run_state_manager+0x0/0x620 [nfs] > Sep 11 23:00:54 nauseated kernel: [] ? kthread+0x96/0xa0 > Sep 11 23:00:54 nauseated kernel: [] ? child_rip+0xa/0x20 > Sep 11 23:00:54 nauseated kernel: [] ? kthread+0x0/0xa0 > Sep 11 23:00:54 nauseated kernel: [] ? child_rip+0x0/0x20 > > -- > Derek T. Yarnell > University of Maryland > Institute for Advanced Computer Studies > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > -------------- next part -------------- An HTML attachment was scrubbed... URL: From danmcd at omniti.com Fri Sep 12 15:05:31 2014 From: danmcd at omniti.com (Dan McDonald) Date: Fri, 12 Sep 2014 11:05:31 -0400 Subject: [OmniOS-discuss] sed on bloody crashes when compiling cdrtools In-Reply-To: References: <83B1E61C-DDC9-4EB9-8B30-94FC4DD6DB29@omniti.com> Message-ID: <47946905-E5CF-4978-B941-48282CA8BCD3@omniti.com> On Sep 12, 2014, at 11:03 AM, Dan Vatca wrote: > Yes. And it also reproduces with a simple transliteration. But it does go awry only with /usr/bin/sed, not with /usr/gnu/bin/sed. Replacements also work just fine. Hmmm. I want to try this out on on OI with a very latest illumos-gate. I suspect it was introduced with some recent changes in that space. I'll get back to you with those OI results. If they fail the same way on OI, I will file an illumos bug and see if someone up there can fix it. Be right back, Dan From jeffpc at josefsipek.net Fri Sep 12 15:14:00 2014 From: jeffpc at josefsipek.net (Josef 'Jeff' Sipek) Date: Fri, 12 Sep 2014 11:14:00 -0400 Subject: [OmniOS-discuss] sed on bloody crashes when compiling cdrtools In-Reply-To: <47946905-E5CF-4978-B941-48282CA8BCD3@omniti.com> References: <83B1E61C-DDC9-4EB9-8B30-94FC4DD6DB29@omniti.com> <47946905-E5CF-4978-B941-48282CA8BCD3@omniti.com> Message-ID: <20140912151400.GB978@meili> On Fri, Sep 12, 2014 at 11:05:31AM -0400, Dan McDonald wrote: > > On Sep 12, 2014, at 11:03 AM, Dan Vatca wrote: > > > Yes. And it also reproduces with a simple transliteration. But it does go awry only with /usr/bin/sed, not with /usr/gnu/bin/sed. Replacements also work just fine. > > Hmmm. > > I want to try this out on on OI with a very latest illumos-gate. I > suspect it was introduced with some recent changes in that space. Here's OI hipster: jeffpc at meili:~>5$ uname -a SunOS meili 5.11 illumos-4ef97ab i86pc i386 i86pc Solaris jeffpc at meili:~>6$ echo "x" | /usr/bin/sed 'y%,%,%' Segmentation Fault (core dumped) jeffpc at meili:~>7$ pstack core core 'core' of 1739: /usr/bin/sed y%,%,% feeb68f9 _UTF8_mbsnrtowcs (0, 8046e5c, ffffffff, 0, 0, 3) + 2d feea8e9d mbsrtowcs_l (0, 8046e5c, 0, 0, fee01a00, 8067d66) + 35 feea8ee1 mbsrtowcs (0, 8046e5c, 0, 0, 0, 0) + 42 08053f2e compile_tr (8067d61, 806a274, 0, fefcac27, fee10048, 38) + 132 0805493c compile_stream (806a260, 804776c, 8047738, 80531aa, 1, 80478c9) + 7b8 08054af3 compile (0, 3, 0, 0, 3, feffb0a4) + 10 080531b5 main (804772c, fef72668, 8047760, 805251b, 2, 804776c) + 1a8 0805251b _start (2, 80478bc, 80478c9, 0, 80478d0, 80478e2) + 83 Jeff. -- Failure is not an option, It comes bundled with your Microsoft product. From danmcd at omniti.com Fri Sep 12 15:18:54 2014 From: danmcd at omniti.com (Dan McDonald) Date: Fri, 12 Sep 2014 11:18:54 -0400 Subject: [OmniOS-discuss] sed on bloody crashes when compiling cdrtools In-Reply-To: <20140912151400.GB978@meili> References: <83B1E61C-DDC9-4EB9-8B30-94FC4DD6DB29@omniti.com> <47946905-E5CF-4978-B941-48282CA8BCD3@omniti.com> <20140912151400.GB978@meili> Message-ID: <5A61BDE1-DAB0-487B-B461-B7B150AB3B86@omniti.com> On Sep 12, 2014, at 11:14 AM, Josef 'Jeff' Sipek wrote: > On Fri, Sep 12, 2014 at 11:05:31AM -0400, Dan McDonald wrote: >> >> On Sep 12, 2014, at 11:03 AM, Dan Vatca wrote: >> >>> Yes. And it also reproduces with a simple transliteration. But it does go awry only with /usr/bin/sed, not with /usr/gnu/bin/sed. Replacements also work just fine. >> >> Hmmm. >> >> I want to try this out on on OI with a very latest illumos-gate. I >> suspect it was introduced with some recent changes in that space. > > Here's OI hipster: > > jeffpc at meili:~>5$ uname -a > SunOS meili 5.11 illumos-4ef97ab i86pc i386 i86pc Solaris > jeffpc at meili:~>6$ echo "x" | /usr/bin/sed 'y%,%,%' > Segmentation Fault (core dumped)\] Well, that proves it to me. Illumos bug. Good catch Dan V, and I just filed... https://www.illumos.org/issues/5158 on your behalf. Thanks, and good catch! Dan From derek at umiacs.umd.edu Fri Sep 12 15:25:24 2014 From: derek at umiacs.umd.edu (Derek Yarnell) Date: Fri, 12 Sep 2014 11:25:24 -0400 Subject: [OmniOS-discuss] NFSv4 client soft lockups In-Reply-To: References: <5412F58A.3060800@umiacs.umd.edu> Message-ID: <54131064.1010105@umiacs.umd.edu> On 9/12/14 11:05 AM, Schweiss, Chip wrote: > Is you RHEL 6.5 client a virtual machine? If so this message is a red > herring to your problem. > > See the VMware KB article: > http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1009996 > > I run all NFSv4 from CentOS 6.5 to OmniOS, but do not use kerberos. It's > been rock solid. Hi Chip, No we are running on physical hardware. It also looks like the parameter they talk about is something different[1] post RHEL 6.1. We are trying to drop to just sec=krb5 to see if that provides any relief and may increase the watchdog timer a bit to see if this is just a race condition. [1] - https://access.redhat.com/solutions/57811? Thanks, derek -- Derek T. Yarnell University of Maryland Institute for Advanced Computer Studies From danmcd at omniti.com Fri Sep 12 15:36:51 2014 From: danmcd at omniti.com (Dan McDonald) Date: Fri, 12 Sep 2014 11:36:51 -0400 Subject: [OmniOS-discuss] sed on bloody crashes when compiling cdrtools In-Reply-To: <5A61BDE1-DAB0-487B-B461-B7B150AB3B86@omniti.com> References: <83B1E61C-DDC9-4EB9-8B30-94FC4DD6DB29@omniti.com> <47946905-E5CF-4978-B941-48282CA8BCD3@omniti.com> <20140912151400.GB978@meili> <5A61BDE1-DAB0-487B-B461-B7B150AB3B86@omniti.com> Message-ID: <747EAE4F-8410-4F86-BA8E-F130AD1ECD29@omniti.com> Dan V. --> As a workaround, set your LANG to 'C' instead of "en_US.UTF-8". Dan From dan at syneto.net Fri Sep 12 15:58:07 2014 From: dan at syneto.net (Dan Vatca) Date: Fri, 12 Sep 2014 18:58:07 +0300 Subject: [OmniOS-discuss] sed on bloody crashes when compiling cdrtools In-Reply-To: <747EAE4F-8410-4F86-BA8E-F130AD1ECD29@omniti.com> References: <83B1E61C-DDC9-4EB9-8B30-94FC4DD6DB29@omniti.com> <47946905-E5CF-4978-B941-48282CA8BCD3@omniti.com> <20140912151400.GB978@meili> <5A61BDE1-DAB0-487B-B461-B7B150AB3B86@omniti.com> <747EAE4F-8410-4F86-BA8E-F130AD1ECD29@omniti.com> Message-ID: It crashes with LANG=C too. Just tested that. As a workaround I will use tr instead of sed. On Fri, Sep 12, 2014 at 6:36 PM, Dan McDonald wrote: > Dan V. --> As a workaround, set your LANG to 'C' instead of "en_US.UTF-8". > > Dan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dan at syneto.net Fri Sep 12 16:50:23 2014 From: dan at syneto.net (Dan Vatca) Date: Fri, 12 Sep 2014 19:50:23 +0300 Subject: [OmniOS-discuss] sed on bloody crashes when compiling cdrtools In-Reply-To: References: <83B1E61C-DDC9-4EB9-8B30-94FC4DD6DB29@omniti.com> <47946905-E5CF-4978-B941-48282CA8BCD3@omniti.com> <20140912151400.GB978@meili> <5A61BDE1-DAB0-487B-B461-B7B150AB3B86@omniti.com> <747EAE4F-8410-4F86-BA8E-F130AD1ECD29@omniti.com> Message-ID: Looks related to the POSIX 2008 locale object support ( https://www.illumos.org/issues/2964) Maybe Garett can take a look at this. On Fri, Sep 12, 2014 at 6:58 PM, Dan Vatca wrote: > It crashes with LANG=C too. Just tested that. > As a workaround I will use tr instead of sed. > > > On Fri, Sep 12, 2014 at 6:36 PM, Dan McDonald wrote: > >> Dan V. --> As a workaround, set your LANG to 'C' instead of "en_US.UTF-8". >> >> Dan >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From valrhona at gmail.com Fri Sep 12 17:23:44 2014 From: valrhona at gmail.com (Valrhona) Date: Fri, 12 Sep 2014 13:23:44 -0400 Subject: [OmniOS-discuss] NFSv4 client soft lockups In-Reply-To: <54131064.1010105@umiacs.umd.edu> References: <5412F58A.3060800@umiacs.umd.edu> <54131064.1010105@umiacs.umd.edu> Message-ID: Not sure if this is the same issue, but I had the same behavior with Windows 8.1 on my laptop; everything has been fine for many months with clients running Win 7, Ubuntu 12.04 LTS, Ubuntu 14.04 LTS, OpenIndiana and XStreamOS (Illumos-based). But the Win 8.1 laptop causes NFSv4 to lock up, and (obviously) blocks the rest of the clients from accessing the server when it does, until NFS is reset. Interestingly, it doesn't seem to do this immediately; NFSv4 works just fine for maybe 15 minutes before the lockup occurs, but I haven't exactly troubleshot the details. Is there a particular log file which might be helpful to examine? Thanks! Peter On Fri, Sep 12, 2014 at 11:25 AM, Derek Yarnell wrote: > > > On 9/12/14 11:05 AM, Schweiss, Chip wrote: >> Is you RHEL 6.5 client a virtual machine? If so this message is a red >> herring to your problem. >> >> See the VMware KB article: >> http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1009996 >> >> I run all NFSv4 from CentOS 6.5 to OmniOS, but do not use kerberos. It's >> been rock solid. > > Hi Chip, > > No we are running on physical hardware. It also looks like the > parameter they talk about is something different[1] post RHEL 6.1. We > are trying to drop to just sec=krb5 to see if that provides any relief > and may increase the watchdog timer a bit to see if this is just a race > condition. > > [1] - https://access.redhat.com/solutions/57811? > > Thanks, > derek > > -- > Derek T. Yarnell > University of Maryland > Institute for Advanced Computer Studies > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss From matthew.lagoe at subrigo.net Fri Sep 12 17:50:56 2014 From: matthew.lagoe at subrigo.net (matthew lagoe) Date: Fri, 12 Sep 2014 10:50:56 -0700 Subject: [OmniOS-discuss] NFSv4 client soft lockups Message-ID: <14r5hatrb0hayktvwpx18tdr.1410544256877@email.android.com> I do not know if it is relevant but I came from open Indiana and it had a similar issue where nfsv4 had a bug that wouldn't unlock files Valrhona wrote: Not sure if this is the same issue, but I had the same behavior with Windows 8.1 on my laptop; everything has been fine for many months with clients running Win 7, Ubuntu 12.04 LTS, Ubuntu 14.04 LTS, OpenIndiana and XStreamOS (Illumos-based). But the Win 8.1 laptop causes NFSv4 to lock up, and (obviously) blocks the rest of the clients from accessing the server when it does, until NFS is reset. Interestingly, it doesn't seem to do this immediately; NFSv4 works just fine for maybe 15 minutes before the lockup occurs, but I haven't exactly troubleshot the details. Is there a particular log file which might be helpful to examine? Thanks! Peter On Fri, Sep 12, 2014 at 11:25 AM, Derek Yarnell wrote: > > > On 9/12/14 11:05 AM, Schweiss, Chip wrote: >> Is you RHEL 6.5 client a virtual machine? If so this message is a red >> herring to your problem. >> >> See the VMware KB article: >> http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=dis playKC&externalId=1009996 >> >> I run all NFSv4 from CentOS 6.5 to OmniOS, but do not use kerberos. It's >> been rock solid. > > Hi Chip, > > No we are running on physical hardware. It also looks like the > parameter they talk about is something different[1] post RHEL 6.1. We > are trying to drop to just sec=krb5 to see if that provides any relief > and may increase the watchdog timer a bit to see if this is just a race > condition. > > [1] - https://access.redhat.com/solutions/57811? > > Thanks, > derek > > -- > Derek T. Yarnell > University of Maryland > Institute for Advanced Computer Studies > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss _______________________________________________ OmniOS-discuss mailing list OmniOS-discuss at lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss -------------- next part -------------- An HTML attachment was scrubbed... URL: From danmcd at omniti.com Sat Sep 13 00:31:34 2014 From: danmcd at omniti.com (Dan McDonald) Date: Fri, 12 Sep 2014 20:31:34 -0400 Subject: [OmniOS-discuss] Quick question --> FTP server usage in OmniOS? Message-ID: <248525F6-AF5E-447E-9426-EA96AAE46981@omniti.com> Recently, but after the freeze for r151012, the FTP server was removed from illumos-gate. This means that it will be removed from the illumos-omnios gate for the new bloody (r151013) and the next stable+LTS (r151014). I'm curious if this is a big loss or not for our users. If it IS, then clearly part of the 013 bloody cycle is to replace the removed FTP server with something else, OR continue to maintain it. I'm inclined not to replace it, unless I get a large mob of torch-and-pitchfork-wielding folks. Curious, Dan From ian at ianshome.com Sat Sep 13 03:25:09 2014 From: ian at ianshome.com (Ian Collins) Date: Sat, 13 Sep 2014 15:25:09 +1200 Subject: [OmniOS-discuss] E5-2600 v3 Haswell In-Reply-To: <659B3799-66F0-4491-8F23-84DE1CEA9A6A@omniti.com> References: <659B3799-66F0-4491-8F23-84DE1CEA9A6A@omniti.com> Message-ID: <5413B915.70407@ianshome.com> Dan McDonald wrote: > On Sep 11, 2014, at 2:40 PM, Jon Hull wrote: > >> The board has 1g nics and those worked fine (igb). I was supposed to get a 10g version of the board but my boss sold it before I had a chance to test it out. > The "10g" may actually be a 40g with 4x 10G ports. If it's the part I'm thinking about, it's the "i40e", which illumos does not yet support. Do you know what 1GigE "igb" part it is? Is it I350, or something newer? It's the i350. > This is a dual-socket board, you said? I'd be interested to know if you see any odd latencies - I've seen {Sandy,Ivy} Bridge-E boards occasionally exhibit odd latencies with 10GigE, but it was very difficult to characterize and reproduce. Fortunately that are still using X540 on these boards. How have these latencies shown up? I have a number of X9 boards with X540 10GE on board and I haven't notices anything untoward. -- Ian. From brogyi at gmail.com Sat Sep 13 08:00:46 2014 From: brogyi at gmail.com (=?ISO-8859-1?Q?Brogy=E1nyi_J=F3zsef?=) Date: Sat, 13 Sep 2014 10:00:46 +0200 Subject: [OmniOS-discuss] Quick question --> FTP server usage in OmniOS? In-Reply-To: <248525F6-AF5E-447E-9426-EA96AAE46981@omniti.com> References: <248525F6-AF5E-447E-9426-EA96AAE46981@omniti.com> Message-ID: <5413F9AE.5050905@gmail.com> Dan It has changed to proftpd. inetadm -e ftp change to svcadm enable proftpd May be it works. :) BR Brogyi 2014.09.13. 2:31 keltez?ssel, Dan McDonald ?rta: > Recently, but after the freeze for r151012, the FTP server was removed from illumos-gate. This means that it will be removed from the illumos-omnios gate for the new bloody (r151013) and the next stable+LTS (r151014). > > I'm curious if this is a big loss or not for our users. If it IS, then clearly part of the 013 bloody cycle is to replace the removed FTP server with something else, OR continue to maintain it. I'm inclined not to replace it, unless I get a large mob of torch-and-pitchfork-wielding folks. > > Curious, > Dan > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss From dan at syneto.net Sat Sep 13 14:29:28 2014 From: dan at syneto.net (Dan Vatca) Date: Sat, 13 Sep 2014 17:29:28 +0300 Subject: [OmniOS-discuss] sed on bloody crashes when compiling cdrtools In-Reply-To: References: <83B1E61C-DDC9-4EB9-8B30-94FC4DD6DB29@omniti.com> <47946905-E5CF-4978-B941-48282CA8BCD3@omniti.com> <20140912151400.GB978@meili> <5A61BDE1-DAB0-487B-B461-B7B150AB3B86@omniti.com> <747EAE4F-8410-4F86-BA8E-F130AD1ECD29@omniti.com> Message-ID: Just as a quick note to whoever compiles bloody: a broken sed will also trip the gcc48 compilation with a not so obvious error. I worked around it for now by using tr instead. If you get this: 'use of enum ?reg_class? without previous declaration' and are currently running on bloody, the you'll have to change gcc/mkconfig.sh to use tr instead of sed for the hg_sed_expr / header_guard definitions. On Fri, Sep 12, 2014 at 7:50 PM, Dan Vatca wrote: > Looks related to the POSIX 2008 locale object support ( > https://www.illumos.org/issues/2964) > Maybe Garett can take a look at this. > > On Fri, Sep 12, 2014 at 6:58 PM, Dan Vatca wrote: > >> It crashes with LANG=C too. Just tested that. >> As a workaround I will use tr instead of sed. >> >> >> On Fri, Sep 12, 2014 at 6:36 PM, Dan McDonald wrote: >> >>> Dan V. --> As a workaround, set your LANG to 'C' instead of >>> "en_US.UTF-8". >>> >>> Dan >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From danmcd at omniti.com Sat Sep 13 15:28:14 2014 From: danmcd at omniti.com (Dan McDonald) Date: Sat, 13 Sep 2014 11:28:14 -0400 Subject: [OmniOS-discuss] sed on bloody crashes when compiling cdrtools In-Reply-To: References: <83B1E61C-DDC9-4EB9-8B30-94FC4DD6DB29@omniti.com> <47946905-E5CF-4978-B941-48282CA8BCD3@omniti.com> <20140912151400.GB978@meili> <5A61BDE1-DAB0-487B-B461-B7B150AB3B86@omniti.com> <747EAE4F-8410-4F86-BA8E-F130AD1ECD29@omniti.com> Message-ID: Pardon the top post, at a soccer game. I compile bloody, and gcc48 *appears* to work for me. The buildctl script should halt if something doesn't compile. I'll check the logs for 012 and 013 when I get home today. Thanks, Dan Sent from my iPhone (typos, autocorrect, and all) > On Sep 13, 2014, at 10:29 AM, Dan Vatca wrote: > > Just as a quick note to whoever compiles bloody: a broken sed will also trip the gcc48 compilation with a not so obvious error. I worked around it for now by using tr instead. If you get this: 'use of enum ?reg_class? without previous declaration' and are currently running on bloody, the you'll have to change gcc/mkconfig.sh to use tr instead of sed for the hg_sed_expr / header_guard definitions. > > > >> On Fri, Sep 12, 2014 at 7:50 PM, Dan Vatca wrote: >> Looks related to the POSIX 2008 locale object support (https://www.illumos.org/issues/2964) >> Maybe Garett can take a look at this. >> >>> On Fri, Sep 12, 2014 at 6:58 PM, Dan Vatca wrote: >>> It crashes with LANG=C too. Just tested that. >>> As a workaround I will use tr instead of sed. >>> >>> >>>> On Fri, Sep 12, 2014 at 6:36 PM, Dan McDonald wrote: >>>> Dan V. --> As a workaround, set your LANG to 'C' instead of "en_US.UTF-8". >>>> >>>> Dan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dan at syneto.net Sat Sep 13 18:49:13 2014 From: dan at syneto.net (Dan Vatca) Date: Sat, 13 Sep 2014 21:49:13 +0300 Subject: [OmniOS-discuss] Building developer/make fails for unresolved dependencies Message-ID: Hello, I'm making progress in having bloody compile on bloody, but I keep having this problem that baffles me. If I run "./buildctl -bpil build all" it fails. If I run it by itself with './buildctl -bpil build make' it works just fine. ============================================== Building and installing (devpro-sccs-20061219) Moving closed bins into place Shifting binaries and setting up links Making package --- Generating package manifest from /code/tmp/build_admin/make_pkg ------ Running: /usr/bin/pkgsend generate /code/tmp/build_admin/make_pkg > /code/tmp/build_admin/developer_build_make.p5m.int --- Generating package metadata --- Applying transforms --- Resolving dependencies /code/tmp/build_admin/developer_build_make.p5m.int.3 has unresolved dependency ' depend type=require fmri=__TBD pkg.debug.depend.file=make \ pkg.debug.depend.path=usr/xpg4/bin \ pkg.debug.depend.reason=usr/bin/make pkg.debug.depend.type=hardlink'. /code/tmp/build_admin/developer_build_make.p5m.int.3 has unresolved dependency ' depend type=require fmri=__TBD pkg.debug.depend.file=make \ pkg.debug.depend.path=usr/xpg4/bin \ pkg.debug.depend.reason=usr/lib/svr4.make \ pkg.debug.depend.type=hardlink'. --- Dependency resolution failed Unable to run build.sh ========================================= There is the local.mog transform that must work to drop those dependencies, but for some reason, it keeps failing when it runs through build all. Any idea on what I'm missing? Dan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From danmcd at omniti.com Sat Sep 13 21:16:12 2014 From: danmcd at omniti.com (Dan McDonald) Date: Sat, 13 Sep 2014 17:16:12 -0400 Subject: [OmniOS-discuss] Building developer/make fails for unresolved dependencies In-Reply-To: References: Message-ID: <22BCB31B-3032-4AA5-B941-45E984E8B0AB@omniti.com> On Sep 13, 2014, at 2:49 PM, Dan Vatca wrote: > > There is the local.mog transform that must work to drop those dependencies, but for some reason, it keeps failing when it runs through build all. > Any idea on what I'm missing? I honestly am not sure. If you "cd make ; ./build.sh -bpil" what does it do? I'm also curious what "buildctl list-build" says? It sorts based solely on bash's associative array sorting. Maybe the default bash sorts one way, and your bash (did you compile it oddly?) another way? Dan From danmcd at omniti.com Sat Sep 13 21:44:36 2014 From: danmcd at omniti.com (Dan McDonald) Date: Sat, 13 Sep 2014 17:44:36 -0400 Subject: [OmniOS-discuss] Quick question --> FTP server usage in OmniOS? In-Reply-To: <5413F9AE.5050905@gmail.com> References: <248525F6-AF5E-447E-9426-EA96AAE46981@omniti.com> <5413F9AE.5050905@gmail.com> Message-ID: <367CF037-A7D3-4111-A9AD-22B38F1048A7@omniti.com> On Sep 13, 2014, at 4:00 AM, Brogy?nyi J?zsef wrote: > Dan > > It has changed to proftpd. Nothing in OmniOS has changed to proftpd, nor in illumos-gate. > inetadm -e ftp change to svcadm enable proftpd > > May be it works. :) That is a possibility (shipping proftpd somewhere), BUT I'm asking if we don't have it readily available will that be a major problem for anyone? Dan From gate03 at landcroft.co.uk Sat Sep 13 22:00:16 2014 From: gate03 at landcroft.co.uk (Michael Mounteney) Date: Sun, 14 Sep 2014 08:00:16 +1000 Subject: [OmniOS-discuss] Anyone built Horde? Message-ID: <20140914080016.77bb7223@pimpama> While we're covering the subject of building stuff on OmniOS, has anyone built Horde, following the instructions at http://www.horde.org/apps/horde/docs/INSTALL ? I'm trying to do so in a zone and encountering some difficulty. I installed gcc48 and autoconf and gcc passes the sanity test: echo 'int main () { return 0; }' >og.c ; gcc og.c ; ./a.out but at section 2.4 PECL Modules: # PATH=$PATH:/opt/gcc-4.8.1/bin /pecl install imagick horde_lz4 memcache http No releases available for package "pecl.php.net/horde_lz4" No releases available for package "pecl.php.net/http" downloading imagick-3.1.2.tgz ... Starting to download imagick-3.1.2.tgz (94,657 bytes) .....................done: 94,657 bytes downloading memcache-2.2.7.tgz ... Starting to download memcache-2.2.7.tgz (36,459 bytes) ...done: 36,459 bytes 15 source files, building running: /opt/php54/bin/phpize Configuring for: PHP Api Version: 20100412 Zend Module Api No: 20100525 Zend Extension Api No: 220100525 Please provide the prefix of Imagemagick installation [autodetect] : building in /tmp/pear/temp/pear-build-defaultuser6oaOh4/imagick-3.1.2 running: /tmp/pear/temp/imagick/configure --with-imagick checking for grep that handles long lines and -e... /usr/gnu/bin/grep checking for egrep... /usr/gnu/bin/grep -E checking for a sed that does not truncate output... /usr/gnu/bin/sed checking for cc... no checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... configure: error: in `/tmp/pear/temp/pear-build-defaultuser6oaOh4/imagick-3.1.2': configure: error: cannot run C compiled programs. If you meant to cross compile, use `--host'. See `config.log' for more details but there is no file config.log Any suggestions ? From gate03 at landcroft.co.uk Sat Sep 13 23:36:58 2014 From: gate03 at landcroft.co.uk (Michael Mounteney) Date: Sun, 14 Sep 2014 09:36:58 +1000 Subject: [OmniOS-discuss] Anyone built Horde? In-Reply-To: <20140914080016.77bb7223@pimpama> References: <20140914080016.77bb7223@pimpama> Message-ID: <20140914093658.65740975@pantry> Partly answering my own question, I managed to break into the build process so that pecl didn't delete config.log. It contains: configure:2857: gcc -o conftest conftest.c >&5 conftest.c:9:19: fatal error: stdio.h: No such file or directory #include ^ compilation terminated. Even though: root at horde:~# find / -name stdio.h /opt/gcc-4.8.1/include/c++/4.8.1/tr1/stdio.h /opt/gcc-4.8.1/lib/gcc/i386-pc-solaris2.11/4.8.1/include/ssp/stdio.h It was a straightforward installation of gcc: # pkg install gcc48 So surely it should be configured to find the headers with which it was installed? Michael. From henson at acm.org Sun Sep 14 00:38:23 2014 From: henson at acm.org (Paul B. Henson) Date: Sat, 13 Sep 2014 17:38:23 -0700 Subject: [OmniOS-discuss] Anyone built Horde? In-Reply-To: <20140914093658.65740975@pantry> References: <20140914080016.77bb7223@pimpama> <20140914093658.65740975@pantry> Message-ID: <20140914003823.GM20693@bender.unx.csupomona.edu> On Sun, Sep 14, 2014 at 09:36:58AM +1000, Michael Mounteney wrote: > configure:2857: gcc -o conftest conftest.c >&5 > conftest.c:9:19: fatal error: stdio.h: No such file or directory > #include I think you need the system headers installed, not just the ones that come with gcc. Did you install the system/header package? There's a page at http://omnios.omniti.com/wiki.php/DevEnv which describes what packages should be installed to do basic development. From dan at syneto.net Sun Sep 14 01:41:36 2014 From: dan at syneto.net (Dan Vatca) Date: Sun, 14 Sep 2014 04:41:36 +0300 Subject: [OmniOS-discuss] Building developer/make fails for unresolved dependencies In-Reply-To: <22BCB31B-3032-4AA5-B941-45E984E8B0AB@omniti.com> References: <22BCB31B-3032-4AA5-B941-45E984E8B0AB@omniti.com> Message-ID: Yes, it does it sometimes even when I run ./build.sh -bpil. This is very odd, as it seems to be failing randomly on successive runs. And given it takes around 30s on my machine, I ran it a lot of times just too see if there is a pattern. I tried running it with REMOVE_PREVIOUS=1 and it still sometimes fails. When it fails, it seems that it does not have this file: usr/lib/svr4.make (or can read it?). And it fails because the hardlinks point nowhere. Could it be a race condition where the file is not yet created? Seems far fetched, but will take a look at that shortly. Now I really have to get some sleep ... On Sun, Sep 14, 2014 at 12:16 AM, Dan McDonald wrote: > > On Sep 13, 2014, at 2:49 PM, Dan Vatca wrote: > > > > > There is the local.mog transform that must work to drop those > dependencies, but for some reason, it keeps failing when it runs through > build all. > > Any idea on what I'm missing? > > I honestly am not sure. If you "cd make ; ./build.sh -bpil" what does it > do? > > I'm also curious what "buildctl list-build" says? It sorts based solely > on bash's associative array sorting. Maybe the default bash sorts one way, > and your bash (did you compile it oddly?) another way? > > Dan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From henson at acm.org Sun Sep 14 02:06:28 2014 From: henson at acm.org (Paul B. Henson) Date: Sat, 13 Sep 2014 19:06:28 -0700 Subject: [OmniOS-discuss] Anyone built Horde? In-Reply-To: <20140914113014.38850722@pantry> References: <20140914080016.77bb7223@pimpama> <20140914093658.65740975@pantry> <20140914003823.GM20693@bender.unx.csupomona.edu> <20140914113014.38850722@pantry> Message-ID: <20140914020628.GN20693@bender.unx.csupomona.edu> On Sun, Sep 14, 2014 at 11:30:14AM +1000, Michael Mounteney wrote: > /tmp/pear/temp/imagick/php_imagick.h:49:31: fatal error: wand/MagickWand.h: No such file or directory [...] > /opt/omni/include/ImageMagick/wand/MagickWand.h Looks like somebody somewhere needs a "-I /opt/omni/include/ImageMagick"... Couldn't tell you which piece or how to get it where it needs to be though. If you want to try kludging it, you could run "ln -s /opt/omni/include/ImageMagick/wand /usr/include" and see what happens. I'd remove the link once you got it built. From brogyi at gmail.com Sun Sep 14 08:17:22 2014 From: brogyi at gmail.com (=?ISO-8859-1?Q?Brogy=E1nyi_J=F3zsef?=) Date: Sun, 14 Sep 2014 10:17:22 +0200 Subject: [OmniOS-discuss] Quick question --> FTP server usage in OmniOS? In-Reply-To: <367CF037-A7D3-4111-A9AD-22B38F1048A7@omniti.com> References: <248525F6-AF5E-447E-9426-EA96AAE46981@omniti.com> <5413F9AE.5050905@gmail.com> <367CF037-A7D3-4111-A9AD-22B38F1048A7@omniti.com> Message-ID: <54154F12.10807@gmail.com> Dan Sorry the hipster has it. That's why I thought that. "2014-08-28 ftp daemon (earlier provided by illumos-gate wu-ftpd) is replaced by proftpd. Service network/ftp is renamed to service/proftpd. Now ftp daemon is running in standalone mode (previously it was inetd-managed service)." Brogyi 2014.09.13. 23:44 keltez?ssel, Dan McDonald ?rta: > On Sep 13, 2014, at 4:00 AM, Brogy?nyi J?zsef wrote: > >> Dan >> >> It has changed to proftpd. > Nothing in OmniOS has changed to proftpd, nor in illumos-gate. > >> inetadm -e ftp change to svcadm enable proftpd >> >> May be it works. :) > That is a possibility (shipping proftpd somewhere), BUT I'm asking if we don't have it readily available will that be a major problem for anyone? > > Dan > From brogyi at gmail.com Sun Sep 14 08:22:44 2014 From: brogyi at gmail.com (=?ISO-8859-1?Q?Brogy=E1nyi_J=F3zsef?=) Date: Sun, 14 Sep 2014 10:22:44 +0200 Subject: [OmniOS-discuss] Quick question --> FTP server usage in OmniOS? In-Reply-To: <367CF037-A7D3-4111-A9AD-22B38F1048A7@omniti.com> References: <248525F6-AF5E-447E-9426-EA96AAE46981@omniti.com> <5413F9AE.5050905@gmail.com> <367CF037-A7D3-4111-A9AD-22B38F1048A7@omniti.com> Message-ID: <54155054.7030500@gmail.com> Dan Here is the package name: service/network/ftp/proftpd 1.3.5-2014.1.2.1:20140901T080911Z Brogyi 2014.09.13. 23:44 keltez?ssel, Dan McDonald ?rta: > On Sep 13, 2014, at 4:00 AM, Brogy?nyi J?zsef wrote: > >> Dan >> >> It has changed to proftpd. > Nothing in OmniOS has changed to proftpd, nor in illumos-gate. > >> inetadm -e ftp change to svcadm enable proftpd >> >> May be it works. :) > That is a possibility (shipping proftpd somewhere), BUT I'm asking if we don't have it readily available will that be a major problem for anyone? > > Dan > From mark0x01 at gmail.com Sun Sep 14 09:30:50 2014 From: mark0x01 at gmail.com (Mark) Date: Sun, 14 Sep 2014 21:30:50 +1200 Subject: [OmniOS-discuss] Fibre Target problems In-Reply-To: <562C2ABFE2448D4E95E8910A85488708260B0262@HEIMAT.cm3c.local> References: <541155D5.8080406@gmail.com> <562C2ABFE2448D4E95E8910A85488708260B0262@HEIMAT.cm3c.local> Message-ID: <5415604A.7030408@gmail.com> On 11/09/2014 9:25 p.m., OSN | Marian Fischer wrote: > Hi, > > do you have Sync=disabled in ZFS / ZPOOL settings? > If not, this can cause the slow speed ... No, but I didn't with OI either, and it has no issues achieving 400+ Mbytes/sec and doesn't have link loss issues. > > Mit besten Gruessen > > Marian Fischer > -- > OSN Online Service Nuernberg GmbH http://www.osn.de > Bucher Str. 78 Tel: 0911/39905-0 > 90408 Nuernberg Fax: 0911/39905-55 > HRB 15022 Nuernberg, Ust-Id: DE189301263 GF: Joerg Goltermann > > -----Urspr?ngliche Nachricht----- > Von: OmniOS-discuss [mailto:omnios-discuss-bounces at lists.omniti.com] Im > Auftrag von Mark > Gesendet: Donnerstag, 11. September 2014 09:57 > An: omnios-discuss at lists.omniti.com > Betreff: [OmniOS-discuss] Fibre Target problems > > I have a Supermicro X7DWN+ based server with 24 x 4Tb SAS disks on a LSI > 6G IT mode hba. > > After configuring a bunch of 10Tb Luns and presenting to a Win2012 > server, write is very slow < 6 Mb/sec, and writing causes the Fc link to > drop repeatedly. > Reads reach about 400Mb/sec. > > OmniOS version is r151006_057. > > I've tried two different 4G and an 8G QLogic adapters, via switch or > direct, but there is no change in behaviour. Only 1 HBA and path. > > The odd thing is the exact same hardware and os setup (fct, zpool etc.) > works well with OI or Solaris 11/11, with writes getting around 4-500 > Mb/sec. > I had to start with OI147 and work up, as the later text installer is > very buggy. Upgrading OI with qlt installed fails. > > I'm at a bit of a loss as to a likely cause. > > Anyone have any pointers ? > > > Some details and log: > > HBA Port WWN: 2100001b320aba27 > Port Mode: Target > Port ID: 10100 > OS Device Name: Not Applicable > Manufacturer: QLogic Corp. > Model: QLE2460 > Firmware Version: 5.2.1 > FCode/BIOS Version: N/A > Serial Number: not available > Driver Name: COMSTAR QLT > Driver Version: 20100505-1.05 > Type: F-port > State: online > Supported Speeds: 1Gb 2Gb 4Gb > Current Speed: 4Gb > Node WWN: 2000001b320aba27 > Link Error Statistics: > Link Failure Count: 0 > Loss of Sync Count: 0 > Loss of Signal Count: 0 > Primitive Seq Protocol Error Count: 0 > Invalid Tx Word Count: 4 > Invalid CRC Count: 0 > > > > prtconf > > value='ISP2432-based 4Gb Fibre Channel to PCI Express HBA' > name='subsystem-name' type=string items=1 > value='unknown subsystem' > Device Minor Nodes:dev=(3,1) > dev_path=/pci at 0,0/pci8086,4027 at 7/pci8086,3500 at 0/pci8086,3510 at 0/pci1077,137 at 0 > :qlt1 > > echo "*stmf_trace_buf/s" | mdb -k > > 0xffffff090f7c0000: qlt1,0:0001318: iport is ffffff090f1921b8 > > :0003718: Imported the LU 600144f09cdd9224000053f56a5c0005 > :0003719: Imported the LU 600144f09cdd9224000053f56a5d0006 > :0003721: Imported the LU 600144f09cdd9224000053f56a5d0007 > :0003722: Imported the LU 600144f09cdd9224000053f56a5e0008 > :0003725: Imported the LU 600144f09cdd9224000053f56a5e0009 > :0003726: Imported the LU 600144f09cdd9224000053f56a5f000a > :0003728: Imported the LU 600144f09cdd9224000053f56a5f000b > qlt1,0:0003815: Async event 8010 mb1=f8e8 mb2=c108, mb3=0, mb5=3362, mb6=0 > qlt1,0:0003815: Async event 8011 mb1=3 mb2=c108, mb3=0, mb5=3362, mb6=0 > qlt1,0:0003815: port state change from 0 to e > qlt1,0:0003815: Async event 8014 mb1=ffff mb2=6, mb3=0, mb5=3362, mb6=0 > qlt1,0:0003815: Posting unsol ELS 3 (PLOGI) rp_id=e8 lp_id=ef > qlt1,0:0003815: Rcvd PLOGI with wrong lportid ef, expecting 0. Killing ELS. > qlt1,0:0003815: port state change from e to 4 > qlt1,0:0004216: Posting unsol ELS 3 (PLOGI) rp_id=e8 lp_id=ef > qlt1,0:0004216: Processing unsol ELS 3 (PLOGI) rp_id=e8 > qlt1,0:0004216: Posting unsol ELS 20 (PRLI) rp_id=e8 lp_id=ef > qlt1,0:0004216: Processing unsol ELS 20 (PRLI) rp_id=e8 > qlt1,0:7247736: Posting unsol ELS 5 (LOGO) rp_id=e8 lp_id=ef > qlt1,0:7247736: Processing unsol ELS 5 (LOGO) rp_id=e8 > qlt1,0:7247736: handling LOGO rp_id e8. Triggering cleanup > :7248836: fct_port_shutdown: port-ffffff090f1920b8, fct_process_logo: > unable to clean up I/O. iport-ffffff090f1921b8, icmd-ffffff0931089a00 > qlt1,0:7248836: port state change from 4 to 11 > :7248836: fct_port_shutdown: port-ffffff090f1920b8, fct_process_logo: > unable to clean up I/O. iport-ffffff090f1921b8, icmd-ffffff0931089a00 > qlt1,0:7248836: port state change from 11 to 11 > :7248836: fct_port_shutdown: port-ffffff090f1920b8, fct_process_logo: > unable to clean up I/O. iport-ffffff090f1921b8, icmd-ffffff0931089a00 > qlt1,0:7248936: port state change from 11 to 11 > :7248936: fct_port_shutdown: port-ffffff090f1920b8, fct_process_logo: > unable to clean up I/O. iport-ffffff090f1921b8, icmd-ffffff0931089a00 > qlt1,0:7249036: port state change from 11 to 11 > :7249036: fct_port_shutdown: port-ffffff090f1920b8, fct_process_logo: > unable to clean up I/O. iport-ffffff090f1921b8, icmd-ffffff0931089a00 > qlt1,0:7249136: port state change from 11 to 11 > qlt1,0:7249136: Killing ELS 5 cond 1 > qlt1,0:7249136: Processing sol ELS 5 (LOGO) rp_id=e8 > qlt1,0:7249136: handling LOGO rp_id e8. Triggering cleanup > qlt1,0:7249236: port state change from 11 to 11 > qlt1,0:7249336: port state change from 11 to 11 > qlt1,0:7249336: port state change from 11 to 11 > qlt1,0:7249436: port state change from 11 to 11 > qlt1,0:7249536: port state change from 11 to 11 > qlt1,0:7249536: handling LOGO rp_id e8, waiting for cmds to drain > qlt1,0:7249636: port state change from 11 to 11 > qlt1,0:7249736: port state change from 11 to 11 > qlt1,0:7249836: port state change from 11 to 11 > qlt1,0:7249936: port state change from 11 to 11 > qlt1,0:7250036: port state change from 11 to 11 > qlt1,0:7250136: port state change from 11 to 11 > qlt1,0:7250236: port state change from 11 to 11 > :7250236: fct_port_shutdown: port-ffffff090f1920b8, fct_process_logo: > unable to clean up I/O. iport-ffffff090f1921b8, icmd-ffffff091c5549d0 > qlt1,0:7250336: port state change from 11 to 11 > :7250336: fct_port_shutdown: port-ffffff090f1920b8, fct_process_logo: > unable to clean up I/O. iport-ffffff090f1921b8, icmd-ffffff091c5549d0 > qlt1,0:7250336: port state change from 11 to 11 > :7250336: fct_port_shutdown: port-ffffff090f1920b8, fct_process_logo: > unable to clean up I/O. iport-ffffff090f1921b8, icmd-ffffff091c5549d0 > qlt1,0:7250436: port state change from 11 to 11 > :7250436: fct_port_shutdown: port-ffffff090f1920b8, fct_process_logo: > unable to clean up I/O. iport-ffffff090f1921b8, icmd-ffffff091c5549d0 > qlt1,0:7250536: port state change from 11 to 11 > :7250536: fct_port_shutdown: port-ffffff090f1920b8, fct_process_logo: > unable to clean up I/O. iport-ffffff090f1921b8, icmd-ffffff091c5549d0 > qlt1,0:7250636: port state change from 11 to 11 > :7250636: fct_port_shutdown: port-ffffff090f1920b8, fct_process_logo: > unable to clean up I/O. iport-ffffff090f1921b8, icmd-ffffff091c5549d0 > qlt1,0:7250736: port state change from 11 to 11 > :7250736: fct_port_shutdown: port-ffffff090f1920b8, fct_process_logo: > unable to clean up I/O. iport-ffffff090f1921b8, icmd-ffffff091c5549d0 > qlt1,0:7250836: port state change from 11 to 11 > :7250836: fct_port_shutdown: port-ffffff090f1920b8, fct_process_logo: > unable to clean up I/O. iport-ffffff090f1921b8, icmd-ffffff091c5549d0 > qlt1,0:7250936: port state change from 11 to 11 > :7250936: fct_port_shutdown: port-ffffff090f1920b8, fct_process_logo: > unable to clean up I/O. iport-ffffff090f1921b8, icmd-ffffff091c5549d0 > qlt1,0:7251136: port state change from 11 to 11 > :7251136: fct_port_shutdown: port-ffffff090f1920b8, fct_process_logo: > unable to clean up I/O. iport-ffffff090f1921b8, icmd-ffffff091c5549d0 > qlt1,0:7251236: port state change from 11 to 11 > > > > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > > > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > From jimklimov at cos.ru Sun Sep 14 12:53:30 2014 From: jimklimov at cos.ru (Jim Klimov) Date: Sun, 14 Sep 2014 14:53:30 +0200 Subject: [OmniOS-discuss] Building developer/make fails for unresolved dependencies In-Reply-To: References: <22BCB31B-3032-4AA5-B941-45E984E8B0AB@omniti.com> Message-ID: 14 ???????? 2014??. 3:41:36 CEST, Dan Vatca ?????: >Yes, it does it sometimes even when I run ./build.sh -bpil. >This is very odd, as it seems to be failing randomly on successive >runs. >And given it takes around 30s on my machine, I ran it a lot of times >just >too see if there is a pattern. >I tried running it with REMOVE_PREVIOUS=1 and it still sometimes fails. >When it fails, it seems that it does not have this file: >usr/lib/svr4.make >(or can read it?). And it fails because the hardlinks point nowhere. >Could >it be a race condition where the file is not yet created? Seems far >fetched, but will take a look at that shortly. Now I really have to get >some sleep ... > > >On Sun, Sep 14, 2014 at 12:16 AM, Dan McDonald >wrote: > >> >> On Sep 13, 2014, at 2:49 PM, Dan Vatca wrote: >> >> > >> > There is the local.mog transform that must work to drop those >> dependencies, but for some reason, it keeps failing when it runs >through >> build all. >> > Any idea on what I'm missing? >> >> I honestly am not sure. If you "cd make ; ./build.sh -bpil" what >does it >> do? >> >> I'm also curious what "buildctl list-build" says? It sorts based >solely >> on bash's associative array sorting. Maybe the default bash sorts >one way, >> and your bash (did you compile it oddly?) another way? >> >> Dan >> >> > > >------------------------------------------------------------------------ > >_______________________________________________ >OmniOS-discuss mailing list >OmniOS-discuss at lists.omniti.com >http://lists.omniti.com/mailman/listinfo/omnios-discuss Just in case, are you building on a local or an nfs-mounted filesystem? I've had issues with the latter due to nontrivial times and non-atomic operations to update the fs metadata (or the client's view of it) so compiled objects are not always seen when expected for the next step. Still, a parallel make over nfs followed by a sequential one to cover up the loose ends is usually faster than sequential all the way (at least with an nfs server which has no ddr zil ;) ) Also, some tools like yacc/lex/bison might use the same filename for all outputs, and i've had parallel builds fail due to that - and had to sequentialize those sections. That's not illumos specific, but experience from a number of open-soirce projects (many different OS releases as compute nodes use the same homedir with sources over nfs). HTH, Jim -- Typos courtesy of K-9 Mail on my Samsung Android From gate03 at landcroft.co.uk Sun Sep 14 19:38:02 2014 From: gate03 at landcroft.co.uk (Michael Mounteney) Date: Mon, 15 Sep 2014 05:38:02 +1000 Subject: [OmniOS-discuss] Anyone built Horde? In-Reply-To: <20140914020628.GN20693@bender.unx.csupomona.edu> References: <20140914080016.77bb7223@pimpama> <20140914093658.65740975@pantry> <20140914003823.GM20693@bender.unx.csupomona.edu> <20140914113014.38850722@pantry> <20140914020628.GN20693@bender.unx.csupomona.edu> Message-ID: <20140915053802.4ae59ace@pantry> On Sat, 13 Sep 2014 19:06:28 -0700 "Paul B. Henson" wrote: > > If you want to try kludging it, you could run "ln -s > /opt/omni/include/ImageMagick/wand /usr/include" and see what happens. > I'd remove the link once you got it built. > Well my experience with kludging some elses build is that it rapidly becomes a tar-baby, and this one is no exception. After symlinking ImageMagick/magick to /usr/include as well, it seemed to build but it looks like the PHP stuff went for a 32 bit build with no option to change that: (excuse formatting) /opt/OMNIlighttpd/sbin/lighttpd -D -f ~/lighttpd.conf 2014-09-14 02:42:14: (log.c.166) server started PHP Warning: PHP Startup: Unable to load dynamic library '/opt/php54/lib/extensions/no-debug-non-zts-20100525/imagick.so' - ld.so.1: php-cgi: fatal: /opt/php54/lib/extensions/no-debug-non-zts-20100525/imagick.so: wrong ELF class: ELFCLASS32 in Unknown on line 0PHP Warning: PHP Startup: Unable to load dynamic library '/opt/php54/lib/extensions/no-debug-non-zts-20100525/imagick.so' - ld.so.1: php-cgi: fatal: /opt/php54/lib/extensions/no-debug-non-zts-20100525/imagick.so: wrong ELF class: ELFCLASS32 in Unknown on line 0PHP Warning: PHP Startup: Unable to load dynamic library '/opt/php54/lib/extensions/no-debug-non-zts-20100525/imagick.so' - ld.so.1: php-cgi: fatal: /opt/php54/lib/extensions/no-debug-non-zts-20100525/imagick.so: wrong ELF class: ELFCLASS32 in Unknown on line 0PHP Warning: PHP Startup: Unable to load dynamic library '/opt/php54/lib/extensions/no-debug-non-zts-20100525/imagick.so' - ld.so.1: php-cgi: fatal: /opt/php54/lib/extensions/no-debug-non-zts-20100525/imagick.so: wrong ELF class: ELFCLASS32 in Unknown on line 0 # file /opt/php54/lib/extensions/no-debug-non-zts-20100525/* /opt/php54/lib/extensions/no-debug-non-zts-20100525/imagick.so: ELF 32-bit LSB dynamic lib 80386 Version 1, dynamically linked, not stripped The next step I suppose is to build my own (32 bit) PHP but this is becoming messy. Will I have to build a 32 bit lighttpd as well ? Hmm. From danmcd at omniti.com Mon Sep 15 02:05:52 2014 From: danmcd at omniti.com (Dan McDonald) Date: Sun, 14 Sep 2014 22:05:52 -0400 Subject: [OmniOS-discuss] Jenkins anyone? References: <4C.A7.33115.A3646145@twitter.com> Message-ID: <8F1CCDD5-887F-45F4-A401-7415147C6533@omniti.com> Saw this retweeted on twitter. Anyone here care about Jenkins running on OmniOS? (His calling out of OI is likely just improper conflation.) Dan Begin forwarded message: > From: "Dan McDonald (via Twitter)" > Subject: Dan McDonald (@kebesays) shared a conversation with you! > Date: September 14, 2014 at 9:51:54 PM EDT > To: > > > Dan McDonald saw this and thought of you! > > > > > > R. Tyler Croy > @agentdero > > Do you use the Solaris/OpenIndiana packages for @jenkinsci? Let me know because I'm sick and tired of supporting them > > 06:34 PM - 13 Sep 14 > > > > > > Don't have a Twitter account yet? > Sign up today and follow R. Tyler Croy. > Join Twitter > > > This message was sent by a Twitter user who entered your email address. You canunsubscribe from receiving email notifications from Twitter. For general inquiries, please visit us at Twitter Support. > Twitter, Inc. 1355 Market St., Suite 900 San Francisco, CA 94103 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave-oo at pooserville.com Mon Sep 15 06:22:15 2014 From: dave-oo at pooserville.com (Dave Pooser) Date: Mon, 15 Sep 2014 01:22:15 -0500 Subject: [OmniOS-discuss] How does one get permission to edit the wiki? Message-ID: Or, alternately, what's the best path to submit a proposed documentation patch? I'm currently involved in making an OmniOS machine play nicely with AD and it occurs to me that I might save others some time assembling the necessary steps from Solaris and OI documentation.... -- Dave Pooser Cat-Herder-in-Chief, Pooserville.com From dan at syneto.net Mon Sep 15 08:45:23 2014 From: dan at syneto.net (Dan Vatca) Date: Mon, 15 Sep 2014 11:45:23 +0300 Subject: [OmniOS-discuss] Building developer/make fails for unresolved dependencies In-Reply-To: References: <22BCB31B-3032-4AA5-B941-45E984E8B0AB@omniti.com> Message-ID: Hi Jim, I am building on a local zfs filesystem with atime=on and sync=disabled. I'veI also had problems with NFS mountpoints, so I avoid building on it. On Sun, Sep 14, 2014 at 3:53 PM, Jim Klimov wrote: > 14 ???????? 2014 ?. 3:41:36 CEST, Dan Vatca ?????: > >Yes, it does it sometimes even when I run ./build.sh -bpil. > >This is very odd, as it seems to be failing randomly on successive > >runs. > >And given it takes around 30s on my machine, I ran it a lot of times > >just > >too see if there is a pattern. > >I tried running it with REMOVE_PREVIOUS=1 and it still sometimes fails. > >When it fails, it seems that it does not have this file: > >usr/lib/svr4.make > >(or can read it?). And it fails because the hardlinks point nowhere. > >Could > >it be a race condition where the file is not yet created? Seems far > >fetched, but will take a look at that shortly. Now I really have to get > >some sleep ... > > > > > >On Sun, Sep 14, 2014 at 12:16 AM, Dan McDonald > >wrote: > > > >> > >> On Sep 13, 2014, at 2:49 PM, Dan Vatca wrote: > >> > >> > > >> > There is the local.mog transform that must work to drop those > >> dependencies, but for some reason, it keeps failing when it runs > >through > >> build all. > >> > Any idea on what I'm missing? > >> > >> I honestly am not sure. If you "cd make ; ./build.sh -bpil" what > >does it > >> do? > >> > >> I'm also curious what "buildctl list-build" says? It sorts based > >solely > >> on bash's associative array sorting. Maybe the default bash sorts > >one way, > >> and your bash (did you compile it oddly?) another way? > >> > >> Dan > >> > >> > > > > > >------------------------------------------------------------------------ > > > >_______________________________________________ > >OmniOS-discuss mailing list > >OmniOS-discuss at lists.omniti.com > >http://lists.omniti.com/mailman/listinfo/omnios-discuss > > Just in case, are you building on a local or an nfs-mounted filesystem? > I've had issues with the latter due to nontrivial times and non-atomic > operations to update the fs metadata (or the client's view of it) so > compiled objects are not always seen when expected for the next step. > Still, a parallel make over nfs followed by a sequential one to cover up > the loose ends is usually faster than sequential all the way (at least with > an nfs server which has no ddr zil ;) ) > Also, some tools like yacc/lex/bison might use the same filename for all > outputs, and i've had parallel builds fail due to that - and had to > sequentialize those sections. That's not illumos specific, but experience > from a number of open-soirce projects (many different OS releases as > compute nodes use the same homedir with sources over nfs). > HTH, > Jim > -- > Typos courtesy of K-9 Mail on my Samsung Android > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.r.eremin at gmail.com Mon Sep 15 09:05:06 2014 From: alexander.r.eremin at gmail.com (Alexander Eremin) Date: Mon, 15 Sep 2014 13:05:06 +0400 Subject: [OmniOS-discuss] Building developer/make fails for unresolved dependencies Message-ID: I had same error some time ago for full build. It seems if some of required build dependencies for component are missed, then this line in buildctl fails: PATH=$PATH:. $SCRIPT -r $PKGSRVR $batch_flag $lint_flag || \ May be passing some flag for build deps autoinstall could solve this. Alex > On 13 ????. 2014 ?., at 22:49, Dan Vatca wrote: > > Hello, > > I'm making progress in having bloody compile on bloody, but I keep having this problem that baffles me. If I run "./buildctl -bpil build all" it fails. If I run it by itself with './buildctl -bpil build make' it works just fine. > > ============================================== > Building and installing (devpro-sccs-20061219) > Moving closed bins into place > Shifting binaries and setting up links > Making package > --- Generating package manifest from /code/tmp/build_admin/make_pkg > ------ Running: /usr/bin/pkgsend generate /code/tmp/build_admin/make_pkg > /code/tmp/build_admin/developer_build_make.p5m.int > --- Generating package metadata > --- Applying transforms > --- Resolving dependencies > /code/tmp/build_admin/developer_build_make.p5m.int.3 has unresolved dependency ' > depend type=require fmri=__TBD pkg.debug.depend.file=make \ > pkg.debug.depend.path=usr/xpg4/bin \ > pkg.debug.depend.reason=usr/bin/make pkg.debug.depend.type=hardlink'. > /code/tmp/build_admin/developer_build_make.p5m.int.3 has unresolved dependency ' > depend type=require fmri=__TBD pkg.debug.depend.file=make \ > pkg.debug.depend.path=usr/xpg4/bin \ > pkg.debug.depend.reason=usr/lib/svr4.make \ > pkg.debug.depend.type=hardlink'. > --- Dependency resolution failed > Unable to run build.sh > ========================================= > > There is the local.mog transform that must work to drop those dependencies, but for some reason, it keeps failing when it runs through build all. > Any idea on what I'm missing? > > Dan. > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss -------------- next part -------------- An HTML attachment was scrubbed... URL: From jimklimov at cos.ru Mon Sep 15 10:54:09 2014 From: jimklimov at cos.ru (Jim Klimov) Date: Mon, 15 Sep 2014 12:54:09 +0200 Subject: [OmniOS-discuss] Jenkins anyone? In-Reply-To: <8F1CCDD5-887F-45F4-A401-7415147C6533@omniti.com> References: <4C.A7.33115.A3646145@twitter.com> <8F1CCDD5-887F-45F4-A401-7415147C6533@omniti.com> Message-ID: <33c25541-5361-48b3-9ac4-7d98970b70ed@email.android.com> 15 ???????? 2014??. 4:05:52 CEST, Dan McDonald ?????: >Saw this retweeted on twitter. Anyone here care about Jenkins running >on OmniOS? (His calling out of OI is likely just improper conflation.) > >Dan > >Begin forwarded message: > >> From: "Dan McDonald (via Twitter)" >> Subject: Dan McDonald (@kebesays) shared a conversation with you! >> Date: September 14, 2014 at 9:51:54 PM EDT >> To: >> >> >> Dan McDonald saw this and thought of you! >> >> >> >> >> >> R. Tyler Croy >> @agentdero >> >> Do you use the Solaris/OpenIndiana packages for @jenkinsci? Let me >know because I'm sick and tired of supporting them >> >> 06:34 PM - 13 Sep 14 >> >> >> >> >> >> Don't have a Twitter account yet? >> Sign up today and follow R. Tyler Croy. >> Join Twitter >> >> >> This message was sent by a Twitter user who entered your email >address. You canunsubscribe from receiving email notifications from >Twitter. For general inquiries, please visit us at Twitter Support. >> Twitter, Inc. 1355 Market St., Suite 900 San Francisco, CA 94103 >> > > > >------------------------------------------------------------------------ > >_______________________________________________ >OmniOS-discuss mailing list >OmniOS-discuss at lists.omniti.com >http://lists.omniti.com/mailman/listinfo/omnios-discuss I did set it up on my hipster notebook, but I took the war's and fed them to glassfish directly, just as well as opengrok, adding the OS setup bits according to the readmes as i went along. So I do use Jenkins on an illumos OS (with an Oracle JDK... something in the overall stack did not go well with the opensource one in OI/hipster, can't remember what now... maybe netbeans...). But I did not use packaging. As far as I am concerned, he can be relieved ;) But this is indeed a non-trivial setup that can benefit from pre-packaging at least for some default case of 'pkg install jenkins' fire and forget. Manually... there are quite many flexible options to be aware of. I can imagine some users reluctant to go this route. Though probably not people in SW development. And after the setup is complete, the alplication takes care of offering to pull and install its new builds inside the appserver sandbox. -- Typos courtesy of K-9 Mail on my Samsung Android From KBruene at simmonsperrine.com Mon Sep 15 15:02:17 2014 From: KBruene at simmonsperrine.com (Kyle Bruene) Date: Mon, 15 Sep 2014 15:02:17 +0000 Subject: [OmniOS-discuss] Fibre Target problems (Mark) Message-ID: <202C92988C5CF249BD3F9F21B2B199CB33D2D0F7@SPMAIL1.spae.local> Mark, Each LU in Comstar has a "writeback cache" property. Maybe you had that enabled instead? Kyle Message: 1 Date: Sun, 14 Sep 2014 21:30:50 +1200 From: Mark To: omnios-discuss at lists.omniti.com Subject: Re: [OmniOS-discuss] Fibre Target problems Message-ID: <5415604A.7030408 at gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed On 11/09/2014 9:25 p.m., OSN | Marian Fischer wrote: > Hi, > > do you have Sync=disabled in ZFS / ZPOOL settings? > If not, this can cause the slow speed ... No, but I didn't with OI either, and it has no issues achieving 400+ Mbytes/sec and doesn't have link loss issues. From doug at will.to Mon Sep 15 19:26:57 2014 From: doug at will.to (Doug Hughes) Date: Mon, 15 Sep 2014 15:26:57 -0400 Subject: [OmniOS-discuss] problems with kayak r151010 In-Reply-To: References: <1036251497.153946.1407744402126.JavaMail.zimbra@cantekstil.com.tr> <352190161.173238.1407770192701.JavaMail.zimbra@cantekstil.com.tr> <573500158.180555.1407825555010.JavaMail.zimbra@cantekstil.com.tr> Message-ID: <54173D81.6060801@will.to> I had some problems with 006 also, but these appear to be different so far. I took an omniOS 008 machine and upgraded to 010 using the standard upgrade mechanism. Totally successul. My /etc/release is updated and everything is fine. Then I made sure that the kayak and kayak-server packages were installed. So far so good. But going to /usr/share/kayak and running the gmake build has problems. The problems exist mostly in build_zfs_send.sh 1) the url listed is =http://pkg.omniti.com/omnios/release This doesn't work with OmniOS 010. It complains about the 'entire' not being a valid package to install. if I substitute r151010 on this line and the following as such, I get past this issue: OMNIOS_URL=http://pkg.omniti.com/omnios/r151010 : ${PKGURL:=http://pkg.omniti.com/omnios/r151010} : ${BZIP2:=bzip2} 2) this line appears to be wrong: pkg -R $MP install entire at 11-0.$entire_version || fail "install entire" substituting that with: pkg -R $MP install entire at 11,5.11-0.$entire_version || fail "install entire" works much better. (that's the right thing for the upgrade as well) 3) if the build fails for any reason, it leaves unclean state behind. There should be a troubleshooting step that recommends doing zfs destroy -r rpool/kayak_image 4) the r151010 kayak-server doesn't seem to include miniroot. Where do I find that now? From danmcd at omniti.com Mon Sep 15 20:00:41 2014 From: danmcd at omniti.com (Dan McDonald) Date: Mon, 15 Sep 2014 16:00:41 -0400 Subject: [OmniOS-discuss] problems with kayak r151010 In-Reply-To: <54173D81.6060801@will.to> References: <1036251497.153946.1407744402126.JavaMail.zimbra@cantekstil.com.tr> <352190161.173238.1407770192701.JavaMail.zimbra@cantekstil.com.tr> <573500158.180555.1407825555010.JavaMail.zimbra@cantekstil.com.tr> <54173D81.6060801@will.to> Message-ID: <3F175B4F-9B1D-4F69-80FC-975EDD2D576D@omniti.com> On Sep 15, 2014, at 3:26 PM, Doug Hughes wrote: > > I had some problems with 006 also, but these appear to be different so far. I took an omniOS 008 machine and upgraded to 010 using the standard upgrade mechanism. Totally successul. My /etc/release is updated and everything is fine. Then I made sure that the kayak and kayak-server packages were installed. So far so good. > > 1) the url listed is =http://pkg.omniti.com/omnios/release > This doesn't work with OmniOS 010. It complains about the 'entire' not being a valid package to install. if I substitute r151010 on this line and the following as such, I get past this issue: > OMNIOS_URL=http://pkg.omniti.com/omnios/r151010 > : ${PKGURL:=http://pkg.omniti.com/omnios/r151010} > : ${BZIP2:=bzip2} Yeah. That may be a bug in kayak itself. > 2) this line appears to be wrong: > pkg -R $MP install entire at 11-0.$entire_version || fail "install entire" > substituting that with: > pkg -R $MP install entire at 11,5.11-0.$entire_version || fail "install entire" > works much better. (that's the right thing for the upgrade as well) > > 3) if the build fails for any reason, it leaves unclean state behind. There should be a troubleshooting step that recommends doing zfs destroy -r rpool/kayak_image Hmmmm... > 4) the r151010 kayak-server doesn't seem to include miniroot. Where do I find that now? ... I'm not sure, and my Kayak knowledge has always been shaky. I'm trying to get r151012 ready, so I'll make DAMNED sure Kayak works on there, but I'm not sure how to fix the 010 version. Eric or Dale, may, however. Sorry I can't help more fully, Dan From doug at will.to Mon Sep 15 20:04:39 2014 From: doug at will.to (Doug Hughes) Date: Mon, 15 Sep 2014 16:04:39 -0400 Subject: [OmniOS-discuss] problems with kayak r151010 In-Reply-To: <3F175B4F-9B1D-4F69-80FC-975EDD2D576D@omniti.com> References: <1036251497.153946.1407744402126.JavaMail.zimbra@cantekstil.com.tr> <352190161.173238.1407770192701.JavaMail.zimbra@cantekstil.com.tr> <573500158.180555.1407825555010.JavaMail.zimbra@cantekstil.com.tr> <54173D81.6060801@will.to> <3F175B4F-9B1D-4F69-80FC-975EDD2D576D@omniti.com> Message-ID: <54174657.5030000@will.to> On 9/15/2014 4:00 PM, Dan McDonald wrote: > > On Sep 15, 2014, at 3:26 PM, Doug Hughes wrote: > >> >> I had some problems with 006 also, but these appear to be different so far. I took an omniOS 008 machine and upgraded to 010 using the standard upgrade mechanism. Totally successul. My /etc/release is updated and everything is fine. Then I made sure that the kayak and kayak-server packages were installed. So far so good. >> >> 1) the url listed is =http://pkg.omniti.com/omnios/release >> This doesn't work with OmniOS 010. It complains about the 'entire' not being a valid package to install. if I substitute r151010 on this line and the following as such, I get past this issue: >> OMNIOS_URL=http://pkg.omniti.com/omnios/r151010 >> : ${PKGURL:=http://pkg.omniti.com/omnios/r151010} >> : ${BZIP2:=bzip2} > > Yeah. That may be a bug in kayak itself. > >> 2) this line appears to be wrong: >> pkg -R $MP install entire at 11-0.$entire_version || fail "install entire" >> substituting that with: >> pkg -R $MP install entire at 11,5.11-0.$entire_version || fail "install entire" >> works much better. (that's the right thing for the upgrade as well) >> >> 3) if the build fails for any reason, it leaves unclean state behind. There should be a troubleshooting step that recommends doing zfs destroy -r rpool/kayak_image > > Hmmmm... > >> 4) the r151010 kayak-server doesn't seem to include miniroot. Where do I find that now? > > ... I'm not sure, and my Kayak knowledge has always been shaky. > > I'm trying to get r151012 ready, so I'll make DAMNED sure Kayak works on there, but I'm not sure how to fix the 010 version. Eric or Dale, may, however. > > Sorry I can't help more fully, > Dan > Thanks for the reply. If anybody has a working miniroot that they could 'lend' me. I would appreciate it. That's the only thing that's holding me up right now. I'd like to bang out a few installs this evening. From doug at will.to Tue Sep 16 00:18:37 2014 From: doug at will.to (Doug Hughes) Date: Mon, 15 Sep 2014 20:18:37 -0400 Subject: [OmniOS-discuss] problems with kayak r151010 In-Reply-To: <0c6a1f644273308246668a5f3139ddc2@blackdot.be> References: <1036251497.153946.1407744402126.JavaMail.zimbra@cantekstil.com.tr> <352190161.173238.1407770192701.JavaMail.zimbra@cantekstil.com.tr> <573500158.180555.1407825555010.JavaMail.zimbra@cantekstil.com.tr> <54173D81.6060801@will.to> <3F175B4F-9B1D-4F69-80FC-975EDD2D576D@omniti.com> <54174657.5030000@will.to> <0c6a1f644273308246668a5f3139ddc2@blackdot.be> Message-ID: <541781DD.5090705@will.to> I figured out how to build the miniroot after skulking around the utils a bit. I had to make the same edits to ./build_image.sh that I did to the build_zfs_send.sh (http://pkg.omniti.com/omnios/release => http://pkg.omniti.com/omnios/r151010) after that running gmake with tftp-install made the miniroot successfully. hope that helps somebody else. Doug From danmcd at omniti.com Tue Sep 16 00:24:55 2014 From: danmcd at omniti.com (Dan McDonald) Date: Mon, 15 Sep 2014 20:24:55 -0400 Subject: [OmniOS-discuss] problems with kayak r151010 In-Reply-To: <541781DD.5090705@will.to> References: <1036251497.153946.1407744402126.JavaMail.zimbra@cantekstil.com.tr> <352190161.173238.1407770192701.JavaMail.zimbra@cantekstil.com.tr> <573500158.180555.1407825555010.JavaMail.zimbra@cantekstil.com.tr> <54173D81.6060801@will.to> <3F175B4F-9B1D-4F69-80FC-975EDD2D576D@omniti.com> <54174657.5030000@will.to> <0c6a1f644273308246668a5f3139ddc2@blackdot.be> <541781DD.5090705@will.to> Message-ID: On Sep 15, 2014, at 8:18 PM, Doug Hughes wrote: > > I figured out how to build the miniroot after skulking around the utils a bit. > > I had to make the same edits to ./build_image.sh that I did to the build_zfs_send.sh (http://pkg.omniti.com/omnios/release => http://pkg.omniti.com/omnios/r151010) > > after that running gmake with tftp-install made the miniroot successfully. > > hope that helps somebody else. Actually... I'd fixed these in the bloody branch, and have fixed them as well in the r151012 branch. If you checkout either of those branches, you should see the mods (and a comment reminding future folks to keep 'em up to date). Thanks! Dan From danmcd at omniti.com Tue Sep 16 00:28:00 2014 From: danmcd at omniti.com (Dan McDonald) Date: Mon, 15 Sep 2014 20:28:00 -0400 Subject: [OmniOS-discuss] problems with kayak r151010 In-Reply-To: References: <1036251497.153946.1407744402126.JavaMail.zimbra@cantekstil.com.tr> <352190161.173238.1407770192701.JavaMail.zimbra@cantekstil.com.tr> <573500158.180555.1407825555010.JavaMail.zimbra@cantekstil.com.tr> <54173D81.6060801@will.to> <3F175B4F-9B1D-4F69-80FC-975EDD2D576D@omniti.com> <54174657.5030000@will.to> <0c6a1f644273308246668a5f3139ddc2@blackdot.be> <541781DD.5090705@will.to> Message-ID: On Sep 15, 2014, at 8:24 PM, Dan McDonald wrote: > > Actually... I'd fixed these in the bloody branch, and have fixed them as well in the r151012 branch. If you checkout either of those branches, you should see the mods (and a comment reminding future folks to keep 'em up to date). To be fair, I fixed them VERY RECENTLY, bloody in August, and r151012 just last week when I created that branch in the kayak repo. Sorry for not putting 2 + 2 together sooner, Dan From doug at will.to Tue Sep 16 03:46:41 2014 From: doug at will.to (Doug Hughes) Date: Mon, 15 Sep 2014 23:46:41 -0400 Subject: [OmniOS-discuss] problems with kayak r151010 In-Reply-To: References: <1036251497.153946.1407744402126.JavaMail.zimbra@cantekstil.com.tr> <352190161.173238.1407770192701.JavaMail.zimbra@cantekstil.com.tr> <573500158.180555.1407825555010.JavaMail.zimbra@cantekstil.com.tr> <54173D81.6060801@will.to> <3F175B4F-9B1D-4F69-80FC-975EDD2D576D@omniti.com> <54174657.5030000@will.to> <0c6a1f644273308246668a5f3139ddc2@blackdot.be> <541781DD.5090705@will.to> Message-ID: <5417B2A1.301@will.to> On 9/15/2014 8:28 PM, Dan McDonald wrote: > > On Sep 15, 2014, at 8:24 PM, Dan McDonald wrote: > >> >> Actually... I'd fixed these in the bloody branch, and have fixed them as well in the r151012 branch. If you checkout either of those branches, you should see the mods (and a comment reminding future folks to keep 'em up to date). > > To be fair, I fixed them VERY RECENTLY, bloody in August, and r151012 just last week when I created that branch in the kayak repo. > > Sorry for not putting 2 + 2 together sooner, > Dan > I can confirm that miniroot is available in r151012! That's good. Also the zfs build image builds cleanly. However, something appears to be wrong with either the miniroot. I'm pretty sure it's the mintroot based upon the fact that the tftp load completes successfully and then the traceback happens. after miniroot loads, I see this: Unexpected trap error code 0x0 instruction pointer 0xfffffffffb8a96b4 code segment 0x28 flags register 0x10097 return %rsp 0xc109a0 return %ss 0x8 Attempting stack backtrace: Stack traceback: Unexpected trap error code 0x0 instruction pointer 0xfffffffffb87e5de code segment 0x28 flags register 0x10046 return %rsp 0xc10808 return %ss 0x8 Attempting stack backtrace: Stack traceback: Nested trap Press any key to reboot. Has anybody seen this? (I used the miniroot from the package vs building one). I built the miniroot from the kayak build-image.sh and that one boots successfully. This miniroot, as has been the case for past miniroot, seems to be missing {/lib/,/usr/lib}/libintl* which means that the curl attempts to fetch the kayak build image and the mac address config file fail. also /usr/lib/libidn* (and /usr/lib/amd64/libidn* and /usr/lib/amd64/libintl* and /lib/amd64/libintl*) luckily, miniroot.gz is relatively easy to modify. =) From danmcd at omniti.com Tue Sep 16 04:26:45 2014 From: danmcd at omniti.com (Dan McDonald) Date: Tue, 16 Sep 2014 00:26:45 -0400 Subject: [OmniOS-discuss] problems with kayak r151010 In-Reply-To: <5417B2A1.301@will.to> References: <1036251497.153946.1407744402126.JavaMail.zimbra@cantekstil.com.tr> <352190161.173238.1407770192701.JavaMail.zimbra@cantekstil.com.tr> <573500158.180555.1407825555010.JavaMail.zimbra@cantekstil.com.tr> <54173D81.6060801@will.to> <3F175B4F-9B1D-4F69-80FC-975EDD2D576D@omniti.com> <54174657.5030000@will.to> <0c6a1f644273308246668a5f3139ddc2@blackdot.be> <541781DD.5090705@will.to> <5417B2A1.301@will.to> Message-ID: On Sep 15, 2014, at 11:46 PM, Doug Hughes wrote: > > I can confirm that miniroot is available in r151012! That's good. Also the zfs build image builds cleanly. However, something appears to be wrong with either the miniroot. I'm pretty sure it's the mintroot based upon the fact that the tftp load completes successfully and then the traceback happens. Keep in mind, the r151012 OmniOS repo is NOT OFFICIALLY OUT yet. It may go under a full update. Kayak testing is one of the things on the agenda still. You may have saved someone here some time, however. > after miniroot loads, I see this: > Unexpected trap > error code 0x0 > instruction pointer 0xfffffffffb8a96b4 > code segment 0x28 > flags register 0x10097 > return %rsp 0xc109a0 > return %ss 0x8 > Attempting stack backtrace: > Stack traceback: > Unexpected trap > error code 0x0 > instruction pointer 0xfffffffffb87e5de > code segment 0x28 > flags register 0x10046 > return %rsp 0xc10808 > return %ss 0x8 > Attempting stack backtrace: > Stack traceback: > Nested trap > Press any key to reboot. > > > Has anybody seen this? (I used the miniroot from the package vs building one). Huh... I have theories, but none of them may be easy to prove. > I built the miniroot from the kayak build-image.sh and that one boots successfully. > > This miniroot, as has been the case for past miniroot, seems to be missing {/lib/,/usr/lib}/libintl* which means that the curl attempts to fetch the kayak build image and the mac address config file fail. also /usr/lib/libidn* (and /usr/lib/amd64/libidn* and /usr/lib/amd64/libintl* and /lib/amd64/libintl*) > > luckily, miniroot.gz is relatively easy to modify. =) Thank you for this. I'll make sure I keep all of this in mind when we get to Kayak verification. Dan From esproul at omniti.com Tue Sep 16 13:58:25 2014 From: esproul at omniti.com (Eric Sproul) Date: Tue, 16 Sep 2014 09:58:25 -0400 Subject: [OmniOS-discuss] problems with kayak r151010 In-Reply-To: References: <1036251497.153946.1407744402126.JavaMail.zimbra@cantekstil.com.tr> <352190161.173238.1407770192701.JavaMail.zimbra@cantekstil.com.tr> <573500158.180555.1407825555010.JavaMail.zimbra@cantekstil.com.tr> <54173D81.6060801@will.to> <3F175B4F-9B1D-4F69-80FC-975EDD2D576D@omniti.com> <54174657.5030000@will.to> <0c6a1f644273308246668a5f3139ddc2@blackdot.be> <541781DD.5090705@will.to> <5417B2A1.301@will.to> Message-ID: On Tue, Sep 16, 2014 at 12:26 AM, Dan McDonald wrote: > > On Sep 15, 2014, at 11:46 PM, Doug Hughes wrote: >> Has anybody seen this? (I used the miniroot from the package vs building one). > > Huh... I have theories, but none of them may be easy to prove. Sounds like a kernel/userland mismatch. The miniroot and the boot kernel ("unix") must be from the same release. I've seen that happen when I accidentally mixed them. Eric From Kevin.Swab at ColoState.EDU Tue Sep 16 16:20:42 2014 From: Kevin.Swab at ColoState.EDU (Kevin Swab) Date: Tue, 16 Sep 2014 10:20:42 -0600 Subject: [OmniOS-discuss] Fibre Target problems (Mark) In-Reply-To: <202C92988C5CF249BD3F9F21B2B199CB33D2D0F7@SPMAIL1.spae.local> References: <202C92988C5CF249BD3F9F21B2B199CB33D2D0F7@SPMAIL1.spae.local> Message-ID: <5418635A.6080306@ColoState.EDU> This is a good point. Some time recently (I think with the update to r151010) writeback cache went from being _enabled_ by default to being _disabled_ by default. Maybe this change was backported to r151006_057? Does anyone know why this change was made? If it was accidental, could it be reversed in time for the r151012 release? Kevin On 09/15/2014 09:02 AM, Kyle Bruene wrote: > Mark, > > Each LU in Comstar has a "writeback cache" property. Maybe you had that enabled instead? > > Kyle > > Message: 1 > Date: Sun, 14 Sep 2014 21:30:50 +1200 > From: Mark > To: omnios-discuss at lists.omniti.com > Subject: Re: [OmniOS-discuss] Fibre Target problems > Message-ID: <5415604A.7030408 at gmail.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 11/09/2014 9:25 p.m., OSN | Marian Fischer wrote: >> Hi, >> >> do you have Sync=disabled in ZFS / ZPOOL settings? >> If not, this can cause the slow speed ... > > No, but I didn't with OI either, and it has no issues achieving 400+ Mbytes/sec and doesn't have link loss issues. > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > -- ------------------------------------------------------------------- Kevin Swab UNIX Systems Administrator ACNS Colorado State University Phone: (970)491-6572 Email: Kevin.Swab at ColoState.EDU GPG Fingerprint: 7026 3F66 A970 67BD 6F17 8EB8 8A7D 142F 2392 791C From hakansom at ohsu.edu Wed Sep 17 07:12:43 2014 From: hakansom at ohsu.edu (Marion Hakanson) Date: Wed, 17 Sep 2014 00:12:43 -0700 Subject: [OmniOS-discuss] Intel C600 driver issue Message-ID: <201409170712.s8H7ChDs015332@kyklops.ohsu.edu> Greetings, I'm trying to install OmniOS 151010u onto an Intel S2600WP motherboard, and the OmniOS live image is not finding the boot/root drive. This system is in a 4-motherboard chassis with a disk backplane on the front, and each of the 4 motherboards gets some drive slots on that backplane. In this particular case, there's a single SSD for boot/root, and while the motherboard includes two SATA controllers, the SSD is plumbed to the "difficult" one, which has two modes in the BIOS: (1) RSTe mode (default); Functions in SATA pass-through mode, according to the BIOS blurb. Windows would use the "iastor" driver. In this mode, the device describes itself (in "prtconf -Dv" or "scanpci") as: C602 chipset 4-Port SATA Storage Control Unit (2) ERST2 mode; Functions like an LSI-something SAS/SATA RAID controller. Windows/Linux would supposedly use the "megasr" driver. In this mode, the device describes itself (in "prtconf -Dv" or "scanpci") as: C600/X79 series chipset 4-Port SATA Storage Control Unit Unfortunately, OmniOS drivers do not attach to this device. I've tried some manual driver suggestions, all of which fail to attach, in either of the above two modes: update_drv -a -i '"pci8086,358f"' mpt update_drv -a -i '"pci8086,358f"' mega_sas update_drv -a -i '"pci8086,358f"' mr_sas update_drv -a -i '"pci8086,358f"' mpt_sas update_drv -a -i '"pci8086,358f"' ahci I've also tried pci8085,106b, which is a device-id alias listed in the "prtconf -Dv" output. Has anyone in OmniOS- or illumo-land gotten the OS to talk to this storage controller? Suggestions? Linux appears to use the "isci" driver for this device. Thanks and regards, Marion From danmcd at omniti.com Wed Sep 17 13:42:52 2014 From: danmcd at omniti.com (Dan McDonald) Date: Wed, 17 Sep 2014 09:42:52 -0400 Subject: [OmniOS-discuss] Intel C600 driver issue In-Reply-To: <201409170712.s8H7ChDs015332@kyklops.ohsu.edu> References: <201409170712.s8H7ChDs015332@kyklops.ohsu.edu> Message-ID: I believe the "difficult" one, as you put it, is the SCU (ahh, you even call it out in your PCI scans). Illumos has no driver for the C600 SCU, so you're out of luck. There was a prototype rumored to be floating around, but given most people ponied up for an LSI SAS HBA, which performed better, there was not a strong community push to get it up and running. Sorry I don't have better news, Dan Sent from my iPhone (typos, autocorrect, and all) > On Sep 17, 2014, at 3:12 AM, Marion Hakanson wrote: > > Greetings, > > I'm trying to install OmniOS 151010u onto an Intel S2600WP motherboard, > and the OmniOS live image is not finding the boot/root drive. This > system is in a 4-motherboard chassis with a disk backplane on the front, > and each of the 4 motherboards gets some drive slots on that backplane. > > In this particular case, there's a single SSD for boot/root, and while > the motherboard includes two SATA controllers, the SSD is plumbed to > the "difficult" one, which has two modes in the BIOS: > > (1) RSTe mode (default); Functions in SATA pass-through mode, according > to the BIOS blurb. Windows would use the "iastor" driver. In this > mode, the device describes itself (in "prtconf -Dv" or "scanpci") as: > C602 chipset 4-Port SATA Storage Control Unit > > (2) ERST2 mode; Functions like an LSI-something SAS/SATA RAID controller. > Windows/Linux would supposedly use the "megasr" driver. In this > mode, the device describes itself (in "prtconf -Dv" or "scanpci") as: > C600/X79 series chipset 4-Port SATA Storage Control Unit > > Unfortunately, OmniOS drivers do not attach to this device. I've tried > some manual driver suggestions, all of which fail to attach, in either > of the above two modes: > > update_drv -a -i '"pci8086,358f"' mpt > update_drv -a -i '"pci8086,358f"' mega_sas > update_drv -a -i '"pci8086,358f"' mr_sas > update_drv -a -i '"pci8086,358f"' mpt_sas > update_drv -a -i '"pci8086,358f"' ahci > > I've also tried pci8085,106b, which is a device-id alias listed in > the "prtconf -Dv" output. > > Has anyone in OmniOS- or illumo-land gotten the OS to talk to this > storage controller? Suggestions? Linux appears to use the "isci" > driver for this device. > > Thanks and regards, > > Marion > > > > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss From hakansom at ohsu.edu Wed Sep 17 17:58:30 2014 From: hakansom at ohsu.edu (Marion Hakanson) Date: Wed, 17 Sep 2014 10:58:30 -0700 Subject: [OmniOS-discuss] Intel C600 driver issue In-Reply-To: Message from Dan McDonald of "Wed, 17 Sep 2014 09:42:52 EDT." Message-ID: <201409171758.s8HHwU2G015786@kyklops.ohsu.edu> Hi Dan (and sjorge), Thanks for the feedback. Yep, that's the conclusion I was coming to myself. When I saw the BIOS setting for "ESRT2" mode, which claimed it was an LSI derivative, I dared to entertain a glimmer of hope for a little while (:-). We actually have an LSI SAS HBA in this system, connected to an external JBOD. Can't really justify using one of its 4TB SAS disks as a boot drive, as those are all dedicated to other tasks. The SCU can be "upgraded" with optional "RAID Upgrade Key" thingies that you plug into a socket in the motherboard. Some of them enable SAS-mode, among other things, but I suspect we'd still be stuck with something that doesn't speak to the mpt_sas, etc. drivers in illumos. There is actually an AHCI SATA controller onboard too, but the disk backplane in this 4-node chassis seems to be directly wired (via a bridge-board) to the SCU. The one exception is Port 0 on the system's AHCI SATA controller, which allegedly goes to a special "DOM" socket. The system came with an Intel DC S3700 SSD for its boot drive, regular SATA unit, and there doesn't seem to be space in this jam-packed motherboard + chassis to connect it to one of the other onboard AHCI SATA ports. Hmm, Plan B? Those DOM's aren't cheap. Would 16GB be sufficient? http://www.directron.com/d150qvlintel16.html Can dump/swap zvols be on a non-mirrored (raidz3) external pool? Failing that, Plan C: Probably we'll have to use ZFS-on-Linux. Oh, the disappointment.... Thanks and regards, Marion ========================================================================= Subject: Re: [OmniOS-discuss] Intel C600 driver issue From: Dan McDonald Date: Wed, 17 Sep 2014 09:42:52 -0400 (06:42 PDT) To: Marion Hakanson Cc: "omnios-discuss at lists.omniti.com" I believe the "difficult" one, as you put it, is the SCU (ahh, you even call it out in your PCI scans). Illumos has no driver for the C600 SCU, so you're out of luck. There was a prototype rumored to be floating around, but given most people ponied up for an LSI SAS HBA, which performed better, there was not a strong community push to get it up and running. Sorry I don't have better news, Dan Sent from my iPhone (typos, autocorrect, and all) > On Sep 17, 2014, at 3:12 AM, Marion Hakanson wrote: > > Greetings, > > I'm trying to install OmniOS 151010u onto an Intel S2600WP motherboard, > and the OmniOS live image is not finding the boot/root drive. This > system is in a 4-motherboard chassis with a disk backplane on the front, > and each of the 4 motherboards gets some drive slots on that backplane. > > In this particular case, there's a single SSD for boot/root, and while > the motherboard includes two SATA controllers, the SSD is plumbed to > the "difficult" one, which has two modes in the BIOS: > > (1) RSTe mode (default); Functions in SATA pass-through mode, according > to the BIOS blurb. Windows would use the "iastor" driver. In this > mode, the device describes itself (in "prtconf -Dv" or "scanpci") as: > C602 chipset 4-Port SATA Storage Control Unit > > (2) ERST2 mode; Functions like an LSI-something SAS/SATA RAID controller. > Windows/Linux would supposedly use the "megasr" driver. In this > mode, the device describes itself (in "prtconf -Dv" or "scanpci") as: > C600/X79 series chipset 4-Port SATA Storage Control Unit > > Unfortunately, OmniOS drivers do not attach to this device. I've tried > some manual driver suggestions, all of which fail to attach, in either > of the above two modes: > > update_drv -a -i '"pci8086,358f"' mpt > update_drv -a -i '"pci8086,358f"' mega_sas > update_drv -a -i '"pci8086,358f"' mr_sas > update_drv -a -i '"pci8086,358f"' mpt_sas > update_drv -a -i '"pci8086,358f"' ahci > > I've also tried pci8085,106b, which is a device-id alias listed in > the "prtconf -Dv" output. > > Has anyone in OmniOS- or illumo-land gotten the OS to talk to this > storage controller? Suggestions? Linux appears to use the "isci" > driver for this device. > > Thanks and regards, > > Marion > > > > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss From danmcd at omniti.com Wed Sep 17 18:09:49 2014 From: danmcd at omniti.com (Dan McDonald) Date: Wed, 17 Sep 2014 14:09:49 -0400 Subject: [OmniOS-discuss] Intel C600 driver issue In-Reply-To: <201409171758.s8HHwU2G015786@kyklops.ohsu.edu> References: <201409171758.s8HHwU2G015786@kyklops.ohsu.edu> Message-ID: On Sep 17, 2014, at 1:58 PM, Marion Hakanson wrote: > The SCU can be "upgraded" with optional "RAID Upgrade Key" thingies that > you plug into a socket in the motherboard. Some of them enable SAS-mode, > among other things, but I suspect we'd still be stuck with something that > doesn't speak to the mpt_sas, etc. drivers in illumos. That's correct. No SCU support for any of those, with or without a RAID Upgrade Key. (Unless there's some bizarro way for them to look/smell/feel like AHCI, which I doubt is the case.) > There is actually an AHCI SATA controller onboard too, but the disk > backplane in this 4-node chassis seems to be directly wired (via a > bridge-board) to the SCU. That's disappointing. I suppose this is a limitation of the form factor? > The one exception is Port 0 on the system's > AHCI SATA controller, which allegedly goes to a special "DOM" socket. > The system came with an Intel DC S3700 SSD for its boot drive, regular > SATA unit, and there doesn't seem to be space in this jam-packed > motherboard + chassis to connect it to one of the other onboard > AHCI SATA ports. Eeesh. > Hmm, Plan B? Those DOM's aren't cheap. Would 16GB be sufficient? > http://www.directron.com/d150qvlintel16.html > Can dump/swap zvols be on a non-mirrored (raidz3) external pool? 16GB can keep an rpool and some amount of subsequent BEs. You can definitely put *dump* zvols on a raidz3 pool as of r151010, thanks to this illumos fix: https://illumos.org/issues/2932 I wasn't sure about swap, but a quick query of #illumos on IRC suggests that YES, you can. So 16GB rpool + everything else on your big pool == win. Hope this helps, Dan From danmcd at omniti.com Fri Sep 19 00:40:47 2014 From: danmcd at omniti.com (Dan McDonald) Date: Thu, 18 Sep 2014 20:40:47 -0400 Subject: [OmniOS-discuss] Bloody release (r151011) has been toxic since mid/late-August Message-ID: <525A5D07-641E-4759-BAB2-CE7C8578C047@omniti.com> I've been getting r151012 ready to ship, but while doing so, I discovered some bad news that, thankfully, will not affect r151012 from a user's point of view.. unless you wished to upgrade from bloody (r151011) to r151012 or the new r151013 bloody. As of the update of CherryPy to 3.5.0 (which was subsequently ripped out of omnios-build, but lingers in the bloody repo), the http://pkg.omniti.com/omnios/bloody/ repo is toxic. If you've upgraded your bloody machine and have CherryPy 3.5.0 (pkg list -v cherrypy), your BE is toxic as well. If you have a BE where the installed CherryPy is not 3.5.0 (e.g. if you last updated on the August 9th bump), you can actually upgrade safely to r151012 or the new bloody, r151013. Otherwise, you'll have to reinstall your bloody box with r151012 or the r151013 version of bloody off a CD, USB, etc. I haven't yet gone and ripped things out of the bloody repo, but I'm planning on just replacing it with a brand new set of r151013 packages once r151012 is out the door and the r151013 ISO & USB get burned. Sorry if this causes you any inconvenience, but since it is the bloody repo, sometimes things will get messy. Thanks, Dan From jeffpc at josefsipek.net Fri Sep 19 00:58:52 2014 From: jeffpc at josefsipek.net (Josef 'Jeff' Sipek) Date: Thu, 18 Sep 2014 20:58:52 -0400 Subject: [OmniOS-discuss] Bloody release (r151011) has been toxic since mid/late-August In-Reply-To: <525A5D07-641E-4759-BAB2-CE7C8578C047@omniti.com> References: <525A5D07-641E-4759-BAB2-CE7C8578C047@omniti.com> Message-ID: <20140919005852.GG1320@meili> On Thu, Sep 18, 2014 at 08:40:47PM -0400, Dan McDonald wrote: > I've been getting r151012 ready to ship, but while doing so, I discovered > some bad news that, thankfully, will not affect r151012 from a user's > point of view.. unless you wished to upgrade from bloody (r151011) to > r151012 or the new r151013 bloody. > > As of the update of CherryPy to 3.5.0 (which was subsequently ripped out > of omnios-build, but lingers in the bloody repo), the > http://pkg.omniti.com/omnios/bloody/ repo is toxic. If you've upgraded > your bloody machine and have CherryPy 3.5.0 (pkg list -v cherrypy), your > BE is toxic as well. > > If you have a BE where the installed CherryPy is not 3.5.0 (e.g. if you > last updated on the August 9th bump), you can actually upgrade safely to > r151012 or the new bloody, r151013. Otherwise, you'll have to reinstall > your bloody box with r151012 or the r151013 version of bloody off a CD, > USB, etc. Uninstalling it isn't an option? Jeff (not affected, but curious). -- The obvious mathematical breakthrough would be development of an easy way to factor large prime numbers. - Bill Gates, The Road Ahead, pg. 265 From danmcd at omniti.com Fri Sep 19 02:44:53 2014 From: danmcd at omniti.com (Dan McDonald) Date: Thu, 18 Sep 2014 22:44:53 -0400 Subject: [OmniOS-discuss] Bloody release (r151011) has been toxic since mid/late-August In-Reply-To: <20140919005852.GG1320@meili> References: <525A5D07-641E-4759-BAB2-CE7C8578C047@omniti.com> <20140919005852.GG1320@meili> Message-ID: <245CED70-4CF1-408C-A336-C5D95BDE2058@omniti.com> On Sep 18, 2014, at 8:58 PM, Josef 'Jeff' Sipek wrote: > On Thu, Sep 18, 2014 at 08:40:47PM -0400, Dan McDonald wrote: >> I've been getting r151012 ready to ship, but while doing so, I discovered >> some bad news that, thankfully, will not affect r151012 from a user's >> point of view.. unless you wished to upgrade from bloody (r151011) to >> r151012 or the new r151013 bloody. >> >> As of the update of CherryPy to 3.5.0 (which was subsequently ripped out >> of omnios-build, but lingers in the bloody repo), the >> http://pkg.omniti.com/omnios/bloody/ repo is toxic. If you've upgraded >> your bloody machine and have CherryPy 3.5.0 (pkg list -v cherrypy), your >> BE is toxic as well. >> >> If you have a BE where the installed CherryPy is not 3.5.0 (e.g. if you >> last updated on the August 9th bump), you can actually upgrade safely to >> r151012 or the new bloody, r151013. Otherwise, you'll have to reinstall >> your bloody box with r151012 or the r151013 version of bloody off a CD, >> USB, etc. > > Uninstalling it isn't an option? It's a rat's nest of dependencies, since pkg.depotd depends on CherryPy directly (and its requirement of a specific version or earlier is how I discovered the mess in the first place). Godawful, trust me. Old BEs before the CherryPy update are your best bet. Dan From cks at cs.toronto.edu Fri Sep 19 06:03:54 2014 From: cks at cs.toronto.edu (Chris Siebenmann) Date: Fri, 19 Sep 2014 02:03:54 -0400 Subject: [OmniOS-discuss] Tips on diagnosing an OmniOS lockup? Message-ID: <20140919060354.6F8F75A019C@testapps.cs.toronto.edu> We have a situation where one of our OmniOS NFS fileservers (running r151010 although not current on updates) is hanging/locking up mysteriously (other identical servers run fine). No messages are logged either to the console or to syslog and the machine becomes almost totally unresponsive; at best it pings, but input on the console is ignored and network services (including NFS) no longer respond. Beyond 'use mdb -K so we can capture a crash dump the next time this happens', do people have any suggestions for diagnosing the cause here? Thanks in advance. - cks PS: if people want to know the hardware and setup details, this and its links are a description of the systems: http://utcc.utoronto.ca/~cks/space/blog/solaris/ZFSFileserverSetupII The fileserver systems are not currently using the LSI SAS ports for anything so I believe we should be unaffected by any OmniOS issues there. From matthew.lagoe at subrigo.net Fri Sep 19 07:13:49 2014 From: matthew.lagoe at subrigo.net (Matthew Lagoe) Date: Fri, 19 Sep 2014 00:13:49 -0700 Subject: [OmniOS-discuss] Tips on diagnosing an OmniOS lockup? In-Reply-To: <20140919060354.6F8F75A019C@testapps.cs.toronto.edu> References: <20140919060354.6F8F75A019C@testapps.cs.toronto.edu> Message-ID: <000701cfd3d9$4537c300$cfa74900$@subrigo.net> I would run memtest on the system I have had similar issues in the past with bad ram/cpu/mobo Doesn't sound like a OS issue tbh -----Original Message----- From: OmniOS-discuss [mailto:omnios-discuss-bounces at lists.omniti.com] On Behalf Of Chris Siebenmann Sent: Thursday, September 18, 2014 11:04 PM To: omnios-discuss at lists.omniti.com Subject: [OmniOS-discuss] Tips on diagnosing an OmniOS lockup? We have a situation where one of our OmniOS NFS fileservers (running r151010 although not current on updates) is hanging/locking up mysteriously (other identical servers run fine). No messages are logged either to the console or to syslog and the machine becomes almost totally unresponsive; at best it pings, but input on the console is ignored and network services (including NFS) no longer respond. Beyond 'use mdb -K so we can capture a crash dump the next time this happens', do people have any suggestions for diagnosing the cause here? Thanks in advance. - cks PS: if people want to know the hardware and setup details, this and its links are a description of the systems: http://utcc.utoronto.ca/~cks/space/blog/solaris/ZFSFileserverSetupII The fileserver systems are not currently using the LSI SAS ports for anything so I believe we should be unaffected by any OmniOS issues there. _______________________________________________ OmniOS-discuss mailing list OmniOS-discuss at lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss From fabio at fabiorabelo.wiki.br Fri Sep 19 11:37:24 2014 From: fabio at fabiorabelo.wiki.br (=?UTF-8?Q?F=C3=A1bio_Rabelo?=) Date: Fri, 19 Sep 2014 08:37:24 -0300 Subject: [OmniOS-discuss] Tips on diagnosing an OmniOS lockup? In-Reply-To: <000701cfd3d9$4537c300$cfa74900$@subrigo.net> References: <20140919060354.6F8F75A019C@testapps.cs.toronto.edu> <000701cfd3d9$4537c300$cfa74900$@subrigo.net> Message-ID: +1 here . I had a similar issue, Supermicro Motherboard, originally with Kingston Memory, changed memory to Nanya, and this system are running smoothly for more than 8 mounts . F?bio Rabelo 2014-09-19 4:13 GMT-03:00 Matthew Lagoe : > I would run memtest on the system I have had similar issues in the past with > bad ram/cpu/mobo > > Doesn't sound like a OS issue tbh > > -----Original Message----- > From: OmniOS-discuss [mailto:omnios-discuss-bounces at lists.omniti.com] On > Behalf Of Chris Siebenmann > Sent: Thursday, September 18, 2014 11:04 PM > To: omnios-discuss at lists.omniti.com > Subject: [OmniOS-discuss] Tips on diagnosing an OmniOS lockup? > > We have a situation where one of our OmniOS NFS fileservers (running > r151010 although not current on updates) is hanging/locking up mysteriously > (other identical servers run fine). No messages are logged either to the > console or to syslog and the machine becomes almost totally unresponsive; at > best it pings, but input on the console is ignored and network services > (including NFS) no longer respond. > > Beyond 'use mdb -K so we can capture a crash dump the next time this > happens', do people have any suggestions for diagnosing the cause here? > > Thanks in advance. > > - cks > PS: if people want to know the hardware and setup details, this and > its links are a description of the systems: > http://utcc.utoronto.ca/~cks/space/blog/solaris/ZFSFileserverSetupII > The fileserver systems are not currently using the LSI SAS ports for > anything so I believe we should be unaffected by any OmniOS issues > there. > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss From fabio at fabiorabelo.wiki.br Fri Sep 19 11:41:48 2014 From: fabio at fabiorabelo.wiki.br (=?UTF-8?Q?F=C3=A1bio_Rabelo?=) Date: Fri, 19 Sep 2014 08:41:48 -0300 Subject: [OmniOS-discuss] Fwd: Tips on diagnosing an OmniOS lockup? In-Reply-To: References: <20140919060354.6F8F75A019C@testapps.cs.toronto.edu> <000701cfd3d9$4537c300$cfa74900$@subrigo.net> Message-ID: +1 here . I had a similar issue, Supermicro Motherboard, originally with Kingston Memory, changed memory to Nanya, and this system are running smoothly for more than 8 mounts . F?bio Rabelo Sorry, I forgot to mention, memtest did not show any error with Kingston memory, but after the change to nanya, the lockups completely stops ! F?bio Rabelo 2014-09-19 4:13 GMT-03:00 Matthew Lagoe : > I would run memtest on the system I have had similar issues in the past with > bad ram/cpu/mobo > > Doesn't sound like a OS issue tbh > > -----Original Message----- > From: OmniOS-discuss [mailto:omnios-discuss-bounces at lists.omniti.com] On > Behalf Of Chris Siebenmann > Sent: Thursday, September 18, 2014 11:04 PM > To: omnios-discuss at lists.omniti.com > Subject: [OmniOS-discuss] Tips on diagnosing an OmniOS lockup? > > We have a situation where one of our OmniOS NFS fileservers (running > r151010 although not current on updates) is hanging/locking up mysteriously > (other identical servers run fine). No messages are logged either to the > console or to syslog and the machine becomes almost totally unresponsive; at > best it pings, but input on the console is ignored and network services > (including NFS) no longer respond. > > Beyond 'use mdb -K so we can capture a crash dump the next time this > happens', do people have any suggestions for diagnosing the cause here? > > Thanks in advance. > > - cks > PS: if people want to know the hardware and setup details, this and > its links are a description of the systems: > http://utcc.utoronto.ca/~cks/space/blog/solaris/ZFSFileserverSetupII > The fileserver systems are not currently using the LSI SAS ports for > anything so I believe we should be unaffected by any OmniOS issues > there. > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss From doug at will.to Fri Sep 19 15:44:38 2014 From: doug at will.to (Doug Hughes) Date: Fri, 19 Sep 2014 11:44:38 -0400 Subject: [OmniOS-discuss] SolarFlare SFXGE with OmniOS Message-ID: Is anybody using Solarflare 10G cards with OmniOS. I have a 2010 vintage of Openindiana (yeah, I should really upgrade that - it's a test box) running with the Sol10 production sfxge driver and working flawlessly for years. It tried the sfxge package for Sol11 and for Sol10 on OmniOS r151012 (yeah, I know it's not quite ready) and it crashes and core dumps as soon as I send any traffic on the nic, even a ping. Curious if anybody else is using them and having luck? -------------- next part -------------- An HTML attachment was scrubbed... URL: From danmcd at omniti.com Fri Sep 19 17:13:51 2014 From: danmcd at omniti.com (Dan McDonald) Date: Fri, 19 Sep 2014 13:13:51 -0400 Subject: [OmniOS-discuss] SolarFlare SFXGE with OmniOS In-Reply-To: References: Message-ID: <923F799C-ED2F-4F79-950F-5256C2C6A60F@omniti.com> On Sep 19, 2014, at 11:44 AM, Doug Hughes wrote: > Is anybody using Solarflare 10G cards with OmniOS. I have a 2010 vintage of Openindiana (yeah, I should really upgrade that - it's a test box) running with the Sol10 production sfxge driver and working flawlessly for years. It tried the sfxge package for Sol11 and for Sol10 on OmniOS r151012 (yeah, I know it's not quite ready) and it crashes and core dumps as soon as I send any traffic on the nic, even a ping. > > Curious if anybody else is using them and having luck? Without source you'll be out of luck. The Generic Lan Driver (GLDv3) interface is *slightly* different on recent-vintage illumos. A modern OI (like hipster) would likely exhibit the same problems. If you want Solarflare cards, you'll need to get them to cough up the source. Dan From danmcd at omniti.com Fri Sep 19 20:57:02 2014 From: danmcd at omniti.com (Dan McDonald) Date: Fri, 19 Sep 2014 16:57:02 -0400 Subject: [OmniOS-discuss] Bloody release (r151011) has been toxic since mid/late-August In-Reply-To: <541C936D.3030903@netbsd.org> References: <525A5D07-641E-4759-BAB2-CE7C8578C047@omniti.com> <20140919005852.GG1320@meili> <245CED70-4CF1-408C-A336-C5D95BDE2058@omniti.com> <541C936D.3030903@netbsd.org> Message-ID: <47C60499-D5F0-4140-A54A-16597C761F29@omniti.com> Yeah, you'll have to start from your previous BE to get to 012 or 013. You can use beadm(1M) to clone a new BE from the old one, then use pkg -R. Eg. beadm create -e oldbe newbe beadm mount newbe /mnt pkg -R /mnt set-publisher.... pkg -R /mnt update The only gotcha is any data from your current BE SHOULD be migrated to "newbe". Dan Sent from my iPhone (typos, autocorrect, and all) > On Sep 19, 2014, at 4:34 PM, Richard PALO wrote: > > > > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Le 19/09/14 04:44, Dan McDonald a ?crit : >> >> On Sep 18, 2014, at 8:58 PM, Josef 'Jeff' Sipek >> wrote: >> >>>> On Thu, Sep 18, 2014 at 08:40:47PM -0400, Dan McDonald wrote: >>>> I've been getting r151012 ready to ship, but while doing so, I >>>> discovered some bad news that, thankfully, will not affect >>>> r151012 from a user's point of view.. unless you wished to >>>> upgrade from bloody (r151011) to r151012 or the new r151013 >>>> bloody. >>>> >>>> As of the update of CherryPy to 3.5.0 (which was subsequently >>>> ripped out of omnios-build, but lingers in the bloody repo), >>>> the http://pkg.omniti.com/omnios/bloody/ repo is toxic. If >>>> you've upgraded your bloody machine and have CherryPy 3.5.0 >>>> (pkg list -v cherrypy), your BE is toxic as well. >>>> >>>> If you have a BE where the installed CherryPy is not 3.5.0 >>>> (e.g. if you last updated on the August 9th bump), you can >>>> actually upgrade safely to r151012 or the new bloody, r151013. >>>> Otherwise, you'll have to reinstall your bloody box with >>>> r151012 or the r151013 version of bloody off a CD, USB, etc. >>> >>> Uninstalling it isn't an option? >> >> It's a rat's nest of dependencies, since pkg.depotd depends on >> CherryPy directly (and its requirement of a specific version or >> earlier is how I discovered the mess in the first place). >> Godawful, trust me. >> >> Old BEs before the CherryPy update are your best bet. >> >> Dan >> > Dan, if I understand correctly... if my current BE has: >> pkg://omnios/library/python-2/cherrypy at 3.5.0,5.11-0.151011:20140902T192935Z > > but >> > a previous BE >> pkg://omnios/library/python-2/cherrypy at 3.2.2,5.11-0.151011:20140723T191919Z > > the >> > only recourse is to boot the previous BE and upgrade to lastest. > No other way? > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQEcBAEBAgAGBQJUHJNtAAoJECAB22fHtp27wckH/ikDZ1ioqNC9AToEf3Ex2fhS > 1I9JNRUcWtYyraw7hKxIDBqPxFnDa64GiiMESAWOd23lV7/UbtNc6miX9Q+5Ob7R > pLo5QBx2oU+kijCq6bshktgbvbTUpaHT2R3budnwZDFZ6retuiH4GCR3qR1gxl9q > wuMQ8+5X5OQ+zNdf5+dYAzpcZzsK000ji686btS02nwjRJTFRwgRNRWNR4ZPVgS8 > aKw1rdAEh/7M7wvR5jnfSuxvng0GxfxqHGhDbvb2C/jDdDZKft7Cxwf6dsiYuE6k > OnuSWP3pJOnsmOlq4h8IYKlUBwfpaJDR4/pHni8MvDkDbplvb6AQhGOhQkG3Qks= > =sG4A > -----END PGP SIGNATURE----- > > From info at houseofancients.nl Fri Sep 19 23:04:51 2014 From: info at houseofancients.nl (Floris van Essen ..:: House of Ancients Amstafs ::..) Date: Fri, 19 Sep 2014 23:04:51 +0000 Subject: [OmniOS-discuss] Bloody release (r151011) has been toxic since mid/late-August In-Reply-To: <47C60499-D5F0-4140-A54A-16597C761F29@omniti.com> References: <525A5D07-641E-4759-BAB2-CE7C8578C047@omniti.com> <20140919005852.GG1320@meili> <245CED70-4CF1-408C-A336-C5D95BDE2058@omniti.com> <541C936D.3030903@netbsd.org> <47C60499-D5F0-4140-A54A-16597C761F29@omniti.com> Message-ID: <356582D1FC91784992ABB4265A16ED4856F43CDE@vEX01.mindstorm-internet.local> Hi Dan, Would you expect that this will be fixed at a later stage ? So far Bloody r151011 has been running "bloody well" :-) for me , and I surely don't feel like downgrading a perfectly running system, with all risks that come with it. Stupid me even updated a production system from r151010 to r151011, expecting the r151012 release soon, because in tests it had fixed some lockups on both my 2 test systems as on my production system. You see my dilemma :-), so I do hope this is fixable or there is a work around somewhere Regards, Floris -----Oorspronkelijk bericht----- Van: OmniOS-discuss [mailto:omnios-discuss-bounces at lists.omniti.com] Namens Dan McDonald Verzonden: vrijdag 19 september 2014 22:57 Aan: Richard PALO CC: omnios-discuss Onderwerp: Re: [OmniOS-discuss] Bloody release (r151011) has been toxic since mid/late-August Yeah, you'll have to start from your previous BE to get to 012 or 013. You can use beadm(1M) to clone a new BE from the old one, then use pkg -R. Eg. beadm create -e oldbe newbe beadm mount newbe /mnt pkg -R /mnt set-publisher.... pkg -R /mnt update The only gotcha is any data from your current BE SHOULD be migrated to "newbe". Dan Sent from my iPhone (typos, autocorrect, and all) > On Sep 19, 2014, at 4:34 PM, Richard PALO wrote: > > > > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Le 19/09/14 04:44, Dan McDonald a ?crit : >> >> On Sep 18, 2014, at 8:58 PM, Josef 'Jeff' Sipek >> wrote: >> >>>> On Thu, Sep 18, 2014 at 08:40:47PM -0400, Dan McDonald wrote: >>>> I've been getting r151012 ready to ship, but while doing so, I >>>> discovered some bad news that, thankfully, will not affect >>>> r151012 from a user's point of view.. unless you wished to upgrade >>>> from bloody (r151011) to r151012 or the new r151013 bloody. >>>> >>>> As of the update of CherryPy to 3.5.0 (which was subsequently >>>> ripped out of omnios-build, but lingers in the bloody repo), the >>>> http://pkg.omniti.com/omnios/bloody/ repo is toxic. If you've >>>> upgraded your bloody machine and have CherryPy 3.5.0 (pkg list -v >>>> cherrypy), your BE is toxic as well. >>>> >>>> If you have a BE where the installed CherryPy is not 3.5.0 (e.g. if >>>> you last updated on the August 9th bump), you can actually upgrade >>>> safely to r151012 or the new bloody, r151013. >>>> Otherwise, you'll have to reinstall your bloody box with >>>> r151012 or the r151013 version of bloody off a CD, USB, etc. >>> >>> Uninstalling it isn't an option? >> >> It's a rat's nest of dependencies, since pkg.depotd depends on >> CherryPy directly (and its requirement of a specific version or >> earlier is how I discovered the mess in the first place). >> Godawful, trust me. >> >> Old BEs before the CherryPy update are your best bet. >> >> Dan >> > Dan, if I understand correctly... if my current BE has: >> pkg://omnios/library/python-2/cherrypy at 3.5.0,5.11-0.151011:20140902T1 >> 92935Z > > but >> > a previous BE >> pkg://omnios/library/python-2/cherrypy at 3.2.2,5.11-0.151011:20140723T1 >> 91919Z > > the >> > only recourse is to boot the previous BE and upgrade to lastest. > No other way? > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQEcBAEBAgAGBQJUHJNtAAoJECAB22fHtp27wckH/ikDZ1ioqNC9AToEf3Ex2fhS > 1I9JNRUcWtYyraw7hKxIDBqPxFnDa64GiiMESAWOd23lV7/UbtNc6miX9Q+5Ob7R > pLo5QBx2oU+kijCq6bshktgbvbTUpaHT2R3budnwZDFZ6retuiH4GCR3qR1gxl9q > wuMQ8+5X5OQ+zNdf5+dYAzpcZzsK000ji686btS02nwjRJTFRwgRNRWNR4ZPVgS8 > aKw1rdAEh/7M7wvR5jnfSuxvng0GxfxqHGhDbvb2C/jDdDZKft7Cxwf6dsiYuE6k > OnuSWP3pJOnsmOlq4h8IYKlUBwfpaJDR4/pHni8MvDkDbplvb6AQhGOhQkG3Qks= > =sG4A > -----END PGP SIGNATURE----- > > _______________________________________________ OmniOS-discuss mailing list OmniOS-discuss at lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss ###################################################################### Attentie: De informatie verzonden met dit E-mail bericht is uitsluitend bestemd voor de geadresseerde. Gebruik van deze informatie door anderen dan de geadresseerde is verboden. Openbaarmaking, vermenigvuldiging, verspreiding en/of verstrekking van deze informatie aan derden is niet toegestaan. House of Ancients staat niet in voor de juiste en volledige overbrenging van de inhoud van een verzonden E-mail, noch voor een tijdig ontvangst daarvan. Attention: This e-mail message is privileged and confidential. If you are not the intended recipient please delete the message and notify the sender. Any views or opinions presented are solely those of the author. ###################################################################### From mark0x01 at gmail.com Fri Sep 19 23:14:20 2014 From: mark0x01 at gmail.com (Mark) Date: Sat, 20 Sep 2014 11:14:20 +1200 Subject: [OmniOS-discuss] SolarFlare SFXGE with OmniOS In-Reply-To: <923F799C-ED2F-4F79-950F-5256C2C6A60F@omniti.com> References: <923F799C-ED2F-4F79-950F-5256C2C6A60F@omniti.com> Message-ID: <541CB8CC.3020706@gmail.com> On 20/09/2014 5:13 a.m., Dan McDonald wrote: > > On Sep 19, 2014, at 11:44 AM, Doug Hughes wrote: > >> Is anybody using Solarflare 10G cards with OmniOS. I have a 2010 vintage of Openindiana (yeah, I should really upgrade that - it's a test box) running with the Sol10 production sfxge driver and working flawlessly for years. It tried the sfxge package for Sol11 and for Sol10 on OmniOS r151012 (yeah, I know it's not quite ready) and it crashes and core dumps as soon as I send any traffic on the nic, even a ping. >> >> Curious if anybody else is using them and having luck? > > Without source you'll be out of luck. > > The Generic Lan Driver (GLDv3) interface is *slightly* different on recent-vintage illumos. A modern OI (like hipster) would likely exhibit the same problems. If you want Solarflare cards, you'll need to get them to cough up the source. > > Dan > See https://www.illumos.org/issues/4057 > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > From mark0x01 at gmail.com Fri Sep 19 23:23:12 2014 From: mark0x01 at gmail.com (Mark) Date: Sat, 20 Sep 2014 11:23:12 +1200 Subject: [OmniOS-discuss] SolarFlare SFXGE with OmniOS In-Reply-To: <923F799C-ED2F-4F79-950F-5256C2C6A60F@omniti.com> References: <923F799C-ED2F-4F79-950F-5256C2C6A60F@omniti.com> Message-ID: <541CBAE0.2030405@gmail.com> On 20/09/2014 5:13 a.m., Dan McDonald wrote: > > On Sep 19, 2014, at 11:44 AM, Doug Hughes wrote: > >> Is anybody using Solarflare 10G cards with OmniOS. I have a 2010 vintage of Openindiana (yeah, I should really upgrade that - it's a test box) running with the Sol10 production sfxge driver and working flawlessly for years. It tried the sfxge package for Sol11 and for Sol10 on OmniOS r151012 (yeah, I know it's not quite ready) and it crashes and core dumps as soon as I send any traffic on the nic, even a ping. >> >> Curious if anybody else is using them and having luck? > > Without source you'll be out of luck. Source at http://cr.illumos.org/~webrev/rincebrain/illumos-sfxge/ > > The Generic Lan Driver (GLDv3) interface is *slightly* different on recent-vintage illumos. A modern OI (like hipster) would likely exhibit the same problems. If you want Solarflare cards, you'll need to get them to cough up the source. > > Dan > > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > From skiselkov.ml at gmail.com Fri Sep 19 23:27:50 2014 From: skiselkov.ml at gmail.com (Saso Kiselkov) Date: Sat, 20 Sep 2014 01:27:50 +0200 Subject: [OmniOS-discuss] SolarFlare SFXGE with OmniOS In-Reply-To: <541CB8CC.3020706@gmail.com> References: <923F799C-ED2F-4F79-950F-5256C2C6A60F@omniti.com> <541CB8CC.3020706@gmail.com> Message-ID: <541CBBF6.9070702@gmail.com> On 9/20/14, 1:14 AM, Mark wrote: > On 20/09/2014 5:13 a.m., Dan McDonald wrote: >> >> On Sep 19, 2014, at 11:44 AM, Doug Hughes wrote: >> >>> Is anybody using Solarflare 10G cards with OmniOS. I have a 2010 >>> vintage of Openindiana (yeah, I should really upgrade that - it's a >>> test box) running with the Sol10 production sfxge driver and working >>> flawlessly for years. It tried the sfxge package for Sol11 and for >>> Sol10 on OmniOS r151012 (yeah, I know it's not quite ready) and it >>> crashes and core dumps as soon as I send any traffic on the nic, even >>> a ping. >>> >>> Curious if anybody else is using them and having luck? >> >> Without source you'll be out of luck. >> >> The Generic Lan Driver (GLDv3) interface is *slightly* different on >> recent-vintage illumos. A modern OI (like hipster) would likely >> exhibit the same problems. If you want Solarflare cards, you'll need >> to get them to cough up the source. >> >> Dan >> > See https://www.illumos.org/issues/4057 Appears to have stalled despite an offer of help from Robert. Maybe it wasn't production ready? Does anybody know if Rich published the source? Maybe I can get it built so people with sfxge hardware can get testing. Cheers, -- Saso From skiselkov.ml at gmail.com Sat Sep 20 01:03:15 2014 From: skiselkov.ml at gmail.com (Saso Kiselkov) Date: Sat, 20 Sep 2014 03:03:15 +0200 Subject: [OmniOS-discuss] SolarFlare SFXGE with OmniOS In-Reply-To: <541CBAE0.2030405@gmail.com> References: <923F799C-ED2F-4F79-950F-5256C2C6A60F@omniti.com> <541CBAE0.2030405@gmail.com> Message-ID: <541CD253.9060205@gmail.com> On 9/20/14, 1:23 AM, Mark wrote: > On 20/09/2014 5:13 a.m., Dan McDonald wrote: >> >> On Sep 19, 2014, at 11:44 AM, Doug Hughes wrote: >> >>> Is anybody using Solarflare 10G cards with OmniOS. I have a 2010 >>> vintage of Openindiana (yeah, I should really upgrade that - it's a >>> test box) running with the Sol10 production sfxge driver and working >>> flawlessly for years. It tried the sfxge package for Sol11 and for >>> Sol10 on OmniOS r151012 (yeah, I know it's not quite ready) and it >>> crashes and core dumps as soon as I send any traffic on the nic, even >>> a ping. >>> >>> Curious if anybody else is using them and having luck? >> >> Without source you'll be out of luck. > > > Source at http://cr.illumos.org/~webrev/rincebrain/illumos-sfxge/ > Ok, got it to build cleanly, code at: https://github.com/skiselkov/illumos-gate/tree/sfxge Unique commits in that branch: 1c3fe595 - initial commit of the sfxge pretty much as-is from the webrev (plus a few formatting fixes to get git to shut up about trailing whitespace) efb39dd8 - build & lint cleaning to get it to build with our gcc, plus one bugfix noted below I'm not going to bother with cstyle fixes for foreign code, there's 1200 offending lines and it would jeopardize upstream-mergeability anyway. Willing testers with sfxge hardware who don't wanna muck around with manual building can grab a pre-built version at: http://37.153.99.61/sfxge.tar.gz. To install & use, do: # tar xzf sfxge.tar.gz # beadm create sfxge_test # beadm mount sfxge_test Mounted successfully on: '' # cp -r sfxge/sfxge.conf sfxge/debug/* /kernel/drv # bootadm update-archive -R # reboot -fe sfxge_test And take her out for a good spin. If testing proves this card to work well, I can post a code review & RTI. ============== Lint found one potential bug (which I've fixed) that might be worth reporting back to Solarflare: sfxge_gld_v3.c:680: contains a line like this: if ((rc = sfxge_ev_moderation_set(sp, (unsigned int) val) != 0)) The double brace at the end is incorrect, "rc" will get assigned the result of the "sfxge_ev_moderation_set() != 0" comparison. I'm fairly confident this is not what the author intended. Cheers, -- Saso From danmcd at omniti.com Sat Sep 20 01:13:55 2014 From: danmcd at omniti.com (Dan McDonald) Date: Fri, 19 Sep 2014 21:13:55 -0400 Subject: [OmniOS-discuss] Bloody release (r151011) has been toxic since mid/late-August In-Reply-To: <356582D1FC91784992ABB4265A16ED4856F43CDE@vEX01.mindstorm-internet.local> References: <525A5D07-641E-4759-BAB2-CE7C8578C047@omniti.com> <20140919005852.GG1320@meili> <245CED70-4CF1-408C-A336-C5D95BDE2058@omniti.com> <541C936D.3030903@netbsd.org> <47C60499-D5F0-4140-A54A-16597C761F29@omniti.com> <356582D1FC91784992ABB4265A16ED4856F43CDE@vEX01.mindstorm-internet.local> Message-ID: On Sep 19, 2014, at 7:04 PM, Floris van Essen ..:: House of Ancients Amstafs ::.. wrote: > Hi Dan, > > Would you expect that this will be fixed at a later stage ? > So far Bloody r151011 has been running "bloody well" :-) for me , and I surely don't feel like downgrading a perfectly running system, with all risks that come with it. > Stupid me even updated a production system from r151010 to r151011, expecting the r151012 release soon, because in tests it had fixed some lockups on both my 2 test systems as on my production system. > > You see my dilemma :-), so I do hope this is fixable or there is a work around somewhere CherryPy is locked in to so much of pkg(5) that I have no idea how to back it out. You can't just uninstall CherryPy without backing out everything. If you have an early-August BE, clone it and update it, then move over any configuration that changed between then and now. Sorry, Dan p.s. We never make promises with bloody, to cover situations just like this. I'd rather this then find out the hard way during the release of 012. From doug at will.to Sat Sep 20 01:21:16 2014 From: doug at will.to (Doug Hughes) Date: Fri, 19 Sep 2014 21:21:16 -0400 Subject: [OmniOS-discuss] SolarFlare SFXGE with OmniOS In-Reply-To: <541CD253.9060205@gmail.com> References: <923F799C-ED2F-4F79-950F-5256C2C6A60F@omniti.com> <541CBAE0.2030405@gmail.com> <541CD253.9060205@gmail.com> Message-ID: <541CD68C.9010101@will.to> On 9/19/2014 9:03 PM, Saso Kiselkov wrote: > > Ok, got it to build cleanly, code at: > > https://github.com/skiselkov/illumos-gate/tree/sfxge > > Unique commits in that branch: > > 1c3fe595 - initial commit of the sfxge pretty much as-is from the webrev > (plus a few formatting fixes to get git to shut up about > trailing whitespace) > > efb39dd8 - build & lint cleaning to get it to build with our gcc, plus > one bugfix noted below > > I'm not going to bother with cstyle fixes for foreign code, there's 1200 > offending lines and it would jeopardize upstream-mergeability anyway. > > Willing testers with sfxge hardware who don't wanna muck around with > manual building can grab a pre-built version at: > http://37.153.99.61/sfxge.tar.gz. To install & use, do: > > # tar xzf sfxge.tar.gz > # beadm create sfxge_test > # beadm mount sfxge_test > Mounted successfully on: '' > # cp -r sfxge/sfxge.conf sfxge/debug/* /kernel/drv > # bootadm update-archive -R > # reboot -fe sfxge_test > > And take her out for a good spin. If testing proves this card to work > well, I can post a code review & RTI. > That's awesome. Thanks! From dmkhacherian at csupomona.edu Sat Sep 20 02:25:47 2014 From: dmkhacherian at csupomona.edu (David Khacherian) Date: Fri, 19 Sep 2014 19:25:47 -0700 Subject: [OmniOS-discuss] Panic when starting installer as KVM guest Message-ID: <541CE5AB.7000106@csupomona.edu> I've been trying to get the OmniOS installer working under kvm with qemu, and I'm always presented with the same kernel panic at the same place after the Oracle copyright notice, after which the installer restarts itself: *SunOS Release 5.11 Version omnios-b281e50 64-bit Copyright (c) 1983, 2010, Oracle and/or its affiliates. All rights reserved. panic[cpu0]/thread=fffffffffbc2fac0* I've tried both the LTS and current stable installers, and they give the same results. I've tried disabling ACPI and HPET, varying the amount of RAM and VCPUs, etc..., to no avail. Here's the exact line I'm using to invoke qemu: *qemu-system-x86_64 -enable-kvm -vga std -m 2048 -cdrom OmniOS_Text_r151010u.iso -boot order=d omnios.img* Output of 'qemu -version': *QEMU emulator version 2.1.0, Copyright (c) 2003-2008 Fabrice Bellard *And if it helps, the KVM host is Gentoo, with a hardened 3.15.8 kernel. The use-flags I used when building qemu can be found here: http://pastebin.com/hDTUgU4r Omitting "-enable-kvm" lets the virtual machine run as expected, albeit at a crawl. I suspect that there may be a bug at work here, and I'd greatly appreciate any suggestions on how to proceed. Thanks for your time. -------------- next part -------------- An HTML attachment was scrubbed... URL: From danmcd at omniti.com Sat Sep 20 02:51:46 2014 From: danmcd at omniti.com (Dan McDonald) Date: Fri, 19 Sep 2014 22:51:46 -0400 Subject: [OmniOS-discuss] Panic when starting installer as KVM guest In-Reply-To: <541CE5AB.7000106@csupomona.edu> References: <541CE5AB.7000106@csupomona.edu> Message-ID: On Sep 19, 2014, at 10:25 PM, David Khacherian wrote: > I've been trying to get the OmniOS installer working under kvm with qemu, and I'm always presented with the same kernel panic at the same place after the Oracle copyright notice, after which the installer restarts itself: > > SunOS Release 5.11 Version omnios-b281e50 64-bit > Copyright (c) 1983, 2010, Oracle and/or its affiliates. All rights reserved. > panic[cpu0]/thread=fffffffffbc2fac0 > > I've tried both the LTS and current stable installers, and they give the same results. I've tried disabling ACPI and HPET, varying the amount of RAM and VCPUs, etc..., to no avail. > Here's the exact line I'm using to invoke qemu: > > qemu-system-x86_64 -enable-kvm -vga std -m 2048 -cdrom OmniOS_Text_r151010u.iso -boot order=d omnios.img > > Output of 'qemu -version': > > QEMU emulator version 2.1.0, Copyright (c) 2003-2008 Fabrice Bellard > > And if it helps, the KVM host is Gentoo, with a hardened 3.15.8 kernel. The use-flags I used when building qemu can be found here: http://pastebin.com/hDTUgU4r > > Omitting "-enable-kvm" lets the virtual machine run as expected, albeit at a crawl. > > I suspect that there may be a bug at work here, and I'd greatly appreciate any suggestions on how to proceed. Thanks for your time. You're seeing this with the boot iso, right? Next time, when presented the opportunity, press ESC and get to the grub menu. When you get there, press 'e' for edit, then edit the line with "unix" toward the end. After "..../unix" and before any other flags, insert "-k". You will boot with kmdb, and when it panics, you will enter the kernel debugger, where you can show this list the panic stack with mdb's "$c" command. Please share that stack with the list. THanks, Dan From dmkhacherian at csupomona.edu Sat Sep 20 05:36:46 2014 From: dmkhacherian at csupomona.edu (David Khacherian) Date: Fri, 19 Sep 2014 22:36:46 -0700 Subject: [OmniOS-discuss] Panic when starting installer as KVM guest In-Reply-To: References: <541CE5AB.7000106@csupomona.edu> Message-ID: <541D126E.5050608@csupomona.edu> I copied and pasted that output I gave you in the last message from a boot with kmdb. After the panic message, the installer immediately restarts. I don't even get a prompt. On 09/19/2014 07:51 PM, Dan McDonald wrote: > On Sep 19, 2014, at 10:25 PM, David Khacherian wrote: > >> I've been trying to get the OmniOS installer working under kvm with qemu, and I'm always presented with the same kernel panic at the same place after the Oracle copyright notice, after which the installer restarts itself: >> >> SunOS Release 5.11 Version omnios-b281e50 64-bit >> Copyright (c) 1983, 2010, Oracle and/or its affiliates. All rights reserved. >> panic[cpu0]/thread=fffffffffbc2fac0 >> >> I've tried both the LTS and current stable installers, and they give the same results. I've tried disabling ACPI and HPET, varying the amount of RAM and VCPUs, etc..., to no avail. >> Here's the exact line I'm using to invoke qemu: >> >> qemu-system-x86_64 -enable-kvm -vga std -m 2048 -cdrom OmniOS_Text_r151010u.iso -boot order=d omnios.img >> >> Output of 'qemu -version': >> >> QEMU emulator version 2.1.0, Copyright (c) 2003-2008 Fabrice Bellard >> >> And if it helps, the KVM host is Gentoo, with a hardened 3.15.8 kernel. The use-flags I used when building qemu can be found here: http://pastebin.com/hDTUgU4r >> >> Omitting "-enable-kvm" lets the virtual machine run as expected, albeit at a crawl. >> >> I suspect that there may be a bug at work here, and I'd greatly appreciate any suggestions on how to proceed. Thanks for your time. > You're seeing this with the boot iso, right? > > Next time, when presented the opportunity, press ESC and get to the grub menu. When you get there, press 'e' for edit, then edit the line with "unix" toward the end. After "..../unix" and before any other flags, insert "-k". > > You will boot with kmdb, and when it panics, you will enter the kernel debugger, where you can show this list the panic stack with mdb's "$c" command. > > Please share that stack with the list. > > THanks, > Dan > > From richard at netbsd.org Sat Sep 20 06:23:14 2014 From: richard at netbsd.org (Richard PALO) Date: Sat, 20 Sep 2014 08:23:14 +0200 Subject: [OmniOS-discuss] r151012 is coming... In-Reply-To: References: <20140902184159.GA15289@gutsman.lotheac.fi> <3A4418FB-0F2D-410D-A7A0-D6E0F0C899D2@omniti.com> <36172C77-7003-4B62-8EED-70A9405CC63C@omniti.com> <20140902201645.GD20693@bender.unx.csupomona.edu> <20140902213816.GF20693@bender.unx.csupomona.edu> Message-ID: <541D1D52.2090808@netbsd.org> Le 03/09/14 00:06, Bob Friesenhahn a ?crit : > On Tue, 2 Sep 2014, Theo Schlossnagle wrote: > >> The poses the question: we're already responsible for the correct >> operation of the pkgadd (SVR4 tools) and pkg(5) IPS tools. >> I'm not sure that OmniOS wants to be responsible for the correct >> operation of pkgin (not even opening the can of worms that >> are the packages that it provides). > > There is also the issue that there are 32-bit and 64-bit versions of the > packages and different package manager binaries for each. I installed > the 64-bit versions on my OpenIndiana system and learned that they are > very 64-bit. For example, the GCC compiler produces 64-bit code by > default. Linking behavior is also different. > > Putting the pkgsrc-installed packages in my executable search path > caused stability problems for my software development practices > (introduced build problems) and so I have removed it from my executable > search path. > > Bob > > You seem to indicate a preference (or need) for the multiarch work that Joyent has in progress but not pushed as yet to upstream pkgsrc. https://github.com/joyent/pkgsrc/tree/joyent/feature/multiarch/trunk Naturally for a contained pkgsrc development environment (which it is), bootstrapping a zone for each arch (e.g. i386 and x86_64) is actually quite useful (let's ignore for the moment any other architectures)... I'm running gnome with ff/tb esr24 on omnios and use it as my dev platform primarily with pkgsrc tools, using 32bit for the global zone. I also bootstrap two development zones - dev32 and dev64 - respectively with --abi=32 and --abi=64. From tobi at oetiker.ch Mon Sep 22 06:32:21 2014 From: tobi at oetiker.ch (Tobias Oetiker) Date: Mon, 22 Sep 2014 08:32:21 +0200 (CEST) Subject: [OmniOS-discuss] /lib/svc/method/logadm-upgrade - a true engineering marvel Message-ID: I just did a little investigation, why my additions to /etc/logadm.d were not showing up in /etc/logadm.conf and came upon /lib/svc/method/logadm-upgrade Has the person who crafed this little marvel ever wonderd what the meaning of upgrade is ? Seriously ? Maybe the script should have been called /lib/svc/method/logadm-append-for-files-in-etc-logadm.d-newer-than-logadm.conf cheers tobi -- Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland www.oetiker.ch tobi at oetiker.ch +41 62 775 9902 From matthew.lagoe at subrigo.net Tue Sep 23 00:44:57 2014 From: matthew.lagoe at subrigo.net (Matthew Lagoe) Date: Mon, 22 Sep 2014 17:44:57 -0700 Subject: [OmniOS-discuss] Fault Manager component could not load Message-ID: <006401cfd6c7$9bee37b0$d3caa710$@subrigo.net> I tried to add "setprop temp-multiple 0" to /usr/lib/fm/fmd/plugins/disk-transport.conf due to a bug in Seagate drives, however when I start up the machine with that configuration in it I get the following error, if anyone has any ideas what the cause could be. Thanks --------------- ------------------------------------ -------------- --------- TIME EVENT-ID MSG-ID SEVERITY --------------- ------------------------------------ -------------- --------- Sep 22 17:10:10 e0719be1-fe87-6a27-cb4c-aaf2f8902a13 FMD-8000-3F Minor Host : stor10 Platform : PowerEdge-R720 Chassis_id : FCNH3W1 Product_sn : Fault class : defect.sunos.fmd.config Affects : fmd:///module/disk-transport faulted and taken out of service FRU : None faulty Description : A Solaris Fault Manager component could not load due to an erroroneous configuration file. Refer to http://illumos.org/msg/FMD-8000-3F for more information. Response : The module has been disabled. Events destined for the module will be saved for manual diagnosis. Impact : Automated diagnosis and response for subsequent events associated with this module will not occur. Action : Use fmdump -v -u to locate the module. Use fmadm load to load the module after repairing its configuration. From ikaufman at eng.ucsd.edu Tue Sep 23 01:17:16 2014 From: ikaufman at eng.ucsd.edu (Ian Kaufman) Date: Mon, 22 Sep 2014 18:17:16 -0700 Subject: [OmniOS-discuss] Fault Manager component could not load In-Reply-To: <006401cfd6c7$9bee37b0$d3caa710$@subrigo.net> References: <006401cfd6c7$9bee37b0$d3caa710$@subrigo.net> Message-ID: AFAIK, this has not been implemented yet in the Open Source community. Ian On Mon, Sep 22, 2014 at 5:44 PM, Matthew Lagoe wrote: > I tried to add "setprop temp-multiple 0" to > /usr/lib/fm/fmd/plugins/disk-transport.conf due to a bug in Seagate drives, > however when I start up the machine with that configuration in it I get the > following error, if anyone has any ideas what the cause could be. > > Thanks > > --------------- ------------------------------------ -------------- > --------- > TIME EVENT-ID MSG-ID > SEVERITY > --------------- ------------------------------------ -------------- > --------- > Sep 22 17:10:10 e0719be1-fe87-6a27-cb4c-aaf2f8902a13 FMD-8000-3F Minor > > > Host : stor10 > Platform : PowerEdge-R720 Chassis_id : FCNH3W1 > Product_sn : > > Fault class : defect.sunos.fmd.config > Affects : fmd:///module/disk-transport > faulted and taken out of service > FRU : None > faulty > > Description : A Solaris Fault Manager component could not load due to an > erroroneous configuration file. Refer to > http://illumos.org/msg/FMD-8000-3F for more information. > > Response : The module has been disabled. Events destined for the module > will be saved for manual diagnosis. > > Impact : Automated diagnosis and response for subsequent events > associated > with this module will not occur. > > Action : Use fmdump -v -u to locate the module. Use fmadm load > to load the module after repairing its configuration. > > > > > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss -- Ian Kaufman Research Systems Administrator UC San Diego, Jacobs School of Engineering ikaufman AT ucsd DOT edu From doug at will.to Tue Sep 23 01:27:49 2014 From: doug at will.to (Doug Hughes) Date: Mon, 22 Sep 2014 21:27:49 -0400 Subject: [OmniOS-discuss] further problem with r010 install with kayak Message-ID: <5420CC95.8000902@will.to> I got the miniroot (earlier emails) worked out by getting the bloody build and building a new miniroot, but I suspect that this is making the final boot non-functional because it's not backwards compatible because it includes new com.delphix:embedded_data. The kayak install works fine, but I get a bunch of missing feature messages very quickly (had to catch them in video from my camera-phone), and then it just goes to grub, so it won't boot successfully. I do have a working 012 kayak build, but I know that's not ready yet, and the r011 should be considered toxic. Looking for advice on the best course of action here (since the r010 included miniroot is totally broken) From danmcd at omniti.com Tue Sep 23 02:19:00 2014 From: danmcd at omniti.com (Dan McDonald) Date: Mon, 22 Sep 2014 22:19:00 -0400 Subject: [OmniOS-discuss] further problem with r010 install with kayak In-Reply-To: <5420CC95.8000902@will.to> References: <5420CC95.8000902@will.to> Message-ID: On Sep 22, 2014, at 9:27 PM, Doug Hughes wrote: > > I got the miniroot (earlier emails) worked out by getting the bloody build and building a new miniroot, but I suspect that this is making the final boot non-functional because it's not backwards compatible because it includes new com.delphix:embedded_data. That's likely the problem. > The kayak install works fine, but I get a bunch of missing feature messages very quickly (had to catch them in video from my camera-phone), and then it just goes to grub, so it won't boot successfully. I do have a working 012 kayak build, but I know that's not ready yet, and the r011 should be considered toxic. You can always, post-install, edit the "unix" line in grub and add "-k" to the flags. This will force a boot with the kernel debugger loaded. Instead of panicking and rebooting, it'll drop into the debugger, where you can utter "$c" and other commands to see where it broke. > Looking for advice on the best course of action here (since the r010 included miniroot is totally broken) I wish I had a good answer for you. We have two things left before 012 can officially release, and one of them is this very miniroot & kayak problem you were seeing. I won't release 012 until we have kayak & miniroot working satisfactorily. (Right now, the miniroot panics, and even using -k doesn't help!) The other problem is more pressing, though, so I can't get you progress on kayak until I solve this other problem. Thank you for your patience, Dan From doug at will.to Tue Sep 23 02:36:44 2014 From: doug at will.to (Doug Hughes) Date: Mon, 22 Sep 2014 22:36:44 -0400 Subject: [OmniOS-discuss] further problem with r010 install with kayak In-Reply-To: References: <5420CC95.8000902@will.to> Message-ID: <5420DCBC.4070107@will.to> On 9/22/2014 10:19 PM, Dan McDonald wrote: > > On Sep 22, 2014, at 9:27 PM, Doug Hughes wrote: > >> >> I got the miniroot (earlier emails) worked out by getting the bloody build and building a new miniroot, but I suspect that this is making the final boot non-functional because it's not backwards compatible because it includes new com.delphix:embedded_data. > > That's likely the problem. > >> The kayak install works fine, but I get a bunch of missing feature messages very quickly (had to catch them in video from my camera-phone), and then it just goes to grub, so it won't boot successfully. I do have a working 012 kayak build, but I know that's not ready yet, and the r011 should be considered toxic. > > You can always, post-install, edit the "unix" line in grub and add "-k" to the flags. This will force a boot with the kernel debugger loaded. Instead of panicking and rebooting, it'll drop into the debugger, where you can utter "$c" and other commands to see where it broke. > >> Looking for advice on the best course of action here (since the r010 included miniroot is totally broken) > > > I wish I had a good answer for you. We have two things left before 012 can officially release, and one of them is this very miniroot & kayak problem you were seeing. I won't release 012 until we have kayak & miniroot working satisfactorily. (Right now, the miniroot panics, and even using -k doesn't help!) The other problem is more pressing, though, so I can't get you progress on kayak until I solve this other problem. > > Thank you for your patience, > Dan > huh, I didn't have too many problems with the r012 miniroot, other than the missing libraries for kayak. I got a bootable system out of it. From what you are saying, if that's all that's left, I may be best off just booting into my 012 kayak install with the working boot. From matthew.lagoe at subrigo.net Tue Sep 23 02:58:08 2014 From: matthew.lagoe at subrigo.net (Matthew Lagoe) Date: Mon, 22 Sep 2014 19:58:08 -0700 Subject: [OmniOS-discuss] Fault Manager component could not load In-Reply-To: References: <006401cfd6c7$9bee37b0$d3caa710$@subrigo.net> Message-ID: <008601cfd6da$3736da30$a5a48e90$@subrigo.net> Is there anything I can do then to work around this issue on the Seagate drives? At the moment the only reason it is working is because it broke fmd, if I enable fmd it causes my whole storage to go out of commission :( Any assistance is greatly apreaciated. -----Original Message----- From: OmniOS-discuss [mailto:omnios-discuss-bounces at lists.omniti.com] On Behalf Of Ian Kaufman Sent: Monday, September 22, 2014 06:17 PM To: omnios-discuss Subject: Re: [OmniOS-discuss] Fault Manager component could not load AFAIK, this has not been implemented yet in the Open Source community. Ian On Mon, Sep 22, 2014 at 5:44 PM, Matthew Lagoe wrote: > I tried to add "setprop temp-multiple 0" to > /usr/lib/fm/fmd/plugins/disk-transport.conf due to a bug in Seagate > drives, however when I start up the machine with that configuration in > it I get the following error, if anyone has any ideas what the cause could be. > > Thanks > > --------------- ------------------------------------ -------------- > --------- > TIME EVENT-ID MSG-ID > SEVERITY > --------------- ------------------------------------ -------------- > --------- > Sep 22 17:10:10 e0719be1-fe87-6a27-cb4c-aaf2f8902a13 FMD-8000-3F Minor > > > Host : stor10 > Platform : PowerEdge-R720 Chassis_id : FCNH3W1 > Product_sn : > > Fault class : defect.sunos.fmd.config > Affects : fmd:///module/disk-transport > faulted and taken out of service > FRU : None > faulty > > Description : A Solaris Fault Manager component could not load due to an > erroroneous configuration file. Refer to > http://illumos.org/msg/FMD-8000-3F for more information. > > Response : The module has been disabled. Events destined for the module > will be saved for manual diagnosis. > > Impact : Automated diagnosis and response for subsequent events > associated > with this module will not occur. > > Action : Use fmdump -v -u to locate the module. Use fmadm load > to load the module after repairing its configuration. > > > > > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss -- Ian Kaufman Research Systems Administrator UC San Diego, Jacobs School of Engineering ikaufman AT ucsd DOT edu _______________________________________________ OmniOS-discuss mailing list OmniOS-discuss at lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss From richard.elling at richardelling.com Tue Sep 23 03:36:29 2014 From: richard.elling at richardelling.com (Richard Elling) Date: Mon, 22 Sep 2014 20:36:29 -0700 Subject: [OmniOS-discuss] Fault Manager component could not load In-Reply-To: <008601cfd6da$3736da30$a5a48e90$@subrigo.net> References: <006401cfd6c7$9bee37b0$d3caa710$@subrigo.net> <008601cfd6da$3736da30$a5a48e90$@subrigo.net> Message-ID: > On Sep 22, 2014, at 7:58 PM, "Matthew Lagoe" wrote: > > Is there anything I can do then to work around this issue on the Seagate > drives? 4TB nearline SAS? You'll need a firmware update from Seagate if you are at rev 3. The fix allows you to change the drive's reference temperature. -- richard > > At the moment the only reason it is working is because it broke fmd, if I > enable fmd it causes my whole storage to go out of commission :( > > Any assistance is greatly apreaciated. > > -----Original Message----- > From: OmniOS-discuss [mailto:omnios-discuss-bounces at lists.omniti.com] On > Behalf Of Ian Kaufman > Sent: Monday, September 22, 2014 06:17 PM > To: omnios-discuss > Subject: Re: [OmniOS-discuss] Fault Manager component could not load > > AFAIK, this has not been implemented yet in the Open Source community. > > Ian > > On Mon, Sep 22, 2014 at 5:44 PM, Matthew Lagoe > wrote: >> I tried to add "setprop temp-multiple 0" to >> /usr/lib/fm/fmd/plugins/disk-transport.conf due to a bug in Seagate >> drives, however when I start up the machine with that configuration in >> it I get the following error, if anyone has any ideas what the cause could > be. >> >> Thanks >> >> --------------- ------------------------------------ -------------- >> --------- >> TIME EVENT-ID MSG-ID >> SEVERITY >> --------------- ------------------------------------ -------------- >> --------- >> Sep 22 17:10:10 e0719be1-fe87-6a27-cb4c-aaf2f8902a13 FMD-8000-3F Minor >> >> >> Host : stor10 >> Platform : PowerEdge-R720 Chassis_id : FCNH3W1 >> Product_sn : >> >> Fault class : defect.sunos.fmd.config >> Affects : fmd:///module/disk-transport >> faulted and taken out of service >> FRU : None >> faulty >> >> Description : A Solaris Fault Manager component could not load due to an >> erroroneous configuration file. Refer to >> http://illumos.org/msg/FMD-8000-3F for more information. >> >> Response : The module has been disabled. Events destined for the > module >> will be saved for manual diagnosis. >> >> Impact : Automated diagnosis and response for subsequent events >> associated >> with this module will not occur. >> >> Action : Use fmdump -v -u to locate the module. Use fmadm load >> to load the module after repairing its configuration. >> >> >> >> >> >> _______________________________________________ >> OmniOS-discuss mailing list >> OmniOS-discuss at lists.omniti.com >> http://lists.omniti.com/mailman/listinfo/omnios-discuss > > > > -- > Ian Kaufman > Research Systems Administrator > UC San Diego, Jacobs School of Engineering ikaufman AT ucsd DOT edu > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss From mark0x01 at gmail.com Tue Sep 23 06:48:11 2014 From: mark0x01 at gmail.com (Mark) Date: Tue, 23 Sep 2014 18:48:11 +1200 Subject: [OmniOS-discuss] Fault Manager component could not load In-Reply-To: References: <006401cfd6c7$9bee37b0$d3caa710$@subrigo.net> <008601cfd6da$3736da30$a5a48e90$@subrigo.net> Message-ID: <542117AB.1040402@gmail.com> On 23/09/2014 3:36 p.m., Richard Elling wrote: > > >> On Sep 22, 2014, at 7:58 PM, "Matthew Lagoe" wrote: >> >> Is there anything I can do then to work around this issue on the Seagate >> drives? > > 4TB nearline SAS? You'll need a firmware update from Seagate if you are at rev 3. The fix allows you to change the drive's reference temperature. > Definitely the only solution. I used a live linux cd, and it updates all the compatible model disks it can find in one go. Seagate support are useless, and say there is no update. If you can't locate it on the Segate, site send me a pm and I'll email the link. Mark. > > -- richard > >> >> At the moment the only reason it is working is because it broke fmd, if I >> enable fmd it causes my whole storage to go out of commission :( >> >> Any assistance is greatly apreaciated. >> >> -----Original Message----- >> From: OmniOS-discuss [mailto:omnios-discuss-bounces at lists.omniti.com] On >> Behalf Of Ian Kaufman >> Sent: Monday, September 22, 2014 06:17 PM >> To: omnios-discuss >> Subject: Re: [OmniOS-discuss] Fault Manager component could not load >> >> AFAIK, this has not been implemented yet in the Open Source community. >> >> Ian >> >> On Mon, Sep 22, 2014 at 5:44 PM, Matthew Lagoe >> wrote: >>> I tried to add "setprop temp-multiple 0" to >>> /usr/lib/fm/fmd/plugins/disk-transport.conf due to a bug in Seagate >>> drives, however when I start up the machine with that configuration in >>> it I get the following error, if anyone has any ideas what the cause could >> be. >>> >>> Thanks >>> >>> --------------- ------------------------------------ -------------- >>> --------- >>> TIME EVENT-ID MSG-ID >>> SEVERITY >>> --------------- ------------------------------------ -------------- >>> --------- >>> Sep 22 17:10:10 e0719be1-fe87-6a27-cb4c-aaf2f8902a13 FMD-8000-3F Minor >>> >>> >>> Host : stor10 >>> Platform : PowerEdge-R720 Chassis_id : FCNH3W1 >>> Product_sn : >>> >>> Fault class : defect.sunos.fmd.config >>> Affects : fmd:///module/disk-transport >>> faulted and taken out of service >>> FRU : None >>> faulty >>> >>> Description : A Solaris Fault Manager component could not load due to an >>> erroroneous configuration file. Refer to >>> http://illumos.org/msg/FMD-8000-3F for more information. >>> >>> Response : The module has been disabled. Events destined for the >> module >>> will be saved for manual diagnosis. >>> >>> Impact : Automated diagnosis and response for subsequent events >>> associated >>> with this module will not occur. >>> >>> Action : Use fmdump -v -u to locate the module. Use fmadm load >>> to load the module after repairing its configuration. >>> >>> >>> >>> >>> >>> _______________________________________________ >>> OmniOS-discuss mailing list >>> OmniOS-discuss at lists.omniti.com >>> http://lists.omniti.com/mailman/listinfo/omnios-discuss >> >> >> >> -- >> Ian Kaufman >> Research Systems Administrator >> UC San Diego, Jacobs School of Engineering ikaufman AT ucsd DOT edu >> _______________________________________________ >> OmniOS-discuss mailing list >> OmniOS-discuss at lists.omniti.com >> http://lists.omniti.com/mailman/listinfo/omnios-discuss >> >> >> _______________________________________________ >> OmniOS-discuss mailing list >> OmniOS-discuss at lists.omniti.com >> http://lists.omniti.com/mailman/listinfo/omnios-discuss > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > From tom.robinson at motec.com.au Wed Sep 24 05:23:46 2014 From: tom.robinson at motec.com.au (Tom Robinson) Date: Wed, 24 Sep 2014 15:23:46 +1000 Subject: [OmniOS-discuss] beadm activate issue (and pkg update fails to install boot files) Message-ID: <54225562.3030507@motec.com.au> Hi, I was discussing this on #omnios IRC so forgive the repeat if you've seen this before. And also there's a lot of lead up to the beadm issue. It's turned out to be a deep rabbit hole. # cat /etc/release OmniOS v11 r151006 Copyright 2012-2013 OmniTI Computer Consulting, Inc. All rights reserved. Use is subject to license terms. Basically we're trying to update because we think there's an issue with the infiniband srp targets where they hang. It's a lot like this (same error messages): https://www.illumos.org/issues/5078 OmniOS is providing iSCSI boot disk to two ESXi hosts. The guest VM disks are via SRP. Every so often (once a month) something hangs and I have to reboot the whole shooting match to get things working again (I've taken to beating it to the draw by rebooting before we get an issue but sometimes it beates me!). At first I thought it was ESXi and made some queries/changes there but it didn't fix the issue. During a maintenance period I was trying to offline the srp target but it wouldn't offline - just hung in 'going offline' state and I couldn't do anything with it until after reboot of the OmniOS host. There were other tests, like after fresh reboot I could offline/online the SRP target to my hearts content without once it hanging. Come back 24 hours later and it hangs in going offline mode. Me thinks that there are some updates, maybe? OK, so I try pkg update but it fails because the ca-bundle was out of sync. After some help I jumped that hurdle and decide to update to r151008 following: http://omnios.omniti.com/wiki.php/Upgrade_r151006_r151008 But that was rejected! http://pastebin.com/7RiqEmhy I now think that maybe I'll just apply the r151006 pending updates. After all, pkg update -nv shows a couple of interesting things to update. Amongst others: network/iscsi/iser network/iscsi/target storage/stmf system/kernel So I just try pkg update under r151006 and all goes well at first but then I get an issue: pkg: unable to activate omnios-2 # beadm list BE Active Mountpoint Space Policy Created omnios NR / 6.87G static 2013-08-08 23:04 omnios-1 - - 301M static 2013-10-15 16:32 omnios-2 - /tmp/tmp2muEqp 450M static 2014-09-24 07:37 omnios-backup-1 - - 71.0K static 2013-08-12 21:25 omnios-backup-2 - - 81.0K static 2013-08-12 21:28 omnios-backup-3 - - 44.0K static 2014-09-23 11:06 omnios-backup-4 - - 101K static 2014-09-23 11:17 omniosvar - - 31.0K static 2013-08-08 23:04 Hmmm, no so good. On #omnios IRC a suggestion to leap to r151010 makes some sense and I follow these steps: beadm create r151010 beadm mount r151010 /mnt pkg -R /mnt set-publisher -G http://pkg.omniti.com/omnios/stable/ -g http://pkg.omniti.com/omnios/r151010/ omnios pkg -R /mnt update beadm activate r151010 But that last step fails again with: # beadm activate r151010 Unable to activate r151010. Error installing boot files. Hmm, much later I thought to pass the -v option and got: beadm activate -v r151010 be_do_installgrub: installgrub failed for device c4t3d0s0. Command: "/sbin/installgrub /mnt/boot/grub/stage1 /mnt/boot/grub/stage2 /dev/rdsk/c4t3d0s0" H?Z???H?Partition 0 of the disk has an incorrect offset Unable to gather device information for /dev/rdsk/c4t3d0s0 be_run_cmd: command terminated with error status: 1 Unable to activate r151010. Error installing boot files. (also, truss output here if you're interested: http://pastebin.com/fnznXtrC ) # zpool status rpool pool: rpool state: ONLINE scan: resilvered 65.4G in 0h14m with 0 errors on Fri Aug 9 01:48:26 2013 config: NAME STATE READ WRITE CKSUM rpool ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 c4t2d0s0 ONLINE 0 0 0 c4t3d0s0 ONLINE 0 0 0 errors: No known data errors Maybe this is something simple but I'm stumped. Any help is appreciated. Thanks, Tom -- Tom Robinson IT Manager/System Administrator MoTeC Pty Ltd 121 Merrindale Drive Croydon South 3136 Victoria Australia T: +61 3 9761 5050 F: +61 3 9761 5051 E: tom.robinson at motec.com.au -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From danmcd at omniti.com Wed Sep 24 05:29:10 2014 From: danmcd at omniti.com (Dan McDonald) Date: Wed, 24 Sep 2014 01:29:10 -0400 Subject: [OmniOS-discuss] beadm activate issue (and pkg update fails to install boot files) In-Reply-To: <54225562.3030507@motec.com.au> References: <54225562.3030507@motec.com.au> Message-ID: <3DAC4A06-8F04-46DF-B5B8-7BF8E207E563@omniti.com> Hmmm, perhaps trying the installgrub, AND the stageX files from the r151010 BE... /mnt/..../installgrub /mnt/boot/grub/stage[12] /dev/rdsk... That would keep things more recent. Dan From tom.robinson at motec.com.au Wed Sep 24 05:33:22 2014 From: tom.robinson at motec.com.au (Tom Robinson) Date: Wed, 24 Sep 2014 15:33:22 +1000 Subject: [OmniOS-discuss] beadm activate issue (and pkg update fails to install boot files) In-Reply-To: <3DAC4A06-8F04-46DF-B5B8-7BF8E207E563@omniti.com> References: <54225562.3030507@motec.com.au> <3DAC4A06-8F04-46DF-B5B8-7BF8E207E563@omniti.com> Message-ID: <542257A2.3040009@motec.com.au> On 24/09/14 15:29, Dan McDonald wrote: > Hmmm, perhaps trying the installgrub, AND the stageX files from the r151010 BE... > > /mnt/..../installgrub /mnt/boot/grub/stage[12] /dev/rdsk... > > That would keep things more recent. > > Dan > Thanks Dan, I can see where you're going with that idea. Should I pay any attention to: Partition 0 of the disk has an incorrect offset Unable to gather device information for /dev/rdsk/c4t3d0s0 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From danmcd at omniti.com Wed Sep 24 05:35:02 2014 From: danmcd at omniti.com (Dan McDonald) Date: Wed, 24 Sep 2014 01:35:02 -0400 Subject: [OmniOS-discuss] beadm activate issue (and pkg update fails to install boot files) In-Reply-To: <542257A2.3040009@motec.com.au> References: <54225562.3030507@motec.com.au> <3DAC4A06-8F04-46DF-B5B8-7BF8E207E563@omniti.com> <542257A2.3040009@motec.com.au> Message-ID: <663E7CB7-D2F1-4078-9B11-E7D1239E28EF@omniti.com> On Sep 24, 2014, at 1:33 AM, Tom Robinson wrote: > Thanks Dan, I can see where you're going with that idea. Should I pay any attention to: > > Partition 0 of the disk has an incorrect offset > Unable to gather device information for /dev/rdsk/c4t3d0s0 That is a bit disturbing. What about the other one in the mirror? c4t2d0s0 ? Dan From tom.robinson at motec.com.au Wed Sep 24 05:40:16 2014 From: tom.robinson at motec.com.au (Tom Robinson) Date: Wed, 24 Sep 2014 15:40:16 +1000 Subject: [OmniOS-discuss] beadm activate issue (and pkg update fails to install boot files) In-Reply-To: <663E7CB7-D2F1-4078-9B11-E7D1239E28EF@omniti.com> References: <54225562.3030507@motec.com.au> <3DAC4A06-8F04-46DF-B5B8-7BF8E207E563@omniti.com> <542257A2.3040009@motec.com.au> <663E7CB7-D2F1-4078-9B11-E7D1239E28EF@omniti.com> Message-ID: <54225940.2050805@motec.com.au> On 24/09/14 15:35, Dan McDonald wrote: > On Sep 24, 2014, at 1:33 AM, Tom Robinson wrote: > >> Thanks Dan, I can see where you're going with that idea. Should I pay any attention to: >> >> Partition 0 of the disk has an incorrect offset >> Unable to gather device information for /dev/rdsk/c4t3d0s0 > That is a bit disturbing. > > What about the other one in the mirror? c4t2d0s0 ? Nothing reported by beadm. I'm not sure if c4t3d0s0 is first or last according to installgrub. Is the only way to tell by running installgrub? I get nervous at this point. Also my next maintenance window will most likely not be until next week. In theory, installgrub shouldn't have any influence on the currently booted system, right? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From tom.robinson at motec.com.au Wed Sep 24 05:47:37 2014 From: tom.robinson at motec.com.au (Tom Robinson) Date: Wed, 24 Sep 2014 15:47:37 +1000 Subject: [OmniOS-discuss] beadm activate issue (and pkg update fails to install boot files) In-Reply-To: <54225940.2050805@motec.com.au> References: <54225562.3030507@motec.com.au> <3DAC4A06-8F04-46DF-B5B8-7BF8E207E563@omniti.com> <542257A2.3040009@motec.com.au> <663E7CB7-D2F1-4078-9B11-E7D1239E28EF@omniti.com> <54225940.2050805@motec.com.au> Message-ID: <54225AF9.4050506@motec.com.au> On 24/09/14 15:40, Tom Robinson wrote: > On 24/09/14 15:35, Dan McDonald wrote: >> On Sep 24, 2014, at 1:33 AM, Tom Robinson wrote: >> >>> Thanks Dan, I can see where you're going with that idea. Should I pay any attention to: >>> >>> Partition 0 of the disk has an incorrect offset >>> Unable to gather device information for /dev/rdsk/c4t3d0s0 >> That is a bit disturbing. >> >> What about the other one in the mirror? c4t2d0s0 ? > Nothing reported by beadm. I'm not sure if c4t3d0s0 is first or last according to installgrub. Is > the only way to tell by running installgrub? I get nervous at this point. Also my next maintenance > window will most likely not be until next week. > > In theory, installgrub shouldn't have any influence on the currently booted system, right? Ok, since c4t3d0s0 IS failing to accept the installgrub here goes: # installgrub /boot/grub/stage1 /boot/grub/stage2 /dev/rdsk/c4t3d0s0 Partition 0 of the disk has an incorrect offset Unable to gather device information for /dev/rdsk/c4t3d0s0 and # installgrub /mnt/boot/grub/stage1 /boot/grub/stage2 /dev/rdsk/c4t3d0s0 Partition 0 of the disk has an incorrect offset Unable to gather device information for /dev/rdsk/c4t3d0s0 I'm still nervous about running this on my (apparently) only bootable disk... (c4t2d0s0) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From tom.robinson at motec.com.au Wed Sep 24 05:58:06 2014 From: tom.robinson at motec.com.au (Tom Robinson) Date: Wed, 24 Sep 2014 15:58:06 +1000 Subject: [OmniOS-discuss] beadm activate issue (and pkg update fails to install boot files) In-Reply-To: <54225AF9.4050506@motec.com.au> References: <54225562.3030507@motec.com.au> <3DAC4A06-8F04-46DF-B5B8-7BF8E207E563@omniti.com> <542257A2.3040009@motec.com.au> <663E7CB7-D2F1-4078-9B11-E7D1239E28EF@omniti.com> <54225940.2050805@motec.com.au> <54225AF9.4050506@motec.com.au> Message-ID: <54225D6E.1040906@motec.com.au> On 24/09/14 15:47, Tom Robinson wrote: > On 24/09/14 15:40, Tom Robinson wrote: >> On 24/09/14 15:35, Dan McDonald wrote: >>> On Sep 24, 2014, at 1:33 AM, Tom Robinson wrote: >>> >>>> Thanks Dan, I can see where you're going with that idea. Should I pay any attention to: >>>> >>>> Partition 0 of the disk has an incorrect offset >>>> Unable to gather device information for /dev/rdsk/c4t3d0s0 >>> That is a bit disturbing. >>> >>> What about the other one in the mirror? c4t2d0s0 ? >> Nothing reported by beadm. I'm not sure if c4t3d0s0 is first or last according to installgrub. Is >> the only way to tell by running installgrub? I get nervous at this point. Also my next maintenance >> window will most likely not be until next week. >> >> In theory, installgrub shouldn't have any influence on the currently booted system, right? > Ok, since c4t3d0s0 IS failing to accept the installgrub here goes: > > # installgrub /boot/grub/stage1 /boot/grub/stage2 /dev/rdsk/c4t3d0s0 > Partition 0 of the disk has an incorrect offset > Unable to gather device information for /dev/rdsk/c4t3d0s0 > > and > > # installgrub /mnt/boot/grub/stage1 /boot/grub/stage2 /dev/rdsk/c4t3d0s0 > Partition 0 of the disk has an incorrect offset > Unable to gather device information for /dev/rdsk/c4t3d0s0 > > I'm still nervous about running this on my (apparently) only bootable disk... (c4t2d0s0) prtvtoc shows cylinders and accessible cylinders differ by one: # prtvtoc /dev/rdsk/c4t3d0s0 * /dev/rdsk/c4t3d0s0 partition map * * Dimensions: * 512 bytes/sector * 56 sectors/track * 224 tracks/cylinder * 12544 sectors/cylinder * 18689 cylinders * 18687 accessible cylinders * * Flags: * 1: unmountable * 10: read-only * * Unallocated space: * First Sector Last * Sector Count Sector * 0 12544 12543 * * First Sector Last * Partition Tag Flags Sector Count Sector Mount Directory 0 2 00 12544 234384640 234397183 2 5 01 0 234422272 234422271 8 1 01 0 12544 12543 # prtvtoc /dev/rdsk/c4t2d0s0 * /dev/rdsk/c4t2d0s0 partition map * * Dimensions: * 512 bytes/sector * 56 sectors/track * 224 tracks/cylinder * 12544 sectors/cylinder * 18688 cylinders * 18686 accessible cylinders * * Flags: * 1: unmountable * 10: read-only * * Unallocated space: * First Sector Last * Sector Count Sector * 0 12544 12543 * * First Sector Last * Partition Tag Flags Sector Count Sector Mount Directory 0 2 00 12544 234384640 234397183 2 5 01 0 234422272 234422271 8 1 01 0 12544 12543 # prtvtoc /dev/rdsk/c4t3d0s0 > /tmp/prtvtoc-c4t3d0s0 # prtvtoc /dev/rdsk/c4t2d0s0 > /tmp/prtvtoc-c4t2d0s0 # diff /tmp/prtvtoc-c4t2d0s0 /tmp/prtvtoc-c4t3d0s0 1c1 < * /dev/rdsk/c4t2d0s0 partition map --- > * /dev/rdsk/c4t3d0s0 partition map 8,9c8,9 < * 18688 cylinders < * 18686 accessible cylinders --- > * 18689 cylinders > * 18687 accessible cylinders -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From jimklimov at cos.ru Wed Sep 24 07:25:43 2014 From: jimklimov at cos.ru (Jim Klimov) Date: Wed, 24 Sep 2014 09:25:43 +0200 Subject: [OmniOS-discuss] beadm activate issue (and pkg update fails to install boot files) In-Reply-To: <54225AF9.4050506@motec.com.au> References: <54225562.3030507@motec.com.au> <3DAC4A06-8F04-46DF-B5B8-7BF8E207E563@omniti.com> <542257A2.3040009@motec.com.au> <663E7CB7-D2F1-4078-9B11-E7D1239E28EF@omniti.com> <54225940.2050805@motec.com.au> <54225AF9.4050506@motec.com.au> Message-ID: <07471133-5606-4c17-8759-9ccaa4177d8a@email.android.com> 24 ???????? 2014??. 7:47:37 CEST, Tom Robinson ?????: >On 24/09/14 15:40, Tom Robinson wrote: >> On 24/09/14 15:35, Dan McDonald wrote: >>> On Sep 24, 2014, at 1:33 AM, Tom Robinson > wrote: >>> >>>> Thanks Dan, I can see where you're going with that idea. Should I >pay any attention to: >>>> >>>> Partition 0 of the disk has an incorrect offset >>>> Unable to gather device information for /dev/rdsk/c4t3d0s0 >>> That is a bit disturbing. >>> >>> What about the other one in the mirror? c4t2d0s0 ? >> Nothing reported by beadm. I'm not sure if c4t3d0s0 is first or last >according to installgrub. Is >> the only way to tell by running installgrub? I get nervous at this >point. Also my next maintenance >> window will most likely not be until next week. >> >> In theory, installgrub shouldn't have any influence on the currently >booted system, right? >Ok, since c4t3d0s0 IS failing to accept the installgrub here goes: > ># installgrub /boot/grub/stage1 /boot/grub/stage2 /dev/rdsk/c4t3d0s0 >Partition 0 of the disk has an incorrect offset >Unable to gather device information for /dev/rdsk/c4t3d0s0 > >and > ># installgrub /mnt/boot/grub/stage1 /boot/grub/stage2 >/dev/rdsk/c4t3d0s0 >Partition 0 of the disk has an incorrect offset >Unable to gather device information for /dev/rdsk/c4t3d0s0 > >I'm still nervous about running this on my (apparently) only bootable >disk... (c4t2d0s0) > > > >------------------------------------------------------------------------ > >_______________________________________________ >OmniOS-discuss mailing list >OmniOS-discuss at lists.omniti.com >http://lists.omniti.com/mailman/listinfo/omnios-discuss One point in Dan's message was to use /mnt/.../installgrub. Another one to consider may be differences in MBR partitioning (with one of those good old partitions being the container for your slice table and ultimately an rpool vdev). If your system has parted - it can be revealing on a sector-by-sector sizing (and offset) comparison. Otherwise solaris fdisk can be used, though imho not so granular. Since you have a mirror, don't discard the option of breaking it, creating a partition layout which just works for grub, and either attaching the slice back to the rpool if it remains big enough, or migrating the data (zfs-send/zfs-recv and/or rsync), and after a bootability-check - repartition and reattach the other disk. The tricky part in this quest is to retain the 'rpool' name if you make a new pool - this would probably require booting from live media, importing the new pool (maybe by GUID) as 'rpool' and exporting it. I wrote a number of howtos and examples on the related subjects on illumos and/or OI wiki's, if you're interested. HTH, Jim Klimov -- Typos courtesy of K-9 Mail on my Samsung Android From joeveliscos at gmail.com Wed Sep 24 11:59:16 2014 From: joeveliscos at gmail.com (Joe Veliscos) Date: Wed, 24 Sep 2014 13:59:16 +0200 Subject: [OmniOS-discuss] installing expect Message-ID: Hi , Can somebody tell me what would be the right way to install expect in omnios r10 thanks, Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobi at oetiker.ch Wed Sep 24 13:02:39 2014 From: tobi at oetiker.ch (Tobias Oetiker) Date: Wed, 24 Sep 2014 15:02:39 +0200 (CEST) Subject: [OmniOS-discuss] illumos-kvm network performance Message-ID: Hi I have been looking into network performance on omnios hosted kvm hosts. especially in connection with ssh. the test is this: physical-linux-host$ ssh -c aes256-cbc virtual-kvm-linux-host dd if=/dev/zero bs=10M count=10 > /dev/null running this simple test from a physical ubuntu 12.04 host to a omnios hosted (virtio) ubuntu 12.04 I get ~ 9 MB/s running the same test to a ubuntu 12.04 running on linux kvm host I get ~ 69 MB/s runnint the test between two physical linux hosts I get well over 100 MB/s any hints on how to improve the performance on kvm on omnios ? Or am I the only one seeing this ? cheers tobi ps all these systems support the hw aes and running this test via localhost returns transfer speeds over 100 MB/s on all of them -- Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland www.oetiker.ch tobi at oetiker.ch +41 62 775 9902 From tobi at oetiker.ch Wed Sep 24 14:15:11 2014 From: tobi at oetiker.ch (Tobias Oetiker) Date: Wed, 24 Sep 2014 16:15:11 +0200 (CEST) Subject: [OmniOS-discuss] illumos-kvm network performance In-Reply-To: References: Message-ID: Today Tobias Oetiker wrote: > Hi > > I have been looking into network performance on omnios hosted kvm > hosts. especially in connection with ssh. > > the test is this: > > physical-linux-host$ ssh -c aes256-cbc virtual-kvm-linux-host dd if=/dev/zero bs=10M count=10 > /dev/null > > running this simple test from a physical ubuntu 12.04 host to a > omnios hosted (virtio) ubuntu 12.04 I get ~ 9 MB/s > > running the same test to a ubuntu 12.04 running on linux kvm host > I get ~ 69 MB/s > > runnint the test between two physical linux hosts I get well over 100 MB/s > > any hints on how to improve the performance on kvm on omnios ? Or > am I the only one seeing this ? upon further investigtion I found that smartos seem to be launching their kvm instances with -device virtio-net-pci,mac=$mac,tx=timer,x-txtimer=200000,x-txburst=128,vlan=0 using this I got up to 30.5 MB/s (still not the 69 MB/s seen with linux, but at least somewhat closer) ... cheers tobi > cheers > tobi > > ps all these systems support the hw aes and running this test via > localhost returns transfer speeds over 100 MB/s on all of them > > -- Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland www.oetiker.ch tobi at oetiker.ch +41 62 775 9902 From doug at will.to Thu Sep 25 03:02:02 2014 From: doug at will.to (Doug Hughes) Date: Wed, 24 Sep 2014 23:02:02 -0400 Subject: [OmniOS-discuss] SolarFlare SFXGE with OmniOS In-Reply-To: <541CD253.9060205@gmail.com> References: <923F799C-ED2F-4F79-950F-5256C2C6A60F@omniti.com> <541CBAE0.2030405@gmail.com> <541CD253.9060205@gmail.com> Message-ID: <542385AA.8050000@will.to> On 9/19/2014 9:03 PM, Saso Kiselkov wrote: > On 9/20/14, 1:23 AM, Mark wrote: >> On 20/09/2014 5:13 a.m., Dan McDonald wrote: >>> >>> On Sep 19, 2014, at 11:44 AM, Doug Hughes wrote: >>> >>>> Is anybody using Solarflare 10G cards with OmniOS. I have a 2010 >>>> vintage of Openindiana (yeah, I should really upgrade that - it's a >>>> test box) running with the Sol10 production sfxge driver and working >>>> flawlessly for years. It tried the sfxge package for Sol11 and for >>>> Sol10 on OmniOS r151012 (yeah, I know it's not quite ready) and it >>>> crashes and core dumps as soon as I send any traffic on the nic, even >>>> a ping. >>>> >>>> Curious if anybody else is using them and having luck? >>> >>> Without source you'll be out of luck. >> >> >> Source at http://cr.illumos.org/~webrev/rincebrain/illumos-sfxge/ >> > > Ok, got it to build cleanly, code at: > > https://github.com/skiselkov/illumos-gate/tree/sfxge > > Unique commits in that branch: > > 1c3fe595 - initial commit of the sfxge pretty much as-is from the webrev > (plus a few formatting fixes to get git to shut up about > trailing whitespace) > > efb39dd8 - build & lint cleaning to get it to build with our gcc, plus > one bugfix noted below > > I'm not going to bother with cstyle fixes for foreign code, there's 1200 > offending lines and it would jeopardize upstream-mergeability anyway. > > Willing testers with sfxge hardware who don't wanna muck around with > manual building can grab a pre-built version at: > http://37.153.99.61/sfxge.tar.gz. To install & use, do: > > # tar xzf sfxge.tar.gz > # beadm create sfxge_test > # beadm mount sfxge_test > Mounted successfully on: '' > # cp -r sfxge/sfxge.conf sfxge/debug/* /kernel/drv > # bootadm update-archive -R > # reboot -fe sfxge_test > > And take her out for a good spin. If testing proves this card to work > well, I can post a code review & RTI. > > ============== > > Lint found one potential bug (which I've fixed) that might be worth > reporting back to Solarflare: > > sfxge_gld_v3.c:680: contains a line like this: > > if ((rc = sfxge_ev_moderation_set(sp, (unsigned int) val) != 0)) > > The double brace at the end is incorrect, "rc" will get assigned the > result of the "sfxge_ev_moderation_set() != 0" comparison. I'm fairly > confident this is not what the author intended. > > Cheers, > So far so good. ping tests work successfully with OmniOS r012 and dladm aggr. will run some real tests soon. PS - the add-drv command from the solaris postinstall is: add_drv -m '* 0600 root sys' -i '"pciex1924,703" "pciex1924,710" "pciex1924,803" "pciex1924,813"' sfxge From danmcd at omniti.com Thu Sep 25 03:07:21 2014 From: danmcd at omniti.com (Dan McDonald) Date: Wed, 24 Sep 2014 23:07:21 -0400 Subject: [OmniOS-discuss] SolarFlare SFXGE with OmniOS In-Reply-To: <542385AA.8050000@will.to> References: <923F799C-ED2F-4F79-950F-5256C2C6A60F@omniti.com> <541CBAE0.2030405@gmail.com> <541CD253.9060205@gmail.com> <542385AA.8050000@will.to> Message-ID: <0143C713-E31E-46AB-B90C-2B130BB6439F@omniti.com> On Sep 24, 2014, at 11:02 PM, Doug Hughes wrote: > > So far so good. ping tests work successfully with OmniOS r012 and dladm aggr. FYI, 012 isn't officially out yet. There are more updates and respins. (bash & mozilla-nss being the biggies.) > will run some real tests soon. > > PS - the add-drv command from the solaris postinstall is: > add_drv -m '* 0600 root sys' -i '"pciex1924,703" "pciex1924,710" "pciex1924,803" "pciex1924,813"' sfxge Are you thinking this is good enough for upstreaming into illumos-gate, perhaps? :) Thanks! Dan From doug at will.to Thu Sep 25 03:25:09 2014 From: doug at will.to (Doug Hughes) Date: Wed, 24 Sep 2014 23:25:09 -0400 Subject: [OmniOS-discuss] SolarFlare SFXGE with OmniOS In-Reply-To: <0143C713-E31E-46AB-B90C-2B130BB6439F@omniti.com> References: <923F799C-ED2F-4F79-950F-5256C2C6A60F@omniti.com> <541CBAE0.2030405@gmail.com> <541CD253.9060205@gmail.com> <542385AA.8050000@will.to> <0143C713-E31E-46AB-B90C-2B130BB6439F@omniti.com> Message-ID: <54238B15.8040505@will.to> On 9/24/2014 11:07 PM, Dan McDonald wrote: > > On Sep 24, 2014, at 11:02 PM, Doug Hughes wrote: >> >> So far so good. ping tests work successfully with OmniOS r012 and dladm aggr. > > FYI, 012 isn't officially out yet. There are more updates and respins. (bash & mozilla-nss being the biggies.) > >> will run some real tests soon. >> >> PS - the add-drv command from the solaris postinstall is: >> add_drv -m '* 0600 root sys' -i '"pciex1924,703" "pciex1924,710" "pciex1924,803" "pciex1924,813"' sfxge > > Are you thinking this is good enough for upstreaming into illumos-gate, perhaps? :) > > Thanks! > Dan > I ran an iperf from not a full speed slot. inbound (receiver) was 3.8gbits, outbound was only 78Mbits.. So far no crashes. That's awesome. The outbound is a bit worrisome but could just be a configuration issue. From doug at will.to Thu Sep 25 19:16:50 2014 From: doug at will.to (Doug Hughes) Date: Thu, 25 Sep 2014 15:16:50 -0400 Subject: [OmniOS-discuss] SolarFlare SFXGE with OmniOS In-Reply-To: <54238B15.8040505@will.to> References: <923F799C-ED2F-4F79-950F-5256C2C6A60F@omniti.com> <541CBAE0.2030405@gmail.com> <541CD253.9060205@gmail.com> <542385AA.8050000@will.to> <0143C713-E31E-46AB-B90C-2B130BB6439F@omniti.com> <54238B15.8040505@will.to> Message-ID: locally connected to same switch solves the outbound problem. I got 7.46gbits/sec outbound (not full bandwidth slot in x4440) and 3.3mbits/sec inbound. This is with the debugging driver loaded. I'll try with the non debug driver shortly. On Wed, Sep 24, 2014 at 11:25 PM, Doug Hughes wrote: > On 9/24/2014 11:07 PM, Dan McDonald wrote: > >> >> On Sep 24, 2014, at 11:02 PM, Doug Hughes wrote: >> >>> >>> So far so good. ping tests work successfully with OmniOS r012 and dladm >>> aggr. >>> >> >> FYI, 012 isn't officially out yet. There are more updates and respins. >> (bash & mozilla-nss being the biggies.) >> >> will run some real tests soon. >>> >>> PS - the add-drv command from the solaris postinstall is: >>> add_drv -m '* 0600 root sys' -i '"pciex1924,703" "pciex1924,710" >>> "pciex1924,803" "pciex1924,813"' sfxge >>> >> >> Are you thinking this is good enough for upstreaming into illumos-gate, >> perhaps? :) >> >> Thanks! >> Dan >> >> > I ran an iperf from not a full speed slot. inbound (receiver) was > 3.8gbits, outbound was only 78Mbits.. So far no crashes. That's awesome. > The outbound is a bit worrisome but could just be a configuration issue. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug at will.to Thu Sep 25 19:35:48 2014 From: doug at will.to (Doug Hughes) Date: Thu, 25 Sep 2014 15:35:48 -0400 Subject: [OmniOS-discuss] SolarFlare SFXGE with OmniOS In-Reply-To: References: <923F799C-ED2F-4F79-950F-5256C2C6A60F@omniti.com> <541CBAE0.2030405@gmail.com> <541CD253.9060205@gmail.com> <542385AA.8050000@will.to> <0143C713-E31E-46AB-B90C-2B130BB6439F@omniti.com> <54238B15.8040505@will.to> Message-ID: With non-debug driver: 9.71 gbits/sec inbound 8.54 gbits/sec outboudn 512k tcp window size. same 10g switch stack, but I can't guarantee that it's not traversing the stack 40g link between the two stack members. one side is a Sol10U10 box, the other is this x4440 running OmniOS. Both have Solarflare cards setup in LACP to the switch stack. I'd say this is ok to release/bundle! (I'd be happy to volunteer a sfxge.conf for this, also we should use the Solaris postinstall or a variant of it to do the correct add-drv and driver_aliases stuff.) On Thu, Sep 25, 2014 at 3:16 PM, Doug Hughes wrote: > locally connected to same switch solves the outbound problem. > I got 7.46gbits/sec outbound (not full bandwidth slot in x4440) and > 3.3mbits/sec inbound. This is with the debugging driver loaded. I'll try > with the non debug driver shortly. > > > On Wed, Sep 24, 2014 at 11:25 PM, Doug Hughes wrote: > >> On 9/24/2014 11:07 PM, Dan McDonald wrote: >> >>> >>> On Sep 24, 2014, at 11:02 PM, Doug Hughes wrote: >>> >>>> >>>> So far so good. ping tests work successfully with OmniOS r012 and dladm >>>> aggr. >>>> >>> >>> FYI, 012 isn't officially out yet. There are more updates and respins. >>> (bash & mozilla-nss being the biggies.) >>> >>> will run some real tests soon. >>>> >>>> PS - the add-drv command from the solaris postinstall is: >>>> add_drv -m '* 0600 root sys' -i '"pciex1924,703" "pciex1924,710" >>>> "pciex1924,803" "pciex1924,813"' sfxge >>>> >>> >>> Are you thinking this is good enough for upstreaming into illumos-gate, >>> perhaps? :) >>> >>> Thanks! >>> Dan >>> >>> >> I ran an iperf from not a full speed slot. inbound (receiver) was >> 3.8gbits, outbound was only 78Mbits.. So far no crashes. That's awesome. >> The outbound is a bit worrisome but could just be a configuration issue. >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From skiselkov.ml at gmail.com Thu Sep 25 19:39:34 2014 From: skiselkov.ml at gmail.com (Saso Kiselkov) Date: Thu, 25 Sep 2014 21:39:34 +0200 Subject: [OmniOS-discuss] SolarFlare SFXGE with OmniOS In-Reply-To: References: <923F799C-ED2F-4F79-950F-5256C2C6A60F@omniti.com> <541CBAE0.2030405@gmail.com> <541CD253.9060205@gmail.com> <542385AA.8050000@will.to> <0143C713-E31E-46AB-B90C-2B130BB6439F@omniti.com> <54238B15.8040505@will.to> Message-ID: <54246F76.9090603@gmail.com> On 9/25/14, 9:35 PM, Doug Hughes wrote: > With non-debug driver: > 9.71 gbits/sec inbound > 8.54 gbits/sec outboudn > > 512k tcp window size. same 10g switch stack, but I can't guarantee that > it's not traversing the stack 40g link between the two stack members. > one side is a Sol10U10 box, the other is this x4440 running OmniOS. > Both have Solarflare cards setup in LACP to the switch stack. > > I'd say this is ok to release/bundle! > > (I'd be happy to volunteer a sfxge.conf for this, also we should use the > Solaris postinstall or a variant of it to do the correct add-drv and > driver_aliases stuff.) Great. If you have customizations to sfxge.conf that are supposed to be included, post 'em. Illumos doesn't really deal with packaging, so bit is going to be dealt with by the distro maintainers. Cheers, -- Saso From danmcd at omniti.com Thu Sep 25 20:03:35 2014 From: danmcd at omniti.com (Dan McDonald) Date: Thu, 25 Sep 2014 16:03:35 -0400 Subject: [OmniOS-discuss] SolarFlare SFXGE with OmniOS In-Reply-To: References: <923F799C-ED2F-4F79-950F-5256C2C6A60F@omniti.com> <541CBAE0.2030405@gmail.com> <541CD253.9060205@gmail.com> <542385AA.8050000@will.to> <0143C713-E31E-46AB-B90C-2B130BB6439F@omniti.com> <54238B15.8040505@will.to> Message-ID: On Sep 25, 2014, at 3:35 PM, Doug Hughes wrote: > (I'd be happy to volunteer a sfxge.conf for this, also we should use the Solaris postinstall or a variant of it to do the correct add-drv and driver_aliases stuff.) That's all packaging - make sure the delievered .mf file is good and you're golden. Looking forward! Dan From doug at will.to Thu Sep 25 20:28:10 2014 From: doug at will.to (Doug Hughes) Date: Thu, 25 Sep 2014 16:28:10 -0400 Subject: [OmniOS-discuss] SolarFlare SFXGE with OmniOS In-Reply-To: <54246F76.9090603@gmail.com> References: <923F799C-ED2F-4F79-950F-5256C2C6A60F@omniti.com> <541CBAE0.2030405@gmail.com> <541CD253.9060205@gmail.com> <542385AA.8050000@will.to> <0143C713-E31E-46AB-B90C-2B130BB6439F@omniti.com> <54238B15.8040505@will.to> <54246F76.9090603@gmail.com> Message-ID: the default sfxge.conf doesn't even include the capability to use jumbo frames until you edit it and reboot, so that's silly. Enabling them by default in the sfxge.conf doesn't hurt and allows you to use jumbo or not when the time comes. Other info tidbits a default inter_moderation of 100 seems to be good for most NFS workloads. default is 30. the sfxge parent lines for rx_scale_count are good for most multi-cpu systems, but people will need to change the pci device ID for things that aren't a 5162 (which is what we by and large use) We generally use rxq_size=2048, but that's our choice. It may not be right for any particular. I'd suggest leaving it as default and am leaving it commented out like the above. by default large receiver offload is disabled. There seems to be no super good reason for this (except maybe for the high frequency onboot guys), so I enable it by default. add_drv sets up appropriate permissions and aliases: add_drv -m '* 0600 root sys' -i '"pciex1924,703" "pciex1924,710" "pciex1924,803" sfxge.conf attached On Thu, Sep 25, 2014 at 3:39 PM, Saso Kiselkov wrote: > On 9/25/14, 9:35 PM, Doug Hughes wrote: > > With non-debug driver: > > 9.71 gbits/sec inbound > > 8.54 gbits/sec outboudn > > > > 512k tcp window size. same 10g switch stack, but I can't guarantee that > > it's not traversing the stack 40g link between the two stack members. > > one side is a Sol10U10 box, the other is this x4440 running OmniOS. > > Both have Solarflare cards setup in LACP to the switch stack. > > > > I'd say this is ok to release/bundle! > > > > (I'd be happy to volunteer a sfxge.conf for this, also we should use the > > Solaris postinstall or a variant of it to do the correct add-drv and > > driver_aliases stuff.) > > Great. If you have customizations to sfxge.conf that are supposed to be > included, post 'em. Illumos doesn't really deal with packaging, so bit > is going to be dealt with by the distro maintainers. > > Cheers, > -- > Saso > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: sfxge.conf Type: application/octet-stream Size: 9213 bytes Desc: not available URL: From filip.marvan at aira.cz Fri Sep 26 14:30:28 2014 From: filip.marvan at aira.cz (Filip Marvan) Date: Fri, 26 Sep 2014 16:30:28 +0200 Subject: [OmniOS-discuss] Managing KVM virtual machines Message-ID: <3BE0DEED8863E5429BAE4CAEDF6245650368955678B4@AIRA-SRV.aira.local> Hello, I'm running virtual machines on KVM in OmniOS. It works great, but I would like to know, if there is any way, how to manage that virtual machines more comfortably. If I create a transient service for every virtual guest (transient, because I don't want to start that virtual machine again when I shutdown the system directly from the guest), but as service is transient, it seems to be still "online" even guest is not running anymore so I have no knowledge from OmniOS, if this virtual machine is running or not. So Is there any other way, how to find which virtual machines are running? Of course I can shutdown virtualmachine with: svcadm disable virtualmachine But sometimes ACPI is not working or is blocked by some reason, si I have to shutdown system directly from guest. So how can I see, which KVM virtual machines are really running? Thank you very much for any help, Filip Marvan -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6247 bytes Desc: not available URL: From hakansom at ohsu.edu Fri Sep 26 18:55:46 2014 From: hakansom at ohsu.edu (Marion Hakanson) Date: Fri, 26 Sep 2014 11:55:46 -0700 Subject: [OmniOS-discuss] kayak-kernel missing pxegrub? Message-ID: <201409261855.s8QItkxO028993@kyklops.ohsu.edu> Greetings, I recently setup our first Kayak server here (on a system running OmniOS-151010u), and can't get the PXE boot to work. The PXE client starts the TFTP phase, but gives up immediately, unable to download the file. I followed these instructions to setup the Kayak server: http://omnios.omniti.com/wiki.php/Installation#Fromthenetwork One thing I noticed is that there is no pxegrub file in /tftpboot/, nor any menu.lst file. This page indicates that the kayak-kernel package should contain both of those items as well as the miniroot: http://omnios.omniti.com/wiki.php/PXEfromNonOmniOS However, "pkg contents kayak-kernel" does not list pxegrub, miniroot.gz, nor menu.lst: # pkg contents kayak-kernel PATH tftpboot tftpboot/boot tftpboot/boot/grub tftpboot/boot/platform tftpboot/boot/platform/i86pc tftpboot/boot/platform/i86pc/kernel tftpboot/boot/platform/i86pc/kernel/amd64 tftpboot/boot/platform/i86pc/kernel/amd64/unix tftpboot/kayak # pkg publisher PUBLISHER TYPE STATUS URI omnios origin online http://pkg.omniti.com/omnios/r151010/ ms.omniti.com origin online http://pkg.omniti.com/omniti-ms/ # This system was originally installed with 151006, upgraded to 151008, and then to 151010u. After all that was done, the Kayak packages were added. Suggestions? Thanks and regards, Marion From sjorge+ml at blackdot.be Fri Sep 26 21:35:00 2014 From: sjorge+ml at blackdot.be (Jorge Schrauwen) Date: Fri, 26 Sep 2014 23:35:00 +0200 Subject: [OmniOS-discuss] Managing KVM virtual machines In-Reply-To: <3BE0DEED8863E5429BAE4CAEDF6245650368955678B4@AIRA-SRV.aira.local> References: <3BE0DEED8863E5429BAE4CAEDF6245650368955678B4@AIRA-SRV.aira.local> Message-ID: <4cf467ff3390a378ce5fc74fb73386e4@blackdot.be> You can make qemu dump a monitoring socket, you can then use netcat to send commands like acpi shutdown events but also query other info. If the socket is dead, the qemu process crashed. So applying some wrapper magic it could be possible to make the svc more intelligent. I can't offor you a working manifest though :( I theorized about it but deemed it too much work for the one vm I run. I do use the qemu monitoring socket however. -chardev socket,id=monitor,path=/vms/hosts/${VMNAME}/run/monitor.sock,server,nowait -monitor chardev:monitor To add the monitor Hope this is somewhat helpful! Regards Jorge On 2014-09-26 16:30, Filip Marvan wrote: > Hello, > > I'm running virtual machines on KVM in OmniOS. It works great, but I would like to know, if there is any way, how to manage that virtual machines more comfortably. > > If I create a transient service for every virtual guest (transient, because I don't want to start that virtual machine again when I shutdown the system directly from the guest), but as service is transient, it seems to be still "online" even guest is not running anymore so I have no knowledge from OmniOS, if this virtual machine is running or not. So Is there any other way, how to find which virtual machines are running? > > Of course I can shutdown virtualmachine with: > > svcadm disable virtualmachine > > But sometimes ACPI is not working or is blocked by some reason, si I have to shutdown system directly from guest. > > So how can I see, which KVM virtual machines are really running? > > Thank you very much for any help, > > Filip Marvan > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss [1] Links: ------ [1] http://lists.omniti.com/mailman/listinfo/omnios-discuss -------------- next part -------------- An HTML attachment was scrubbed... URL: From zmalone at omniti.com Sat Sep 27 01:52:57 2014 From: zmalone at omniti.com (Zach Malone) Date: Fri, 26 Sep 2014 21:52:57 -0400 Subject: [OmniOS-discuss] Bash 4.2.49 updates Message-ID: Hello everyone, Dan's published pkg://omnios/shell/bash at 4.2.49,5.11-0.151006:20140926T220552Z and pkg://omnios/shell/bash at 4.2.49,5.11-0.151010:20140926T221751Z , which correspond with http://ftp.gnu.org/gnu/bash/bash-4.2-patches/bash42-049 . You will want to upgrade with the first package if you are on 151006, and the second for 151010. --Zach Malone From mayuresh at kathe.in Sat Sep 27 20:18:22 2014 From: mayuresh at kathe.in (Mayuresh Kathe) Date: Sun, 28 Sep 2014 01:48:22 +0530 Subject: [OmniOS-discuss] running r151012 : quite smoothly ... Message-ID: <114786aee4daf4d0f46eb367b606d9b9@kathe.in> hah, looks like i might be the first one to try out r151012 (outside omniti) and definitely the first one to post about it out here. :) it works well on my brand new hp aio (18-5019il). thanks to omniti, and especially to dan mcdonald for his efforts. :) best, ~mayuresh From mir at miras.org Sat Sep 27 22:42:59 2014 From: mir at miras.org (Michael Rasmussen) Date: Sun, 28 Sep 2014 00:42:59 +0200 Subject: [OmniOS-discuss] running r151012 : quite smoothly ... In-Reply-To: <114786aee4daf4d0f46eb367b606d9b9@kathe.in> References: <114786aee4daf4d0f46eb367b606d9b9@kathe.in> Message-ID: <20140928004259.00c6a4ea@sleipner.datanom.net> On Sun, 28 Sep 2014 01:48:22 +0530 Mayuresh Kathe wrote: > hah, looks like i might be the first one to try out r151012 (outside omniti) and definitely the first one to post about it out here. :) > > it works well on my brand new hp aio (18-5019il). > Upgraded smoothly from r151010 to r151012. Using fast reboot and by server only had a down-time less than 30 sec. Impressive;-) Excellent work by Dan and Omniti:-) -- Hilsen/Regards Michael Rasmussen Get my public GnuPG keys: michael rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras org http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 -------------------------------------------------------------- /usr/games/fortune -es says: Toothpaste never hurts the taste of good scotch. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From sjorge+ml at blackdot.be Sun Sep 28 07:31:27 2014 From: sjorge+ml at blackdot.be (Jorge Schrauwen) Date: Sun, 28 Sep 2014 09:31:27 +0200 Subject: [OmniOS-discuss] running r151012 : quite smoothly ... In-Reply-To: <20140928004259.00c6a4ea@sleipner.datanom.net> References: <114786aee4daf4d0f46eb367b606d9b9@kathe.in> <20140928004259.00c6a4ea@sleipner.datanom.net> Message-ID: <3c3ea67a123fb7288199f005b2a79f26@blackdot.be> Also went smoothly, about 15 min here (no fast reboot and a couple of zones) (Did some extra reboots to be safe (aka make a temp be to do the actual upgrade from) On 2014-09-28 00:42, Michael Rasmussen wrote: > On Sun, 28 Sep 2014 01:48:22 +0530 > Mayuresh Kathe wrote: > >> hah, looks like i might be the first one to try out r151012 (outside >> omniti) and definitely the first one to post about it out here. :) >> >> it works well on my brand new hp aio (18-5019il). >> > Upgraded smoothly from r151010 to r151012. Using fast reboot and by > server only had a down-time less than 30 sec. Impressive;-) > > Excellent work by Dan and Omniti:-) > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss From tom.robinson at motec.com.au Mon Sep 29 04:06:19 2014 From: tom.robinson at motec.com.au (Tom Robinson) Date: Mon, 29 Sep 2014 14:06:19 +1000 Subject: [OmniOS-discuss] beadm activate issue (and pkg update fails to install boot files) In-Reply-To: <54225D6E.1040906@motec.com.au> References: <54225562.3030507@motec.com.au> <3DAC4A06-8F04-46DF-B5B8-7BF8E207E563@omniti.com> <542257A2.3040009@motec.com.au> <663E7CB7-D2F1-4078-9B11-E7D1239E28EF@omniti.com> <54225940.2050805@motec.com.au> <54225AF9.4050506@motec.com.au> <54225D6E.1040906@motec.com.au> Message-ID: <5428DABB.3020500@motec.com.au> On 24/09/14 15:58, Tom Robinson wrote: > On 24/09/14 15:47, Tom Robinson wrote: >> On 24/09/14 15:40, Tom Robinson wrote: >>> On 24/09/14 15:35, Dan McDonald wrote: >>>> On Sep 24, 2014, at 1:33 AM, Tom Robinson wrote: >>>> >>>>> Thanks Dan, I can see where you're going with that idea. Should I pay any attention to: >>>>> >>>>> Partition 0 of the disk has an incorrect offset >>>>> Unable to gather device information for /dev/rdsk/c4t3d0s0 >>>> That is a bit disturbing. >>>> >>>> What about the other one in the mirror? c4t2d0s0 ? >>> Nothing reported by beadm. I'm not sure if c4t3d0s0 is first or last according to installgrub. Is >>> the only way to tell by running installgrub? I get nervous at this point. Also my next maintenance >>> window will most likely not be until next week. >>> >>> In theory, installgrub shouldn't have any influence on the currently booted system, right? >> Ok, since c4t3d0s0 IS failing to accept the installgrub here goes: >> >> # installgrub /boot/grub/stage1 /boot/grub/stage2 /dev/rdsk/c4t3d0s0 >> Partition 0 of the disk has an incorrect offset >> Unable to gather device information for /dev/rdsk/c4t3d0s0 >> >> and >> >> # installgrub /mnt/boot/grub/stage1 /boot/grub/stage2 /dev/rdsk/c4t3d0s0 >> Partition 0 of the disk has an incorrect offset >> Unable to gather device information for /dev/rdsk/c4t3d0s0 >> >> I'm still nervous about running this on my (apparently) only bootable disk... (c4t2d0s0) > prtvtoc shows cylinders and accessible cylinders differ by one: > > # prtvtoc /dev/rdsk/c4t3d0s0 > * /dev/rdsk/c4t3d0s0 partition map > * > * Dimensions: > * 512 bytes/sector > * 56 sectors/track > * 224 tracks/cylinder > * 12544 sectors/cylinder > * 18689 cylinders > * 18687 accessible cylinders > * > * Flags: > * 1: unmountable > * 10: read-only > * > * Unallocated space: > * First Sector Last > * Sector Count Sector > * 0 12544 12543 > * > * First Sector Last > * Partition Tag Flags Sector Count Sector Mount Directory > 0 2 00 12544 234384640 234397183 > 2 5 01 0 234422272 234422271 > 8 1 01 0 12544 12543 > > # prtvtoc /dev/rdsk/c4t2d0s0 > * /dev/rdsk/c4t2d0s0 partition map > * > * Dimensions: > * 512 bytes/sector > * 56 sectors/track > * 224 tracks/cylinder > * 12544 sectors/cylinder > * 18688 cylinders > * 18686 accessible cylinders > * > * Flags: > * 1: unmountable > * 10: read-only > * > * Unallocated space: > * First Sector Last > * Sector Count Sector > * 0 12544 12543 > * > * First Sector Last > * Partition Tag Flags Sector Count Sector Mount Directory > 0 2 00 12544 234384640 234397183 > 2 5 01 0 234422272 234422271 > 8 1 01 0 12544 12543 > > # prtvtoc /dev/rdsk/c4t3d0s0 > /tmp/prtvtoc-c4t3d0s0 > > # prtvtoc /dev/rdsk/c4t2d0s0 > /tmp/prtvtoc-c4t2d0s0 > > # diff /tmp/prtvtoc-c4t2d0s0 /tmp/prtvtoc-c4t3d0s0 > 1c1 > < * /dev/rdsk/c4t2d0s0 partition map > --- >> * /dev/rdsk/c4t3d0s0 partition map > 8,9c8,9 > < * 18688 cylinders > < * 18686 accessible cylinders > --- >> * 18689 cylinders >> * 18687 accessible cylinders Maybe recreating the mirror would work. Not sure what happened but I could possibly follow this: http://malsserver.blogspot.com.au/2008/08/mirroring-resolved-correct-way.html Especially note comments by Malachi de ?lfweald 11/25/2008 8:49 PM >> before doing the fmthard, you have to do fdisk on the new drive -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From tom.robinson at motec.com.au Mon Sep 29 04:26:52 2014 From: tom.robinson at motec.com.au (Tom Robinson) Date: Mon, 29 Sep 2014 14:26:52 +1000 Subject: [OmniOS-discuss] beadm activate issue (and pkg update fails to install boot files) Message-ID: <5428DF8C.1050601@motec.com.au> After a lot of reading I decided to break the mirror: # zpool detach rpool c4t3d0s0 Now the issue was how to format that device to match up with the remaining mirror disk. I'm using an x86 architecture so I need to use fdisk first. I also found I need to use a different device that fdisk will understand: c4t3d0p0 # fdisk -B /dev/rdsk/c4t3d0p0 (-B defaults to one Solaris partition that uses the whole disk). # prtvtoc /dev/rdsk/c4t3d0s0 * /dev/rdsk/c4t3d0s0 partition map * * Dimensions: * 512 bytes/sector * 56 sectors/track * 224 tracks/cylinder * 12544 sectors/cylinder * 18688 cylinders * 18686 accessible cylinders * * Flags: * 1: unmountable * 10: read-only * * Unallocated space: * First Sector Last * Sector Count Sector * 12544 234384640 234397183 * * First Sector Last * Partition Tag Flags Sector Count Sector Mount Directory 2 5 01 0 234397184 234397183 8 1 01 0 12544 12543 Woohoo! That's looking better. It matches the remaining mirror disk (c4t2d0p0). So now I do this: # prtvtoc /dev/rdsk/c4t2d0s0 | fmthard -s - /dev/rdsk/c4t3d0s0 fmthard: Partition 2 specifies the full disk and is not equal full size of disk. The full disk capacity is 234397184 sectors. fmthard: Partition 2 specified as 234422272 sectors starting at 0 does not fit. The full disk contains 234397184 sectors. fmthard: New volume table of contents now in place. Which worries me slightly but 'diffing' the prtvtoc outputs shows the two disks now share the same layout: # prtvtoc /dev/rdsk/c4t2d0s0 > /tmp/c4t2d0s0 # prtvtoc /dev/rdsk/c4t3d0s0 > /tmp/c4t3d0s0 # diff /tmp/c4t2d0s0 /tmp/c4t3d0s0 1c1 < * /dev/rdsk/c4t2d0s0 partition map --- > * /dev/rdsk/c4t3d0s0 partition map So I decide to attach the disk to the mirror again: # zpool attach -f rpool c4t2d0s0 c4t3d0s0 Make sure to wait until resilver is done before rebooting. # zpool status rpool pool: rpool state: ONLINE status: One or more devices is currently being resilvered. The pool will continue to function, possibly in a degraded state. action: Wait for the resilver to complete. scan: resilver in progress since Mon Sep 29 14:02:05 2014 818M scanned out of 71.4G at 68.1M/s, 0h17m to go 814M resilvered, 1.12% done config: NAME STATE READ WRITE CKSUM rpool ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 c4t2d0s0 ONLINE 0 0 0 c4t3d0s0 ONLINE 0 0 0 (resilvering) errors: No known data errors # beadm activate r151010 Activated successfully # beadm list r151010 BE Active Mountpoint Space Policy Created r151010 NR / 7.34G static 2014-09-24 07:47 Do I still need to run installgrub? Thanks to all those who contributed Regards, Tom -- Tom Robinson IT Manager/System Administrator MoTeC Pty Ltd 121 Merrindale Drive Croydon South 3136 Victoria Australia T: +61 3 9761 5050 F: +61 3 9761 5051 E: tom.robinson at motec.com.au -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From filip.marvan at aira.cz Mon Sep 29 09:59:27 2014 From: filip.marvan at aira.cz (Filip Marvan) Date: Mon, 29 Sep 2014 11:59:27 +0200 Subject: [OmniOS-discuss] Managing KVM virtual machines In-Reply-To: <4cf467ff3390a378ce5fc74fb73386e4@blackdot.be> References: <3BE0DEED8863E5429BAE4CAEDF6245650368955678B4@AIRA-SRV.aira.local> <4cf467ff3390a378ce5fc74fb73386e4@blackdot.be> Message-ID: <3BE0DEED8863E5429BAE4CAEDF624565036895567920@AIRA-SRV.aira.local> Hello Jorge, thank you for reply. I found another quite simply solution. When I set sevice properties in manifest like this: it does exactly what I need. Qemu process is still monitored by SMF, but when process stoped (because of shutdown from guest), SMF will not restart process again, but service is switched to maintanance mode. So now when I list KVM services, I can see, which are running (are online) and which are not (are maintanance). Filip From: Jorge Schrauwen [mailto:sjorge+ml at blackdot.be] Sent: Friday, September 26, 2014 11:35 PM To: Filip Marvan Cc: omnios-discuss at lists.omniti.com Subject: Re: [OmniOS-discuss] Managing KVM virtual machines You can make qemu dump a monitoring socket, you can then use netcat to send commands like acpi shutdown events but also query other info. If the socket is dead, the qemu process crashed. So applying some wrapper magic it could be possible to make the svc more intelligent. I can't offor you a working manifest though :( I theorized about it but deemed it too much work for the one vm I run. I do use the qemu monitoring socket however. -chardev socket,id=monitor,path=/vms/hosts/${VMNAME}/run/monitor.sock,server,nowait \ -monitor chardev:monitor \ To add the monitor Hope this is somewhat helpful! Regards Jorge -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6247 bytes Desc: not available URL: From sjorge+ml at blackdot.be Mon Sep 29 13:57:54 2014 From: sjorge+ml at blackdot.be (Jorge Schrauwen) Date: Mon, 29 Sep 2014 15:57:54 +0200 Subject: [OmniOS-discuss] Managing KVM virtual machines In-Reply-To: <3BE0DEED8863E5429BAE4CAEDF624565036895567920@AIRA-SRV.aira.local> References: <3BE0DEED8863E5429BAE4CAEDF6245650368955678B4@AIRA-SRV.aira.local> <4cf467ff3390a378ce5fc74fb73386e4@blackdot.be> <3BE0DEED8863E5429BAE4CAEDF624565036895567920@AIRA-SRV.aira.local> Message-ID: <845bce0a17c238baeac9f5392a6ed3b7@blackdot.be> This will not cleanly shutdown your vm's at system halt though. But if you can live with that, that will work fine :) On 2014-09-29 11:59, Filip Marvan wrote: > Hello Jorge, > > thank you for reply. I found another quite simply solution. When I set sevice properties in manifest like this: > > > > > > > > > > it does exactly what I need. Qemu process is still monitored by SMF, but when process stoped (because of shutdown from guest), SMF will not restart process again, but service is switched to maintanance mode. > > So now when I list KVM services, I can see, which are running (are online) and which are not (are maintanance). > > Filip > > FROM: Jorge Schrauwen [mailto:sjorge+ml at blackdot.be] > SENT: Friday, September 26, 2014 11:35 PM > TO: Filip Marvan > CC: omnios-discuss at lists.omniti.com > SUBJECT: Re: [OmniOS-discuss] Managing KVM virtual machines > > You can make qemu dump a monitoring socket, you can then use netcat to send commands like acpi shutdown events but also query other info. If the socket is dead, the qemu process crashed. > > So applying some wrapper magic it could be possible to make the svc more intelligent. I can't offor you a working manifest though :( I theorized about it but deemed it too much work for the one vm I run. I do use the qemu monitoring socket however. > > -chardev socket,id=monitor,path=/vms/hosts/${VMNAME}/run/monitor.sock,server,nowait > -monitor chardev:monitor > > To add the monitor > > Hope this is somewhat helpful! > > Regards > > Jorge -------------- next part -------------- An HTML attachment was scrubbed... URL: From mir at miras.org Sat Sep 27 23:16:33 2014 From: mir at miras.org (Michael Rasmussen) Date: Sun, 28 Sep 2014 01:16:33 +0200 Subject: [OmniOS-discuss] running r151012 : quite smoothly ... In-Reply-To: <20140928004259.00c6a4ea@sleipner.datanom.net> References: <114786aee4daf4d0f46eb367b606d9b9@kathe.in> <20140928004259.00c6a4ea@sleipner.datanom.net> Message-ID: <20140928011633.6b7022ab@sleipner.datanom.net> I did a quick iozone test before and after the upgrade from r151010 to r151012. Seems ZFS has slightly improved performance from r151010 to r151012. See attached PDF. -- Hilsen/Regards Michael Rasmussen Get my public GnuPG keys: michael rasmussen cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir miras org http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 -------------------------------------------------------------- /usr/games/fortune -es says: Do, or do not; there is no try. -------------- next part -------------- A non-text attachment was scrubbed... Name: iozone.pdf Type: application/pdf Size: 1231651 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From sjorge+ml at blackdot.be Mon Sep 29 14:34:59 2014 From: sjorge+ml at blackdot.be (Jorge Schrauwen) Date: Mon, 29 Sep 2014 16:34:59 +0200 Subject: [OmniOS-discuss] OmniOS r151012 vioblk not working with ISO Message-ID: Hey Guys, In the requests thread for r151012 I brought up vioblk and it was included in entire (yay!). But it seems the ISO installer does not see disks of type 'virtio' in KVM :( I'm adding my disk like this: -drive file=/dev/zvol/dsk/core/vms/hosts/leonov/disk0,if=virtio,index=0 Any ideas how to troubleshoot this? Booting a linux iso with instead of OmniOS the disk is properly detected ?? Regards Jorge -------------- next part -------------- A non-text attachment was scrubbed... Name: Capture.PNG Type: image/png Size: 34774 bytes Desc: not available URL: From filip.marvan at aira.cz Mon Sep 29 14:40:04 2014 From: filip.marvan at aira.cz (Filip Marvan) Date: Mon, 29 Sep 2014 16:40:04 +0200 Subject: [OmniOS-discuss] Managing KVM virtual machines In-Reply-To: <845bce0a17c238baeac9f5392a6ed3b7@blackdot.be> References: <3BE0DEED8863E5429BAE4CAEDF6245650368955678B4@AIRA-SRV.aira.local> <4cf467ff3390a378ce5fc74fb73386e4@blackdot.be> <3BE0DEED8863E5429BAE4CAEDF624565036895567920@AIRA-SRV.aira.local> <845bce0a17c238baeac9f5392a6ed3b7@blackdot.be> Message-ID: <3BE0DEED8863E5429BAE4CAEDF62456503689556794E@AIRA-SRV.aira.local> For shutdown from host I'm using monitor and "system_powerdown" qemu command through netcat exactly as you wrote before, and I have this configured in service manifest as well. So on system halt it cleanly shutdown all my vm's with ACPI support, there is no problem with that. I think that it finally solved all my problems with KVM on OmniOS. I can see if vm's are running or not, they are not restarted automatically after shutdown from guest and I'm able to cleanly shutdown them with: svcadm disable vmname. Filip From: Jorge Schrauwen [mailto:sjorge+ml at blackdot.be] Sent: Monday, September 29, 2014 3:58 PM To: Filip Marvan Cc: omnios-discuss at lists.omniti.com Subject: RE: [OmniOS-discuss] Managing KVM virtual machines This will not cleanly shutdown your vm's at system halt though. But if you can live with that, that will work fine :) -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6247 bytes Desc: not available URL: From mmabis at vmware.com Mon Sep 29 17:20:19 2014 From: mmabis at vmware.com (Matthew Mabis) Date: Mon, 29 Sep 2014 17:20:19 +0000 Subject: [OmniOS-discuss] Infiniband In Omni Message-ID: Hey All I was wondering if someone who has been using IB in their lab has any good advice for someone just starting to integrate IB into their ZFS environment. I have Connect-X (HCA) Card put into the host ( i do have a CX3 but i have heard its not natively supported and there were issues with the drivers) what i am looking for is this Any Best Practices for using IPoIB with OmniOS? Should i use the Stock drivers build into solaris (are there different ones that work better more stable?) Are there Management tools i can install to run further tests? Any other Guidelines you might recommend. What i am going to attempt is my 3 ESXI hosts have CX-3 (VPI Pro Cards) connected to a SX6012 Switch i have a CX4 to QSFP cable coming to hook it into the switch and wanted to see if there would be any problems (yes the CX card is 20Gb/s) but this is the best i can offer it based on the drivers. Anything someone might see as an issue (Gonna try iSCSI/NFS with This method direct lines to the hosts) uses CIFS on the 1Gb Ether. Thanks Matt Mabis -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan.kragsterman at capvert.se Mon Sep 29 17:33:09 2014 From: johan.kragsterman at capvert.se (Johan Kragsterman) Date: Mon, 29 Sep 2014 19:33:09 +0200 Subject: [OmniOS-discuss] Ang: Infiniband In Omni In-Reply-To: References: Message-ID: -----"OmniOS-discuss" skrev: ----- Fr?n: Matthew Mabis S?nt av: "OmniOS-discuss" Datum: 2014-09-29 19:21 Kopia: "omnios-discuss at lists.omniti.com" ?rende: [OmniOS-discuss] Infiniband In Omni Hey All I was wondering if someone who has been using IB in their lab has any good advice for someone just starting to integrate IB into their ZFS environment. ?I have Connect-X (HCA) Card put into the host ( i do have a CX3 but i have heard its not natively supported and there were issues with the drivers) what i am looking for is this ? ? Any Best Practices for using IPoIB with OmniOS? ? ? Should i use the Stock drivers build into solaris (are there different ones that work better more stable?) ? ? Are there Management tools i can install to run further tests? ? ? Any other Guidelines you might recommend. What i am going to attempt is my 3 ESXI hosts have CX-3 (VPI Pro Cards) connected to a SX6012 Switch i have a CX4 to QSFP cable coming to hook it into the switch and wanted to see if there would be any problems (yes the CX card is 20Gb/s) but this is the best i can offer it based on the drivers. Anything someone might see as an issue (Gonna try iSCSI/NFS with This method direct lines to the hosts) uses CIFS on the 1Gb Ether.? Thanks Matt Mabis Well, I'm interested in that! Why not try srp? Can you run srp initiator from VmWare? Perhaps not ESXi, but from ESX? Have you thought of OpenSM? Rgrds Johan _______________________________________________ OmniOS-discuss mailing list OmniOS-discuss at lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss From narayan.desai at gmail.com Mon Sep 29 18:02:44 2014 From: narayan.desai at gmail.com (Narayan Desai) Date: Mon, 29 Sep 2014 14:02:44 -0400 Subject: [OmniOS-discuss] Infiniband In Omni In-Reply-To: References: Message-ID: I hate to sound negative, but you're in for a bad time. The current drivers were written by sun/oracle, and only just happen to still work. Parts (like IPoIB) work, but others (EoIB) will randomly panic. Hardware support is limited to connectx 1-2. And if anything goes wrong, there isn't anyone that can really help you. That all said, we had decent success with iscsi/iSER over connectX 1 cards. Fujita Syoyo forward ported the last version of the OFED stack that Sun/Oracle modified up to more recent illumos. Those bits are here: https://github.com/syoyo/solaris-infiniband-tools -nld On Mon, Sep 29, 2014 at 1:20 PM, Matthew Mabis wrote: > Hey All > > I was wondering if someone who has been using IB in their lab has any > good advice for someone just starting to integrate IB into their ZFS > environment. I have Connect-X (HCA) Card put into the host ( i do have a > CX3 but i have heard its not natively supported and there were issues with > the drivers) what i am looking for is this > > Any Best Practices for using IPoIB with OmniOS? > Should i use the Stock drivers build into solaris (are there different > ones that work better more stable?) > Are there Management tools i can install to run further tests? > Any other Guidelines you might recommend. > > What i am going to attempt is my 3 ESXI hosts have CX-3 (VPI Pro Cards) > connected to a SX6012 Switch i have a CX4 to QSFP cable coming to hook it > into the switch and wanted to see if there would be any problems (yes the > CX card is 20Gb/s) but this is the best i can offer it based on the drivers. > > Anything someone might see as an issue (Gonna try iSCSI/NFS with This > method direct lines to the hosts) uses CIFS on the 1Gb Ether. > Thanks > *Matt Mabis* > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew.lagoe at subrigo.net Mon Sep 29 18:12:25 2014 From: matthew.lagoe at subrigo.net (Matthew Lagoe) Date: Mon, 29 Sep 2014 11:12:25 -0700 Subject: [OmniOS-discuss] Infiniband In Omni In-Reply-To: References: Message-ID: <00cc01cfdc10$eec2b940$cc482bc0$@subrigo.net> Also for infiniband you need a subnet manager, if your switch doesn?t have a built in one you have to run like a linux box on the same network just for traffic to work, as there wasn?t any I was able to find for openindiana back in the day, that?s why we went with 10gbe. From: OmniOS-discuss [mailto:omnios-discuss-bounces at lists.omniti.com] On Behalf Of Narayan Desai Sent: Monday, September 29, 2014 11:03 AM To: Matthew Mabis Cc: omnios-discuss at lists.omniti.com Subject: Re: [OmniOS-discuss] Infiniband In Omni I hate to sound negative, but you're in for a bad time. The current drivers were written by sun/oracle, and only just happen to still work. Parts (like IPoIB) work, but others (EoIB) will randomly panic. Hardware support is limited to connectx 1-2. And if anything goes wrong, there isn't anyone that can really help you. That all said, we had decent success with iscsi/iSER over connectX 1 cards. Fujita Syoyo forward ported the last version of the OFED stack that Sun/Oracle modified up to more recent illumos. Those bits are here: https://github.com/syoyo/solaris-infiniband-tools -nld On Mon, Sep 29, 2014 at 1:20 PM, Matthew Mabis wrote: Hey All I was wondering if someone who has been using IB in their lab has any good advice for someone just starting to integrate IB into their ZFS environment. I have Connect-X (HCA) Card put into the host ( i do have a CX3 but i have heard its not natively supported and there were issues with the drivers) what i am looking for is this Any Best Practices for using IPoIB with OmniOS? Should i use the Stock drivers build into solaris (are there different ones that work better more stable?) Are there Management tools i can install to run further tests? Any other Guidelines you might recommend. What i am going to attempt is my 3 ESXI hosts have CX-3 (VPI Pro Cards) connected to a SX6012 Switch i have a CX4 to QSFP cable coming to hook it into the switch and wanted to see if there would be any problems (yes the CX card is 20Gb/s) but this is the best i can offer it based on the drivers. Anything someone might see as an issue (Gonna try iSCSI/NFS with This method direct lines to the hosts) uses CIFS on the 1Gb Ether. Thanks Matt Mabis _______________________________________________ OmniOS-discuss mailing list OmniOS-discuss at lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss -------------- next part -------------- An HTML attachment was scrubbed... URL: From zembower at criterion.com Mon Sep 29 18:26:00 2014 From: zembower at criterion.com (Chris Zembower) Date: Mon, 29 Sep 2014 14:26:00 -0400 Subject: [OmniOS-discuss] Infiniband In Omni Message-ID: I'm actually lab'ing with this right now in OmniOS! Although using SRP, and not to ESX initiators... Currently I have a mini-ITX board with a single PCIe 3.0 x16 slot, populated with a ConnectX-2. zpool is 4x1TB SSD's (on mainboard SATA 6gb/s SATA ports) in a zvol, exported via Comstar to Windows7 SRP initiator (OFED). Performance is about 1.2GB/s on sequential I/O. I threw log data at it all weekend to see if it would hiccup, so far so good. Not bad, and couldn't have been easier to set up. Essentially plug and play, took my 3 hours from unboxing the board to working SRP target. My currently production environment is Linux/SCST/ConnectX-3. Performance is fine (aggregate bandwidth from a single server is in the 10GB/s area), but configuration is much more involved than Comstar and I'm running into some latency issues. I wanted to give Illumos an IB test drive and see how it held up. Fortunately, you don't need OpenSM because that switch has an integrated subnet manager. Not sure if those cards you're using are compatible, but if not, ConnectX-2's are cheap and perform quite well. Other comments are accurate, the Hermon/Tevor drivers don't seem to have been updated since forever ago (I have yet to investigate Fujita's port of OFED), so you can't use the newer HCA's, but everything does seem stable (and that's what's important, right?) Even on ConnectX-2, you're still using a fabric with twice the bandwidth of 16gb fibre channel... Good luck, interested to hear what you learn. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mmabis at vmware.com Mon Sep 29 18:31:45 2014 From: mmabis at vmware.com (Matthew Mabis) Date: Mon, 29 Sep 2014 18:31:45 +0000 Subject: [OmniOS-discuss] Infiniband In Omni In-Reply-To: <00cc01cfdc10$eec2b940$cc482bc0$@subrigo.net> References: , <00cc01cfdc10$eec2b940$cc482bc0$@subrigo.net> Message-ID: Thanks Narayan for the info that will really help! I assumed using IPoIB realistically for all the things i wanted. but i might want to test out RDSH and ISER as well. I just wanted to know what things i should expect using this type of card... also what firmwares are you using on your CX1/CX2s? i think all of mine are programmed to 2.7.0 as that was the most stable of firmwares for ESXi using Raphael's (Hypervisor.fr) OpenSM manager :) Matthew the SX6012 Switch that i have has an OpenSM manager on it so i don't have to deal with that specific issue. Here is a link to the switch i got. http://www.mellanox.com/related-docs/prod_ib_switch_systems/SX6012.pdf Matt Mabis ________________________________ From: Matthew Lagoe Sent: Monday, September 29, 2014 11:12 AM To: 'Narayan Desai'; Matthew Mabis Cc: omnios-discuss at lists.omniti.com Subject: RE: [OmniOS-discuss] Infiniband In Omni Also for infiniband you need a subnet manager, if your switch doesn't have a built in one you have to run like a linux box on the same network just for traffic to work, as there wasn't any I was able to find for openindiana back in the day, that's why we went with 10gbe. From: OmniOS-discuss [mailto:omnios-discuss-bounces at lists.omniti.com] On Behalf Of Narayan Desai Sent: Monday, September 29, 2014 11:03 AM To: Matthew Mabis Cc: omnios-discuss at lists.omniti.com Subject: Re: [OmniOS-discuss] Infiniband In Omni I hate to sound negative, but you're in for a bad time. The current drivers were written by sun/oracle, and only just happen to still work. Parts (like IPoIB) work, but others (EoIB) will randomly panic. Hardware support is limited to connectx 1-2. And if anything goes wrong, there isn't anyone that can really help you. That all said, we had decent success with iscsi/iSER over connectX 1 cards. Fujita Syoyo forward ported the last version of the OFED stack that Sun/Oracle modified up to more recent illumos. Those bits are here: https://github.com/syoyo/solaris-infiniband-tools -nld On Mon, Sep 29, 2014 at 1:20 PM, Matthew Mabis > wrote: Hey All I was wondering if someone who has been using IB in their lab has any good advice for someone just starting to integrate IB into their ZFS environment. I have Connect-X (HCA) Card put into the host ( i do have a CX3 but i have heard its not natively supported and there were issues with the drivers) what i am looking for is this Any Best Practices for using IPoIB with OmniOS? Should i use the Stock drivers build into solaris (are there different ones that work better more stable?) Are there Management tools i can install to run further tests? Any other Guidelines you might recommend. What i am going to attempt is my 3 ESXI hosts have CX-3 (VPI Pro Cards) connected to a SX6012 Switch i have a CX4 to QSFP cable coming to hook it into the switch and wanted to see if there would be any problems (yes the CX card is 20Gb/s) but this is the best i can offer it based on the drivers. Anything someone might see as an issue (Gonna try iSCSI/NFS with This method direct lines to the hosts) uses CIFS on the 1Gb Ether. Thanks Matt Mabis _______________________________________________ OmniOS-discuss mailing list OmniOS-discuss at lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss -------------- next part -------------- An HTML attachment was scrubbed... URL: From sjorge+ml at blackdot.be Mon Sep 29 18:35:51 2014 From: sjorge+ml at blackdot.be (Jorge Schrauwen) Date: Mon, 29 Sep 2014 20:35:51 +0200 Subject: [OmniOS-discuss] OmniOS r151012 vioblk not working with ISO In-Reply-To: References: Message-ID: <5ce5ee8ab3a5e99ff5556ea2201bedc4@blackdot.be> Just an update, switching to IDE sort of makes it install but it takes about an hour or so and it only boots once after that. It also only enables 1 cpu using either core2due, Nehalem or qemu64 cpu type. Does anybody have a working 012 running inside KVM on 012? Regards Jorge On 2014-09-29 16:34, Jorge Schrauwen wrote: > Hey Guys, > > In the requests thread for r151012 I brought up vioblk and it was > included in entire (yay!). But it seems the ISO installer does not see > disks of type 'virtio' in KVM :( > > I'm adding my disk like this: > -drive file=/dev/zvol/dsk/core/vms/hosts/leonov/disk0,if=virtio,index=0 > > Any ideas how to troubleshoot this? Booting a linux iso with instead > of OmniOS the disk is properly detected ?? > > Regards > > Jorge > > > > > > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss From matthew.lagoe at subrigo.net Mon Sep 29 19:08:59 2014 From: matthew.lagoe at subrigo.net (Matthew Lagoe) Date: Mon, 29 Sep 2014 12:08:59 -0700 Subject: [OmniOS-discuss] Infiniband In Omni In-Reply-To: References: , <00cc01cfdc10$eec2b940$cc482bc0$@subrigo.net> Message-ID: <011201cfdc18$d5e69ce0$81b3d6a0$@subrigo.net> We talked to mellanox when we were buying our gear, iirc there was an upgrade key you needed to go with the base switch for L2 functionality. If you are dealing with mellanox directly they are good, just if you are buying used or w/e be careful ^.^ From: Matthew Mabis [mailto:mmabis at vmware.com] Sent: Monday, September 29, 2014 11:32 AM To: Matthew Lagoe; 'Narayan Desai' Cc: omnios-discuss at lists.omniti.com Subject: RE: [OmniOS-discuss] Infiniband In Omni Thanks Narayan for the info that will really help! I assumed using IPoIB realistically for all the things i wanted. but i might want to test out RDSH and ISER as well. I just wanted to know what things i should expect using this type of card... also what firmwares are you using on your CX1/CX2s? i think all of mine are programmed to 2.7.0 as that was the most stable of firmwares for ESXi using Raphael's (Hypervisor.fr) OpenSM manager :) Matthew the SX6012 Switch that i have has an OpenSM manager on it so i don't have to deal with that specific issue. Here is a link to the switch i got. http://www.mellanox.com/related-docs/prod_ib_switch_systems/SX6012.pdf Matt Mabis _____ From: Matthew Lagoe Sent: Monday, September 29, 2014 11:12 AM To: 'Narayan Desai'; Matthew Mabis Cc: omnios-discuss at lists.omniti.com Subject: RE: [OmniOS-discuss] Infiniband In Omni Also for infiniband you need a subnet manager, if your switch doesn't have a built in one you have to run like a linux box on the same network just for traffic to work, as there wasn't any I was able to find for openindiana back in the day, that's why we went with 10gbe. From: OmniOS-discuss [mailto:omnios-discuss-bounces at lists.omniti.com] On Behalf Of Narayan Desai Sent: Monday, September 29, 2014 11:03 AM To: Matthew Mabis Cc: omnios-discuss at lists.omniti.com Subject: Re: [OmniOS-discuss] Infiniband In Omni I hate to sound negative, but you're in for a bad time. The current drivers were written by sun/oracle, and only just happen to still work. Parts (like IPoIB) work, but others (EoIB) will randomly panic. Hardware support is limited to connectx 1-2. And if anything goes wrong, there isn't anyone that can really help you. That all said, we had decent success with iscsi/iSER over connectX 1 cards. Fujita Syoyo forward ported the last version of the OFED stack that Sun/Oracle modified up to more recent illumos. Those bits are here: https://github.com/syoyo/solaris-infiniband-tools -nld On Mon, Sep 29, 2014 at 1:20 PM, Matthew Mabis wrote: Hey All I was wondering if someone who has been using IB in their lab has any good advice for someone just starting to integrate IB into their ZFS environment. I have Connect-X (HCA) Card put into the host ( i do have a CX3 but i have heard its not natively supported and there were issues with the drivers) what i am looking for is this Any Best Practices for using IPoIB with OmniOS? Should i use the Stock drivers build into solaris (are there different ones that work better more stable?) Are there Management tools i can install to run further tests? Any other Guidelines you might recommend. What i am going to attempt is my 3 ESXI hosts have CX-3 (VPI Pro Cards) connected to a SX6012 Switch i have a CX4 to QSFP cable coming to hook it into the switch and wanted to see if there would be any problems (yes the CX card is 20Gb/s) but this is the best i can offer it based on the drivers. Anything someone might see as an issue (Gonna try iSCSI/NFS with This method direct lines to the hosts) uses CIFS on the 1Gb Ether. Thanks Matt Mabis _______________________________________________ OmniOS-discuss mailing list OmniOS-discuss at lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss -------------- next part -------------- An HTML attachment was scrubbed... URL: From narayan.desai at gmail.com Mon Sep 29 19:09:20 2014 From: narayan.desai at gmail.com (Narayan Desai) Date: Mon, 29 Sep 2014 15:09:20 -0400 Subject: [OmniOS-discuss] Infiniband In Omni In-Reply-To: References: <00cc01cfdc10$eec2b940$cc482bc0$@subrigo.net> Message-ID: IIRC, we never worried much about firmware revisions; they were 2.7.0 or newer. I'd run a subnet manager on a regular linux box, just because it is easier to work with linux daemons than processes on a slow embedded linux on a switch. -nld On Mon, Sep 29, 2014 at 2:31 PM, Matthew Mabis wrote: > Thanks Narayan for the info that will really help! I assumed using > IPoIB realistically for all the things i wanted. but i might want to test > out RDSH and ISER as well. I just wanted to know what things i should > expect using this type of card... also what firmwares are you using on your > CX1/CX2s? i think all of mine are programmed to 2.7.0 as that was the most > stable of firmwares for ESXi using Raphael's (Hypervisor.fr) OpenSM manager > :) > > Matthew the SX6012 Switch that i have has an OpenSM manager on it so i > don't have to deal with that specific issue. Here is a link to the switch > i got. > > http://www.mellanox.com/related-docs/prod_ib_switch_systems/SX6012.pdf > > *Matt Mabis* > > ------------------------------ > *From:* Matthew Lagoe > *Sent:* Monday, September 29, 2014 11:12 AM > *To:* 'Narayan Desai'; Matthew Mabis > *Cc:* omnios-discuss at lists.omniti.com > *Subject:* RE: [OmniOS-discuss] Infiniband In Omni > > > Also for infiniband you need a subnet manager, if your switch doesn?t have > a built in one you have to run like a linux box on the same network just > for traffic to work, as there wasn?t any I was able to find for openindiana > back in the day, that?s why we went with 10gbe. > > > > *From:* OmniOS-discuss [mailto:omnios-discuss-bounces at lists.omniti.com] *On > Behalf Of *Narayan Desai > *Sent:* Monday, September 29, 2014 11:03 AM > *To:* Matthew Mabis > *Cc:* omnios-discuss at lists.omniti.com > *Subject:* Re: [OmniOS-discuss] Infiniband In Omni > > > > I hate to sound negative, but you're in for a bad time. The current > drivers were written by sun/oracle, and only just happen to still work. > Parts (like IPoIB) work, but others (EoIB) will randomly panic. Hardware > support is limited to connectx 1-2. And if anything goes wrong, there isn't > anyone that can really help you. > > > > That all said, we had decent success with iscsi/iSER over connectX 1 > cards. Fujita Syoyo forward ported the last version of the OFED stack that > Sun/Oracle modified up to more recent illumos. Those bits are here: > > https://github.com/syoyo/solaris-infiniband-tools > > > -nld > > > > On Mon, Sep 29, 2014 at 1:20 PM, Matthew Mabis wrote: > > Hey All > > > > I was wondering if someone who has been using IB in their lab has any good > advice for someone just starting to integrate IB into their ZFS > environment. I have Connect-X (HCA) Card put into the host ( i do have a > CX3 but i have heard its not natively supported and there were issues with > the drivers) what i am looking for is this > > > > Any Best Practices for using IPoIB with OmniOS? > > Should i use the Stock drivers build into solaris (are there different > ones that work better more stable?) > > Are there Management tools i can install to run further tests? > > Any other Guidelines you might recommend. > > > > What i am going to attempt is my 3 ESXI hosts have CX-3 (VPI Pro Cards) > connected to a SX6012 Switch i have a CX4 to QSFP cable coming to hook it > into the switch and wanted to see if there would be any problems (yes the > CX card is 20Gb/s) but this is the best i can offer it based on the drivers. > > > > Anything someone might see as an issue (Gonna try iSCSI/NFS with This > method direct lines to the hosts) uses CIFS on the 1Gb Ether. > > Thanks > > *Matt Mabis* > > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From danmcd at omniti.com Mon Sep 29 19:48:01 2014 From: danmcd at omniti.com (Dan McDonald) Date: Mon, 29 Sep 2014 15:48:01 -0400 Subject: [OmniOS-discuss] OmniOS r151012 vioblk not working with ISO In-Reply-To: <5ce5ee8ab3a5e99ff5556ea2201bedc4@blackdot.be> References: <5ce5ee8ab3a5e99ff5556ea2201bedc4@blackdot.be> Message-ID: <042D5761-B061-413B-A9C2-0053381288B2@omniti.com> On Sep 29, 2014, at 2:35 PM, Jorge Schrauwen wrote: > Just an update, switching to IDE sort of makes it install but it takes about an hour or so and it only boots once after that. > > It also only enables 1 cpu using either core2due, Nehalem or qemu64 cpu type. > > Does anybody have a working 012 running inside KVM on 012? I have to ask --> what problem are you solving by running a full KVMed 012 inside 012? What does that buy you that a simple native zone can't? I understand there's virtio issues, but I figured you'd be having them on some other KVM. Don't forget that ZFS-inside-ZFS is akin to running TCP-inside-TCP w.r.t. unusual feedback loops and patterns. Dan From sjorge+ml at blackdot.be Mon Sep 29 19:48:56 2014 From: sjorge+ml at blackdot.be (Jorge Schrauwen) Date: Mon, 29 Sep 2014 21:48:56 +0200 Subject: [OmniOS-discuss] OmniOS r151012 vioblk not working with ISO In-Reply-To: <042D5761-B061-413B-A9C2-0053381288B2@omniti.com> References: <5ce5ee8ab3a5e99ff5556ea2201bedc4@blackdot.be> <042D5761-B061-413B-A9C2-0053381288B2@omniti.com> Message-ID: <0a8df081c9ea154c4aec50791b3cb1bb@blackdot.be> Build environment, that's the only reason. AFAIK that still does not work in a zone yet. On 2014-09-29 21:48, Dan McDonald wrote: > On Sep 29, 2014, at 2:35 PM, Jorge Schrauwen > wrote: > >> Just an update, switching to IDE sort of makes it install but it takes >> about an hour or so and it only boots once after that. >> >> It also only enables 1 cpu using either core2due, Nehalem or qemu64 >> cpu type. >> >> Does anybody have a working 012 running inside KVM on 012? > > I have to ask --> what problem are you solving by running a full KVMed > 012 inside 012? What does that buy you that a simple native zone > can't? > > I understand there's virtio issues, but I figured you'd be having them > on some other KVM. Don't forget that ZFS-inside-ZFS is akin to > running TCP-inside-TCP w.r.t. unusual feedback loops and patterns. > > Dan From cks at cs.toronto.edu Mon Sep 29 19:51:04 2014 From: cks at cs.toronto.edu (Chris Siebenmann) Date: Mon, 29 Sep 2014 15:51:04 -0400 Subject: [OmniOS-discuss] Debugging reproducable iSCSI initiator hang problem? Message-ID: <20140929195105.01D7B5A105A@testapps.cs.toronto.edu> We have found a reproducable iSCSI initiator issue in our environment. The short form version of the hang is that if there is a network interruption between one of our OmniOS machines and an iSCSI target and you run 'iscsiadm list target -S' in a roughly 30-second window after the interruption starts and before the OmniOS iSCSI initiator subsystem really notices the problem, 'iscsiadm' will hang in an uninterruptable state. Further iscsiadm commands will also hang and we have seen machines escalate into full-scale system lockups. Because this is completely reproducable for us, we have a 'savecore -L' vmdump file (and can generate as many more as would be useful, and we can fully panic a test system if desired). However I don't have much experience poking around OmniOS crash dumps. Where should I be looking as far as mdb commands and so on go? Is there any particular state that would be most useful to get a test machine into before taking/forcing a crash dump? Thanks in advance. - cks [For people who want to know more about our iSCSI configuration, the setup is described here: http://utcc.utoronto.ca/~cks/space/blog/solaris/ZFSFileserverSetupII It may be relevant that we're running multipathing over two separate iSCSI networks; we've not currently tried to reproduce this with only a single network or without multipathing enabled. ] From danmcd at omniti.com Mon Sep 29 20:08:30 2014 From: danmcd at omniti.com (Dan McDonald) Date: Mon, 29 Sep 2014 16:08:30 -0400 Subject: [OmniOS-discuss] OmniOS r151012 vioblk not working with ISO In-Reply-To: <0a8df081c9ea154c4aec50791b3cb1bb@blackdot.be> References: <5ce5ee8ab3a5e99ff5556ea2201bedc4@blackdot.be> <042D5761-B061-413B-A9C2-0053381288B2@omniti.com> <0a8df081c9ea154c4aec50791b3cb1bb@blackdot.be> Message-ID: <2110698B-55F8-44A4-9311-E84615141A49@omniti.com> On Sep 29, 2014, at 3:48 PM, Jorge Schrauwen wrote: > Build environment, that's the only reason. > AFAIK that still does not work in a zone yet. You can build illumos-omnios in a zone, but not *some* of the omnios-build packages (kayak primarily). Dan From nsmith at careyweb.com Mon Sep 29 20:10:55 2014 From: nsmith at careyweb.com (Nate Smith) Date: Mon, 29 Sep 2014 16:10:55 -0400 Subject: [OmniOS-discuss] SATA SSD vs. SAS Message-ID: Recently purchased a large number of 480GB datacenter grade SSDs with the idea to make a ZPOOL for a VM infrastructure. After receiving, I realized that they are SATA and not SAS, and that I'd completely overlooked that fact. I was planning on using them in a DELL R720XD which only uses two SAS cables for 24x2.5" disks. Since this backplane is obviously a SAS expander/multiplier, it will probably lead to disastrous results with SATA drives. Everything I've read says "don't use SAS expanders with SATA drives." (not to mention, that I'll completely saturate the data paths with these). In that vein, I've got a few questions. People choose SATA for SSD, because when it comes to SSD, the price may be 4-10 times as much for SAS. I've seen lots of setups with SAS spinning disks and SATA for L2ARC or ZIL. How are people connecting SATA disks for just these tasks and avoiding problems? Straight onto the SATA port on the motherboard? Are there any SATA only controllers that work well for SSD on Omnios? Does anyone know of any JBODs that are expander/multiplier free that would work for this setup? I have had a hard time finding any. Has anyone had any luck with interposers? I read this report, and it sounded promising till I got to the end. http://xnat.org/blog/xnat-hardware/rsf-1-high-availablity-ssd-pool-for-vm-storage-and-build-space/ Thanks in advance, -- Nate Smith From sjorge+ml at blackdot.be Mon Sep 29 20:14:37 2014 From: sjorge+ml at blackdot.be (Jorge Schrauwen) Date: Mon, 29 Sep 2014 22:14:37 +0200 Subject: [OmniOS-discuss] OmniOS r151012 vioblk not working with ISO In-Reply-To: <2110698B-55F8-44A4-9311-E84615141A49@omniti.com> References: <5ce5ee8ab3a5e99ff5556ea2201bedc4@blackdot.be> <042D5761-B061-413B-A9C2-0053381288B2@omniti.com> <0a8df081c9ea154c4aec50791b3cb1bb@blackdot.be> <2110698B-55F8-44A4-9311-E84615141A49@omniti.com> Message-ID: <711a51ca17c8919232b654f72dc71279@blackdot.be> Excellent news, I would greatly prefer a zone over a kvm! I'll be mostly interested in building illumos-gate and illumos-omnios. Some more info: Omnios 012 works fine on and is 'usable' on SmartOS using ide mode. Fails the same way with vioblk :( So it seems to be am OmniOS 012 on OmniOS KVM issue. But hey if zones work, i'm not going to waste more time. Regards Jorge On 2014-09-29 22:08, Dan McDonald wrote: > On Sep 29, 2014, at 3:48 PM, Jorge Schrauwen > wrote: > >> Build environment, that's the only reason. >> AFAIK that still does not work in a zone yet. > > You can build illumos-omnios in a zone, but not *some* of the > omnios-build packages (kayak primarily). > > Dan From danmcd at omniti.com Mon Sep 29 20:17:21 2014 From: danmcd at omniti.com (Dan McDonald) Date: Mon, 29 Sep 2014 16:17:21 -0400 Subject: [OmniOS-discuss] OmniOS r151012 vioblk not working with ISO In-Reply-To: <711a51ca17c8919232b654f72dc71279@blackdot.be> References: <5ce5ee8ab3a5e99ff5556ea2201bedc4@blackdot.be> <042D5761-B061-413B-A9C2-0053381288B2@omniti.com> <0a8df081c9ea154c4aec50791b3cb1bb@blackdot.be> <2110698B-55F8-44A4-9311-E84615141A49@omniti.com> <711a51ca17c8919232b654f72dc71279@blackdot.be> Message-ID: <23C4A8C5-0E68-4D97-91AA-8AFD2476DD5B@omniti.com> On Sep 29, 2014, at 4:14 PM, Jorge Schrauwen wrote: > Excellent news, I would greatly prefer a zone over a kvm! > I'll be mostly interested in building illumos-gate and illumos-omnios. You can't build illumos-gate just yet on omnios. But unless you're dinking in specific subsystems, you can develop with illumos-omnios, then shuffle it over to illumos-gate for a last-minute OI build pre-integration. > Some more info: Omnios 012 works fine on and is 'usable' on SmartOS using ide mode. Fails the same way with vioblk :( > So it seems to be am OmniOS 012 on OmniOS KVM issue. But hey if zones work, i'm not going to waste more time. I build illumos-omnios occasionally on my HDC's "omniti" zone. make-clobber-to-full in <100 minutes (CPU bound with my low-power Xeon E3). Dan From sjorge+ml at blackdot.be Mon Sep 29 20:19:07 2014 From: sjorge+ml at blackdot.be (Jorge Schrauwen) Date: Mon, 29 Sep 2014 22:19:07 +0200 Subject: [OmniOS-discuss] OmniOS r151012 vioblk not working with ISO In-Reply-To: <23C4A8C5-0E68-4D97-91AA-8AFD2476DD5B@omniti.com> References: <5ce5ee8ab3a5e99ff5556ea2201bedc4@blackdot.be> <042D5761-B061-413B-A9C2-0053381288B2@omniti.com> <0a8df081c9ea154c4aec50791b3cb1bb@blackdot.be> <2110698B-55F8-44A4-9311-E84615141A49@omniti.com> <711a51ca17c8919232b654f72dc71279@blackdot.be> <23C4A8C5-0E68-4D97-91AA-8AFD2476DD5B@omniti.com> Message-ID: Alright! I'm stuck home (crushed nerv in foot) the entire week so if you got a bit of time to point me in the right way to setup a zone like that. That would be sweet. Finishing some last bits of testing to with OmniOS vs SmartOS KVM running 012 because I just want to be complete for my self :) Regards Jorge On 2014-09-29 22:17, Dan McDonald wrote: > On Sep 29, 2014, at 4:14 PM, Jorge Schrauwen > wrote: > >> Excellent news, I would greatly prefer a zone over a kvm! >> I'll be mostly interested in building illumos-gate and illumos-omnios. > > You can't build illumos-gate just yet on omnios. But unless you're > dinking in specific subsystems, you can develop with illumos-omnios, > then shuffle it over to illumos-gate for a last-minute OI build > pre-integration. > >> Some more info: Omnios 012 works fine on and is 'usable' on SmartOS >> using ide mode. Fails the same way with vioblk :( >> So it seems to be am OmniOS 012 on OmniOS KVM issue. But hey if zones >> work, i'm not going to waste more time. > > I build illumos-omnios occasionally on my HDC's "omniti" zone. > make-clobber-to-full in <100 minutes (CPU bound with my low-power Xeon > E3). > > Dan From matthew.lagoe at subrigo.net Mon Sep 29 20:23:32 2014 From: matthew.lagoe at subrigo.net (matthew lagoe) Date: Mon, 29 Sep 2014 13:23:32 -0700 Subject: [OmniOS-discuss] SATA SSD vs. SAS Message-ID: Most people who care about uptime and want to avoid problems don't mix sas and SATA however if you do want to mix them I would recommend using onboard SATA ports or a SATA expander for just the sata drive That said you can mix them and potentially not have issues however the likelihood of problems is significantly greater Nate Smith wrote: Recently purchased a large number of 480GB datacenter grade SSDs with the idea to make a ZPOOL for a VM infrastructure. After receiving, I realized that they are SATA and not SAS, and that I'd completely overlooked that fact. I was planning on using them in a DELL R720XD which only uses two SAS cables for 24x2.5" disks. Since this backplane is obviously a SAS expander/multiplier, it will probably lead to disastrous results with SATA drives. Everything I've read says "don't use SAS expanders with SATA drives." (not to mention, that I'll completely saturate the data paths with these). In that vein, I've got a few questions. People choose SATA for SSD, because when it comes to SSD, the price may be 4-10 times as much for SAS. I've seen lots of setups with SAS spinning disks and SATA for L2ARC or ZIL. How are people connecting SATA disks for just these tasks and avoiding problems? Straight onto the SATA port on the motherboard? Are there any SATA only controllers that work well for SSD on Omnios? Does anyone know of any JBODs that are expander/multiplier free that would work for this setup? I have had a hard time finding any. Has anyone had any luck with interposers? I read this report, and it sounded promising till I got to the end. http://xnat.org/blog/xnat-hardware/rsf-1-high-availablity-ssd-pool-for-vm-st orage-and-build-space/ Thanks in advance, -- Nate Smith _______________________________________________ OmniOS-discuss mailing list OmniOS-discuss at lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss -------------- next part -------------- An HTML attachment was scrubbed... URL: From danmcd at omniti.com Mon Sep 29 20:24:05 2014 From: danmcd at omniti.com (Dan McDonald) Date: Mon, 29 Sep 2014 16:24:05 -0400 Subject: [OmniOS-discuss] OmniOS r151012 vioblk not working with ISO In-Reply-To: References: <5ce5ee8ab3a5e99ff5556ea2201bedc4@blackdot.be> <042D5761-B061-413B-A9C2-0053381288B2@omniti.com> <0a8df081c9ea154c4aec50791b3cb1bb@blackdot.be> <2110698B-55F8-44A4-9311-E84615141A49@omniti.com> <711a51ca17c8919232b654f72dc71279@blackdot.be> <23C4A8C5-0E68-4D97-91AA-8AFD2476DD5B@omniti.com> Message-ID: <3E44D17C-50CE-4A2E-8C05-BC766A7AED4A@omniti.com> On Sep 29, 2014, at 4:19 PM, Jorge Schrauwen wrote: > Alright! I'm stuck home (crushed nerv in foot) the entire week so if you got a bit of time to point me in the right way to setup a zone like that. That would be sweet. > > Finishing some last bits of testing to with OmniOS vs SmartOS KVM running 012 because I just want to be complete for my self :) Lots of output appended as attachments. These include: - My illumos-omnios.env file for /opt/onbld/bin/nightly. - My list of packages on my omniti zone. I think I'll spin up a nightly now, just to be sure. Dan -------------- next part -------------- A non-text attachment was scrubbed... Name: illumos-omnios.env Type: application/octet-stream Size: 8206 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pkgs Type: application/octet-stream Size: 33620 bytes Desc: not available URL: From fabio at fabiorabelo.wiki.br Mon Sep 29 20:24:35 2014 From: fabio at fabiorabelo.wiki.br (=?UTF-8?Q?F=C3=A1bio_Rabelo?=) Date: Mon, 29 Sep 2014 17:24:35 -0300 Subject: [OmniOS-discuss] SATA SSD vs. SAS In-Reply-To: References: Message-ID: Hi to all ... I live in Brazil, and here there are things that are VERY hard to find ! So, I need to be creative to get things done ... This as my experiences, till now : I Use Supermicro SATA backplanes ( the ones wirh "TQ" in the end of the part number ) with a mix of SATA and SAS disks without any kind of issue so far ... The only controller card I used till now are the IBM 1015 flashed to IT , and the breakout cables, one end are sff8087 and the other end have 4 SATA connectors . Systems are running fine for more then an year ... several Samsung and Sandisk SSDs for ZIL . But till now no pure SSD system . F?bio Rabelo 2014-09-29 17:10 GMT-03:00 Nate Smith : > Recently purchased a large number of 480GB datacenter grade SSDs with the idea to make a ZPOOL for a VM infrastructure. After receiving, I realized that they are SATA and not SAS, and that I'd completely overlooked that fact. I was planning on using them in a DELL R720XD which only uses two SAS cables for 24x2.5" disks. Since this backplane is obviously a SAS expander/multiplier, it will probably lead to disastrous results with SATA drives. Everything I've read says "don't use SAS expanders with SATA drives." (not to mention, that I'll completely saturate the data paths with these). In that vein, I've got a few questions. > > People choose SATA for SSD, because when it comes to SSD, the price may be 4-10 times as much for SAS. I've seen lots of setups with SAS spinning disks and SATA for L2ARC or ZIL. How are people connecting SATA disks for just these tasks and avoiding problems? Straight onto the SATA port on the motherboard? Are there any SATA only controllers that work well for SSD on Omnios? > > Does anyone know of any JBODs that are expander/multiplier free that would work for this setup? I have had a hard time finding any. > > Has anyone had any luck with interposers? I read this report, and it sounded promising till I got to the end. > http://xnat.org/blog/xnat-hardware/rsf-1-high-availablity-ssd-pool-for-vm-storage-and-build-space/ > > Thanks in advance, > > -- > Nate Smith > > _______________________________________________ > OmniOS-discuss mailing list > OmniOS-discuss at lists.omniti.com > http://lists.omniti.com/mailman/listinfo/omnios-discuss From nsmith at careyweb.com Mon Sep 29 20:29:49 2014 From: nsmith at careyweb.com (Nate Smith) Date: Mon, 29 Sep 2014 16:29:49 -0400 Subject: [OmniOS-discuss] SATA SSD vs. SAS In-Reply-To: References: Message-ID: <464d4678-371c-4266-92b2-9ff6089832d6@careyweb.com> Thanks, Fabio, Yeah, the 1015 cards are great and cheap. I used that on my old system for ZIL with the exact same setup you're talking about. Unfortunately, it doesn't scale in the servers I have. I had to "shoehorn" my zil drives in to bypass the backplane on my previous server. I may have to get another chassis like the one you describe. -----Original Message----- From: F?bio Rabelo [mailto:fabio at fabiorabelo.wiki.br] Sent: Monday, September 29, 2014 4:25 PM To: Nate Smith; omnios-discuss at lists.omniti.com Subject: Re: [OmniOS-discuss] SATA SSD vs. SAS Hi to all ... I live in Brazil, and here there are things that are VERY hard to find ! So, I need to be creative to get things done ... This as my experiences, till now : I Use Supermicro SATA backplanes ( the ones wirh "TQ" in the end of the part number ) with a mix of SATA and SAS disks without any kind of issue so far ... The only controller card I used till now are the IBM 1015 flashed to IT , and the breakout cables, one end are sff8087 and the other end have 4 SATA connectors . From vorob at yamalfin.ru Tue Sep 30 08:16:34 2014 From: vorob at yamalfin.ru (Yuri Vorobyev) Date: Tue, 30 Sep 2014 14:16:34 +0600 Subject: [OmniOS-discuss] errors when using smartmontools on 151006 Message-ID: <000b01cfdc86$d8f5a7a0$8ae0f6e0$@ru> Hello. I'm getting errors like in https://www.illumos.org/issues/1787 on last updated LTS release 151006. > Error for Command: Error Level: Recovered > scsi: [ID 107833 kern.notice] Requested Block: 0 Error Block: 0 > scsi: [ID 107833 kern.notice] Vendor: ATA Serial Number: MN1220 > scsi: [ID 107833 kern.notice] Sense Key: Soft_Error > scsi: [ID 107833 kern.notice] ASC: 0x0 (), ASCQ: 0x1d, FRU: 0x0 > scsi: [ID 107833 kern.warning] WARNING: /scsi_vhci/disk at g5000cca369c910ec (sd14): I would like to know fix included in latest 151006 or not? From sjorge+ml at blackdot.be Tue Sep 30 13:32:29 2014 From: sjorge+ml at blackdot.be (Jorge Schrauwen) Date: Tue, 30 Sep 2014 15:32:29 +0200 Subject: [OmniOS-discuss] OmniOS r151012 vioblk not working with ISO In-Reply-To: <3E44D17C-50CE-4A2E-8C05-BC766A7AED4A@omniti.com> References: <5ce5ee8ab3a5e99ff5556ea2201bedc4@blackdot.be> <042D5761-B061-413B-A9C2-0053381288B2@omniti.com> <0a8df081c9ea154c4aec50791b3cb1bb@blackdot.be> <2110698B-55F8-44A4-9311-E84615141A49@omniti.com> <711a51ca17c8919232b654f72dc71279@blackdot.be> <23C4A8C5-0E68-4D97-91AA-8AFD2476DD5B@omniti.com> <3E44D17C-50CE-4A2E-8C05-BC766A7AED4A@omniti.com> Message-ID: Hey Dan, So I got a zone setup and all the packages installed. Checkout illumos-omnios into /export/home/sjorge/build, copied the closed bits to /export/home/sjorge/ws/closed. When I run /opt/onbld/bin/nightly illumos-omnios.env I get: /opt/onbld/bin/nightly: line 1023: dmake: not found dmake is missing. I seem to be missing /opt/SUNWspro though, could that be the issue? Regards Jorge On 2014-09-29 22:24, Dan McDonald wrote: > On Sep 29, 2014, at 4:19 PM, Jorge Schrauwen > wrote: > >> Alright! I'm stuck home (crushed nerv in foot) the entire week so if >> you got a bit of time to point me in the right way to setup a zone >> like that. That would be sweet. >> >> Finishing some last bits of testing to with OmniOS vs SmartOS KVM >> running 012 because I just want to be complete for my self :) > > Lots of output appended as attachments. These include: > > - My illumos-omnios.env file for /opt/onbld/bin/nightly. > > - My list of packages on my omniti zone. > > I think I'll spin up a nightly now, just to be sure. > > Dan From danmcd at omniti.com Tue Sep 30 18:12:52 2014 From: danmcd at omniti.com (Dan McDonald) Date: Tue, 30 Sep 2014 14:12:52 -0400 Subject: [OmniOS-discuss] Coming soon: r151013 version of "bloody" Message-ID: <385B7FCC-249D-4A65-B625-6F3118E5B2BD@omniti.com> I mentioned earlier that the current "bloody" repository (which is labelled r151011) is toxic. I updated CherryPy there without thinking it through. It broke pkg(5), specifically pkg.depotd, and I had to back it out in source. I managed to do this before r151012 had a repo, so it did not affect the r151012 release, nor its repository. Any bloody boot environment updated after August 20th is toxic. A simple test is to utter: pkg list cherrypy and see if the version is 3.5.0. If it is, your BE is toxic. If it is 3.2.2, it is not. My knowledge of pkg(5) isn't deep enough to know of a non-destructive way to back this out. If you have a BE that predates the misapplied CherryPy 3.5 update, please use THAT BE as a basis for upgrading out to either r151012, or the upcoming r151013 version of bloody. Later this week, I plan on replacing the http://pkg.omniti.com/omnios/bloody/ repo with bits that are version r151013. And when I say replacing, I mean, "remove the backing IPS on-disk repo, and put in brand new ones. Because this is the bloody repo, I don't expect to have to help people transition. You know that when you're using bloody, things can get sketchy. I always hope at the end of a bloody cycle one can update to the next supported release, but this time, that didn't happen. (Trust me, it took a while for me to untangle this for what became the r151012 build box.) So heads up, r151013 will be coming very soon. I will have release media for it at the same time. If anyone out there uses Kayak, I'd be especially interested in bloody testing for Kayak. Thanks, Dan From richard.elling at richardelling.com Tue Sep 30 23:38:39 2014 From: richard.elling at richardelling.com (Richard Elling) Date: Tue, 30 Sep 2014 16:38:39 -0700 Subject: [OmniOS-discuss] errors when using smartmontools on 151006 In-Reply-To: <000b01cfdc86$d8f5a7a0$8ae0f6e0$@ru> References: <000b01cfdc86$d8f5a7a0$8ae0f6e0$@ru> Message-ID: <599EBE18-9094-4875-9104-72BCFB86727F@richardelling.com> On Sep 30, 2014, at 1:16 AM, Yuri Vorobyev wrote: > Hello. > > I'm getting errors like in https://www.illumos.org/issues/1787 on last > updated LTS release 151006. > >> Error for Command: Error Level: Recovered >> scsi: [ID 107833 kern.notice] Requested Block: 0 > Error Block: 0 >> scsi: [ID 107833 kern.notice] Vendor: ATA > Serial Number: MN1220 >> scsi: [ID 107833 kern.notice] Sense Key: Soft_Error >> scsi: [ID 107833 kern.notice] ASC: 0x0 (), > ASCQ: 0x1d, FRU: 0x0 >> scsi: [ID 107833 kern.warning] WARNING: /scsi_vhci/disk at g5000cca369c910ec > (sd14): > > I would like to know fix included in latest 151006 or not? This is a message that ATA passthrough information is available for an undecoded op code. These usually occur when a SMART request is issued against something that doesn't understand SMART, such as a CD-ROM. They are harmless, though annoying. I don't recall if there is a fix, nor how one would cleanly and consistently insititute a fix for ATA devices at the other end of a SAS fabric, but I'll bet a steak dinner this error message can occur in any or all versions of 151006. -- richard