03:35:25 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 03:37:46 jbk: I would not be surprised 03:38:17 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 03:39:01 A driver absolutely must drop its own locks before calling into mac_rx() 03:40:40 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').. 03:40:58 they don't use tx completion interrupts based on a comment that the MMIO writes are expensive in an ISR 03:41:10 (for reasons such as that).. so trying to understand if that might be relevant 03:41:37 (or if perhaps it might be better to maybe kick off a softint on TX completion instead of reaping in the ISR) 03:42:06 (the big thing is adding ring support) 03:42:54 though I suppose first, get this working, so jsut putting a note to take a look at that in the future 13:10:36 [illumos-gate] 15052 libc: unused label -- Toomas Soome 20:15:25 [illumos-gate] 15057 i86pc: redefinition of typedef 'vmm_data_req_t' is a C11 feature -- Toomas Soome 20:16:50 alanc: and we thought we should maybe use ISC because everyone else did 20:16:53 who's laughing now! 20:16:54 (it's not me) 20:20:32 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. 20:21:43 yeah 20:22:16 why? 20:24:43 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. 20:25:15 I don't think it was very portable out of the box.. 20:27:08 btw, https://code.illumos.org/c/illumos-gate/+/2374 still needs review... 20:27:11 → CODE REVIEW 2374: 14993 zfs-tests: Move platform independent tests to a shared runfile (NEW) | https://www.illumos.org/issues/14993 20:34:42 looking - I'll add a comment or two 20:34:51 (assuming I'm reading the python properly) 20:41:25 it was once the reference implementation after all 20:41:59 but then everyone else used Xorg/XFree86 when we switched to it, and now they're all moving to Wayland instead 21:01:00 tsoome_: can you help Dan in 15039 (fenix?) review, avoid the boot time modules so he can test fastreboot? 21:01:33 fenix: #15039 21:01:35 BUG 15039: kernel initializes early GDT (New) 21:01:35 ↳ https://www.illumos.org/issues/15039 | https://code.illumos.org/c/illumos-gate/+/2414 21:01:53 boot time modules are the checksum, right? 21:02:01 not only 21:02:45 but... I think, the fastest way to get into fast reboot is to use multiboot1 21:02:56 because fastreboot was implemented with it. 21:05:09 does fast reboot even work anymore? 21:05:32 no idea 21:06:17 for MB1, it likely would. 21:06:42 without test, its just an guess anyhow:) 21:11:13 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 21:11:29 ofc, will only do for BIOS boot. 21:17:45 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 21:17:57 so they'd need help in the review, or something. 21:23:04 Ah, that last comment there "If you tested fast reboot and it works..." ... 21:23:21 it is a trap, of course:D 21:24:30 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. 21:27:28 well definitely, but neither helps them now. 21:30:00 anyway, as emacs is also nice hex editor, it would be easy to zero out MB2 magic from unix binary and have nice experiment;)