03:35:47 <yuripv> is there any reason we are limiting MSI vectors to just 2? https://src.illumos.org/source/xref/illumos-gate/usr/src/uts/common/sys/ddi_intr_impl.h?r=b4a2f1d2#146
03:36:55 <yuripv> there's nothing in ddi_intr_alloc() discussing this, and it actually says you can have count of 32
03:37:18 <yuripv> in ddi_intr_alloc() man page, that is
04:56:36 <rmustacc> There are a few bits. Some of it comes from pcplusmp. The other bit comes from registering the IRM ddi callback which basically gives drivers access to more with the constraint that the system can dynamically claw them back.
04:56:57 <rmustacc> See for example, ixgbe_intr_adjust, ixgbe_cbfunc, and ixgbe_intr_cb_register.
05:06:31 <yuripv> these seems to handle msix
05:07:10 <rmustacc> Oh, you meant MSI specifically and not MSI-X?
05:07:26 <yuripv> i looked through ddi_intr_alloc() and it seems to deny resizing irm for MSI
05:07:37 <yuripv> yes, specifically MSI
05:08:03 <yuripv> have a device that uses 32 msi vectors (17 actually, but given the p2 requirement - 32)
05:08:10 <rmustacc> Probably because most things that needed more interrupts all supported MSI-X due to the improved masking and related features.
05:08:19 <rmustacc> What's the device?
05:08:31 <yuripv> broadcom ntb
05:08:50 <yuripv> and it doesn't support msix for this purpose
05:09:01 <rmustacc> I would guess most bridges don't.
05:09:46 <yuripv> i have modified the define to 32, allocation is successful, now checking if it would break anything else 
05:11:50 <rmustacc> You may throw off allocation balance of other devices, depends on how that maps to the total number of CPUs and what IPLs and related.
05:12:01 <rmustacc> But probably things you don't care about in your context, I'm guessing.
18:39:46 <anathaema> new tar?
18:40:59 <tsoome> no, our own good old tar:)
18:41:13 <dangergrrl> it looks like the thing with crashing from win11 smb traffic is gone
18:41:23 <dangergrrl> oh, it's still pax?
18:43:42 <dangergrrl> i'll keep wishing it was just gnu tar :)  this tar gets antsy with me if i don't provide a - for tar -xvf <filename>, oddly it still seems to work it just produces odd console output
18:44:52 <tsoome> ?
18:45:54 <dangergrrl> i got a screen full of complaints, i don't remember them but the tar still extracted and the code inside still compiled
18:46:48 <ptribble> Hm, I've been using our tar for decades and never bothered with a leading -
18:47:07 <tsoome> tar does not need -
18:47:34 <dangergrrl> weird, maybe there was something odd about the tar file the other day
18:47:42 <dangergrrl> i don't have that one anymore
18:48:07 <dangergrrl> i just tried with and withoit - and identical output
18:48:19 <ptribble> There are plenty of malformed tarfiles out there, sadly
18:48:45 <dangergrrl> it gave ominous complaints and still worked :)
18:49:02 <dangergrrl> I don't like ominous complaints when stuff actually worked :)
18:49:31 <tsoome> the only annoying thing (for me) is handling the long file names
18:49:55 <dangergrrl> sorry, it was a step for something else and it did actually work so i didn't keep the evidence...
18:54:38 <gitomat> [illumos-gate] 16953 sfe: possible memory leak -- Toomas Soome <tsoome⊙mc>
18:57:08 <gitomat> [illumos-gate] 16954 ib: possible memory leak of 'comm_svcp' -- Toomas Soome <tsoome⊙mc>
19:05:06 <gitomat> [illumos-gate] 16957 dprov: possible memory leak of 'object' -- Toomas Soome <tsoome⊙mc>
19:07:17 <gitomat> [illumos-gate] 16958 usbgem: possible memory leak of 'dp' -- Toomas Soome <tsoome⊙mc>
19:09:14 <jclulow> tsoome: Long file names as in, if you don't specify the "E" function modifier?
19:09:40 <jclulow> It seems conceivable that we could look at making E the default behaviour under at least some conditions
19:09:58 <tsoome> I meant, the gnu extension -- when you have tar created by gtar and end up having those @... files around
19:10:04 <jclulow> Oh
19:10:10 <jclulow> Yeah, GNU tar is not the best
19:10:21 <jclulow> I feel like I can say that now without summoning anybody
19:10:25 <tsoome> .oO but it has all of those options!
19:10:44 <jclulow> I will say that I very occasionally appreciate the option to fake up uid/gid in the archive
19:11:05 <tsoome> I have actually read all of those option descriptions, but remember almost nothing. :D
19:11:07 <jclulow> And maybe I guess strip-component or whatever it is
19:11:30 <jclulow> I think if we added something for strip-component, and for uid/gid faking, I might never need gtar again haha
19:11:43 <ptribble> I remember having problems with our E extension, although the details are a bit fuzzy
19:12:11 <jclulow> ptribble: If you can figure out even fuzzy details about it, a bug would be good.  I think we should fix it etc
19:12:18 <tsoome> as I happen to be one who is keeping eye on gtar message translations;)
19:12:43 <ptribble> It switches a few behaviours beyond the simple allowing of large things
19:13:09 <jclulow> Yes, I believe it creates ustar archives instead of classical tar archives
19:13:16 <jclulow> Which may well imply other things
19:13:38 <ptribble> Maybe it was something to do with changing interpretation of locale or charset, which meant it choked on input that would have been acceptable normally
19:14:35 <jclulow> I believe in order to make the long filename stuff work we have to be willing and able to split the string
19:14:42 <jclulow> which may require looking more closely at it with iconv
19:15:01 <jclulow> It might also be that ustar actually specifies the encoding on some level and we have to comply, whereas classic tar was just ... HAHAHA BYTES
19:15:13 <jclulow> But also it might just be a mistake
19:15:30 <jclulow> I have begun some spring cleaning in there; e.g., using unifdef to remove the cruft
19:15:46 <jclulow> Obviously going to need some more mechanical tests though
19:16:18 <ptribble> In my case it was the 8GB filesize limit that I was trying to get around
19:34:43 <richlowe> I feel like you can split an array of bytes that's actually an arbitrarily encoded string wherever you like  
19:34:48 <richlowe> as long as you don't try to interpret the two halves
19:52:52 <gitomat> [illumos-gate] 17007 ZTS: zfs_mount_all_fail leaves /var/tmp/testrootPIDNUM directory around -- Toomas Soome <tsoome⊙mc>
19:54:27 <gitomat> [illumos-gate] 16999 ZTS: history_007_pos mkdir should use -p -- Toomas Soome <tsoome⊙mc>
19:55:16 <nomad> . o O ( uuencode | split )
19:56:57 <gitomat> [illumos-gate] 17009 ZTS: enospc_002_pos can fail because of enospc_001_pos -- Toomas Soome <tsoome⊙mc>
20:10:20 <gitomat> [illumos-gate] 16959 audioixp: possible memory leak of 'port' -- Toomas Soome <tsoome⊙mc>
20:28:22 <gitomat> [illumos-gate] 16972 asy detach races with interrupt -- Andy Fiddaman <illumos⊙fn>
20:28:22 <gitomat> [illumos-gate] 16971 More debug output could use common hexdump routine -- Andy Fiddaman <illumos⊙fn>
21:48:05 <Guest16> How does illumos compare to linux when it comes to high performance remote storage. ROCE/nvme etc