who has recently worked in the smartos ipxe? github.com/TritonDataCenter/ipxe currently I'm trying to boot using netboot but I'm stuck at github.com/TritonDataCenter/ipxe/bl…rc/arch/x86/image/multiboot2.c#L813 but I don't have a clue on how to continue

When you say you're stuck can you clarify what you mean?

rmustacc yes, I mean that the last thing I see on the debug build is that "MULTIBOOT2 exit_boot_services" is printed then the call to get_efi_mmap never returns and then after a while the process exists to the efi shell again

So, exiting boot services is a way of telling firmware it's done and the primary ownership of the system is the OS.

rmustacc oh, yes, but it never actually exits boot services it seems stuck, let me get the last debug messages I have

So is it stuck getting the memory map or in the call to exit boot services?

rmustacc ctrl.vi/i/u1epRh9Ip, yes I added debug messages once is stuck in the memory map call

rmustacc I'm sorry, yes I see that is stuck in the GetMemoryMap call, according to debug messages I added sometime ago when boot_services calls get_efi_mmap

neirac GetMemoryMap should either return memory map or tell the buffer is not large enough and returns the expected buffer size. Now the issue might be the expected size is not exact as memoty map can grow during the GetMemoryMap call itself... so, we should round the buffer size up. So, if the system is stuck in GetMemoryMap, it hints that we did call it with some buffer space, and the GetMemoryMap may be running

ast buffer end and thus corrupting whatever memory there is and somehow this will eventually trigger exit from ipxe and we end up in UEFI shell.

neirac to work around this issue, we call GetMemoryMap initially with NULL buffer to get suggested buffer size, and we allocate buffer with some number of pages larger than hinted.

OK so ran out of space again, but my zvol is 100G but illumos only sees 10G -_- thats unfortunately

Well, 3rd time is the charm, I hope

So this is the only fine I need to copy to the new be right, assuming everything is build from the same commit as what I'm currently running? ./proto/root_i386-nd/usr/kernel/drv/amd64/viona

tsoome thanks I'll try to check that but I could not find the GetMemoryMap implementation in the ipxe code

Here goes nothing, lets reboot

Ok, I'm booted into the BE and nothing exploded yet

Now to figure out how the properly format the tunable name

OK with a vq of 128 I hit the issue almost imediatly after booting the VM

Good good

OMG It works, well at least viona_tx_copy_needed now returns 1 instead of 0 after setting the tunable and rebooting

And somehow i am not left holding multiple pieces

OK, the change is super super tiny

But still

Also TIL fbt probes only show up in dtrace -l after the first viona instances is created

Now the big test, does pushing large amounts of data over it with forced copying prevent it from locking up or not

I may have squeeze the vqsize down to 8 *whistles*

Looks to be holding up, there is a performance impact, which is to be expected I guess

NFS now tops out around 437 MB/s

Which is still very very good IMHO, before I was seeing closer to 7xx MB/s range

At first glance nfsstat also has less random super high latancy spikes, which is unexpected but interesting

jclulow: do I file a sub-ticket for adding the force copy tunable to viona ? Seems mine tiny patch works, or do I use 13463 ?

I think adding notes on what I did and how I tested to 13463 would just clutter that one up, given this doesn't fix the actual problem and is just a bandaid.

any suggestions for debugging my other network problem? :)

also, is there a way to change the queue size via vmadm now?

or how to play with it?

Not sure you can via vmadm

Has anyone had much luck running the zfs testsuite recently?

I'm getting lots of errors that look like it's assuming bash (local: not found) and path problems - digest: not found / uuidgen: not found

I only got 91% success, which is a lot lower than I'm used to

there seems like there's a couple of new failures..

for the zfs stats i ran the test suite against an unmodified illumos-gate (since it had been a while), then a build w/ the change applied..

and most of the failures were ones that have been on my list (I've filed tickets for all of those)

but it did seem like there was 1-2 new ones (even after re-running)

@andyf --> I now run them under the umbrella of `smartos-test` every release week.

Last run: Out of 1292 lines stating PASS/FAIL/SKIP, I get 1070 PASS, 75 FAIL, and 147 SKIP. *which* ZFS test(s) fails does vary from release to release, suggestiong transient failures.

The %-ages do seem high, however. I've NOT taken deep-dives yet into why.

apparently you're supposed to be able to set ZFS_ABORT to force zpool commands to create a core when they exit, but I think that either is broken or the test isn't properly detecting things -- that seems to be at least a few of the failures

others seem like some test don't always properly clean up, and some later test (not always the immediate one afterwards) then fails because of that (but is fine when run on their own)

unfortunately, such things are not a priority at $JOB, so it's hard to find time to dig into them

jbk - I also had hanging tests, so it's likely I'm doing something daft, although I've run these frequently in the past

I think it's the first time I've used two NVMe and one vioblk disks for the test temporary ones though

I shall try going back to vioblk for all!

[illumos-gate] 15194 libdladm: tautological-pointer-compare -- Toomas Soome <tsoome⊙mc>

tsoome is it bad when ipxe is loading the boot_archive saying that the image has no multiboot2 header?

neirac: You're using the Triton iPXE booter?

danmcd I'm using netboot.smartos.org/smartos.ipxe

That's a config file.

dancmd I mean I compiled the one that's on the triton repo to load it

Which ipxe *binary* are you using... ahh, you typed the answer I wanted.

So you compiled it yourself.

(which shouldn't be a problem FTR).

danmcd that's right I added debug to see where it's stuck, but my last test exit_bootservices returned EFI_SUCCESS so after that the vm get's back to the efi shell

danmcd on the ipxe shell I'm just typing dhcp then chain netboot.smartos.org/smartos.ipxe. then choose text instead of a tty

danmcd I was wrong get_efi_mmap returne ok, I'll activate more debug on boot_services

sjorge: Not a sub ticket but just a new ticket, and you can add the original bug as a related issue

OK then i did it correctly

So who is off to FOSDEM?

do we have a booth?

neirac boot_archive will not have MB header, kernel does. and MB bootloaders expect kernel first..

so really dumb question.. shouldn't 'chmod 2750 dir' result in '-r-xr-s--' ? it's stripping the setgid bit when i try it so i feel like i've forgotten something i should know

chmod g+s does work however

Odd indeed.

Yeah. 2 in that first octal digit (even or-ed with other bits) seems to be a nop.

`chmod 6750 kebe` gives me:

drwsr-x--- 2 root root 512 Dec 20 21:11 kebe

Ahh.

@jbk ^^^

Now WHY that's there is a mystery to me, and I'm sure would make a good history story.

The behavior IS documented in the chmod(1) man page too.

ok.. so i'm not crazy or forgetting something silly..

You're not crazy. You HAVE piqued my curiousity as to WHY this behavior is there. I don't see it on MacOS, e.g.

My gut says SysV-ism, but :shrug:

yeah.. we have someone that has an app that for whatever reason wants 2750 on an NFS share, and chmod wasn't working

Linux (ubuntu16 in an LX zone) chmod also behaves like MacOS.

There's gotta be some OG SysV thing I'm missing.

oh... there is a note at the very bottom of chmod(1)... that contradicts the stuff earlier about it

well kinda...

it could maybe make the distinction of 'when present' vs 'when you try to set it'

Eeesh, example 5 is broken.

jbk/danmcd: if I recall correctly, this is a holdover from SysV using that bit for mandatory locking

Thank you!

though I may be remembering wrong, since the comment Don Cragun left when closing illumos.org/opensolaris/bugdb/bug.html#!4067561 says:

→ OpenSolaris issue 4067561: chmod 2xxx fails on directories (Closed)

Doing what is being suggested here would not make the system more

user friendly. It would create chaos as regular users accidentally

change the way group IDs are set when subdirectories are created.

The current method of only changing the GID inheritance mode when

done by symbolic mode changes was done as a result of a user interface

design study. It may seem strange to users who are not used to

systems that allow the user to specify whether subdirectories are to be

created with the group ID of the creating process or the group ID of

the containing directory. Switching the behavior to allow absolute

mode changes (as well as symbolic mode changes) to set and clear the

set-GID bit on directories should only be done if using the set-GID

bit on a directory to determine which group-ID assignment to use on

subdirectories is removed from the system at the same time. Since

there has been no suggestion that this capability should be removed

from Solaris systems, I am closing this bug again as Not A Defect.

well, that certainly sounds like don

...but since Linux & BSD allowed it, we ignored Don's advice and changed it anyway in 12.0^H^H^H^H^H11.4

as part of our adding GNU-compatible options to /usr/bin/chown

yeah, I don't follow any individual part of don's reasoning (fitting...), so I would do it too

"it's so confusing we don't let you do it when you use chmod in the greybeard octal way nobody does by accident, only the easy way"

I'll happily code-review or RTI-approve such a fix, richlowe

though I've also just noticed our man page still claims "Absolute changes do not work for the set-group-ID bit of a directory.

You must use g+s or g-s."

That was the text I saw in ours.

I always just thought I was missing something since I "grew up" on Linux

I don't understand that argument

but then I spend half my life on BSD

SysV was always odd. ALWAYS.

and that was even before it become LarryOS :)