13:54:42 [illumos-gate] 18100 Linker should merge gcc_except_table sections -- Joshua Carp 20:11:23 jbk: is there a ticket I can watch for E380 support? I'm not seeing anything in illumos.org/projects/illumos-gate (but I could very easily be missing the obvious). 20:19:07 not sure if there's one filed yet 20:27:32 we tend to be bad about filing stuff early 20:27:43 because there's approximately 0 risk of conflicting work 20:28:14 though on a related note, is anyone keeping up with that realtek driver danmcd didn't like? 20:28:19 (I'm sorry, that's the only memorable detail of it for me) 20:28:40 I'm not sure if someone is fixing it, or not noticing Dan's actual feedback 20:33:55 E380? 20:34:05 Or E830 ? 20:38:54 E830. 20:39:35 Though even with the correction I'm not finding any open tickets. 20:40:53 I'm guessing this means we're probably "more than a few months" from getting a working driver for this card. 20:40:58 * nomad glowers at vendor 20:41:16 i'm working on it, but it's a slog 20:41:48 intel made it so f$#@$@# complicated... for comparison, the freebsd _source_ for it's ice driver is several megabytes in size 20:42:23 y'all thought I was crazy when I complained about this trend 20 years ago :) 20:42:41 (I probably was, to be fair) 20:43:19 it's all of the non-NIC stuff, and the problem is even if you want nothing to do with it, you can't avoid it 20:44:20 jbk: so ice is the device name? At least I got that much right in labeling the host yesterday. 20:44:43 and the quality of intel's documentation has been steadily going downhill as well, so you end up having to reverse engineer the bits that are poorly explained in the documentation 20:45:43 This doesn't sound like fun. 21:08:06 it's certainly a grind.. 21:08:18 but will be nice to have once it's done... 21:08:33 I appreciate your effort. 21:09:26 on a completely difference subject... i'm curious if anyone's given any thought to backpressure mechanisms in the I/O stack... 21:10:35 e.g. if you run non-local storage, zfs will throttle itself (possibly severly) because AFAICT there's no way for a device to really say 'i'm full, wait and try again' 22:13:23 jbk: guess there's the question of what ZFS can do when waiting for a device to not be "full". 22:14:01 and what "full" actually means. I can imagine some queue occupancy controls (no more than X outstanding write requests?) 22:39:13 just pause sending i/o 22:39:19 right now it does that after a few i/os 22:39:30 which often leaves a pretty fair amount of performance on the table 22:39:40 you can bump the r/w tunables globally 22:40:03 but i'm guessing the 'right' values for an HDD vs. SSD vs. array could all be different 22:40:41 and the existing standards seem to have various flavors of 'queue full' errors 22:40:56 (we even have a code for it with sd, but doesn't appear to be generated or really used)