11:25:51 [illumos-gate] 17221 bhyve emulated e1000g fails with TSO -- Andy Fiddaman 12:53:26 7G free ram and ramdiskadm can not create 2G disk, really?! 18:21:31 tsoome: How much physical memory and how much swap on the system? 18:21:43 8G + 8G 18:21:54 That's definitely a little suspicious haha 18:22:03 Do you know what check it's failing at? 18:22:29 EAGAIN - we get it on memory allocation failure 18:23:00 I was able to allocate like 1800MB 18:23:32 system is vmware fusion VM 18:25:08 tbh, I did not really dig too much... 18:26:32 I guess it'll stay the way it is then haha 18:30:59 btw https://www.illumos.org/issues/7291 or https://github.com/illumos/illumos-gate/pull/22 — the panic script at issue does still work (it is a bit buggy, however): panic[cpu1]/thread=fffffe1719b9cc20: assertion failed: dv->sdev_nlink == 1, file: ../../common/fs/dev/sdev_subr.c, line: 2961 18:31:00 → BUG 7291: Attempting to destroy ZFS filesystem and create ZFS volume with the same name caused system panic (In Progress) 19:10:06 do ramdisks need to be contiguous in kernel virtual space? maybe that space is fragmented but looks sufficiently underutilized that we don't grow it? 19:13:12 well, it also failed right after boot. but that does not really mean the memory is not fragmented.... 19:13:42 freebsd with 4GB of ram has no problem to create 2GB ramdisk. 19:13:52 go figure. 19:17:29 sorry to say, but this os needs much love. 19:19:38 Hello, not sure if anyone's aware but the illumos man pages are down (at least for me). I haven't been able to access them for a couple of weeks 19:23:27 We're aware, the internet sucks, work is afoot 19:24:25 sommerfeld: No, it doesn't need to be contiguous 19:25:33 tsoome: If you decide to debug it, let us know what check it's failing on for you. 19:26:38 it has exactly one (1) line with return (EAGAIN); its pretty easy to see. 19:27:05 Right, but why is it returning that 19:27:57 richlowe Is there an alternative source of documentation? 19:28:42 Assuming you don't have a local system, you can always clone it and point man/mandoc tools at the pages directly. 19:28:54 I've been referencing the SmartOS man pages but I'm not sure if there are discrepancies between those pages and the illumos pages 19:29:14 I'll keep that in mind 19:29:19 Guest7 you can use https://man.omnios.org, there is small difference, but nothing too drastic. 19:29:53 If you have an illumos system installed, and presuming you're not short of disk space, I *strongly* suggest installing the manpages. Having them local means you don't care what the cloud is doing. 19:30:30 * nomad is the personification of 'old man yells at [the] cloud'. 19:30:34 tsoome: aren't ramdisks limited to 25% of free memory? which 2G of 7G will exceed. 19:31:04 ptribble yay;) 19:33:02 ramdisk(4D) says "percentage of available physical memory" which isn't exactly clear whethere it's available or physical 19:33:40 or both 19:34:01 though why you'd do that I don't know 19:35:58 Why would a build throw an 'implicit declaration of function' error for 'strdup', which is located in , when this header is indeed present in the source file? Not blocked out by any ifdefs 19:37:50 Guest7 replace -c by -E and see what is going on. 19:38:42 Guest7 you should see traces of string.h, also function declarations in it, including one for strdup(). 19:39:51 Guest7: Isn't strdup(3C) in strings.h not string.h 19:40:33 it can happen if you set _POSIX_SOURCE or _XOPEN_SOURCE to an older version that didn't have strdup() and don't have __EXTENSIONS__ defined to allow non-standard functions to be declared 19:41:07 it's pretty common for people to misunderstand the standards defines and think they're helping themselves 19:41:31 string.h:extern char *strdup(const char *); 19:42:04 and some of those people write Makefiles or CMakefiles or meson.build files in to propogate those mistakes to others 19:42:14 it's also fairly common to fall victim to namespace badness that makes things work on other systems, just because of the implementation details of how their headers include other headers 19:42:31 ptribble: d'oh. 19:43:51 tsoome: see the standards/namespace guards surrounding literally that line 19:46:46 tsoome Thanks! I'll try looking here next 19:47:56 I did find strdup(3C) in strings.h instead of string.h per jclulow. There are plenty of other functions which are getting the same error 19:49:31 Guest7: What does the command line for "gcc" end up being 19:49:38 a number getting the same error sounds like standards namespace defines 19:49:48 oh, jclulow is ahead of me 19:54:11 Hmm forgive my inexperience, are you asking for the output specs for gcc? 19:56:07 No, the full gcc command line that is being used that creates the failure. 19:56:23 So it would include things like -std=... -D... -o foo.o -c foo.c, etc. 20:00:20 20:00:49 rmustacc Thanks, I'll find it and share it 20:00:53 if you're using a build system that just prints "CC foo.o" the usual way to make that useful is to do `make V=1` 20:02:17 adfasd 20:05:46 This program is using CMake 20:11:35 ls 20:11:39 Oops 20:19:17 Still looking around for those flags, if nothing else, here's the repository https://github.com/hpc-gridware/clusterscheduler 20:33:15 It's passing -std=c99 21:15:27 ptribble: was there anything still holding you back about fixing int8_t? 21:15:39 "just" possible mangling ABI damage? 21:16:39 ptribble: and if there's anything I could do to help get whatever manual page fixes you have outstanding upstream, what is it? :) 21:17:20 Fixing char requires a number of changes to the gate itself 21:17:48 I think you've already fixed them in the arm gate, but those would need to be fixed first 21:18:17 I'll have fixed them, but I'm not sure in an easy to cherry-pick way :\ 21:18:38 and I won't have fixed anything I've unilaterally declared too crap to port 21:18:48 which I sure look forward to writing an IPD about :\ 21:19:27 ptribble: but if your porting old software into the future hobby needs a further outlet... :) 21:20:15 I wonder how much overlap there is between your "too crap to port" and my "too crap to ship in Tribblix" 21:39:08 alanc: do you know what the hell is going on with `_I32LPx`? and it's use anywhere at all? 21:39:49 it appears our headers decide "don't care about LP except they're the same" actually means "x == 64" 21:40:39 jlevon: you used this on purpose in dboot 21:48:40 richlowe: (cc pmooney) I think, looking at this some more, that it's fine to use _I32LPx there, but we should _also_ use _ILP32 when that's true -- and the UINTPTR_MAX definition should take that into account 21:49:23 And probably that there are a great many places in the gate where we are assuming stuff (for, e.g., padding) which is actually only true for LP64 and would not necessarily be true for I32LPx at all 21:49:23 yeah, I think the larger use of I32LPx as "pointers are 64-bit, right?" is wrong 21:49:28 right 21:49:37 but then _I32LPx surely only means "not a computer that doesn't exist" 21:49:42 if you have to define the concrete reality too 21:49:58 and also that all the uses we have for it in the code are sketchy as hell 21:50:07 Yeah, I think it's probably a silly definition 21:50:08 I mean, I32LPx would be true for amd64 21:50:18 Right, I32LPx is true for everything we currently support haha 21:50:34 I32LPx would be true for every computer that's not like, a Cray or NEC monstrosity 21:50:36 and is also only relevant if you're actually trying to stuff a pointer into a long, or that you care about int being 32bit 21:50:45 it looks like things checking for _only_ I32LPx is rare (if nonexistent) 21:50:57 so the things checking for LP64 will continue to be correct 21:51:08 We should probably look at cleaning up the silly haha 21:51:11 we should 21:51:17 This is indeed quite confusing 21:51:24 (and, in this case, causing UINTPTR_MAX to be wrong) 21:51:28 yup 21:51:37 I'll get something filed for this 21:51:38 I'll file a bug 21:51:40 ok 21:51:43 you do it then 21:51:45 :D 21:52:09 fine, I will 21:52:24 richlowe: thanks for poking at this 21:52:29 Yes, thank you 21:55:10 _I32LPx apparently came from PSARC/1996/370 21:55:38 PSARC/1996/370 Derived Types for 64-bit Solaris Tim Marsland closed approved 9/17/97 Unpublished 21:55:42 rip 21:57:06 the exception, though I don't know why Solaris or illumos would care, would be the initial HAL 64-bit port of Solaris to their SPARC64 CPU before Fujitsu absorbed them, since they were actually ILP64 21:57:32 https://en.wikipedia.org/wiki/64-bit_computing#64-bit_data_models 22:01:27 https://sparc.org/wp-content/uploads/2014/01/64.derived.type_.pdf.gz is a very similar paper to the ARC case, except it's missing the ILP32x sections 22:05:29 but the discussion of how it sucks that C++ mangles "int" and "long" differently in 32-bit, even though they have the same underlying representation, and thus changing types from "long" to "int" to mean "really 32-bit" breaks C++ when preparing your headers for LP64 environments 22:07:16 same problem I asked ptribble about earlier 22:07:26 plate, shrimp 22:07:37 that ARC case also includes the wonderful statement " We have around 38 years to work out how to fix the time_t problem, for example." 22:14:00 filed 17234 for this 22:14:29 If you think there's reason to leave I32LPx defined, on the off chance that we want to handle non-32bit ints in the future, please say so 22:14:36 otherwise I'm inclined to rip it all the way out 22:15:39 good riddance;) 22:16:23 from what I have seen, I don't think it would help even if that happened. 22:16:57 speaking of, there is still https://code.illumos.org/c/illumos-gate/+/3288 22:16:58 → CODE REVIEW 3288: 17139 sparc: remove (NEW) | https://www.illumos.org/issues/17139 22:17:10 I wish I understood how it got into usbwcm, ilb, rds, 22:17:48 and presumably dboot was explicitly _trying_ to get 64bit definitions without being 64bit itself? 22:18:49 worse. its 32-bit in i86pc and 64-bit in i86xpv. And yes, it needs 64-bit defs to fill boot_info et al for 64-bit kernel. 22:19:17 and of course, part of the mess is because it had to take care of both 32-bit and 64-bit kernels. 22:21:02 uts/intel/sys/bootinfo.h has explicit sizing and definitions of its own to make that happen though 22:21:22 _I32LPx doesn't get used in there 22:25:30 got sidetracked reading through the extensive mail log (including many digressions into how many years it would be before the 32-bit time_t became a problem), since I32LPx wasn't in the initial proposal 22:26:51 it looks like it came out of trying to resolve compatibility issues with older compilers (older by 1996 standards, so pre-historic for illumos) and also XPG3 standards test failures 22:27:15 We would also support a new feature test macro that lets users 22:27:15 choose to opt into a "portable source" world i.e. define a 22:27:15 preprocessor symbol _I32LPx to see a world where integers are 22:27:15 always 32-bit, and longs and pointers are simply the same 22:27:15 size. 22:27:15 This symbol would be used for constructing the ON 22:27:17 consolidation, since we do not wish to fill it full of useless 22:27:19 #ifdef's. 22:27:55 and yet, here we are haha 22:29:20 apparently XPG3 still defined interfaces like write() as "int" instead of "size_t" 22:29:48 That's unfortunate 22:37:13 https://pastebin.com/7WukCeB2 is the body of the opinion from that case - see section 4.2 for I32LPx 22:40:08 thanks!! 22:43:14 so it seems like the non-_ILP32x case was for compatibility, with _ILP32x being the way they wanted new software to be written 22:43:37 err, I32LPx 22:44:14 its friday afternoon, brains may not be at full operating capacity