Switch to DuckDuckGo Search
   April 4, 2020  
< | 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 | >


NOTICE: This channel is no longer actively logged.

Toggle Join/Part | bottom
[00:09:18] *** lgtaube <lgtaube!~lgt@84.16.224.13> has quit IRC (Ping timeout: 256 seconds)
[00:19:04] *** andy_js <andy_js!~andy@51.146.99.40> has quit IRC (Quit: andy_js)
[00:25:44] *** lgtaube <lgtaube!~lgt@45.86.203.33> has joined #illumos
[01:37:41] *** neirac <neirac!~neirac@pc-215-101-46-190.cm.vtr.net> has quit IRC (Remote host closed the connection)
[01:54:02] <rmustacc> sjorge: I think I'm going to have to iterate a bit on that for a bit longer.
[01:54:56] <rmustacc> liv3010m: I updated the bge driver in the same place. New sha is e94381a92b603dd26296369432359f90b076dc38f1cedbe4960fba726c26bcb3.
[02:32:32] <jbk> am11: >_Ux86_64_dwarf_callback: no .eh_frame_hdr section found -- that could be a problem
[02:32:52] <jbk> (the section is there, but for some reason the library can't find it)
[02:45:24] *** alanc <alanc!~alanc@inet-hqmc01-o.oracle.com> has quit IRC (Remote host closed the connection)
[02:45:51] *** alanc <alanc!~alanc@inet-hqmc01-o.oracle.com> has joined #illumos
[02:49:23] *** ballew <ballew!sid244342@gateway/web/irccloud.com/x-dvvgvswxopewnkyh> has quit IRC (Ping timeout: 246 seconds)
[02:51:33] *** ballew <ballew!sid244342@gateway/web/irccloud.com/x-dphdyhgymsvaqaxg> has joined #illumos
[02:57:53] <jbk> .. and this code doesn't make it easy to even figure out how it's attempting to find it
[03:10:42] *** ovi <ovi!~sh42@fsf/member/zeroSignal> has quit IRC (Ping timeout: 256 seconds)
[03:17:32] *** ovi <ovi!~sh42@178.251.69.48> has joined #illumos
[03:19:29] <jbk> hmm.. how horrible would it be if mmap took a void * not only for whatever posix environment, but if __EXTENSIONS__ was defined
[03:19:35] <jbk> instead of caddr_t
[03:35:58] *** neirac <neirac!~neirac@pc-215-101-46-190.cm.vtr.net> has joined #illumos
[03:37:34] <liv3010m> Hi @rmustacc, thanks, I'll download it and give it a try
[03:40:41] *** clapont <clapont!~clapont@unaffiliated/clapont> has quit IRC (Ping timeout: 250 seconds)
[03:50:31] <jbk> am11: ok.. so one issue (I'll need to dig a bit more, or maybe prod richlowe since I think he touched this last :P)... when it walks up the stack.. it gets to _start and then instead of stopping (as I think that should be the last frame), it tries to keep going and ends up in the weeds (and returning an error)
[04:02:42] *** clapont <clapont!~clapont@unaffiliated/clapont> has joined #illumos
[04:04:55] <liv3010m> @rmustacc: this time the driver attached successfully
[04:11:17] *** mnrmnaugh <mnrmnaugh!~mnrmnaugh@unaffiliated/mnrmnaugh> has quit IRC (Quit: Leaving)
[04:12:00] *** neirac <neirac!~neirac@pc-215-101-46-190.cm.vtr.net> has quit IRC (Remote host closed the connection)
[04:16:28] *** jcea <jcea!~Thunderbi@2001:bc8:2ecd:caed:7670:6e00:7670:6e00> has quit IRC (Quit: jcea)
[04:16:45] <richlowe> jbk: how's it trying to go further, though?
[04:17:14] <richlowe> jbk: there's no further.
[04:19:03] <jbk> i'm trying to figure that out.. it looks like it's expecting %rbp == 0 to stop
[04:19:09] <jbk> but we end up with %rip == 0
[04:22:17] <richlowe> rbp should be 0 too
[04:22:52] <richlowe> if it weren't, mdb, pstack, etc, would also walk too far.
[04:23:03] <richlowe> is it rather than using the framepointer using something else to walk the stack?
[04:24:10] <jbk> https://gist.github.com/jasonbking/366c6f237b16c19a77df25d65146e082
[04:24:15] <jbk> it's using the eh_frame info
[04:24:24] <jbk> (libunwind)
[04:25:49] *** mnrmnaugh <mnrmnaugh!~mnrmnaugh@unaffiliated/mnrmnaugh> has joined #illumos
[04:26:16] *** mnrmnaugh <mnrmnaugh!~mnrmnaugh@unaffiliated/mnrmnaugh> has quit IRC (Remote host closed the connection)
[04:26:21] <richlowe> and there won't be eh info for _start, because asm.
[04:36:55] <jbk> yeah.. so if i'm understanding this.. it fails to find eh_info, so i think it falls back to using frame pointers.. except that doesn't quite work (it gets %rip == 0, but not %rbp)
[05:06:13] <jbk> god this code is hard to follow
[05:07:48] <richlowe> all the unwinders are
[05:17:03] *** tsoome_ <tsoome_!~tsoome@91.209.240.229> has quit IRC (Read error: Connection reset by peer)
[05:17:28] *** tsoome_ <tsoome_!~tsoome@91.209.240.229> has joined #illumos
[05:18:28] <jbk> it's all the 100+line multi-level nested ifs
[05:20:36] *** hww3 <hww3!~hww3@c-73-128-248-73.hsd1.md.comcast.net> has quit IRC (Read error: Connection reset by peer)
[05:24:41] *** hww3 <hww3!~hww3@c-73-128-248-73.hsd1.md.comcast.net> has joined #illumos
[05:50:50] <jbk> hmm..
[05:51:48] <jbk> so.. https://gist.github.com/jasonbking/862ec40b73bf119c2c02f95f8b8e4661 gets us to 24 tests passing
[05:52:48] <jbk> and at least one that's failing looks _very_ close -- when comparing the addresses of the stack trace between using the frame pointer and the eh_frame data, the addresses differ by 1
[06:11:49] <rmustacc> liv3010m: That's good. Try making an aggr again at some point and seeing if it works.
[06:12:00] <rmustacc> liv3010m: I'd also be curious of vnics work.
[07:16:44] *** eki <eki!~eki@dsl-hkibng41-54f858-46.dhcp.inet.fi> has quit IRC (Quit: leaving)
[07:18:57] *** eki <eki!~eki@dsl-hkibng41-54f858-46.dhcp.inet.fi> has joined #illumos
[07:19:47] *** BOKALDO <BOKALDO!~BOKALDO@87.110.91.76> has joined #illumos
[07:40:51] *** KungFuJesus <KungFuJesus!~adam@dsl-74-83-211-105.fuse.net> has quit IRC (Quit: Lost terminal)
[08:11:08] *** nde <nde!uid414739@gateway/web/irccloud.com/x-rwfhsdrphvdeamxo> has quit IRC (Quit: Connection closed for inactivity)
[08:15:18] <jbk> hmm..
[08:18:22] <jbk> so gcc is using a p_type of PT_SUNW_UNWIND and not PT_SUNW_EH_FRAME
[08:18:30] <jbk> for the elf program header
[08:18:47] <jbk> despite the comments in sys/elf.h saying the latter is required by the amd64 ABI
[08:18:56] <jbk> (the former being an earlier value)
[08:19:24] <jbk> (the illumos utilities treat the two as equivalent, but other stuff -- like libunwind -- may not)
[08:20:58] <jbk> ... or is it ld that's doing that
[08:55:35] *** arnoldoree <arnoldoree!~arnoldore@2001:d08:2082:93f:33f5:dba:2017:63e0> has joined #illumos
[08:59:02] *** clapont <clapont!~clapont@unaffiliated/clapont> has quit IRC (Ping timeout: 265 seconds)
[09:00:56] *** clapont <clapont!~clapont@37.251.221.34> has joined #illumos
[09:25:00] *** psarria <psarria!~phyre___@78.30.17.247> has joined #illumos
[09:33:02] <tsoome> jbk :)
[09:52:17] *** andy_js <andy_js!~andy@51.146.99.40> has joined #illumos
[09:52:53] *** varna_ <varna_!~varna@115.192.34.215> has joined #illumos
[09:53:29] *** neuroserve <neuroserve!~toens@ip-84-118-130-187.unity-media.net> has quit IRC (Ping timeout: 265 seconds)
[09:56:14] *** superjen96 <superjen96!~jenelizab@cpc155793-brmb11-2-0-cust474.1-3.cable.virginm.net> has quit IRC (Ping timeout: 240 seconds)
[09:56:17] *** varna <varna!~varna@60.176.144.113> has quit IRC (Ping timeout: 260 seconds)
[09:57:50] *** jenelizabeth <jenelizabeth!~jenelizab@cpc155793-brmb11-2-0-cust474.1-3.cable.virginm.net> has joined #illumos
[09:59:19] *** Markus-FN <Markus-FN!5b309c66@p5B309C66.dip0.t-ipconnect.de> has joined #illumos
[09:59:48] *** Markus-FN <Markus-FN!5b309c66@p5B309C66.dip0.t-ipconnect.de> has quit IRC (Remote host closed the connection)
[10:00:31] *** Markus-FN <Markus-FN!5b309c66@p5B309C66.dip0.t-ipconnect.de> has joined #illumos
[10:02:40] *** Markus-FN <Markus-FN!5b309c66@p5B309C66.dip0.t-ipconnect.de> has quit IRC (Remote host closed the connection)
[10:12:20] *** varna_ <varna_!~varna@115.192.34.215> has quit IRC (Ping timeout: 265 seconds)
[10:12:39] *** varna <varna!~varna@60.176.150.59> has joined #illumos
[10:56:42] *** igork <igork!~igork@91.204.56.74> has joined #illumos
[11:13:55] *** wacki <wacki!~wacki@i577B0885.versanet.de> has joined #illumos
[11:22:45] *** lgtaube <lgtaube!~lgt@45.86.203.33> has left #illumos
[11:24:17] *** lgtaube1 <lgtaube1!~lgt@213-67-21-71-no84.tbcn.telia.com> has joined #illumos
[11:30:00] *** lgtaube1 is now known as lgtaube
[11:32:11] *** Guest35579 <Guest35579!~kayront@zbase.xen.prgmr.com> has left #illumos ("Leaving")
[11:49:25] *** ibenn <ibenn!~benn@HSI-KBW-095-208-237-062.hsi5.kabel-badenwuerttemberg.de> has joined #illumos
[12:09:45] *** BOKALDO <BOKALDO!~BOKALDO@87.110.91.76> has quit IRC (Quit: Leaving)
[12:39:07] <sjorge> rmustacc: no problem
[12:39:25] <sjorge> jbk / Agnar : does 'getent shadow' show the correct shadowAccount info for you guys?
[12:39:40] <sjorge> Mines just lists everything as empty and the password as *NP*
[12:40:21] *** nbhauke <nbhauke!~hauke@55d4023b.access.ecotel.net> has joined #illumos
[12:45:36] *** nbhauke <nbhauke!~hauke@55d4023b.access.ecotel.net> has quit IRC (Quit: nbhauke)
[13:11:17] <toasterson1> Question about memory leaks. I have a zone running Gitea and it sometimes allocates all available memory of the system. When I restart gitea the momory is not freed but when I restart the zone it is. Any clue what this is?
[13:14:02] *** arnoldoree <arnoldoree!~arnoldore@2001:d08:2082:93f:33f5:dba:2017:63e0> has quit IRC (Ping timeout: 260 seconds)
[13:19:58] <psarria> toasterson1, i use gitea in a zone too, when i restart gitea, memory catch the previous value almost immediately
[13:20:14] <psarria> 88993 root 226M 112M sleep 1 0 4:10:05 0.4% gitea/24
[13:20:16] <psarria> restart
[13:20:24] <psarria> 38040 root 226M 109M sleep 1 0 0:00:01 0.6% gitea/23
[13:23:01] <toasterson1> Yeah that is about what it should be. But after some time it increases.
[13:23:22] <toasterson1> I guess it is related to the mirrors I have running.
[13:24:15] <toasterson1> But I was more interested, that the memory would not be freed until the zone is restarted.
[13:29:20] *** BOKALDO <BOKALDO!~BOKALDO@87.110.91.76> has joined #illumos
[13:31:02] *** arnoldoree <arnoldoree!~arnoldore@113.210.103.25> has joined #illumos
[13:45:52] *** BrownBear <BrownBear!~BrownBear@107.175.247.247> has quit IRC (Ping timeout: 256 seconds)
[13:48:29] *** BrownBear <BrownBear!~BrownBear@107.175.247.247> has joined #illumos
[13:51:36] *** wacki <wacki!~wacki@i577B0885.versanet.de> has quit IRC (Ping timeout: 256 seconds)
[13:52:18] *** wacki <wacki!~wacki@i577B0885.versanet.de> has joined #illumos
[13:57:47] *** varna <varna!~varna@60.176.150.59> has quit IRC (Ping timeout: 260 seconds)
[13:58:06] *** varna <varna!~varna@60.176.150.59> has joined #illumos
[14:01:10] *** liv3010m <liv3010m!~liv3010m@77-72-245-190.fibertel.com.ar> has quit IRC (Ping timeout: 256 seconds)
[14:03:06] *** tsoome_ <tsoome_!~tsoome@91.209.240.229> has quit IRC (Read error: Connection reset by peer)
[14:03:30] *** tsoome_ <tsoome_!~tsoome@91.209.240.229> has joined #illumos
[14:04:48] *** liv3010m <liv3010m!~liv3010m@77-72-245-190.fibertel.com.ar> has joined #illumos
[14:23:06] <liv3010m> @rmustacc: morning! sorry I felt asleep yesterday. Right now I'm trying to figure out why after creating the "addr" object (create-addr) it stays in inaccessible state on ipadm show-addr and down state on dladm show-phys. It doesn't matter the value the MTU is set.
[14:43:39] *** clapont <clapont!~clapont@unaffiliated/clapont> has quit IRC (Ping timeout: 265 seconds)
[14:54:48] *** Kruppt <Kruppt!~Kruppt@50.111.31.107> has joined #illumos
[15:06:57] *** nbhauke <nbhauke!~hauke@55d4023b.access.ecotel.net> has joined #illumos
[15:12:55] <toasterson1> Who is our resident rust programmer? I want to get firefox 60 to compile with rust 1.40 so we can update rust. Turns out rust 1.40 finds more bugs than 1.32 and so we need to fix some rust code. https://github.com/OpenIndiana/oi-userland/pull/5626
[15:33:18] *** mnrmnaugh <mnrmnaugh!~mnrmnaugh@unaffiliated/mnrmnaugh> has joined #illumos
[15:33:49] *** jlevon` <jlevon`!jlevon@2a01:7e00::f03c:92ff:fefb:3ad2> has joined #illumos
[15:44:42] *** BOKALDO <BOKALDO!~BOKALDO@87.110.91.76> has quit IRC (Quit: Leaving)
[15:47:46] *** jlevon <jlevon!~jlevon@178.79.150.28> has quit IRC (Quit: Coyote finally caught me)
[15:47:56] *** jlevon` <jlevon`!jlevon@2a01:7e00::f03c:92ff:fefb:3ad2> has quit IRC (Quit: Coyote finally caught me)
[16:04:55] *** yomisei <yomisei!~void@ip4d16be28.dynamic.kabel-deutschland.de> has quit IRC (Ping timeout: 256 seconds)
[16:08:27] *** neirac <neirac!~neirac@pc-215-101-46-190.cm.vtr.net> has joined #illumos
[16:10:14] *** jcea <jcea!~Thunderbi@2001:bc8:2ecd:caed:7670:6e00:7670:6e00> has joined #illumos
[16:20:47] *** jlevon <jlevon!jlevon@2a01:7e00::f03c:92ff:fefb:3ad2> has joined #illumos
[16:34:29] *** yomisei <yomisei!~void@ip4d16be28.dynamic.kabel-deutschland.de> has joined #illumos
[16:49:29] *** superjen96 <superjen96!~jenelizab@185.192.70.184> has joined #illumos
[16:50:54] *** jenelizabeth <jenelizabeth!~jenelizab@cpc155793-brmb11-2-0-cust474.1-3.cable.virginm.net> has quit IRC (Ping timeout: 240 seconds)
[16:56:36] *** BOKALDO <BOKALDO!~BOKALDO@87.110.91.76> has joined #illumos
[17:08:29] *** neirac <neirac!~neirac@pc-215-101-46-190.cm.vtr.net> has quit IRC (Remote host closed the connection)
[17:18:42] <LeftWing> toasterson1: oof, that doesn't look like a good bug
[17:22:23] *** jlevon <jlevon!jlevon@2a01:7e00::f03c:92ff:fefb:3ad2> has quit IRC (Quit: Coyote finally caught me)
[17:22:44] *** jlevon <jlevon!~jlevon@178.79.150.28> has joined #illumos
[17:22:46] <toasterson1> which is why I assuem they already fixed it upstream but we are behind too much.
[17:25:54] <toasterson1> and with my limited git knowledge it is going to be a PITA to sort through the firefox repo.
[17:26:48] <rmustacc> liv3010m: Hmm. I'm not sure after creating the address did you turn the address up? What shows up in ifconfig?
[17:26:52] <LeftWing> For what it's worth, we're not using clang while working on the rust port
[17:27:05] <LeftWing> And aren't using any of those pkgsrc patches
[17:27:59] <liv3010m> Hi Robert, let me check. One second
[17:28:30] *** ypankov <ypankov!~ypankov@85.174.202.47> has joined #illumos
[17:28:45] <toasterson1> LeftWing (IRC): You mean the patches for firefox? No I was compiling 60 from Oi/hipster branch in oi-userland
[17:28:56] <LeftWing> For Rust, I mean
[17:29:08] *** dopplergange <dopplergange!~dop@152.89.160.124> has quit IRC (Ping timeout: 256 seconds)
[17:29:13] <toasterson1> ah you mean they create that bug maybe?
[17:30:10] <LeftWing> Well I'm not sure about that, but I wonder what other unintended consequences they may have
[17:30:33] <toasterson1> hmm good idea to try. Do you have alist of your patches somewhere?
[17:30:41] *** neirac <neirac!~neirac@pc-215-101-46-190.cm.vtr.net> has joined #illumos
[17:30:42] <liv3010m> I don't see anything strange on ifconfig
[17:30:49] *** neirac <neirac!~neirac@pc-215-101-46-190.cm.vtr.net> has quit IRC (Remote host closed the connection)
[17:31:42] <LeftWing> toasterson1: So we're currently building the toolchain with GCC 7 or 8 on Linux (it's a cross build, using a copy of illumos gate as a sysroot)
[17:31:55] <LeftWing> Because thats how they do their builds
[17:32:00] <liv3010m> shows IP, mtu (because I changed it again to 9K), broadcast addr, mac addr.. the usual stuff is shown
[17:32:11] <toasterson1> ok any patches?
[17:32:26] <LeftWing> They have a specific LLVM version they include for instance, not just whatever local clang
[17:32:27] <toasterson1> or should pure upstream work?
[17:32:45] <LeftWing> Pure upstream is working pretty well
[17:33:01] <tsoome_> ok, any idea why solaris_sparc.o is built ELFCLASS32 while it should be 64 while building openjdk-8?
[17:33:02] <LeftWing> Any problems with it I will fix upstream too
[17:33:37] <toasterson1> I'll try to do an upstream build then and tell you which patches are still required.
[17:34:25] <LeftWing> Tah
[17:34:48] <toasterson1> ?
[17:35:06] <toasterson1> is that IRC lingo? or an exclamation?
[17:35:09] *** jlevon` <jlevon`!jlevon@2a01:7e00::f03c:92ff:fefb:3ad2> has joined #illumos
[17:35:16] <LeftWing> It is Australian for Thank you!
[17:35:27] <toasterson1> :)
[17:53:07] *** neirac <neirac!~neirac@pc-215-101-46-190.cm.vtr.net> has joined #illumos
[17:57:27] *** neirac <neirac!~neirac@pc-215-101-46-190.cm.vtr.net> has quit IRC (Remote host closed the connection)
[17:58:22] *** neirac <neirac!~neirac@pc-215-101-46-190.cm.vtr.net> has joined #illumos
[18:11:53] <richlowe> tsoome_: expecting the compiler to default -m64 and it isn't?
[18:12:40] *** nbhauke <nbhauke!~hauke@55d4023b.access.ecotel.net> has quit IRC (Quit: nbhauke)
[18:14:03] <rmustacc> liv3010m: I was just curious to see the actual flags that were set on the device.
[18:16:24] <liv3010m> https://i.ibb.co/VDcMWR6/IMG-1987.jpg
[18:17:31] <rmustacc> Hmm. So up is present, but not running.
[18:17:32] <liv3010m> It's missing the RUNNING word
[18:17:33] <rmustacc> That's weird.
[18:17:38] <liv3010m> exactly
[18:18:18] <rmustacc> Just to humor me, if you do ifconfig bge1 down and then ifconfig bge1 up, does anything change?
[18:18:28] <liv3010m> physically the port on the switch has link
[18:18:42] <liv3010m> I haven't tried, I'll do
[18:19:59] <liv3010m> it's the same
[18:20:29] <rmustacc> OK. So, hmm. I'll have to research later how this works.
[18:20:55] <rmustacc> At some point, I may have to pause at our original, not working with aggr support. Maybe I should track down a bge device so I can do some local testing.
[18:22:38] <liv3010m> I'll try to put the original driver back to see what happens
[18:23:44] *** cypa <cypa!~cypam]_@5.79.187.109> has joined #illumos
[18:23:57] *** neirac <neirac!~neirac@pc-215-101-46-190.cm.vtr.net> has quit IRC (Remote host closed the connection)
[18:24:04] <rmustacc> OK, so maybe what'll be useful is if we go back to the one where I just added support for the new chipset.
[18:24:09] <rmustacc> And verify if 9k mtu works there.
[18:24:44] <rmustacc> Because that wasn't so invasive into the driver as all the other stuff I've been doing to fix the assert.
[18:25:02] *** clapont <clapont!~clapont@unaffiliated/clapont> has joined #illumos
[18:33:33] <tsoome_> richlowe: its built with gcc6 (oi-userland, old one), and it does have bunch of other files built 64-bit, but I can not see any obvious reason why this one should be different:D
[18:36:42] <tsoome_> I never understood the urge to hide build commands, the only thing we get is this damn spam from gmake, and the useful output is all hidden:(
[18:50:05] <liv3010m> @rmustacc: you mean the first release right
[18:51:34] <rmustacc> Yeah, the first one that worked for the part.
[18:51:38] <rmustacc> I can also build that again.
[18:55:08] <jbk> sjorge: yeah, that's pretty normal -- there's two main ways UNIX authentication is done w/ LDAP.. the older method just more or less directly replaces all the /etc files with LDAP entries.. (including the shadow info).. however you end up with a lowest common denominator situation when mixing different OSes and OS versions
[18:56:22] <jbk> it also means that the host and not hte ldap server is what actually does the authentication -- it grabs the hash value and does it's own check (so again.. that usually means the password has to be stored in the old crypt format for cross-platform compatability)
[18:56:30] <jbk> the newer way lets the LDAP server handle all of that
[18:56:55] <jbk> and the server just tries to bind as the LDAP entry for the user (using the password supplied during login)
[18:57:18] <jbk> which means the LDAP server can implement whatever policies it wants
[18:57:30] <jbk> password aging, retry lockouts, etc.
[18:58:09] <jbk> and it can store the password in whatever manner it wants
[18:59:35] <jbk> and during the bind attempt, it can send an ldap control back with the bind response indicating password is about to expire, must be changed, etc.
[19:02:17] <liv3010m> @rmustacc: I've it, I''l try it
[19:10:12] <rmustacc> OK.
[19:10:43] *** jlevon` <jlevon`!jlevon@2a01:7e00::f03c:92ff:fefb:3ad2> has quit IRC (Quit: Coyote finally caught me)
[19:11:47] *** jlevon` <jlevon`!jlevon@2a01:7e00::f03c:92ff:fefb:3ad2> has joined #illumos
[19:16:59] *** ibenn <ibenn!~benn@HSI-KBW-095-208-237-062.hsi5.kabel-badenwuerttemberg.de> has quit IRC (Quit: Leaving)
[19:20:13] *** jlevon` <jlevon`!jlevon@2a01:7e00::f03c:92ff:fefb:3ad2> has quit IRC (Quit: Coyote finally caught me)
[19:21:29] *** jlevon` <jlevon`!jlevon@2a01:7e00::f03c:92ff:fefb:3ad2> has joined #illumos
[19:22:06] <jbk> so this is strange... https://github.com/libunwind/libunwind/blob/master/tests/Gtest-concurrent.c -- each thread calls 'signal(SIGUSR1, handler)' at the start of each launched thread, then each thread does 'pthread_kill(pthread_self(), SIGUSR1)'
[19:22:37] <jbk> yet according to truss, the program dies because one of those pthread_kill() invocations is unhandled
[19:22:42] *** arnoldoree <arnoldoree!~arnoldore@113.210.103.25> has quit IRC (Ping timeout: 260 seconds)
[19:23:01] <jbk> though when it comes to signals, i suppose strangeness par for the course
[19:23:09] *** jlevon` <jlevon`!jlevon@2a01:7e00::f03c:92ff:fefb:3ad2> has quit IRC (Client Quit)
[19:23:37] *** jlevon` <jlevon`!jlevon@2a01:7e00::f03c:92ff:fefb:3ad2> has joined #illumos
[19:25:24] *** jlevon <jlevon!~jlevon@178.79.150.28> has quit IRC (Quit: Coyote finally caught me)
[19:25:27] <liv3010m> @rmustacc: OK, here is the thing I think (at least with version 1). create-if and create-addr work when I don't touch the MTU at datalink level
[19:26:29] <liv3010m> when I remove the IP and IF, change the MTU and try again to create-if and create-addr it seems to work but it doesn't in reality
[19:27:43] <liv3010m> If thereafter I remove if and addr, go to dladm to set the MTU back to 1500 and try to create-if and create-addr they behave the same, ie they "work" but don't work actually
[19:28:12] <liv3010m> it seems that setting MTU to 9K corrupts something
[19:28:33] <rmustacc> OK. Good to know. I'll need to go look at that then.
[19:28:40] <rmustacc> I'll focus on that. Thank you.
[19:28:45] <liv3010m> super!
[19:28:55] <rmustacc> Probably won't happen today, just to be realistic.
[19:29:02] <liv3010m> if you want I can try v4 if it works with aggr
[19:29:08] <liv3010m> no problem!
[19:29:43] <liv3010m> (v4 is the latest version)
[19:30:05] *** jlevon` is now known as jlevon
[19:30:54] <rmustacc> Does the v4 behave in the same way as v1?
[19:31:05] <rmustacc> With respect to working at 1500 byte mtu?
[19:31:15] <liv3010m> I think so, I have to try
[19:31:27] <liv3010m> the first think I did with v4 was to set the MTU to 9K
[19:31:28] <rmustacc> OK, if you could verify that and the aggrs (or a vnic) all at 1500, that'd help me out.
[19:31:52] <liv3010m> and if this is like v1 then than can be the cause that nothing worked
[19:31:58] <liv3010m> yup
[19:32:02] <liv3010m> all in 1.5K
[19:32:11] <liv3010m> I'll try
[19:32:56] <liv3010m> I'll see if rebooting to that BE works or something strange stays on the system and have to create a new BE
[19:33:20] <rmustacc> OK, thanks.
[19:33:24] <liv3010m> ;)
[19:46:12] <liv3010m> Robert a small update: booting into the v4 driver BE got this: - the "corruption" after nothing working by setting MTU to 9K didn't persist reboots since: 1) create-if and create-addr worked on both bge adapters. 2) creating a default static aggregation and doing a create-if and create-addr object on top of it worked
[19:46:29] <liv3010m> I'll try now to create an LACP aggr
[19:48:56] <rmustacc> And I assume as part of this it's usable from another system?
[20:01:38] <liv3010m> that's what I was trying until it crashed. :(
[20:02:23] <liv3010m> before changing to LACP I thought better try something simple, to ssh to it from my computer
[20:03:36] <liv3010m> long story short when I went back to the system I saw that it rebooted
[20:04:10] <liv3010m> https://i.ibb.co/RzJq2NL/IMG-1992.jpg
[20:13:32] <tsoome_> whee, i found the error:D
[20:21:04] <rmustacc> liv3010m: That's too bad. If you decompress the crash dump and use '$C' what happens?
[20:26:31] <liv3010m> I'll do savecore and run the latest dtrace "snippet" we had?
[20:27:08] *** nbhauke <nbhauke!~hauke@55d4023b.access.ecotel.net> has joined #illumos
[20:30:04] *** dopplergange <dopplergange!~dop@titan.pathogen.is> has joined #illumos
[20:30:32] *** dopplergange <dopplergange!~dop@titan.pathogen.is> has quit IRC (Read error: Connection reset by peer)
[20:31:48] *** dopplergange <dopplergange!~dop@titan.pathogen.is> has joined #illumos
[20:36:48] *** hww3 <hww3!~hww3@c-73-128-248-73.hsd1.md.comcast.net> has quit IRC (Ping timeout: 265 seconds)
[20:37:06] *** dopplerg- <dopplerg-!~dop@89.187.173.251> has joined #illumos
[20:37:18] *** hww3 <hww3!~hww3@c-73-128-248-73.hsd1.md.comcast.net> has joined #illumos
[20:37:27] *** dopplergange <dopplergange!~dop@titan.pathogen.is> has quit IRC (Ping timeout: 265 seconds)
[20:40:36] *** nbhauke <nbhauke!~hauke@55d4023b.access.ecotel.net> has quit IRC (Quit: nbhauke)
[20:42:17] *** hww3 <hww3!~hww3@c-73-128-248-73.hsd1.md.comcast.net> has quit IRC (Ping timeout: 265 seconds)
[20:45:05] *** nbhauke <nbhauke!~hauke@55d4023b.access.ecotel.net> has joined #illumos
[20:54:06] *** nbhauke <nbhauke!~hauke@55d4023b.access.ecotel.net> has quit IRC (Quit: nbhauke)
[21:04:07] *** neirac <neirac!~neirac@pc-215-101-46-190.cm.vtr.net> has joined #illumos
[21:22:54] *** clapont <clapont!~clapont@unaffiliated/clapont> has quit IRC (Ping timeout: 265 seconds)
[21:30:04] *** clapont <clapont!~clapont@unaffiliated/clapont> has joined #illumos
[21:56:13] *** Kurlon_ <Kurlon_!~Kurlon@cpe-67-253-136-97.rochester.res.rr.com> has quit IRC (Quit: Leaving...)
[21:57:04] *** BOKALDO <BOKALDO!~BOKALDO@87.110.91.76> has quit IRC (Quit: Leaving)
[21:58:19] *** pmooney <pmooney!~pmooney@67-4-175-230.mpls.qwest.net> has quit IRC (Quit: WeeChat 2.7)
[22:06:12] *** Kurlon <Kurlon!~Kurlon@cpe-67-253-136-97.rochester.res.rr.com> has joined #illumos
[22:12:37] *** neirac <neirac!~neirac@pc-215-101-46-190.cm.vtr.net> has quit IRC (Ping timeout: 250 seconds)
[22:26:28] <sjorge> jbk: ok that should simplify things, I can drop shadowAccount objectClass and attributes and just use ppolicy!
[22:26:56] <sjorge> Looks like sssd on Linux also does both ways were it can do the shadow thing but also the bind thing
[22:27:06] <jbk> ISTR that at least some clients still want the shadowAccount OC on users, but not really used
[22:27:16] <jbk> even if you're doing LDAP binds
[22:27:33] <sjorge> jbk: I also noticed our pam_list lacks filtering on group (not netgroup) like oracle
[22:27:46] <sjorge> Solaris and Linux, I filed an issue for it
[22:27:59] <jbk> richlowe: so it looks like glibc at least adds the cfi_undefined %rip to it's _start, so i'm tempted to file a bug and review w/ that patch
[22:28:22] <jbk> I can't think of any situations where it'd hurt
[22:28:32] <jbk> sjorge: shouldn't be too bad to support
[22:28:34] <sjorge> I had a look at the code and I can’t see an easy way to add it, as currently there are no group membership info in pam to check against ( that I could find)
[22:28:45] <jbk> though i always wanted to manage all of that in ldap itself, but i guess i was the only one :P
[22:28:45] <sjorge> Oh
[22:29:10] <sjorge> Well I want all accounts info to be available
[22:29:25] <sjorge> But want to restrict who can login on different classss of systems based on groups
[22:29:39] <jbk> at a few jobs ago, I actually did a system where you'd create separate LDAP entries for each server (so each server uses it's own account + password to connect to ldap)
[22:29:53] <sjorge> I don’t use netgroups and it not sometbing that seems fun to start using
[22:30:13] <jbk> and then you'd organize the servers into a heirarchy using OUs (this is more common w/ AD + windows servers)
[22:30:29] <sjorge> I still want the passwd and group entries everywhere though
[22:30:40] <jbk> and had a custom auxiliary object class that defined 'allowedUser' and 'allowedGroup' attributes (holding DNs)
[22:31:12] <jbk> and a PAM module that'd find the entry of the server it's running on
[22:31:31] <jbk> the DN of the user being authorized
[22:31:39] <jbk> and the groups fo the user
[22:31:51] <jbk> and look at the allowed{User,Group} entries in the server object
[22:32:03] <jbk> as well as work it's way up the heirarchy to the baseDN
[22:32:12] <jbk> (basically allowing inheritance)
[22:32:26] <sjorge> That seems way more complex than the pam_list route that works on linux/oracle Solaris
[22:32:36] <sjorge> But more controllable though
[22:32:38] <jbk> well it allows you to do things like group servers by function
[22:32:46] <jbk> and then just grant access to a user/group in one spot
[22:32:58] <jbk> and if you add/move a server to a new OU
[22:33:08] <jbk> you don't have to go through and re-do access
[22:33:26] <sjorge> (On a happier note, I figured out how to integrate ldap into freeradius in a way that works for me with one custom objectClass and a bunch of radius profiles)
[22:33:42] <sjorge> Pending an OID registration at IANA now
[22:33:48] <jbk> that way, I didn't have to manage 2000+ copies of a file
[22:34:14] <sjorge> I hope they approve as it does say private organizations only :(
[22:34:24] <jbk> I could basically control access based on the notion of roles
[22:34:31] <jbk> both what things a user did
[22:34:37] <jbk> and what things a particular server was doing
[22:34:50] <jbk> and if the two intersected, the user had access
[22:35:07] <jbk> and manage it in basically one spot
[22:35:17] <sjorge> Also I learned passwd works for self service password changes <
[22:35:35] <jbk> yeah.. you can usually control that if you want
[22:36:01] <jbk> most LDAP servers have functionality to do special handling of a user's password attribute (usually userPassword)
[22:36:24] <sjorge> Yeah I had to allow it via ppolicy, but it’s pretty nice
[22:36:27] *** ypankov <ypankov!~ypankov@85.174.202.47> has quit IRC (Quit: leaving)
[22:37:05] <sjorge> Oops low battery beep, I’ll be AFK
[22:37:12] <jbk> later
[22:44:21] <liv3010m> @rmustacc: I extracted the dump with savecore but don't know how to debug it to see what happened
[22:45:54] <rmustacc> liv3010m: Simplest thing to do is to use mdb and run '::status' and '$C' and that'll give me a good starting point.
[22:46:43] <liv3010m> OKey will do!
[22:53:07] <liv3010m> if I run mdb and right after ::status it doesn't shows anything, After that if I run SC it shows me: mdb: Failed to dereference symbol: unknown symbol name
[22:53:45] *** danmcd <danmcd!~danmcd@static-71-174-113-16.bstnma.fios.verizon.net> has quit IRC (Ping timeout: 240 seconds)
[22:54:46] <liv3010m> I don't think I'm doing it right, like if i'm missing a step between savecore -vf "crashdump_file" and mdb, or is it right?
[22:55:05] <rmustacc> So, what were the arguments to mdb?
[22:55:13] <rmustacc> Did you specify the dump?
[22:57:50] <liv3010m> nope, thats the thing haha. Give me one second
[23:00:36] <liv3010m> SC still doesn't work
[23:01:21] <liv3010m> https://i.ibb.co/CJG7KCv/IMG-1994.jpg
[23:02:50] <rmustacc> Are you using an 'S' or the '$'
[23:04:05] <liv3010m> S from like Solaris
[23:04:19] <liv3010m> is it an money symbol?
[23:04:31] <liv3010m> OMG
[23:04:34] <liv3010m> :(
[23:04:53] <rmustacc> It's the money symbol.
[23:05:05] <liv3010m> sorry the typography looks almost same
[23:05:08] <liv3010m> my bad
[23:05:24] <liv3010m> I'll redoit
[23:06:24] <liv3010m> OK we got something
[23:07:04] <liv3010m> https://i.ibb.co/hKTymHV/IMG-1995.jpg
[23:07:44] <rmustacc> That's awkward.
[23:07:50] <rmustacc> Well, at least I know what's going on.
[23:07:56] <rmustacc> And sorry for the confusion on the typography.
[23:07:57] *** psarria <psarria!~phyre___@78.30.17.247> has quit IRC (Remote host closed the connection)
[23:08:24] <liv3010m> don't worry its my chat client fault and mine
[23:08:42] <liv3010m> yes? does it look simple?
[23:08:47] *** nbhauke <nbhauke!~hauke@55d4023b.access.ecotel.net> has joined #illumos
[23:09:05] *** nbhauke <nbhauke!~hauke@55d4023b.access.ecotel.net> has quit IRC (Client Quit)
[23:09:12] <rmustacc> Certainly it makes it very clear what happened.
[23:09:26] <rmustacc> This is part of the challenge of trying to unwind the driver right now.
[23:09:44] <liv3010m> Ah, OK
[23:10:02] <rmustacc> Since one of the updates that was made a little while back to add support for the 5719/5720 conflated and messed up a bunch of other things.
[23:10:07] <rmustacc> Which is what we're trying to figure out.
[23:10:54] *** wacki <wacki!~wacki@i577B0885.versanet.de> has quit IRC (Quit: Lingo: www.lingoirc.com)
[23:10:57] <liv3010m> I see. Take you time
[23:11:52] <rmustacc> So that's why we kept hitting issues after the initial support was working.
[23:12:13] <rmustacc> And now I wonder if jumbo frames actually works on bge at all (before I added suport for the new chipset)
[23:15:15] <jbk> heh
[23:15:30] <liv3010m> Interesting. Maybe since it behaved so strange after changing the MTU it can be that people who had MTU 9K active before the new chipset change have them continue to work if they didn't touch it?
[23:16:06] <liv3010m> It's a guess ..
[23:16:07] <rmustacc> I'm wondering something more fundamental. Do jumbo frames work at all on the driver.
[23:16:20] <rmustacc> I've pinged someone who has one so hopefully I'll be able to get an answer.
[23:16:31] <liv3010m> Perfect
[23:19:02] *** nbhauke <nbhauke!~hauke@55d4023b.access.ecotel.net> has joined #illumos
[23:23:07] *** nbhauke <nbhauke!~hauke@55d4023b.access.ecotel.net> has quit IRC (Client Quit)
[23:30:59] *** psarria <psarria!~phyre___@78.30.17.247> has joined #illumos
[23:35:48] <toasterson1> LeftWing ok one rust patch is manadatory.
[23:35:55] <LeftWing> Which one!
[23:36:01] <LeftWing> This is news I can use
[23:36:20] <toasterson1> the headers of the lzma config.h file
[23:37:29] <LeftWing> Huh
[23:37:35] <LeftWing> Do you have a link to that one
[23:38:08] <toasterson1> https://github.com/OpenIndiana/oi-userland/blob/5b5ede466ec6405a93e5fadbca460bd50875c5bb/components/developer/rust/patches/vendor_lzma-sys_config.h.patch
[23:39:02] <toasterson1> We also have some patches which will remain manadatory for us as we want to use the system clang.
[23:39:20] <toasterson1> It does not detect the include and runpaths correctly
[23:39:52] <LeftWing> I'm not sure if that's wise
[23:40:02] <LeftWing> I feel like they select and test a very specific LLVM version
[23:40:18] *** cypa <cypa!~cypam]_@5.79.187.109> has quit IRC (Ping timeout: 256 seconds)
[23:40:32] <toasterson1> well we needed several patches until now so that it even builds
[23:41:08] <LeftWing> I haven't hit the lzma one. What compiler are you using to build?
[23:41:16] <toasterson1> We recently found out that many linker bugs were caused by symlink cloning.
[23:41:19] <toasterson1> gcc7
[23:41:28] <toasterson1> 7.5 and clang 9
[23:41:44] <LeftWing> Huh. I don't see that failure with either GCC 7 or 8 in the crossbuild environment
[23:42:07] <toasterson1> Well your headers don't conflict :)
[23:42:32] <LeftWing> We use illumos headers for that build
[23:43:08] <LeftWing> So I would expect the same conflicts or not
[23:46:24] <toasterson1> hmm POSIX source version definetly seems old otherwise.
top

   April 4, 2020  
< | 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 | >