linux-kernel - Re: [PATCH 0/2] i2c: i801: Force no IRQ for Dell Latitude E7450

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:   Mon, 19 Jun 2023 17:19:12 +0200
From:   Jean Delvare <jdelvare@...e.de>
To:     Marius Hoch <mail@...iushoch.de>
Cc:     linux-i2c@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/2] i2c: i801: Force no IRQ for Dell Latitude E7450

On Sun, 18 Jun 2023 15:42:40 +0200, Marius Hoch wrote:
> I just booted with acpi=noirq, the PCI device no longer fails to be 
> enabled and the device got assigned IRQ 19 now (according to lspci -v/ 
> proc/interrupts), while the freefall device remained at IRQ 18.
> Interestingly dmesg is full of spam from the freefall device (endlessly 
> reporting that freefall got detected, probably indicating a problem in 
> IRQ handling, yikes).

Unfortunately, while acpi=noirq can be useful for testing purposes and
bug investigation, there's no guarantee that a modern x86 system can
actually work properly without ACPI-based PCI routing.

> Booting without the smo8800 module results in:
> [root@...ora ~]# dmesg | grep -i smbus
> [   20.042515] i801_smbus 0000:00:1f.3: PCI->APIC IRQ transform: INT C 
> -> IRQ 19  
> [   20.042548] i801_smbus 0000:00:1f.3: SPD Write Disable is set
> [   20.042574] i801_smbus 0000:00:1f.3: SMBus using PCI interrupt
> [   20.051270] i801_smbus 0000:00:1f.3: Accelerometer lis3lv02d is 
> present on SMBus but its address is unknown, skipping registration
> [   20.253942] i801_smbus 0000:00:1f.3: Transaction timeout
> [   20.461962] i801_smbus 0000:00:1f.3: Transaction timeout
> 
> The "Transaction timeout" messages might indicate that interrupt routing 
> isn't actually working?

Indeed. This means the driver waited for an interrupt but was never
called back.

-- 
Jean Delvare
SUSE L3 Support