hello all, does illumos supports MegaRAID 9560-8i ?

@tozhu -->I don't think so. Knowing the PCI ID (`prtconf -d` shows it) would help to confirm/deny it.

(`lspci` on Linux works too)

hello all, may I know which one could help to take a look for 9560-8i driver issue? pastebin.com/uUr3qp9g ; I have post this question in smartos and illumos channel, thanks in advance

hrm... technically, the DMA addresses returned in ddi_dma_cookies are only good until ddi_dma_unbind_handle() is called on the DMA handle that was used to bind them (or to state it slightly differently, the DMA addresses from a cookie should be considered invalid after the handle that created them has been unbound)

right?

(I think that's correct, but want to be sure there isn't some detail there I'm missing)

any way to ensure this isn't forgotten about? illumos.org/issues/15024 I think I'm hitting this bug at least once a month

→ BUG 15024: NFS can exhaust pool threads getting RPCSEC_GSS credentials (In Progress) | code.illumos.org/c/illumos-gate/+/2402

I guess, it would be nice to get more reviewers;)

I did drop the note to Matt anyhow.

also.. (since the relevant man pages don't explicitly mention it) should I expect that the maximum size of a single dma cookie is <= dma_attr_count_max (of the ddi_dma_attr_t instance used when allocating the dma handle)

while the sum of the sizes of all the cookies from a bound buf should be <= dma_attr_maxxfer ?

Yes, that's the correct interpretation of dma_attr_count_max.

this driver (vmxnet3) is basically segmenting the returned cookie itself if the size is too big for a single tx descriptor -- is there any benefit from not letting ddi_dma_addr_bind_handle() take care of it instead? (I'd think it'd be preferrable since it in theory at least means it may not need to work as hard for binding larger buffers if it can split it up)

perhaps they don't trust the nexus to?

or there's an invariant in that case the nexus isn't aware of?

(my knee-jerk reaction was "let the system do it for you", but it being a virtualized driver raises questions)

i don't believe so (looking at the fbsd and linux versions) if anything it's generally fairly loose on it's restrictions

there's a max# of descriptors for a single packet, and a max size of a buffer for a single descriptor

but I don't think it even has any alignment restrictions

my suspicion is that the original code might have copy/pasted some values

it would simplify this code..

i guess the only potential hiccup would be a situation where an already segmented mblk_t (i.e. b_cont != NULL) results in using too many descriptors.. but then there's already a provision to do a pullup

it can handle a packet using up to 16 descriptors (non-tso, just a single packet)

so i suspect that should be fairly rare enough that having to do a pullup if that happened wouldn't be a huge concern

#define U_POOP 0x1f4a9 // poop emoji (💩)

:D

one day I will figure out why my emoji stopped being in color again

but I have to tell you, in line-drawn monochrome, that's indistinguishable from the Java coffee cup.

eh..

dumb question: I'm trying to format(8) -> partition some disks that were in a FreeBSD system, how do I get it to accept a new tag for a slice?

usually you just format -> select disk -> p (partition) -> select partition #, and it'll prompt for the new values

I get a prompt "Enter partition id tag[FreeBSD ZFS]:" and no matter what I put in, it gives " `blah' not expected. "

I think, ? did make it list values

^ unaen.org/pb/6o1@raw yes

if you just want to use the whole disk as a part of a zpool, you don't need to worry about that

just zpool create -f .... (just be sure you have the right disks obviously)

They are SSDs, I just want a 4gb slices for slog, but I should probably trim the whole disks first

alanc: maybe you can get DPS out of adobe now too? :)

Is there a way to trim the whole disk in a smartos gz?

(they are probably smart enough to compress zeros and trim the free'd sectors, but I mean a direct trim)

only zpool trim does pop in mind:D

I guess, it would be nice if format could do trim...

i have a small program i wrote that'll trim a whole disk

i used it for testing some of the vioblk trim support (as well as some other stuff)

but that essentially wipes the disk

if you just want to trim the unused stuff, 'zpool trim zones'

I want to wipe the whole disk, and tell the SSD firmware that all the blocks are available, so that if I only use a 4GB slice, it has the whole disk worth of blocks it can remap

make it wear even, and last the longest

richlowe: you mean other than the copy they require us to keep hidden from the world so we could put it in Xsun?

indeed

slightly closer to showing everyone all of NeWS

which I'm sure only the history museum would be interested in

Gosling actually tried to find the NeWS source during the "Jonathan promises to open source any code Sun owns" days, but I never heard of anyone finding a copy still around

the closest I found was Xnews, which was totally not the same thing

Maybe you're just really depressed richlowe, so color has no emotional feels