[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: Problems in PV dom0 on recent x86 hardware
On 09.07.24 15:08, Jason Andryuk wrote: On 2024-07-09 06:56, Jürgen Groß wrote:On 09.07.24 09:01, Jan Beulich wrote:On 09.07.2024 08:36, Jürgen Groß wrote:On 09.07.24 08:24, Jan Beulich wrote:On 08.07.2024 23:30, Jason Andryuk wrote:From the backtrace, it looks like the immediate case is just trying to read a 4-byte version: >>>> [ 44.575541] ucsi_acpi_dsm+0x53/0x80 >>>> [ 44.575546] ucsi_acpi_read+0x2e/0x60 >>>> [ 44.575550] ucsi_register+0x24/0xa0 >>>> [ 44.575555] ucsi_acpi_probe+0x162/0x1e3 int ucsi_register(struct ucsi *ucsi) { int ret; ret = ucsi->ops->read(ucsi, UCSI_VERSION, &ucsi->version, sizeof(ucsi->version)); ->read being ucsi_acpi_read() However, the driver also appears write to adjacent addresses.There are also corresponding write functions in the driver, yes, but ucsi_acpi_async_write() (used directly or indirectly) similarly calls ucsi_acpi_dsm(), which wires through to acpi_evaluate_dsm(). That's ACPI object evaluation, which isn't obvious without seeing the involved AML whether it might write said memory region.I guess an ACPI dump would help here?Perhaps, yes.It is available in the bug report: https://bugzilla.opensuse.org/show_bug.cgi?id=1227301After acpixtract & iasl: $ grep -ir FEEC * dsdt.dsl: OperationRegion (ECMM, SystemMemory, 0xFEEC2000, 0x0100) ssdt16.dsl: OperationRegion (SUSC, SystemMemory, 0xFEEC2100, 0x30) from the DSDT: Scope (\_SB.PCI0.LPC0.EC0) { OperationRegion (ECMM, SystemMemory, 0xFEEC2000, 0x0100) Field (ECMM, AnyAcc, Lock, Preserve) { TWBT, 2048 } Name (BTBF, Buffer (0x0100) { 0x00 // . }) Method (BTIF, 0, NotSerialized) { BTBF = TWBT /* \_SB_.PCI0.LPC0.EC0_.TWBT */ Return (BTBF) /* \_SB_.PCI0.LPC0.EC0_.BTBF */ } } From SSDT16: DefinitionBlock ("", "SSDT", 2, "LENOVO", "UsbCTabl", 0x00000001) { External (_SB_.PCI0.LPC0.EC0_, DeviceObj) Scope (\_SB) { OperationRegion (SUSC, SystemMemory, 0xFEEC2100, 0x30) Field (SUSC, ByteAcc, Lock, Preserve) { This embedded controller (?) seems to live at 0xfeec2xxx. What is the takeaway from that? Is this a firmware bug (if yes, pointers to a specification saying that this is an illegal configuration would be nice), or do we need a way to map this page from dom0? Juergen
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |