linux-kernel - Re: Failed IRQ assignment for INT0002 on Braswell

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 22 Nov 2017 16:50:33 +0100
From:   Hans de Goede <hdegoede@...hat.com>
To:     Oleksandr Natalenko <oleksandr@...alenko.name>
Cc:     platform-driver-x86@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: Failed IRQ assignment for INT0002 on Braswell

Hi,

On 22-11-17 13:48, Oleksandr Natalenko wrote:
> Hi, Hans.
> 
> On středa 22. listopadu 2017 11:48:50 CET Hans de Goede wrote:
>> /* snip */
>> This should be fixed by:
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/ke
>> rnel/irq?id=382bd4de61827dbaaf5fb4fb7b1f4be4a86505e7
>>
>> Which is in 4.13, but the trigger-type does not seem to be the problem in
>> your case, the problem likely is the ONESHOT flag:
>>
>> #define IRQF_ONESHOT            0x00002000
>>
>> Which appears to be set in the flags for the acpi irq handler:
>>   > kernel: genirq: Flags mismatch irq 9. 00010084 (INT0002) vs. 00002080
>>   > (acpi)
>> But that irq is requested here:
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/driv
>> ers/acpi/osl.c#n570
>>
>>
>>
>> 	if (request_irq(irq, acpi_irq, IRQF_SHARED, "acpi", acpi_irq)) {
>> 		printk(KERN_ERR PREFIX "SCI (IRQ%d) allocation failed\n", irq);
>> 		...
>>
>> And IRQF_ONESHOT is not passed, so I do not understand where the 00002000 in
>> the acpi irq handler flags is coming from ...
> 
> Well, looks like I know where this flag comes from. I boot this machine with
> "threadirqs", and IRQF_ONESHOT description says:
> 
> ===
>   52  * IRQF_ONESHOT - Interrupt is not reenabled after the hardirq handler
> finished.
>   53  *                Used by threaded interrupts which need to keep the
>   54  *                irq line disabled until the threaded handler has been
> run.
> ===
> 
> If I boot the machine without "threadirqs", looks like the device is set up
> okay. The only message I get in the kernel log is:
> 
> ===
> kernel: acpi INT0002:00: Device [GPED] is in always present list
> ===
> 
> Grepping for IRQ 9:
> 
> ===
> kernel: ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
> kernel: ACPI: IRQ9 used by override.
> ===
> 
> and 9th interrupt shows this device:
> 
> ===
>     9:          0          0          0          0   IO-APIC    9-fasteoi
> acpi, INT0002
> ===
> 
> Any idea why "threadirqs" makes this fail?

Yes, I think this is caused by the int0002 vgpio driver unnecessarily
passing the IRQF_NO_THREAD flag, attached is a patch which should fix this,
can you give this a try ?

Regards,

Hans

View attachment "0001-platform-x86-intel_int0002_vgpio-Remove-IRQF_NO_THRE.patch" of type "text/x-patch" (1298 bytes)