I would expect our e1000g driver is not written in a way to minimize exits, fwiw.

sommerfeld: I updated the gist with them, in case you wanted them

rmustacc: oh that's true

nomad: dladm would tell you negotiated speed but it'd be a total lie here. ;)

There is no way for e1000g to tell you that you have any link speed over 1 GbE.

both report 1000 as the negotiated speed.

I mean, it's a total fiction so I wouldn't put much stock in it.

the underlying hw has a 50G connection, as I understand it.

Sure, there's lots that might be going on there. But I would only expect vmxnet3s to get you anywhere here.

but XCP-ng doesn't have xmxnet3s :)

the reason I asked him to test was more datapoints.

We do lots of register reads in the driver that will cause exits if it's being paravirt.

Things like even just normal kstat updates will cause sadness.

So I'd probably try to figure out if that's what's going on or something else. It is surprising that it is that different, but I dunno. Maybe we're not accounting for something that they're emulating in a different way.

I'd probably look at instrumenting the qemu underlying it a bit and see what it thinks is going on.

I'll be adding a report tomorrow or Wednesday.

Normal e1000g does work fine on real hw, so dunno what it'll be.

There definitely have been cases where depending on which e1000g it emulates there are challenges.

For example, VMware in the past didn't honor the numer of rar entries.

I'm still not sure if the problem I'm seeing in XCP-ng is OmniOS or XCP-ng. However given FBSD is also doing unexpected (to me) things I'm inclined to think it's mostly XCP-ng.

Doesn't mean there can 't be multiple problems.

Probably are.

richlowe: huh, it's missing "sida" from the idmap output.

did idmapd restart and lose its state mid-test?

sommerfeld: it doesn't seem to have, no, but its behaviour isn't make sense either. I'll chalk it up to something being broken on arm, and try to get back to what

could we get this poor src.illumos.org fixed? it is really annoying having to fix the urls from duplicates:(

I really really don't like it that illumos dhcp(SmartOS) is sending packets to one IP gateway and then on another gateway, even I ahve said to it in config what gateway to use. It is illumos DHCP that can't use the first gateway it got form DHCP server and then the second gateway and not using them in round-robin principle all the time (one gateway is faster, other one is slow).

Why publish multiple gateways? If the aim is redundancy, then the normal approach is to have a floating IP and use that as the default gateway

[illumos-gate] 16811 unix: 'repl_pfn' may be used uninitialized -- Toomas Soome <tsoome⊙mc>

tsoome: I don't know what you mean, about src.illumos.org

nikolam: Are you saying that you're specifying a default router through, say, defaultrouter(5), and then DHCP is adding a second one based on what it gets from the DHCP server?

If that's the case, look at dhcpagent(8); the description for PARAM_IGNORE_LIST mentions the case of wanting to ignore the default router from the DHCP server, etc.

that's also the way you ignore them when they give you shitty DNS resolvers

which if they're giving you a shitty route, is likely

Indeed

richlowe I'm getting urls like this: src.illumos.org/source/xref/illumos…?mo=7082?r=22028508&mo=7082?mo=7082 or like this src.illumos.org/source/xref/illumos…a/dosfs.c?r=22028508?r=22028508#235

weird

it is rather old issue already, I'm afraid...

jclulow, yes and now when I specified fixed IP for both interfaces, I again get traceroute going on the first and second gateway, even second gateway is not mentioned anymore in config and it is not supposed to use DHCP anymore..

I got encouragement that internet settings in distribution are just a shell script and it can be patched itself.

I would not use traceroute to debug this, you're much better off with "route -n get DESTINATION"

or -nv

jclulow, with route -nv get DESTINATION , I always get the second gateway, not mentioned in config, but present in DHCP, even not using DHCp as per config at least.

So you've disabled the DHCP configuration?

If you look in "netstat -rcnv" the gateway must still be in there

When I enabled static IPs without DHCP , I don't have assigned IP in ipadm for external interface. and still alternatign between gateways. And yes, in ' netstat -rcnv ' there are 2 defaults for 0.0.0.0 , this time both through admin interface , so it is alternating between them.

I observed that before, too. With DHCP, on external interface , on can not set fixed IP for global zone , if it is set to fixed IP, it does not get assigned. (non-global zones works fine over external interface) . And if it is DHCP, is always get another MAC on startup for global zone, so different IP on every boot on external .

But that is more like what distribution itself wants to achieve.

[illumos-gate] 16527 cxgbe: want support for CPL_TX_PKT_XT -- Patrick Mooney <pmooney⊙pc>

[illumos-gate] 15542 wcswidth(3c): example formatting error -- Robert Mustacchi <rm⊙fo>

[illumos-gate] 16609 taskq(9f): unrelated parameter tp -- Robert Mustacchi <rm⊙fo>

[illumos-gate] 16783 dladm(8) has incorrect fields for "show-iptun" -- Robert Mustacchi <rm⊙fo>

[illumos-gate] 16186 ndd is obsolete for TCP/IP too -- Robert Mustacchi <rm⊙fo>

[illumos-gate] 16741 ddi_intr_add_handler(9F) should probably document ddi_intr_handler_t -- Robert Mustacchi <rm⊙fo>

[illumos-gate] 16152 ddi_add_event_handler(9F) has wrong argument type -- Robert Mustacchi <rm⊙fo>

[illumos-gate] 15323 cond_init(3C) is confused about NULL being a pointer -- Robert Mustacchi <rm⊙fo>

[illumos-gate] 15226 scf_tmpl_pg_name(3SCF) missing const on some functions -- Robert Mustacchi <rm⊙fo>

[illumos-gate] 14856 cmn_err(9F) missing vdev_err() -- Robert Mustacchi <rm⊙fo>