[illumos-gate] 15309 zfs_acl_chmod_aclmode_001_pos is failing -- Toomas Soome <tsoome⊙mc>

Consoles: EFI console

illumos/aarch64 EFI loader, Revision 1.1

.oO

tsoome: oO

it does not mean too much yet;)

You are such a tease :)

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

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)

ouch

since this qemu does not shut down properly, it smells like part of disk cache was not flushed before shutdown:)

huh, this qemu is blowing up on ahci sometimes...

So qemu likes ahci in the same way all other software devs do?

Ah, no that was acpi

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.

our arm should not have ahci just yet, the drivers are there but who knows if they work

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

oh, toomas isn't here

do we use ACPI to enumerate all the buses on ARM or do something similar as x86?

neither

no acpi yet, because I haven't seen an armsbsa system or something like it

flat device tree

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)

I have a workaround, though still undecided where in the device tree they should go

(nothings committed anywhere, so nothing's set in stone)

we _do_ enumerate all the "isapnp"-y acpi devices that way.

since there is no PCI-ISA bridge in that instance.. just devices with an IO or MEM address and maybe IRQ

(or x86)

only in the presense of an PCI-ISA bridge

_on x86_, drat

which is the issue there

there are no PCI bridges in hyper-v gen 2 (unless there's PCI pass-thru which isn't supported on illumos yet)

so no PCI-ISA bridge

so the COM ports and such don't get enumerated

it appears freebsd and others let ACPI drive it vs. trying to 'fill in the gaps' after handling the PCI bus

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.

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

which was the problem w/ hyper-v

one of the workarounds was to add some bits to 'un-filter' that stuff under hyper-v

but then the com ports end up under /fw

which maybe is ok?

I would expect them at the root if that's where they are.

the degree it matters is that you're going to be calling your parent, etc's, bus methods

for which rootnex seems more likely to be actually the right one?

but I don't know how that's structured, if that's not true, that sort of dictates where they should go.

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

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

the freebsd code it comes from is a bit of 'taskq-ception' which causes problems

i think i've figured out the (unstated) locking rules surrounding creating children

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)

err at least