oh how i wish the kernel's bzero() actually set up a stack frame

it's a leaf right? what do you need the frame for?

(I'm confused about this one, basically)

gwr: do you still need reviews from me for my bugs? it's _so hot_ here rn my brain doesn't work

well more the lack of a frame pointer

so the calling function doesn't show up in the stack

while you can usually infer it from the offset (the instruction offset will be after the function that was called)

but then you have to crawl the stack to find the arguments passed to that invisible function

which is tedious

and for various reasons, I'm rather brain fried and exhausted today, so it's not a mental exercise I really want to attempt today

are those reasons that it's a million fucking degrees there too?

because I sympethesize from the surface of the sun

oh that's pretty much summer here..

no, I was up rather late fighting ESX's horrid NFS4 support

and then was woken up early this morning because people decided to set off fireworks (and down here you can get the 'big' fireworks)

a few days early

so I'm working off like 4-5 hours of sleep, so the focus needed isn't there today :)

Mayhap it is naptime.

We have New Hampshire only a couple miles from here, which some call "The South of the North". The let you have fireworks too.

Fireworks are illegal in Seattle. That didn't stop $idiotneighbor from setting off several loud explosions between 23:00 and midnightish last night.

I suppose it's at least refreshing they don't bother with the pretense... where I grew up, they could sell all sorts of stuff that was illegal to set off in the state, but they were fine with selling it as long as you signed a waiver you were taking them out of state *wink*wink*

(despite they not being legal in any state within a 4-5 hour drive)

We have plenty of tribes with different laws about fireworks so it's trivial to get them in .wa.us.

illinois troopers would often camp out on the state line this time of year just to bust people taking the fireworks into the state

[illumos-gate] 5048 panic on re-adding an interface to an aggr after removing it -- Dan McDonald <danmcd⊙ei>

i mean it was fun since some family friends had moved out of town to the country and would have a big party for the 4th of july, and one of the people would usually drop a few hundred bucks on the big fireworks to set off...

and never got busted

and would do it on the 4th and not too late

jbk there is a proposal somewhere to teach `mdb` about some of these functions, rather than incur the cost of the frame setup.

illumos 17585 (fenix)

FEATURE 17585: MDB should look past mutex_enter() and find the real stack frame (New)

↳ illumos.org/issues/17585

oh that would be sooooo nice

there was that code that someone at joyent wrote (but not sure anyone remembers who :P) that'll walk the dwarf/amd64 exception data... I had been trying to carefully fold it into libproc (as an alternative -- not to replace -- walking the frame pointers.. mostly for the lx stuff)

but never got around to finishing it (the code was just a proof of concept program to decode the data)

though I don't recall offhand if we strip that off of kernel modules or not

rmustacc has had a variety of dwarven prototypes

we strip all dwarf unless you do a build with source debugging

(I feel like a LOTR refrence would be appropriate now, but can't think of one :P)

when you do such a build, kernel stuff has dwarf too and it is 80% usable

(20% unusable because gdb insists on being told where in memory stuff got placed, and we don't have a strictly great answer for bss)

have any of you used `git cherry` (that creates a list of things you might `cherry-pick`) and been convinced that the patch-id equivalence etc, etc, actually worked?

my list of "cherries" includes everything I have just already picked

suspicious, no?

jbk: I'm having a strange issue with i40e and toolong_error kstat, anyway to dtrace to see what size we are rx'ing that bumps the counter?

(a kstat dtrace provider would be cool...)

is that the actual kstat name?

(it might be the aforementioned lack of sleep, but i'm not seeing a kstat with a name like that in the i40e driver)

oooh

Those are coming from the hardware.

I was just typing that

you wont' see it, because well, the NIC rejected it

hardware and then softmac for the stat to become a stat

I guess?

errrrr, so I'll need to get it from switchport I guess?

This register counts the number of received frames that are longer than maximum size as defined by the Set MAC config command

Smithx10: just tell people to shorten their packets. brevity is the soul of wit, or something

Receive Oversize Count - GLPRT_ROC in the datasheet.

'you using those sized packets? in this economy?'

jbk hahaha yes

Very strange.... When we tx 9k and rx 9k from another CN that are in the same vlan and never go over the gateway we are good

when the gateway is in the flow we get the err toolong and its getting dumped

oddly chelsio is working without issues

Oh, this is tickling an old memory of mine when I was working on a maxbw fix. I believe this could do with our setting of m_margin. Basically all our drivers set it to VLAN_TAGSZ, but I believe that's wrong. The only driver that doesn't set it to VLAN_TAGSZ...cxgbe. It sets it to 22. I would have to look more closely to give coherent story here, but basically this could be related to m_max_sdu/m_margin/etc.

Though I wonder if that chelsio is running an older PI, because I noticed Patrick changed cxgbe to set m_margin to VLAN_TAGSZ while he was doing his cleanup

There's some discussion in dlpi(7P) about the margin value.

Basically I ran into this while doing the maxbw work and it seemed like a huge quagmire and then I got pulled into seomthing else

best way out of a quagmire tbf

rip artax

richlowe: I'm really good at Irish goodbyes

both on SunOS 7fa0a8b5-da12-477b-a1f9-870151b56edb 5.11 joyent_20260522T154557Z i86pc i386 i86pc illumos

Patrick's change: 77983a892403763fb778c095cdc6d7c5388508c9

great thing about the network is that it will resent the packets

unless it's UDP, then whatever I guess

"left package at front door" delivery

Something very strange is the following: gist.github.com/Smithx10/56b702605e2c7517e8d63c299f2112c3

with 9k zones on src and destination anything over 1519 bytes is bumping the toolong_errors

1518 looks like VLAN-tagged ethernet....

Your net0 has 9000, doe the underlying NICs in the aggr have that? There isn't a network hop between them... Same questions on the receiving side.

This stinks of some part of the many layers having kneecapped MTU at 1500.

Check the vnic you're dealing with (both sides), check any other layers of vnic between it and either an aggr or HW link.

If an aggr is involved, check the MTU on each link in the aggr... just to be sure.

@danmcd IP: Total length = 1501 bytes doesn't work IP: Total length = 1500 does. If I use a network on the same network where we don't traverse a gateway we work always

And finally, does your switch do stupid things?

Oh... if you're traversing a router then it isn't doing PathMTU discovery, or ICMP TOO BIG packets are getting dropped.

Not sure tho what is making our toolong_error climb? toolong_errors 9899

that's on the target?

Source

Then check all the way down, INCLUDING if your'e routing on-host... we should catch that. If ICMP TOO BIG messages aren't making it up?!

(Dammit, why do you show up this close to dinner?)

hahah go to dinner

I'll make the gist cleaner*

a little cleaner gist.github.com/Smithx10/56b702605e2c7517e8d63c299f2112c3

Not 100% I get how 'ping -D -s 10.82.131.32 1473' is resulting in toolong_errors ... would anything of the networking infrastructure forward that to source cn?

Yikes, missing the edit button from discord on that one. bah haahah

so any ATAPI experts around? :)

apparently if the device triggers an error during attach, we end up here in a taskq: github.com/illumos/illumos-gate/blo…n/io/sata/impl/sata.c#L10690-L10699

trying to get the error

except since we're in attach, satacmd_acdb_len is not yet set

so the bzero() length underflows (and saddness quickly follows)

the immediate fix is just bzero() the whole fixed sized buffer first

before the bcopy and don't bother with any math

but the 0 satacmd_acdb_len is still bothering me... it should be 12 or 16 (depending on what IDENTIFY PACKET DEVICE returns)

but since we need to just retry until we get a response

i'm wondering about just using 12 if we don't know

(I figure worst case it's going to ignore it if it really wants 16, but even that isn't clear)