danmcd: thank you

hello all, so there is no 9560-8i driver available for illumos right now? where could find out the driver, or I have to exchange the HBA Card? thanks in advance

tozhu: There is no driver available with support for that generation of LSI cards.

The driver would either be mpt_sas or mr_sas, depending on the firmware.

rmustacc: Thank you very much, so there is no plan to develop the driver in illumos community?

tozhu: I can't speak for others. I imagine there are several companies who make storage products where SAS HBA support is important.

okay, got it, hope the new driver will be available in illumos. thanks again :)

richlowe, news sorry for no caps is actually important bevauce jobs took it for apple

and yes it wsn't bad for the time

i mostly worked on the kernel back then which was already wildly divergent

look, i am sure you are more historically important than i am as if it makes some sort of difference

we are all just a part if time

it flows without us but we all change it in our own ways

For native zones not returning the viona loaned buffer thingies and starving the bhyve VM... would sliding a etherstub between the ixgb0 which currently both vnics and the vnic for the bhyve avoid this? or will it still know it's all locale and thus have no effect?

i hit it again a few times this week

i wish i had been able to recreate that locally so i could peer through all the processing

last i was able to see was that somehow on the 'native' side, we somehow exceed the high water mark (by a lot) without ever notifying the upstack stuff or applying backpressure (i.e. drop)

if you lower the vqsize, the mount and write to a nfs share i can trigger it pretty quickly

but couldn't figure out where things are falling apart

yeah viona -> viona or viona -> other non local host is fine

i just vqsize to the max it takes and its mostly usable unless a lot of writes happen (or a lot of read/write mix)

jbk if a dump would help of a zone in that stuck state, I can probably try and get one this weekend but I think one already got posted in the bug IIRC

I'm not sure... it's been well over a year since I last looked at it.. I suspect though that what we need to find is happening before things get wedged

from what I recall

basically long before viona exhausts all of it's TX resources, the destination netstack should be doing some things it's not doing (which lets it get into that state)

just I wasn't able to figure out where that should happen

since the relevant bits of the kernel are both massive, and rather complicated, and I had little prior experience with either

→ BUG 13463: bhyve locks up when viona ring buffers on loan to a local zone are not returned by sockfs (New)

yeah so what's happening is all those packets from viona get queued up onto a socket in the destination zone

but for whatever reason, things aren't being woken up

yeah a dump probably wont help then as there will just be a queue with all of them in it

i remember there was a review (?) for netstat (?) to show the actual command for ports in LISTEN, was it never integrated?

I have no recollection of that at all

but I wanted it recently and couldn't find a way to do it

this one?

It got integrated, well a slightly different version

that had a few followups..

'netstat -u'

heh yes

jbk I think you fixed the fake inodeinum space for sockfs

yes

that was what made me chuckle (the ancient limitation)

we were trying to audit what ports were listening and that led to a bit of a wild goose chase until we figured out what was going on :)

[illumos-gate] 14981 zfs: Several B-tree optimizations -- Alexander Motin <mav⊙Fo>

[illumos-gate] 14982 zfs: Fix use-after-free in btree code -- Richard Yao <richard.yao⊙ase>

2 down, more to go...

Oh, you reminded me I have a tiny one to push - are you in the middle of a batch?

no:)

just noticed it's 20 minutes since, sorry, not enough sleep

[illumos-gate] 15208 Allow building with python 3.11 -- Andy Fiddaman <illumos⊙fn>

[illumos-gate] 15183 SMB server debug builds are a bit noisy -- Gordon Ross <gwr⊙rc>