I've dumped original ACPI tables from original BIOS, but I can't see any such hooks.
https://pastebin.com/Mniskv3f part1 of dsdt https://pastebin.com/hnpgvCMN part2 of dsdt (starts from EHCI/XHCI controllers) I hope it is not in SMM cause I really have no idea how to edit it to solve this problem -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Julius Werner Sent: Tuesday, October 10, 2017 5:56 AM To: Аладышев Константин Cc: Coreboot Subject: Re: [coreboot] USB problem with Haswell+LynxPointLP motherboards > And now I'm kinda stuck. The effect of this commit doesn't seem to > interface with bios for me. So how does original IBASE/DFI bios can > overcome code error before this commit? > > What can be the source of my problem? What should I investigate more > precise based on result that I've got? My gut feeling would be to blame ACPI. The Linux patch is about caching a host controller register in the kernel, and in some cases (e.g. ehci_reset()), the patch re-reads the cached version from the hardware whereas the previous code didn't. If some BIOS ACPI mucks with that register, it's possible that this got the kernel's cached copy out of sync before this patch, but with the patch the kernel will re-read it from the hardware at the right time. Maybe only coreboot's ACPI routines touch the register in that path, or maybe the vendor BIOS' routines were more careful to restore the original state afterwards. Besides ACPI this could also be in SMM code, I guess (especially if the problem occurs around system suspend/resume, although it sounds like it doesn't for you). -- coreboot mailing list: [email protected] https://mail.coreboot.org/mailman/listinfo/coreboot
