On 09/29/11 11:50, Greg KH wrote: > On Thu, Sep 29, 2011 at 08:44:26PM +0200, Christian Schaubschläger wrote: >> >>>> Enabling ACPI is not an option for me in that case. >>> Why not? >> >> Well, the reason is the following: >> After starting the linux system I switch back the machine to real mode >> using the kexec system call (then I run some real/protected mode stuff). >> This works fine in most cases, but on some machines after kexec the >> machine is in a state where important things (eg. some bios interrupt >> calls) don't work any more. The reason for that is that the machine's >> interrupt controller/pci system/chipset is left in an 'unusable' state >> by the ACPI system... >> >> Disabling ACPI solved this issue on almost all machines; however, >> recently I had to deal with some machines with usb3, and on some of them >> I observed the behaviour I described before. >> >> Now I'm aware that this is not the typical usage scenario of a linux >> system, and I'm also aware that another option to get things working in >> real mode again would be trying to re-configure (or reset) the hardware >> after kexec; but this is not a trivial thing to do; for me it would be >> easiest to have xhci working without ACPI. That's why I was asking. > > Again, this isn't a xhci issue, ACPI is in charge of handling the PCI > irq routing here, so it is needed to have the pci devices work properly. > > I suggest you work with the Linux ACPI developers to solve your problem, > and that will then resolve the xhci issue as well. so (for arch/x86/Kconfig), this: config PCI bool "PCI support" default y select ARCH_SUPPORTS_MSI if (X86_LOCAL_APIC && X86_IO_APIC) should also say: select ACPI or depends on ACPI I hope not. I do think it would be worthwhile to discuss this (xhci) problem with the kexec people. -- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html