02:04:47 @jbk don't forget there's not-yet-upstreamed mlxcx work from @arekinath ! 02:05:12 aaaaaaahhh I'm being summoned 02:05:41 have't tried any cx-7 hardware yet, but I would like to find one at some point. only got cx-6s currently 02:05:47 and a cx-6 era PRM 02:06:01 but it doesn't _sound_ like they've changed a whole lot? 02:07:40 mlxcx does cheerfully try to attach to newer versions of the hardware as long as they're still using the same subsystem ids 02:08:21 the last few times something has changed it's been things like not detecting the speed of the link properly because they've added new bits for the link speed and type 02:08:31 but usually it still passes packets ok 03:09:01 I have a newer one I think... 03:09:32 and I have improved link-detection somewhere? been a while. 03:21:27 it looks like we have several cx-6 options, and 1 cx-7 (the rest are broadcom NICs) 03:25:01 I have a cx-7 and some docs if it's useful. 03:26:25 so it was more to know if the cx-7 was also an option at the moment.. 03:27:19 I haven't had a chance to put it in a system and test it, behind on other stuff, but can maybe next week. 03:38:37 i think i have a little bit of a reprieve on the pci segment stuff -- for now it looks like only a single socket system is needed (it looks like the second segment was tied to the second socket) 03:38:38 at least for now... 08:37:58 jbk its loading kernel, yes. 13:42:28 what about the boot archive? 13:45:38 boot archive is loaded as file (loadfile_raw() I believe, in common/module.c) 20:41:57 what's the current recommendation for SSD-based zpools Re: autotrim? I presume we should be setting it to 'on' still? 20:48:35 oh jeez.. yet _another_ pci cfgspace access mechanism 20:50:56 do you mean mechanisms _mechanisms_ or do you mean APIs we have? 20:51:02 APIs 20:52:39 so there's the pci_cfgacc_xxx, there's the pci_{put,get}{bwl}_func, there's the pci_config_xx DDI interfaces, and the cmi_pci_{get,put}{b,w,l} interfaces 20:53:22 Yes, mostly they call eachother 20:53:23 (which kinda use the others, except if they can't get a ddi_acc_handle_t, in which case they seem to plow on 20:53:37 pci_*_func is important because those are the ones prior to us having a device node 20:55:38 yeah, though they seem to imply/assume IO space access 20:55:38 everything else you can simplify in terms of cfgacc if you wanted to 20:55:39 jbk: if you want ecam there, I think the oxide stlouis branch has the changes from Keith for it 20:55:40 and maybe I do in arm64-gate too, since I think I took them 20:55:40 I know I got the suspicious 64bit access sizes from _someone_ 20:56:06 but I'd totally recommend reading the short document I put together in arm64-gate, and the cfgspace bits 20:56:33 I have faith it's not as awful as it could be! 20:59:27 oooh nice! 21:10:43 jbk: re: retiring dimms, I'm not sure. We have page relocation and page migration (migration uses relocation), and claims x86 doesn't support relocation 21:10:50 but it _has in the past_ supported memory DR! 21:11:09 and does currently support retirement 21:12:14 that could be at least somewhat useful for VMs where the hypervisor supports it (I believe there are some for X86.. along with adding/removing CPUs via ACPI) 21:13:49 if the usefulness is worth the required support, I don't know.. 21:14:42 I don't know about memory dr, someone turned it off 21:17:25 side note: would it be worth a ticket to get rid of the mechanism 2 pci access bits? IIUC, these were last seen on pentium systems (so shouldn't be anything we can boot on that'd use them) 21:51:57 I think so. It would be meem compliant at least. Would it make still-in-use code easier to read? Would it rip out things that might be still load-bearing? I'd like to see such a ticket take stabs at those two questions in its analysis. 21:55:01 the risk would be virtualization doing weird shit 21:55:07 assuming that it is in fact correct that no post-pentium system uses mechanism 2 access (all of the sources I can find basically say 'it's so old, we're not going to even bother discussing other than to note it used to be a thing' 21:55:19 it should just be eliminating dead code 21:55:24 I think for the weirdest mechanism, that's unlikely 21:55:38 but I don't remember the mechanisms. I just remember a really weird one, and a less weird one 21:55:46 as well as regular and ecam 21:56:02 I need to come back for more x86 dead code, though, thanks for reminding me dan 21:56:08 and RTI the parameters one 21:57:02 https://wiki.osdev.org/PCI claims 486 and early pentium models 21:59:02 there are some other workarounds that i'm unsure of (so would leave them be without more info) 21:59:52 unless someone specifically knows what 'orion' and 'neptune' were at sun and if they're something we can actually boot on still.. 22:00:04 or intel 22:03:09 well, neptune was the 10G on the T2? 22:03:17 so either they re-used the name, or they aren't sun names 22:03:50 neptune might an Intel name 22:04:03 sounds like it also might be of the same vintage 22:04:09 and orion seems to be a java enterprise application something something something 22:05:02 and a suncluster thing 22:05:14 tangentially related, does anyone know of the fakebop properties (do_bsys_getprop(), etc) get copied over to a device node (rootnex?) at some point 22:05:49 not off the top of my head, but the traditional way is not a copy, it's an explicit search of "prom" properties 22:08:15 oh ok (i see something using something trying to access one of those properties via ddi_prop_lookup_xxx and just wasn't sure if that should work (sounds like it should) 22:08:38 look for `DDI_PROP_FOUND_1275` references 22:09:15 and `impl_ddi_bus_prop_op` 22:11:49 I hear neptune and think, "nxge" per @richlowe. Orion... eeesh, I'd have to dig through my archives. 22:12:52 so neptune is maybe the intel 430NX from 1994 22:13:28 No 22:13:42 Neptune is nxge. 22:13:46 (seems to fit) 22:13:58 "Sun Java Enterprise System (formerly known as Project Orion)" 22:14:08 Orion was ^^^ 22:14:09 and orion is maybe intel 450gx/nx for pentium pros 22:14:17 Damn you for making me dig through my emails. 22:14:17 at least in this context 22:14:22 :) 22:14:29 it took some searching 22:16:00 i'll put in a ticket, and maybe someone with more specific background knowledge can confirm/deny (worst case we reject it) 22:23:37 ok.. issue created.. 23:02:27 the system handbook code names list also has: 23:02:29 Neptune (obsolete) SPARCengine EC 23:02:29 (special for Kodak) 23:02:29 Neptune ASIC that enables SPARC to support 10Gb Ethernet 23:02:51 Orion 17-inch LCD Color Flat Panel monitor 23:03:12 only one of which sounds vaguely relevant 23:04:53 Atlas PCI Express Gigabit Ethernet cards utilizing Neptune ASIC 23:05:23 Sputnik Orion CP2080 and Advantest 23:05:23 500MHz cPCI CPU mezzanine memory (SME)