[illumos-gate] 17221 bhyve emulated e1000g fails with TSO -- Andy Fiddaman <illumos⊙fn>

7G free ram and ramdiskadm can not create 2G disk, really?!

tsoome: How much physical memory and how much swap on the system?

8G + 8G

That's definitely a little suspicious haha

Do you know what check it's failing at?

EAGAIN - we get it on memory allocation failure

I was able to allocate like 1800MB

system is vmware fusion VM

tbh, I did not really dig too much...

I guess it'll stay the way it is then haha

btw illumos.org/issues/7291 or illumos/illumos-gate #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

→ BUG 7291: Attempting to destroy ZFS filesystem and create ZFS volume with the same name caused system panic (In Progress)

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?

well, it also failed right after boot. but that does not really mean the memory is not fragmented....

freebsd with 4GB of ram has no problem to create 2GB ramdisk.

go figure.

sorry to say, but this os needs much love.

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

We're aware, the internet sucks, work is afoot

sommerfeld: No, it doesn't need to be contiguous

tsoome: If you decide to debug it, let us know what check it's failing on for you.

it has exactly one (1) line with return (EAGAIN); its pretty easy to see.

Right, but why is it returning that

richlowe Is there an alternative source of documentation?

Assuming you don't have a local system, you can always clone it and point man/mandoc tools at the pages directly.

I've been referencing the SmartOS man pages but I'm not sure if there are discrepancies between those pages and the illumos pages

I'll keep that in mind

Guest7 you can use man.omnios.org, there is small difference, but nothing too drastic.

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.

tsoome: aren't ramdisks limited to 25% of free memory? which 2G of 7G will exceed.

ptribble yay;)

ramdisk(4D) says "percentage of available physical memory" which isn't exactly clear whethere it's available or physical

or both

though why you'd do that I don't know

Why would a build throw an 'implicit declaration of function' error for 'strdup', which is located in <string.h>, when this header is indeed present in the source file? Not blocked out by any ifdefs

Guest7 replace -c by -E and see what is going on.

Guest7 you should see traces of string.h, also function declarations in it, including one for strdup().

Guest7: Isn't strdup(3C) in strings.h not string.h

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

it's pretty common for people to misunderstand the standards defines and think they're helping themselves

string.h:extern char *strdup(const char *);

and some of those people write Makefiles or CMakefiles or meson.build files in to propogate those mistakes to others

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

ptribble: d'oh.

tsoome: see the standards/namespace guards surrounding literally that line

tsoome Thanks! I'll try looking here next

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

Guest7: What does the command line for "gcc" end up being

a number getting the same error sounds like standards namespace defines

oh, jclulow is ahead of me

Hmm forgive my inexperience, are you asking for the output specs for gcc?

No, the full gcc command line that is being used that creates the failure.

So it would include things like -std=... -D... -o foo.o -c foo.c, etc.

 

rmustacc Thanks, I'll find it and share it

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`

adfasd

This program is using CMake

ls

Oops

Still looking around for those flags, if nothing else, here's the repository github.com/hpc-gridware/clusterscheduler

It's passing -std=c99

ptribble: was there anything still holding you back about fixing int8_t?

"just" possible mangling ABI damage?

ptribble: and if there's anything I could do to help get whatever manual page fixes you have outstanding upstream, what is it? :)

Fixing char requires a number of changes to the gate itself

I think you've already fixed them in the arm gate, but those would need to be fixed first

I'll have fixed them, but I'm not sure in an easy to cherry-pick way :\

and I won't have fixed anything I've unilaterally declared too crap to port

which I sure look forward to writing an IPD about :\

ptribble: but if your porting old software into the future hobby needs a further outlet... :)

I wonder how much overlap there is between your "too crap to port" and my "too crap to ship in Tribblix"

alanc: do you know what the hell is going on with `_I32LPx`? and it's use anywhere at all?

it appears our headers decide "don't care about LP except they're the same" actually means "x == 64"

jlevon: you used this on purpose in dboot

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

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

yeah, I think the larger use of I32LPx as "pointers are 64-bit, right?" is wrong

right

but then _I32LPx surely only means "not a computer that doesn't exist"

if you have to define the concrete reality too

and also that all the uses we have for it in the code are sketchy as hell

Yeah, I think it's probably a silly definition

I mean, I32LPx would be true for amd64

Right, I32LPx is true for everything we currently support haha

I32LPx would be true for every computer that's not like, a Cray or NEC monstrosity

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

it looks like things checking for _only_ I32LPx is rare (if nonexistent)

so the things checking for LP64 will continue to be correct

We should probably look at cleaning up the silly haha

we should

This is indeed quite confusing

(and, in this case, causing UINTPTR_MAX to be wrong)

yup

I'll get something filed for this

I'll file a bug

ok

you do it then

:D

fine, I will

richlowe: thanks for poking at this

Yes, thank you

_I32LPx apparently came from PSARC/1996/370

PSARC/1996/370 Derived Types for 64-bit Solaris Tim Marsland closed approved 9/17/97 Unpublished

rip

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

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

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

same problem I asked ptribble about earlier

plate, shrimp

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."

filed 17234 for this

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

otherwise I'm inclined to rip it all the way out

good riddance;)

from what I have seen, I don't think it would help even if that happened.

speaking of, there is still code.illumos.org/c/illumos-gate/+/3288

→ CODE REVIEW 3288: 17139 sparc: remove (NEW) | illumos.org/issues/17139

I wish I understood how it got into usbwcm, ilb, rds,

and presumably dboot was explicitly _trying_ to get 64bit definitions without being 64bit itself?

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.

and of course, part of the mess is because it had to take care of both 32-bit and 64-bit kernels.

uts/intel/sys/bootinfo.h has explicit sizing and definitions of its own to make that happen though

_I32LPx doesn't get used in there

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

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

We would also support a new feature test macro that lets users

choose to opt into a "portable source" world i.e. define a

preprocessor symbol _I32LPx to see a world where integers are

always 32-bit, and longs and pointers are simply the same

size.

This symbol would be used for constructing the ON

consolidation, since we do not wish to fill it full of useless

#ifdef's.

and yet, here we are haha

apparently XPG3 still defined interfaces like write() as "int" instead of "size_t"

That's unfortunate

pastebin.com/7WukCeB2 is the body of the opinion from that case - see section 4.2 for I32LPx

thanks!!

so it seems like the non-_ILP32x case was for compatibility, with _ILP32x being the way they wanted new software to be written

err, I32LPx

its friday afternoon, brains may not be at full operating capacity