December 28, 2012 
< | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | >
December 28, 2012 [00:01:46] <molybdenum> hi[00:03:02] <molybdenum> as you deduced, no way to manage USB3 independently of any other USB capability[00:03:45] * molybdenum gives up on that system for now anyway[00:05:13] <konobi> molybdenum: there is no usb3 on that system[00:05:24] <konobi> was just a slip up[00:05:40] <wesolows> why do you think USB3 is involved? that system predates its existence.[00:06:02] <konobi> wesolows: nahamu's misunderstanding with uhci3[00:06:42] *** neophenix has quit IRC[00:07:05] <wesolows> oh, I thought we already addressed that[00:08:12] *** potatosalad has quit IRC[00:32:18] *** Traktor has joined #smartos[00:36:45] *** Traktor has quit IRC[00:54:58] <konobi> wesolows: know anything about Intel QuickAssist at all?[00:58:32] <wesolows> nope[00:59:33] <konobi> oh, nevermind... seems to be an embedded thing[01:00:23] *** newlix has joined #smartos[01:04:50] *** newlix has quit IRC[01:15:17] *** wolfeidau has quit IRC[01:16:57] <xmerlin> hi to all[01:17:03] <xmerlin> ...I've two black vnc screens ...I'm trying to boot sysresccd ...[01:18:02] <xmerlin> I've done the same thing almost 15 times today ...and I had no issue ...now ...the last two vms are black[01:19:21] *** arekinath has quit IRC[01:19:42] *** arekinath has joined #smartos[01:19:42] *** arekinath has joined #smartos[01:23:08] <xmerlin> I've stopped and restarted the vm with the same parameters and vnc is ok ...that's very strange[01:30:50] <nahamu> molybdenum: sorry about that![01:54:34] *** sjorge has quit IRC[01:54:58] *** sjorge has joined #smartos[01:56:18] *** potatosalad has joined #smartos[02:19:45] *** potatosalad has quit IRC[02:21:46] *** tonyarkles has joined #smartos[02:33:24] *** tonyarkles has quit IRC[02:45:29] *** tonyarkles has joined #smartos[02:47:57] *** kimc has quit IRC[02:55:14] *** sheppard has joined #smartos[02:57:13] <sheppard> Anyone happen to know if a LSI MegaRAID 9265-8i is supported under SmartOS? I wasn't seeing it listed on the Illuminos HCL, but LSI seems to provide Solaris 10/11 drivers for the card[02:57:24] *** tonyarkles has quit IRC[02:59:34] *** wolfeidau has joined #smartos[03:07:43] <Alasdairrr> sheppard: if you can get the PCI id someone can check the driver aliases file[03:09:24] <sheppard> 01:00.0 0107: 1000:0086 (rev 05)[03:09:34] <wesolows> or you can use illumos.org/hcl[03:09:42] <sheppard> 03:00.0 0200: 8086:10f1 (rev 01)[03:10:53] <sheppard> now one of those id's is my ixgbe[03:10:55] <sheppard> rwar[03:11:13] <sheppard> 83:00.0 0104: 1000:005b (rev 01)[03:11:38] <wesolows> anyway, 1000,86 is an mpt_sas device which seems oddly inconsistent with it being a 9265[03:11:46] <wesolows> ah, there we go[03:11:51] <wesolows> 1000,5b is mr_sas.[03:12:00] <wesolows> that's yer RAID card[03:12:00] <sheppard> wesolows: I have two raid cards in there. one is a 9265, other is mpt_sas of some varietyy[03:13:17] <wesolows> the LSI drivers should not be used, as we cannot guarantee compatibility in the undocumented/uncommitted kernel interfaces HBA drivers normally use.[03:13:48] <wesolows> however, your cards should all work out of the box with current illumos, assuming your distribution is current and hasn't removed support for some reason[03:13:50] <sheppard> but, as shipped, the smartos live dvd *should* detect these cards?[03:14:03] <Alasdairrr> why don't you just try it[03:14:16] <wesolows> yes[03:14:24] <wesolows> the current smartos has support for them[03:14:31] <sheppard> wesolows: thank you so much[03:14:41] <sheppard> Alasdairrr: just wanted to check before I go through rebooting the box, etc.[03:14:47] <wesolows> if they don't work, file a bug.[03:40:09] *** Vod has quit IRC[03:42:07] *** ryancnelson has quit IRC[04:03:35] *** jwk404 has quit IRC[04:06:48] *** indutny has left #smartos[04:12:28] *** potatosalad has joined #smartos[04:13:55] *** avrntsv has joined #smartos[04:26:24] *** enmand has joined #smartos[04:27:12] *** dysinger has joined #smartos[04:29:21] *** molybdenum has quit IRC[04:31:46] *** avrntsv has quit IRC[04:37:08] *** wolstena has quit IRC[04:55:40] *** ira has quit IRC[04:58:54] *** sachinsharma has joined #smartos[05:01:01] *** newlix has joined #smartos[05:05:27] *** newlix has quit IRC[05:09:42] *** dysinger has quit IRC[05:26:06] *** avrntsv has joined #smartos[05:34:55] *** enmand has quit IRC[05:58:54] *** sachinsharma has quit IRC[06:40:02] *** sachinsharma has joined #smartos[06:52:54] *** iyp has joined #smartos[06:55:50] *** wolfeidau has quit IRC[07:01:17] *** newlix has joined #smartos[07:03:20] *** potatosalad has quit IRC[07:05:36] *** newlix has quit IRC[07:24:26] *** potatosalad has joined #smartos[07:41:50] *** rc10 has joined #smartos[08:00:13] *** Wraithhh_ has quit IRC[08:05:01] *** iyp has quit IRC[08:08:38] *** potatosalad has quit IRC[08:45:47] *** molybdenum has joined #smartos[08:51:31] <rc10> hi, is there /boot/loader.conf in OI ?[08:51:31] <rc10> in which file should I set -> vfs.zfs.txg.timeout="5"[08:56:28] *** ipalreadytaken has joined #smartos[09:00:36] <linuxprofessor> rc10: http://www.solarisinternals.com/wiki/index.php/ZFS_Evil_Tuning_Guide#Static_change_via_.2Fetc.2Fsystem[09:03:43] *** Wraithhh has joined #smartos[09:07:07] *** jamesd has quit IRC[09:08:14] *** alucardX has joined #smartos[09:15:11] *** alucardX has quit IRC[09:23:31] *** texarcana has quit IRC[09:24:47] *** texarcana has joined #smartos[09:48:35] *** bens1 has joined #smartos[09:51:04] *** ipalreadytaken has quit IRC[09:52:01] *** alucardX has joined #smartos[10:01:09] *** ipalreadytaken has joined #smartos[10:12:43] *** sachinsharma has quit IRC[10:13:05] *** xmerlin has quit IRC[10:29:56] *** ipalread_ has joined #smartos[10:33:53] *** ipalreadytaken has quit IRC[11:01:49] *** newlix has joined #smartos[11:06:48] *** newlix has quit IRC[11:13:05] *** avrntsv1 has joined #smartos[11:14:16] *** avrntsv has quit IRC[11:15:15] *** Tekni has joined #smartos[11:15:53] *** xinkeT has quit IRC[11:21:37] *** avrntsv1 has quit IRC[11:40:24] *** alucardX has quit IRC[11:53:01] *** ipalread_ has quit IRC[11:58:42] *** sachinsharma has joined #smartos[12:14:49] *** KermitTheFragger has joined #smartos[12:22:37] *** alucardX has joined #smartos[12:24:52] *** wolfeidau has joined #smartos[13:05:08] *** enmand has joined #smartos[13:09:36] *** enmand has quit IRC[13:40:26] *** ira has joined #smartos[13:42:20] *** alucardX has quit IRC[13:55:05] *** riceo has joined #smartos[13:57:36] *** bayoda has quit IRC[14:00:56] *** bayoda has joined #smartos[14:12:35] *** riceo has quit IRC[14:28:31] <nahamu> aha! tools/build_illumos doesn't read variables from configure.smartos[14:35:13] *** rc10 has quit IRC[14:37:58] *** rc10 has joined #smartos[14:43:27] *** rc10 has quit IRC[14:56:14] *** jamesd has joined #smartos[15:06:54] *** mamash has joined #smartos[15:20:35] *** tru_tru has quit IRC[15:20:37] *** riceo has joined #smartos[15:21:02] *** tru_tru has joined #smartos[15:38:19] *** bens1 has quit IRC[15:39:11] *** rc10 has joined #smartos[15:50:37] *** riceo_ has joined #smartos[15:52:47] *** riceo has quit IRC[16:35:01] *** mikl has joined #smartos[16:44:06] *** potatosalad has joined #smartos[16:44:09] <kfr-_> looking at https://download.joyent.com/pub/iso/changelog_release-20121227.txt[16:44:27] *** mamash has left #smartos[16:44:30] <kfr-_> STOR-109 want RAIDZ2 bias for large-slow-disk configurations[16:44:38] <kfr-_> what does tha do?[16:49:07] <Alasdairrr> I think it's to do with the auto-disk-layout selection at install time[16:49:25] <Alasdairrr> If the system has lots of big slow disks, pick raidz2[16:49:42] <nahamu> https://github.com/joyent/smartos-live/commit/3ddfbcb61029689a93c74b6f3ce8522b30dcf656[16:52:16] <wesolows> it's a one-line change and it's open source; how hard can it be to figure out?[16:53:05] <Alasdairrr> you're a real grinch, wesolows[16:53:26] *** tonyarkles has joined #smartos[16:53:30] <wesolows> indeed I am[16:53:34] <Alasdairrr> :-)[16:53:49] * wesolows steals the roast beast[16:55:09] <wesolows> this change was made so that systems with a moderate number (enough for at least one reasonable raidz2 vdev) of very slow disks won't bother mirroring[16:55:49] <wesolows> the rationale is that if you want to bias toward performance, you aren't using the super-slow disks anyway[16:56:03] <wesolows> or if you are, you're using a lot of them[16:56:22] <kfr-_> doesn't look like it's looking at speed[16:56:25] <kfr-_> just size[16:56:28] <Alasdairrr> 500GB SSDs have come down in price an awful lot in 2012, we're thinking about going all-SSD in the near future, especially in things like Dell R620s which can take 8 or even 10 drives (not sure how they get 10 drives passed through to the OS given most LSI chipsets do 8 drives)[16:56:35] <kfr-_> and number of vdev's[16:56:51] <wesolows> the two are 100% correlated today. if in the future they aren't, or we get reliable ways to determine performance, it can change[16:57:14] <wesolows> I don't expect this code will look the same in 2020[16:57:50] <kfr-_> ok[16:57:56] <kfr-_> rgBJA[16:58:00] <kfr-_> THANKS[16:58:37] <wesolows> I do wish there were a universally implemented standard for querying the small-block performance of a device[16:58:40] <kfr-_> err thanks![16:59:09] <wesolows> even just roughly -- 0 for 5400 rpm disks, 1 for 7200, 2, for 10k or 15k, 4 for slow SSDs, 10 for fast ones, or whatever[16:59:16] <kfr-_> could not query the SAS bus[17:00:03] <wesolows> I can query the shit out of SAS. It'll tell me in all cases that the device is linked up at 6 Gb/s.[17:00:38] <wesolows> that tells me nothing about the device's likely latency at responding to 8K reads[17:02:03] <kfr-_> ok[17:04:03] <kfr-_> I guess there is no equivalent of the cddb for harddrives that you could just query[17:09:48] <wesolows> doesn't the cddb just cover the discs themselves? in this case we'd need something in VPD for the entire storage device.[17:13:56] <wesolows> we have for instance the medium rotation rate and form factor in the block device characteristics VPD page, but it is optional.[17:16:05] <nahamu> wesolows: it would be cool if you could fire off a bunch of benchmark reads at the devices and see what the latency is...[17:16:14] <wesolows> slooooooooowwwwwwwwwwwwww[17:16:29] <wesolows> on a machine with 36 disks, that could take minutes[17:17:14] <nahamu> good point.[17:17:26] *** ins0mnia has joined #smartos[17:17:27] <kfr-_> people run 36 disk pools on smartos?[17:17:33] <nahamu> even in parallel?[17:17:51] <wesolows> kfr-_: absolutely[17:18:22] <wesolows> nahamu: we could work on it, I guess, but the reality is that my braindead approach works just as well :-)[17:18:30] <wesolows> cost/benefit can't be beat[17:18:35] <nahamu> haha :)[17:21:39] <nahamu> wesolows: I meant more in the theoretical sense. if anyone in reality wants to actually spend the time to implement it, that's another story...[17:24:27] <nahamu> I wonder if just reading the first block then the last block would give you enough info for a rough estimate (though that measures seek latency, not rotational latency, but still...)[17:24:55] <wesolows> we're only going for something really rough here, basically "is this a slow disk"[17:25:13] *** bens1 has joined #smartos[17:25:16] <wesolows> but the latency of reading any one block is misleading and can include all kinds of other stuff like spinup time[17:25:33] <wesolows> so we'd have to select some decent number of random blocks to read[17:25:39] <nahamu> I'm not criticising your decision at all. I'm just having a thought experiment that I should perhaps keep to myself.[17:25:57] <wesolows> no, it's fine. it's actually kind of a tricky problem if you want to solve it quickly at runtime[17:26:14] <wesolows> which is why having a reliable mandatory VPD field is the best answer[17:26:38] <nahamu> As a rough cut, though, how badly could measuring the latency of first and last block mess you up?[17:26:47] <nahamu> the SSDs will quickly reveal themselves[17:27:01] <wesolows> we already detect SSDs[17:27:09] <nahamu> how?[17:27:15] <wesolows> by using exactly that VPD :-)[17:27:17] * nahamu goes to look at the code again[17:27:19] <nahamu> ah[17:28:22] <nahamu> where's the code that does that query?[17:28:27] *** gregburd_ is now known as gregburd[17:28:39] <nahamu> diskinfo.c?[17:28:49] <wesolows> yes, but ultimately https://github.com/joyent/illumos-joyent/commit/281d692636513b749e11b75b758cd009114b2216[17:29:09] <wesolows> this was a change garrett and richard made[17:29:26] <wesolows> I extended it and plumbed it through to userland[17:30:20] <wesolows> I couldn't find an SSD on which this wasn't reliable, so we went with it. I'm sure some do exist.[17:30:41] <nahamu> is the magic in blkdev.c?[17:32:48] <wesolows> look for wherever un_f_is_solid_state gets set[17:33:01] <wesolows> I only have web access on this machine[17:33:20] <nahamu> it's sd.c which was what I was starting to lean towards.[17:33:26] <wesolows> yes[17:33:44] <nahamu> I guess ddi_copyout reads something in some cool way.[17:34:10] <wesolows> no, it just copies stuff to userland[17:34:18] <nahamu> oh[17:35:13] <wesolows> sd_check_solid_state[17:35:21] <nahamu> this just further confirms for me that I'm no kernel hacker...[17:35:44] <wesolows> specifically the INQUIRY with fucking magic constants[17:36:18] <nahamu> http://src.illumos.org/source/xref/illumos-gate/usr/src/uts/common/io/scsi/targets/sd.c#31665[17:36:36] <nahamu> right, that looks like proper black magic to me. :)[17:37:12] <nahamu> so SSDs report that they don't have a rotation rate...[17:37:27] <wesolows> they report a rate of 1 which is reserved for SSDs by the standard[17:37:46] <wesolows> inqb1[4] and [5] are the 16-bit rate response[17:37:54] <nahamu> that's much more precise, yes.[17:37:55] <wesolows> they're big-endian as always in scsi[17:38:08] <wesolows> it's important because 0 means not reported/not implemented[17:38:12] <nahamu> so in theory one could query at least the rotation rate of regular drives too?[17:38:16] <wesolows> correct[17:38:25] <wesolows> how widely this is implemented I do not know[17:38:29] <nahamu> right.[17:38:56] <wesolows> historically it was unwise to rely on anything more than the most trivial things in these specs because they are all implemented in firmware which is universally shit[17:39:13] <nahamu> and who knows what sorts of lies those "green" drives would tell you if you were silly^Wcheap enough to use those...[17:39:58] <jesse_> the good thing about the "green" drives is that they break so fast that on average, no-one is using them=)[17:40:30] <wesolows> right[17:40:52] <wesolows> the nice thing about ssds reporting 1 here is that if it does report 1, you can probably safely assume it actually is an ssd[17:41:04] <wesolows> but a lot of stuff probably reports 0[17:41:31] <wesolows> in which case you know nothing and are back to the approach that everyone has used for the last 25 years which is tables of VID/PID/REV combos[17:41:58] <wesolows> because vendor and product are about the only fields firmware engineers can reliably figure out how to populate, and even then there are often problems[17:42:54] <wesolows> like the improperly terminated fields in 3320, coincidentally the change I made to sd.c after the one we're discussing[17:43:10] <wesolows> because, you know, reading standards is hard; let's go shopping![17:44:15] <wesolows> and on that note of pure unadulterated hatred for all things firmware, it's time for my annual 4-day vacation[17:44:19] <wesolows> have fun guys[17:44:58] <nahamu> wesolows: enjoy![17:45:46] <rmustacc> wesolows: Enjoy.[17:50:33] <kfr-_> wesolows: have fun![17:59:50] *** chorrell has joined #smartos[18:01:06] *** rc10 has quit IRC[18:43:35] *** tonyarkles has quit IRC[18:47:30] *** KermitTheFragger has quit IRC[18:51:35] *** tonyarkles has joined #smartos[19:03:01] *** newlix has joined #smartos[19:07:32] *** newlix has quit IRC[19:10:04] *** mamash has joined #smartos[19:21:18] *** linuxprofessor has quit IRC[19:21:24] *** iyp has joined #smartos[19:33:18] *** iyp has quit IRC[19:34:33] *** iyp has joined #smartos[19:39:05] *** tonyarkles has quit IRC[19:40:45] *** mamash has left #smartos[19:42:07] *** mamash has joined #smartos[19:57:43] *** wolstena has joined #smartos[20:14:25] *** bens1 has quit IRC[20:14:50] <iyp> Some perl scripts are ending up with improper hash bangs in a package I'm trying to make[20:14:57] <iyp> errors here: https://gist.github.com/4ec1648c210edb819e4a[20:15:01] <iyp> any ideas?[20:17:30] <mamash> are you using REPLACE_PERL to set proper shebangs?[20:20:25] *** mamash has left #smartos[20:20:59] *** ryancnelson has joined #smartos[20:25:02] <nahamu> ryancnelson: do you have any idea why KVM vms might get stuck in a provisioning state?[20:25:36] <nahamu> latest SmartOS platform.[20:26:21] <ryancnelson> using standard vmadm commands?[20:26:26] <nahamu> yeah[20:26:26] <ryancnelson> how did you provision?[20:26:53] <nahamu> vmadm create -f <json payload>[20:28:05] <nahamu> this commit worries me since this feels like a new issue... https://github.com/joyent/smartos-live/commit/a3fd122ab68588dc853fb2c965913a9ac3e18ff8[20:28:18] <ryancnelson> how does it stick? do you get a zone? a zvol?[20:29:08] <nahamu> hmmm. if I create the zone with autoboot=false and then start it manually, I think I avoid a bug...[20:29:17] <nahamu> gotta test that on the other box...[20:30:24] *** ryancnelson has quit IRC[20:42:05] <nahamu> https://github.com/joyent/smartos-live/issues/156[20:42:27] <nahamu> MerlinDMC: got a few minutes to double check that I'm not crazy on this one?[20:44:43] *** mikl has quit IRC[20:59:24] *** chorrell has quit IRC[21:12:05] *** Saskaloon has quit IRC[21:14:20] *** rcamera has joined #smartos[21:27:29] *** linuxprofessor has joined #smartos[21:46:55] *** mamash has joined #smartos[21:48:21] <iyp> mamash: no luck with REPLACE_PERL[21:49:03] <iyp> everything can be found in this repo -- https://github.com/aunalytics/monetdb-pkgsrc[21:49:13] <iyp> including the failure log under logs/[22:02:08] *** kfr-_ has quit IRC[22:19:34] *** jim80net has joined #smartos[22:27:08] *** Saskaloon has joined #smartos[22:31:52] *** bens1 has joined #smartos[22:34:34] *** Teknix has joined #smartos[22:38:52] *** ryancnelson has joined #smartos[22:42:13] *** bens1 has quit IRC[22:43:55] *** ira has quit IRC[22:44:42] *** ipalreadytaken has joined #smartos[23:02:44] *** kfr- has joined #smartos[23:11:40] *** mikl has joined #smartos[23:34:04] <mamash> iyp: are those scripts maybe generated as part of the build? the REPLACE_* framework takes place in the pre-build target, so if the script only exists as a template and gets generated during the build, you'll need to patch it explicitly[23:34:28] <mamash> or just figure out where the "where's perl" logic is taking place in the build and modify that part so that it points to the proper location[23:34:44] <mamash> sounds like it's just doing 'which perl' and then using that path, which is... meh[23:34:49] <iyp> mamash: I think you're dead on with that. I just figured out that the files in the package are actually just ".pl.in" files[23:35:13] <iyp> The templates have #!@PERL@ at the top[23:36:01] <iyp> I can't use the replace_* stuff to replace that line in the template, right?[23:36:51] <mamash> no[23:36:58] <iyp> gotchya[23:37:07] <iyp> So what's the best way to pull off that patch.[23:37:56] <iyp> I'm confused if I'm supposed to patch the template or the final file.[23:38:15] <mamash> you have three options[23:38:48] <mamash> the *best* way is to look in the Makefile (or similar) and make sure it's substituting @PERL@ with the real path and not just what it thinks it has (i.e. the sandbox wrapper)[23:38:49] <mamash> or[23:38:57] <mamash> patch the files before the build[23:38:58] <mamash> or[23:39:04] <mamash> patch the files after the build[23:39:15] <mamash> for the two latter options, you'd use the SUBST framework[23:39:29] *** norman has left #smartos[23:39:53] <mamash> that's probably easier than creating new patches/patch-* files for each of the scripts[23:39:56] <iyp> So if the makefile is using shitty logic for the replacement, I patch that pre-build, right?[23:41:34] <iyp> I have no idea how @PERL@ gets substituted[23:41:46] <iyp> so I guess that means I have to do one of the other two options[23:42:18] <mamash> if the build is Makefile based than it's most likely just calling sed somewhere[23:43:44] <mamash> otherwise use SUBST_SED to patch the files pre-build, that'd be my other choice[23:44:48] <iyp> Would there be any way to just rm that directory before we get started. We don't use any of the perl hooks.[23:45:00] <iyp> Thats pretty dirty, but I'm curious if it'll work[23:45:29] <iyp> actually, SUBST_SED looks pretty good.[23:46:06] *** mamash has left #smartos[23:56:07] *** jim80net has quit IRC