13:15:45 [illumos-gate] 15309 zfs_acl_chmod_aclmode_001_pos is failing -- Toomas Soome 13:21:32 Consoles: EFI console 13:21:32 illumos/aarch64 EFI loader, Revision 1.1 13:21:35 .oO 13:46:21 tsoome: oO 13:46:46 it does not mean too much yet;) 13:47:52 You are such a tease :) 13:48:49 Well if we can boot in qemu thats already helping. If you can PR it towards richlowes aarch64 branch or point me towards a repo I can integrate it into the packaging and start testing 13:48:55 in addition, this bloody qemu just started to get: ZFS: i/o error - all block copies unavailable -- so I need to recover from that (unexpectedly) 14:26:12 ouch 14:33:21 since this qemu does not shut down properly, it smells like part of disk cache was not flushed before shutdown:) 17:35:14 huh, this qemu is blowing up on ahci sometimes... 17:37:40 So qemu likes ahci in the same way all other software devs do? 17:37:51 Ah, no that was acpi 17:49:31 qemu has multpile different types of machines with different designs. The basic qemu virt machine is a good target for basic development and IIRC yes, passes some of that info via acpi. 18:36:42 our arm should not have ahci just yet, the drivers are there but who knows if they work 18:37:00 you want the 'virt' machine, and I actually added a version number specifically so we all knew which one even though it's an old one 18:50:51 oh, toomas isn't here 18:52:26 do we use ACPI to enumerate all the buses on ARM or do something similar as x86? 18:52:33 neither 18:53:20 no acpi yet, because I haven't seen an armsbsa system or something like it 18:53:24 flat device tree 18:54:41 one thing that's caused a bit of a wrinkle w/ the hyper-v gen2 support is that it assumes ACPI is used to enumerate all of the buses.. including all the non-PCI stuff (com ports, TPM2 module, etc) 18:55:12 I have a workaround, though still undecided where in the device tree they should go 18:55:25 (nothings committed anywhere, so nothing's set in stone) 18:55:52 we _do_ enumerate all the "isapnp"-y acpi devices that way. 18:55:59 since there is no PCI-ISA bridge in that instance.. just devices with an IO or MEM address and maybe IRQ 18:56:00 (or x86) 18:56:07 only in the presense of an PCI-ISA bridge 18:56:09 _on x86_, drat 18:59:16 which is the issue there 18:59:36 there are no PCI bridges in hyper-v gen 2 (unless there's PCI pass-thru which isn't supported on illumos yet) 18:59:41 so no PCI-ISA bridge 18:59:48 so the COM ports and such don't get enumerated 19:00:18 it appears freebsd and others let ACPI drive it vs. trying to 'fill in the gaps' after handling the PCI bus 19:21:57 jbk: The PCI PRD (platform resource discovery) allows the platform to enumerate PCI bits in any way. The ACPI devices tree is also set up to allow enumeration of other stuff fwiw. 19:27:45 but only of certain things -- I'd need to find the code again, but we filter out (i.e. ignore) a lot of stuff... under the assumption that a PCI-ISA bridge will exist, which will call an ISA specific ACPI enumeration function 19:28:04 which was the problem w/ hyper-v 19:29:02 one of the workarounds was to add some bits to 'un-filter' that stuff under hyper-v 19:29:37 but then the com ports end up under /fw 19:29:48 which maybe is ok? 19:33:15 I would expect them at the root if that's where they are. 19:34:18 the degree it matters is that you're going to be calling your parent, etc's, bus methods 19:34:33 for which rootnex seems more likely to be actually the right one? 19:34:49 but I don't know how that's structured, if that's not true, that sort of dictates where they should go. 22:47:15 it looks like what i settled on (for now.. nothing's committed at this point) is playing a bit of a game and if we see \_SB_.FW.VMBS, it creates a dev node for the vmbus under the root nexus, and if booted off EFI (how MS suggested distinguishing between gen1 and gen2), also attach an isa instance under the root nexus 22:47:22 https://github.com/jasonbking/illumos-gate/commit/d1a415c7feae5cf6de9f9ef9b6c15c68ec9ace4d#diff-4f592b89c858a2b232585becfdee6bdcd4cde6f973b7afc4845d63972d30f068 22:48:05 the last bit i really need to sort out (if I can ever get the time) is cleaning up how vmbus devices are created and destroyed 22:48:35 the freebsd code it comes from is a bit of 'taskq-ception' which causes problems 22:48:53 i think i've figured out the (unstated) locking rules surrounding creating children 22:49:40 which was another piece that was a problem (though the scsav3 rewrite of the hv storage driver garrett did was at last nice enough to make it easy to hit in a debug kernel so it make it a bit easier to figure out) 22:49:56 err at least