On Tue, Mar 23, 2021 at 08:29:29PM +0100, Mark Kettenis wrote: > > Date: Tue, 23 Mar 2021 17:39:45 +0100 > > From: Theo Buehler <[email protected]> > > > > On Tue, Mar 23, 2021 at 05:28:37PM +0100, Mark Kettenis wrote: > > > > Date: Tue, 23 Mar 2021 16:56:33 +0100 > > > > From: Theo Buehler <[email protected]> > > > > > > > > On Tue, Mar 23, 2021 at 04:13:53PM +0100, Mark Kettenis wrote: > > > > > > Date: Tue, 23 Mar 2021 14:14:40 +0100 > > > > > > From: Theo Buehler <[email protected]> > > > > > > > > > > It would help if you could try and boot a kernel that adds some debug > > > > > prints instead of calling aml_die(). Probably need to know the values > > > > > of alen, bpos, blen, mode and flag for starters. > > > > > > > > Thanks. > > > > > > > > alen 0x00, bpos 0x278, blen 0x10, mode 0x00, flag 0x605 > > > > > > > > So: AML_FIELD_ACCESS(flag) == AML_FIELD_BUFFER_ACC, bpos & 0x03 == 0 > > > > and the aml_die("Invalid GenericSerialBus access") is hit because blen > > > > is twice as long as it should be according to the conditional preceding > > > > it: > > > > > > > > if (AML_FIELD_ACCESS(flag) != AML_FIELD_BUFFERACC || > > > > bpos & 0x3 || blen != 8) > > > > > > Right, we need to figure out what this actually means. The ACPI > > > standard isn't exactly clear on this... > > > > > > > If I skip the aml_die("Invalid GenericSerialBus access"), it hits the > > > > next aml_die("Could not find GenericSerialBus controller"); because > > > > node->i2c == NULL. > > > > > > If I'm reading the AML and FreeBSD dmesg correctly this is an i2c > > > controller that attaches to PCI. I suspect that it is dwiic(4). D > > > you see dwiic(4) attach? > > > > Two of them: > > > > dwiic0 at pci0 dev 21 function 0 "Intel 400 Series I2C" rev 0x00: apic 2 > > int 22 > > iic0 at dwiic0 > > dwiic1 at pci0 dev 21 function 1 "Intel 400 Series I2C" rev 0x00: apic 2 > > int 23 > > iic1 at dwiic1 > > > > > If so, the problem is that we dont't call acpi_register_gsb() for > > > dwiic(4) instances that attach to PCI. I'll see if I can come up with > > > a diff for that. > > > > Thanks a lot! > > Can you try the diff below?
I tried to install a release built with this. With miniroot69.img I still hit the reboot loop described in my first mail: ... wsdisplay0 at efifb0 mux 1: console (std, vt100 emulation), using wskbd0 aml_rwgen: unregistered RegionSpace 0x9 Could not convert 0 to 3 panic: aml_die aml_convert: 2095 syncing disks...uvmfault(0xffffffff818e5d78, 0xbc8, 0, 1) -> e fatal page fault in supervisor mode trap type 6 code 0 rip ffffffff810e216b cs 8 rflags 10286 cr2 bc8 cpl 0 rsp ffff80001f76f120 gsbase 0xffffffff818d0ff0 kgsbase 0x0 panic trap type 6, code=0, pc=ffffffff810e216b dump to dev 17,1 not possible rebooting... I tried to move acpi_register_gsb() and the call to it in dwiic_pci.c out of SMALL_KERNEL, but that didn't help. What info would be useful to debug this further?
