is there any reason we are limiting MSI vectors to just 2? src.illumos.org/source/xref/illumos…/sys/ddi_intr_impl.h?r=b4a2f1d2#146

there's nothing in ddi_intr_alloc() discussing this, and it actually says you can have count of 32

in ddi_intr_alloc() man page, that is

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.

See for example, ixgbe_intr_adjust, ixgbe_cbfunc, and ixgbe_intr_cb_register.

these seems to handle msix

Oh, you meant MSI specifically and not MSI-X?

i looked through ddi_intr_alloc() and it seems to deny resizing irm for MSI

yes, specifically MSI

have a device that uses 32 msi vectors (17 actually, but given the p2 requirement - 32)

Probably because most things that needed more interrupts all supported MSI-X due to the improved masking and related features.

What's the device?

broadcom ntb

and it doesn't support msix for this purpose

I would guess most bridges don't.

i have modified the define to 32, allocation is successful, now checking if it would break anything else

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.

But probably things you don't care about in your context, I'm guessing.

new tar?

no, our own good old tar:)

it looks like the thing with crashing from win11 smb traffic is gone

oh, it's still pax?

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

?

i got a screen full of complaints, i don't remember them but the tar still extracted and the code inside still compiled

Hm, I've been using our tar for decades and never bothered with a leading -

tar does not need -

weird, maybe there was something odd about the tar file the other day

i don't have that one anymore

i just tried with and withoit - and identical output

There are plenty of malformed tarfiles out there, sadly

it gave ominous complaints and still worked :)

I don't like ominous complaints when stuff actually worked :)

the only annoying thing (for me) is handling the long file names

sorry, it was a step for something else and it did actually work so i didn't keep the evidence...

[illumos-gate] 16953 sfe: possible memory leak -- Toomas Soome <tsoome⊙mc>

[illumos-gate] 16954 ib: possible memory leak of 'comm_svcp' -- Toomas Soome <tsoome⊙mc>

[illumos-gate] 16957 dprov: possible memory leak of 'object' -- Toomas Soome <tsoome⊙mc>

[illumos-gate] 16958 usbgem: possible memory leak of 'dp' -- Toomas Soome <tsoome⊙mc>

tsoome: Long file names as in, if you don't specify the "E" function modifier?

It seems conceivable that we could look at making E the default behaviour under at least some conditions

I meant, the gnu extension -- when you have tar created by gtar and end up having those @... files around

Oh

Yeah, GNU tar is not the best

I feel like I can say that now without summoning anybody

.oO but it has all of those options!

I will say that I very occasionally appreciate the option to fake up uid/gid in the archive

I have actually read all of those option descriptions, but remember almost nothing. :D

And maybe I guess strip-component or whatever it is

I think if we added something for strip-component, and for uid/gid faking, I might never need gtar again haha

I remember having problems with our E extension, although the details are a bit fuzzy

ptribble: If you can figure out even fuzzy details about it, a bug would be good. I think we should fix it etc

as I happen to be one who is keeping eye on gtar message translations;)

It switches a few behaviours beyond the simple allowing of large things

Yes, I believe it creates ustar archives instead of classical tar archives

Which may well imply other things

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

I believe in order to make the long filename stuff work we have to be willing and able to split the string

which may require looking more closely at it with iconv

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

But also it might just be a mistake

I have begun some spring cleaning in there; e.g., using unifdef to remove the cruft

Obviously going to need some more mechanical tests though

In my case it was the 8GB filesize limit that I was trying to get around

I feel like you can split an array of bytes that's actually an arbitrarily encoded string wherever you like

as long as you don't try to interpret the two halves

[illumos-gate] 17007 ZTS: zfs_mount_all_fail leaves /var/tmp/testrootPIDNUM directory around -- Toomas Soome <tsoome⊙mc>

[illumos-gate] 16999 ZTS: history_007_pos mkdir should use -p -- Toomas Soome <tsoome⊙mc>

. o O ( uuencode | split )

[illumos-gate] 17009 ZTS: enospc_002_pos can fail because of enospc_001_pos -- Toomas Soome <tsoome⊙mc>

[illumos-gate] 16959 audioixp: possible memory leak of 'port' -- Toomas Soome <tsoome⊙mc>

[illumos-gate] 16972 asy detach races with interrupt -- Andy Fiddaman <illumos⊙fn>

[illumos-gate] 16971 More debug output could use common hexdump routine -- Andy Fiddaman <illumos⊙fn>

How does illumos compare to linux when it comes to high performance remote storage. ROCE/nvme etc