hello, I am having trouble installing any illumos based OS in virt-manager. i have tried omnios, triblix, openindiana, and smartos. all of them exhibit the same behavior. after getting to the menu where you are given the option for multi user boot / boot options / etc.. i get a kernel panic that flashes on the screen for less than a second before

being sent back to SeaBIOS. i enabled the debugger and did a stack trace and got

```

kmdb_enter+0xb()

debug_enter+0x75()

panicsys+0x651()

vpanic+0x15c()

~panic+0x40()

0xfffffffffb869f03()

trap+0x999()

cmntrap_pushed+0x3c()

bcopy_ck_size+0xea()

0xfffffffffb864faa()

startup+0x5a()

main+0x36()

_locore_start+0x88()

```

couldnt find a bug report or anything that seemed to exactly match (possible i didnt look hard enough). is this a known issue? i have tried messing around with the configuration (different nproc, ram amount, remove / change devices)

it's a guess that it's somewhere in startup_modules

I would really try EFI

if you can

you can also try escaping to the loader prompt typing 'set prom_debug=1' then booting (either type 'boot' or 'menu' to return to the menu system and boot from there -- either way should work)

it will make the console fairly verbose, but might give you a better idea of where things are going wrong

oof lol, yea switching to efi fixed it. thank you

cant believe i didnt try that :facepalm:

it'd be nice to dig in deeper to understand what it's not liking there (though really everything these days should be using UEFI)

it's basically old enough to drink in the US now

:)

hmm not really seeing anything useful it seems to me ??

```

../../i86pc/os/startup.c:2074: startup_vm() done

../../i86pc/os/startup.c:2093: startup_tsc() starting...

../../i86pc/os/timestamp.c:1028: Calibrating the TSC...

../../i86pc/os/timestamp.c:1103: 'tsccpp[i]->tscc_source' is 'Hyper-V'

../../i86pc/os/timestamp.c:1103: 'tsccpp[i]->tscc_source' is 'VMware'

../../i86pc/os/timestamp.c:1103: 'tsccpp[i]->tscc_source' is 'PIT'

../../i86pc/os/startup.c:2096: 'tsc_freq' is 0x10bb479b4

../../i86pc/os/startup.c:1521: startup_modules() starting...

panic[cpu0]/thread=fffffffffbca9420: BAD TRAP: type=e (#pf Page fault) rp=fffffffffbcaf0b0 addr=fffffe0604c07370

#pf Page fault

Bad kernel fault at addr=0xfffffe0604c07370

```

so 4.5GHz?

oh they're gone

do we actually document the format for the names in driver_aliases anywhere?

e.g. for most pci/pciex you have pci<VENID>,<DEVID> but there are other variants to that as well

Probably not as well as we could. But I have a summary in github.com/illumos/ipd/blob/master/ipd/0009/README.md jbk.

→ IPD 9: PCI Alias Disambiguation (published)

ahh thanks..

I think it'd probably be helpful to put something into maybe pci(4D) and pcie(4D).

Thoughts?

that was where I looked at first, so it would make sense to me at least..

rmustacc: when you originally started on the ice, driver, did you by any chance have any thoughts on how to manage the shared resources for cards w/ multiple ports? IIUC, like this card I'm testing has two ports, so 2 PFs, but IIUC, the total # of TX/RX queues (and a few other things) are per card, not per PF

with newer, bigger systems, it seems like it _might_ become something we might need to manage in the near(ish) future

(mostly wondering if we need any placeholders now to avoid problems if/when we do need to deal with that)

(if not, that's fine, just figure I'd ask in case you did)

In an ideal world we would have a shared nexus driver that enumerated ports. But lacking that I would do what I did with i40e where each port discovers its peers on the same PCI device and basically just divide up.

The nexus doesn't make sense due to the fact that they use a function per pf, so the i40e approach is what I would probably do off hand.

I don't really remember anything deeper there.

ok..

Look at i40e_device_t, i40e_device_find, etc.

(I was kinda wondering about the nexus driver bit because the other fun wrinkle is there's a chance -- thankfully not immediately -- that we might need something that does RDMA (which AFAIK would be either ice or mlxcx).. but from what _little_ i've looked suggests that might need it's own dip

(I really hope we don't, but not my call)

could I suppose just hang it off the ice node

If there's something more specific for the resource stuff, feel free to shoot me an e-mail jbk.

[illumos-gate] 18333 stmf_sbd: get/load PP data ioctls must validate buffer sizes -- Toomas Soome <tsoome⊙mc>

jbk: at the very least have visibility for each shared resource -- perhaps kstats for each shared resource showing how many you have total, how many are unallocated is free, and how many each port is using.

if doing something to a port fails because the shared resource is overcommited, have sensible error messages explaining why..

sommerfeld: the big one is that (for example) this card has 2 PCI functions (2 physical ports) so 2 dips, but the TX and RX rings are shared (or maybe pooled might be a better way to describe it)

the card has (for example) 2K TX queues (that can be used for LSO, up to I think 16K total)

and AFAIK those 2K queues can be divided in any way you want between the two dips

(I need to look at the i40e stuff still)

but either you need to coordiate between them (and of course if there's another physical card, that's separate)

or just decide '2 ports? ok, i'll divide everything by 2' (or 4 if 4 ports, etc)

the odd/annoyign thing is you really want to attach a driver at the PCI device level, and let it enumerate the PCI functions, but we can't do that (AFAIK)

or something like that to better match what's happening

(though that's also probably not perfect either even if it was possible)

due to each function having their own cfgspace, etc.