15:02:37 danmcd andyf interesting data point, ldapclient in an lx ubuntu zone is now also working (granted, mine is also IPv6 enabled, so it was probably just hitting the socketops somewhere or whatever) 15:08:27 and sudo-ldap! :O 15:08:50 Interesting, lots of thinks that were broken for me all seem to be working now 15:29:11 Oooh, cool! 15:29:31 Hopefully the actual lack of error delivery via recvmsg() doesn't hamper them working properly. 17:04:52 sjorge: always a good feeling when a bunch of stuff starts working 17:30:38 papertigers yes! 17:31:07 danmcd if I understand it correctly, when the there is some sort of error, it will hit as timeout before it's reported like it is with the non ERR variant 17:31:39 So I guess if a nameserver is down it will take longer before it picks a different one 17:31:48 But I'd take that over it not working at all 17:32:08 So far not noticed anything broken or behaving oddly, noticed a lot of stuff now more or less working that were not before like ldap client and such 17:32:21 "all generated errors will be queued in a per-socket error queue" .... 17:32:40 .... "the errors can be received by calling recvmsg(2) with the MSG_ERRQUEUE flag set" 17:33:05 basically apps on LX with MSG_ERRQUEUE set will see nothing in LX (or, apparently FreeBSD's equivalent), but something in actual Linux. 17:33:33 "see nothing" ==> never see an sock_extended_err message in recvmsg(2). 17:34:37 Looks like it passes up all ICMP errors to the datagram socket such that it can manage things better. So yes, it's likely error-corrections will be longer in an LX environment. 17:35:15 You can probably experiment with this by, say, adding a RTF_BLACKHOLE route to your DNS server, see what happens, and then remove the RTF_BLACKHOLE route. 17:35:47 Ooops, I meant to say RTF_REJECT... you *want* an ICMP message heading back. 20:29:07 I just reinstalled the 3108 card, along with a 9500 card, in a recently retired fileserver. It's kind of important that we get functional stable support for one or the other of them. https://illumos.org/issues/15302 has the latest. This is something danmcd was trying to help with in his CFT but it got stuck a while ago. 20:39:12 (3108 and 9500 HBA) 20:39:43 The 9500 will need a at least a little love for mpt_sas. 20:39:59 You're on OmniOS... set up a be and add this to /etc/driver_aliases: 20:41:11 mpt_sas "pciex1000,e6" 20:41:36 I've a bad feeling that alone will not suffice, but try that first booting from the alternate BE with that entry in /etc/driver_aliases. 20:41:57 `beadm activate -t ` is your friend here in case it causes a kernel panic. (-t ==> boot once in that BE). 20:42:10 * danmcd needs to look quickly in mpt_sas source. 20:43:27 give me a few minutes, I need to look at how to edit a non-active BE. Never done that before. 20:44:14 looks like beadm mount is my friend. 20:48:05 I have no idea if this will work. FreeBSD's equivalent of mpt_sas (mpr) supports what we have in mpt_sas PLUS additional devices. 20:48:46 Unsure if those additional devices (incl. your 9500 board) need extra care or not. 20:49:10 I'm hoping to avoid having to convert all my fileservers here to FBSD. I run it at home and for $job[0] but I don't want to disrupt things at $job[1] and $job[2] by making such a major change if I don't have to 20:49:23 but supporting the incoming HBA is kind of a requirement. :) 20:51:18 just to confirm, mpt_sas not mr_sas right? 20:53:11 For 9500 (aka the 38xx chip) yes. 20:54:05 38xx is the successor to other mpt_sas chips. (And like I said, FreeBSD's equivalent of mpt_sas supports it.) 20:54:08 ok, working on it. This host takes a very, very long time to boot. 20:54:23 (and is now complaining about battery backup on the HBA - which doesn't exist so it shouldn't be kvetching about it.) 20:54:40 What sucks for you is the 3108 MegaRAID falls in the cracks between mr_sas and the under-review lmrc(4D) which support later-gen MegaRAID. 20:54:58 how long will that review take? 20:55:10 Your 3108 should probably be supported in mr_sas, but ENOCYCLES. 20:55:21 or are you saying it won't be supported by the new driver. 20:55:48 (3108 is NOT, AFAICT, in lmrc) Review of lmrc is well underway, and I'm spinning SmartOS PIs with it in there for folks who want to run it early. 20:56:01 After this week's SmartOS goes out, I'll try and remember to spin a new one. 20:56:45 This is why I used "between the cracks". 20:58:51 * nomad noda 20:59:01 finally rebooting into the test be. 21:03:10 it didn't kernel panci 21:03:26 but it is saying it needs to reboot because the cache of files (boot archive) were updated. 21:03:32 now I'm waiting for it to actually do that. 21:06:11 ... and it's rebooting now. I presume I'll need to beadm activate -t again. 21:09:06 Oh shit... yeah when you edit one of those using beadm mount that happens unless you do `bootadm update-archive -R /mount/path ` 21:09:40 (Sorry been a while since I've done /etc/* mucking as the sole BE differentiator. Were you replacing a driver I'd have been more apt to remember. My bad.) 21:10:01 no worries 21:11:09 and rebooting again 21:20:06 @nomad I have to go in 20mins. 21:20:37 It just finished booting 21:20:40 no kernel panic. 21:20:46 lots of complaints on the screen 21:20:54 and prtconf -v appears to be hanging. 21:21:11 oh, not hanging, just going .... really .... slowly 21:21:15 and done. 21:21:29 I'll update the ticket with a screenshot and the prtconf -v output. Anything else you want? 21:23:48 I take it there are no disks attached? 21:24:59 There are no disks of any type attached to the 9500. 21:25:14 ticket updated 21:26:27 Okay. 21:26:44 can I grab any other info for you before you need to leave? 21:27:14 I will point out that `illumos-nexenta` has a new driver called "mpt_sas3". 21:27:24 I wonder if anyone's tried upstreaming it? 21:27:48 (It has your 38xx chip in it... I wonder if it uses the more modern HBA framework as well?) 21:30:11 Nope./ 21:30:29 is it ok to boot back to the regular BE? These complaints on the console are ... disturbing my vibe :) 21:30:40 Just a copy of mpt_sas... reminds me of when Joyent did `dr_sas` to keep old mr_sas around in case modern improvements to mr_sas broke something. 21:30:47 yes, reboot your old be. Thank you. 21:31:28 tks 21:31:46 I'll be available again tomorrow morning (US Pacific time) if there's more data I can collect for you. 21:34:52 I'm guessing that BBU was actually a supercap. I'm not seeing the complaint anymore.