I don't suppose if anyone knows offhand if when a mblk_t is passed up from mac_rx() if we'll ever turn around and immediately try to send for things like TCP ACKs

jbk: I would not be surprised

Depending on a variety of factors, but I think at least some of the time we manage to get straight from driver to TCP and back

A driver absolutely must drop its own locks before calling into mac_rx()

the context is I'm trying to update vmxnet3 driver to support more recent features (based on the FreeBSD source, though I don't it'd count as a 'port' as much as 'ahh this reg does X')..

they don't use tx completion interrupts based on a comment that the MMIO writes are expensive in an ISR

(for reasons such as that).. so trying to understand if that might be relevant

(or if perhaps it might be better to maybe kick off a softint on TX completion instead of reaping in the ISR)

(the big thing is adding ring support)

though I suppose first, get this working, so jsut putting a note to take a look at that in the future

[illumos-gate] 15052 libc: unused label -- Toomas Soome <tsoome⊙mc>

[illumos-gate] 15057 i86pc: redefinition of typedef 'vmm_data_req_t' is a C11 feature -- Toomas Soome <tsoome⊙mc>

alanc: and we thought we should maybe use ISC because everyone else did

who's laughing now!

(it's not me)

richlowe - DHCP? They've been announcing the EOL of that for a couple of years. Kea is a bit of a pain to get going on illumos still unfortunately.

yeah

why?

why hard? I forget exactly. We were looking at switching to Kea in OmniOS a couple of years ago and the list of required patches kept on growing.

I don't think it was very portable out of the box..

btw, code.illumos.org/c/illumos-gate/+/2374 still needs review...

→ CODE REVIEW 2374: 14993 zfs-tests: Move platform independent tests to a shared runfile (NEW) | illumos.org/issues/14993

looking - I'll add a comment or two

(assuming I'm reading the python properly)

it was once the reference implementation after all

but then everyone else used Xorg/XFree86 when we switched to it, and now they're all moving to Wayland instead

tsoome_: can you help Dan in 15039 (fenix?) review, avoid the boot time modules so he can test fastreboot?

fenix: #15039

BUG 15039: kernel initializes early GDT (New)

↳ illumos.org/issues/15039 | code.illumos.org/c/illumos-gate/+/2414

boot time modules are the checksum, right?

not only

but... I think, the fastest way to get into fast reboot is to use multiboot1

because fastreboot was implemented with it.

does fast reboot even work anymore?

no idea

for MB1, it likely would.

without test, its just an guess anyhow:)

for MB1, dboot_grub.s would need a bit of hack - replace MULTIBOOT2_HEADER_MAGIC with 0 or something, and that should trigger loader to fall back to MB1

ofc, will only do for BIOS boot.

I don't think any of the people there are here, they just want to check the kernel setting up its own GDT in all the places

so they'd need help in the review, or something.

Ah, that last comment there "If you tested fast reboot and it works..." ...

it is a trap, of course:D

to be really honest, we should decide if fast reboot is desired or not and either fix it (complete the implementation with MB2), or remove it.

well definitely, but neither helps them now.

anyway, as emacs is also nice hex editor, it would be easy to zero out MB2 magic from unix binary and have nice experiment;)