https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236513
--- Comment #26 from stockhau...@collogia.de ---
(In reply to Andriy Gapon from comment #25)
Sorry for the confusion. I'm totally new to the topic and try to do my best to
explain my observations more clear.
The thin clients I'm talking about have a C2 power saving state that is
controlled by port 0x414. This port is the same for all 4 cores. Due to the
ACPI cpu startup logic the port reservation must work for each individual core.
If it fails C2 is not available for a core.
In the buggy case we can see:
1. System registers all known ports in acpi_sysres_alloc() in resource manager.
Port 0x414 is skipped because it is not correctly defined. There exists a BIOS
range 0x3e0 with 2328 ports but it is located directly under the PCI bridge.
2. So we have no range under acpi0 > I/O ports that covers port 0x414.
3. CPUs are fired up and do their initialization. The first CPU wants to
register port 0x414. As it is not yet managed the registration process hangs
the port as "I/O port" below CPU0.
4. The second CPU tries to do the same but it fails. For whatever reason
Result:
nexus0
acpi0
I/O ports:
cpu0 pnpinfo _HID=none _UID=0 at handle=\_PR_.P000
I/O ports: <-- Notice no type ACPI!
0x414
Now to the fixed case:
1. I found a port range 0x40B-0x40B in the ACPI tables that registers fine in
acpi_sysres_alloc() just before the CPUs.
2. I modified the ACPI tables and extended the range to something larger that
also covers port 0x414
3. After a restart with the modified table port 0x414 is now covered by a range
under acpi0 > I/O ports.
4. During CPU startup all CPUs can correctly allocate port 0x414 and a "copy"
named "ACPI I/O port" is placed under each CPU core.
Result:
nexus0
acpi0
I/O ports:
0x400-0x41f
cpu0 pnpinfo _HID=none _UID=0 at handle=\_PR_.P000
ACPI I/O ports: <-- Notice type ACPI!
0x414
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
