sommerfeld: That's an igc bug.

It shouldn't allow that to happen.

Let me know if you want to propose a fix or if I should.

jbk: I would expect a map to be required.

As there's no general mapping of slots to bays and other physical locations on the chassis.

Given the LEDs are driven by a non-PCIe standard mechanism you'll probably want to explicitly enumerate a different indicator in the map as well.

the pcie slot itself though seems to have a label in fmtopo.. .that's what confused me

I dunno. I assume you'd have a custom map regardless.

But it's been a while since I dealt with a non-Oxide system there.

Sepcifically you'd want bays in the chassis map that reflect how it's actually connected.

the PCI labels appear to do that -- it looks like it's more that diskinfo wants a parent named 'bay' or 'slot' to use the label

it's only a sample size of 2 (this Dell box as well as my supermicro server), but adding `|| strcmp(pname, NVME) == 0` to the first group of that expression yields the correct results

rmustacc: from a quick look at how drivers do it, there are both checks of *_link_state != LINK_STATE_UP and driver/device-specific state checks. I'd have to spend a bunch of time reading the driver to figure out the latter part. So if you don't mind fixing it I'll be in a good position to test it. Fix isn't urgent for me as workaround is straightforward (don't leave dhcp configured on a down interface).

sommerfeld: OK. I don't know that I still have it cabled up in the lab, so it may be a little tricky for me to test right now. But I'll see what I can do.

[illumos-gate] 17449 xhci includes spurious newlines in some log messages -- Joshua M. Clulow <josh⊙so>

rmustacc: I can take a stab at it if someone can throw me a clue about what other state to check in the driver to indicate that TX was stalled..

I filed illumos.org/issues/17487 somewhat optimistically, because I didn't 100% spend the time to work out if it was fully possible.

→ FEATURE 17487: want globbed breakpoints in mdb (New)