04:09:29 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 04:09:30 being sent back to SeaBIOS. i enabled the debugger and did a stack trace and got 04:09:30 ``` 04:09:31 kmdb_enter+0xb() 04:09:31 debug_enter+0x75() 04:09:32 panicsys+0x651() 04:09:32 vpanic+0x15c() 04:09:33 ~panic+0x40() 04:09:33 0xfffffffffb869f03() 04:09:34 trap+0x999() 04:09:34 cmntrap_pushed+0x3c() 04:09:35 bcopy_ck_size+0xea() 04:09:35 0xfffffffffb864faa() 04:09:36 startup+0x5a() 04:09:36 main+0x36() 04:09:37 _locore_start+0x88() 04:09:37 ``` 04:09:38 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) 04:19:45 it's a guess that it's somewhere in startup_modules 04:19:50 I would really try EFI 04:19:52 if you can 04:20:50 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) 04:21:13 it will make the console fairly verbose, but might give you a better idea of where things are going wrong 04:23:11 oof lol, yea switching to efi fixed it. thank you 04:23:54 cant believe i didnt try that :facepalm: 04:35:34 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) 04:35:40 it's basically old enough to drink in the US now 04:35:47 :) 04:52:41 hmm not really seeing anything useful it seems to me ?? 04:52:42 ``` 04:52:42 ../../i86pc/os/startup.c:2074: startup_vm() done 04:52:43 ../../i86pc/os/startup.c:2093: startup_tsc() starting... 04:52:43 ../../i86pc/os/timestamp.c:1028: Calibrating the TSC... 04:52:44 ../../i86pc/os/timestamp.c:1103: 'tsccpp[i]->tscc_source' is 'Hyper-V' 04:52:44 ../../i86pc/os/timestamp.c:1103: 'tsccpp[i]->tscc_source' is 'VMware' 04:52:45 ../../i86pc/os/timestamp.c:1103: 'tsccpp[i]->tscc_source' is 'PIT' 04:52:45 ../../i86pc/os/startup.c:2096: 'tsc_freq' is 0x10bb479b4 04:52:46 ../../i86pc/os/startup.c:1521: startup_modules() starting... 04:52:46 panic[cpu0]/thread=fffffffffbca9420: BAD TRAP: type=e (#pf Page fault) rp=fffffffffbcaf0b0 addr=fffffe0604c07370 04:52:47 #pf Page fault 04:52:48 Bad kernel fault at addr=0xfffffe0604c07370 04:52:48 ``` 12:42:47 so 4.5GHz? 12:42:54 oh they're gone 15:50:12 do we actually document the format for the names in driver_aliases anywhere? 15:51:17 e.g. for most pci/pciex you have pci, but there are other variants to that as well 16:07:22 Probably not as well as we could. But I have a summary in https://github.com/illumos/ipd/blob/master/ipd/0009/README.md jbk. 16:07:23 → IPD 9: PCI Alias Disambiguation (published) 16:13:13 ahh thanks.. 16:30:40 I think it'd probably be helpful to put something into maybe pci(4D) and pcie(4D). 16:30:44 Thoughts? 17:03:27 that was where I looked at first, so it would make sense to me at least.. 19:52:48 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 19:53:23 with newer, bigger systems, it seems like it _might_ become something we might need to manage in the near(ish) future 19:54:23 (mostly wondering if we need any placeholders now to avoid problems if/when we do need to deal with that) 19:54:42 (if not, that's fine, just figure I'd ask in case you did) 20:26:35 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. 20:27:09 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. 20:27:14 I don't really remember anything deeper there. 20:27:19 ok.. 20:29:03 Look at i40e_device_t, i40e_device_find, etc. 20:29:09 (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 20:30:14 (I really hope we don't, but not my call) 20:31:01 could I suppose just hang it off the ice node 20:34:28 If there's something more specific for the resource stuff, feel free to shoot me an e-mail jbk. 21:27:56 [illumos-gate] 18333 stmf_sbd: get/load PP data ioctls must validate buffer sizes -- Toomas Soome 21:52:44 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. 21:54:29 if doing something to a port fails because the shared resource is overcommited, have sensible error messages explaining why.. 22:16:27 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) 22:17:03 the card has (for example) 2K TX queues (that can be used for LSO, up to I think 16K total) 22:17:47 and AFAIK those 2K queues can be divided in any way you want between the two dips 22:18:11 (I need to look at the i40e stuff still) 22:18:33 but either you need to coordiate between them (and of course if there's another physical card, that's separate) 22:18:51 or just decide '2 ports? ok, i'll divide everything by 2' (or 4 if 4 ports, etc) 22:19:56 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) 22:20:06 or something like that to better match what's happening 22:20:29 (though that's also probably not perfect either even if it was possible) 22:20:52 due to each function having their own cfgspace, etc.