Do you think it would be possible to replicate the wifibox on illumos? github.com/pgj/freebsd-wifibox

cyber-tec.org/2019/05/29/using-bhyve-pci-passthrough-on-omnios does something like that but using freebsd as a guest instead of linux

hoho, lemme check

This is exactly what i wanted, but nowadays I would go with OpenBSD in the vm as it have better wifi hw support nowadays if I recall it correctly.

a device with devi_node_state of 'DS_READY' means it's successfully gone through it's attach method, correct? (I'm pretty sure, but since so much of the devtree is undocumented, not sure if there's maybe some crazy corner case)

related to that, this is perhaps a bit odd, but is there a way to limit the # of instances of a device that will attach?

szilard Even though this is two years old, it still is a good comparison: github.com/domienschepers/wifi-bsd/blob/main/HARDWARE.md

i need to get some screens for my windows... temps are finally nice outside where I'd want to open them

err

wrong channel

sorry :P

8.7C here:P

21.6C here this morning

it was still getting up to 32C earlier this week

huh:)

i'm around the same latitude as cairo

ah, that explains ofc

florida and other parts of texas are even further south :)

I'm happy with snow:D

i had my fill of snow growing up :) and I get reminded whenever I visit family during the holidays

a light dusting every few years that melts by the end of the day and I'm good :)

very unlikely to be the issue i'm chasing down, but... github.com/illumos/illumos-gate/blo…/uts/i86pc/io/psm/psm_common.c#L822 feels like it should be *irqlistp == NULL

jbk: agreed about psm_common.c.

i don't think it's causing the issue I'm tracking down, but I'll give it a shot

I'm guessing most anything these days is going to have valid APCI info or if not, is so broken already that I doubt the system would be able to make any sort of meaningful progress otherwise...

though some of these comments are at best confusing if not out of date, which obviously isn't helpful...

e.g. github.com/illumos/illumos-gate/blo…/pcplusmp/apic_common.c#L1690-L1705

i'm pretty sure I found that we do in fact enable x2apic mode and use the msrs when we can

i only have access to this box for a week unfortunately, so I don't know how far i'll be able to get to figure out what's going on...

i do see '_CST unsupported package count of 1 for CPU nn' (repeat 128x) during boot on this system -- but IIRC, that's cstates (and I've tried disabling all of that)... I'm think that's just an artifact of the vintage of our current ACPI implementation...

just to clarify.. if you break into kmdb, it only halts the one CPU it's running on, and other CPUs will continue to run, correct?

I thought the rest quiesced. Been a while since I've had to think about that.

if it is, is there a way to let the other CPUs run? the difficulty I'm running into is since NMI only works once, I can't gather some data, resume, break into kmdb again and compare to see if anything of interest has changed

i have to reboot...

side note: was anyone working on supporting the bcm57416 nic?

jbk: if you break into kmdb, everyone stops

the cpu entering cross calls the others to quiesce

but if you're already worried about interrupts, the IPI there is probably worth looking at, I guess

if I don't load the mlxcx driver, I can actually get into userland

though I don't think it's a mlxcx driver problem

i think it's just a victim that's otherwise halting progress when the last instance tries to attach

i do feel like i'm muddling about in the dark... just because i've not messed around in here before...

the fact the ilo devices work (including interrupts) is potentially interesting...

so it's not everything on the system..