Re: Recent tpm_tis IRQ handling changes are causing kernel backtraces

[Hans de Goede <hdegoede@redhat.com>]

Hi,

On 6/1/21 6:04 PM, Hans de Goede wrote:
> Hi,
> 
> On 5/31/21 6:36 AM, Jarkko Sakkinen wrote:
>>> Interestingly enough the first backtrace is also happening on a:
>>> "Dell Inc. XPS 13 9310/0MRT12, BIOS 2.2.0 04/06/2021"
>>>
>>> So it seems that at least with 5.12.6 (which has the last 2 fixes)
>>> all reports are about the XPS 13 9310. I wonder if there is an
>>> issue with the TPM interrupt line on the XPS 13 9310; I've asked the
>>> reporters to try adding tpm_tis.interrupts=0 to their kernel commandline.
>>
>> This is helpful for sure that these all are happening on matching hardware.
> 
> So our kernel-backtrace tracking info (ABRT) just recorded a third backtrace
> with a kernel >= 5.12.6, again on the XPS 13 9310, so now we have 3 variants:
> 
> 1. Backtrace starting with a call to ima_add_boot_aggregate
> https://bugzilla.redhat.com/show_bug.cgi?id=1963712
> 
> 2. Backtrace starting with a call to tpm_dev_async_work:
> https://bugzilla.redhat.com/show_bug.cgi?id=1964974
> (note this one is not easily reproducible)
> 
> 3. Backtrace starting with a call to rng_dev_read:
> https://bugzilla.redhat.com/show_bug.cgi?id=1920510
> 
> 3. is the new one. All bugs linked above are public, all 3 backtraces
> so far have only been reported on the XPS 13 9310 (with kernel >= 5.12.6)
> and I've asked all the reporters to check if tpm_tis.interrupts=0 helps.

Quick status update, I've got a response from a XPS 13 9310 user in:

https://bugzilla.redhat.com/show_bug.cgi?id=1920510

Indicating that a. he can reproduce this with the latest >= 5.12.6 kernels;
and b. it goes away when specifying tpm_tis.interrupts=0 as I expected
(I expected this because all the bug-reports started when the interrupt
code got fixed/re-enabled a while ago).

Si I think that there just is something broken wrt the interrupt setup
on the XPS 13 9310 and that we should probably add an antry for the
XPS 13 9310 to the already existing tpm_tis_dmi_table pointing to the
also already existing tpm_tis_disable_irq callback.

If other people agree that that is probably the best way forward ?
then I can prepare a patch and ask the user to test this.

Regards,

Hans