On Fri Aug 11, 2023 at 9:47 PM EEST, Grundik wrote: > On Fri, 2023-08-11 at 20:40 +0300, Jarkko Sakkinen wrote: > > On Fri Aug 11, 2023 at 8:22 PM EEST, Jarkko Sakkinen wrote: > > > On Fri Aug 11, 2023 at 11:18 AM EEST, Thorsten Leemhuis wrote: > > > > > > > > > I see two long-standing options: > > > > > > A. Move from deny list to allow list when considering using IRQs. > > > This > > > can be supplemented with a kernel command-line parameter to > > > enforce > > > IRQs and ignore the allow list (and IRQ storm detection provides > > > additional measure in case you try to enforce) > > > B. Change deny list to match only vendors for the time being. This > > > can > > > be supplemented with a allow list that is processed after the > > > deny > > > list for models where IRQs are known to work. > [...] > > > > This is also super time consuming and takes the focus away from more > > important matters (like most likely the AMD rng fix would have gone > > smoother without these getting in the way all the time). > > Main problem of any list is maintaining of them. So, I think there > should not be any black or white lists at all. Module should work with > reasonable default (polling is the one, which lived without problems > for years and years due to bug, as I understand), and probably a boot > option to force IRQ. Maybe module should warn user to try that option. > > I don't know: is it even worth it to use IRQ, if it so problematic? Are > there any significant advantages of that? I understand, polling is a > resource consumer, but its just TPM, which is used mainly at the boot > time, is it worth it? +1 Thanks for sharing your opinion. I'll take the necessary steps. BR, Jarkko
