Maximilian Luz

I'm moving this to https://github.com/qzed/linux-surface-kernel as it doesn't seem to have anything to do with the SAN/SAM drivers or their targeted devices. I have no idea what could cause this...

Based on some reverse-engineering, the payload has the form `8bit (unused), 32bit, 32bit, 16bit, 16bit, 32bit, 32bit`. Converted to integers, this yields `1, 99770, 74630, 101, 7457, 0, 13000`. @archseer:...

Here's that decoded into numbers: ``` [(1, 108360, 76500, 99, 7479, 0, 13000), (1, 107340, 76260, 99, 7438, 0, 13000), (1, 108460, 76520, 99, 7414, 0, 13000), (1, 109480, 76760,...

Oh, I forgot to answer to the 0x0015 events during reloading: Those are input events (TC=0x15). They should _normally_ get disabled when the sid_vhf module is unloaded. I suspect that...

Can you upload an acpidump (run `sudo acpidump > acpidump.out`)?

Okay, to be sure: If you unload the SAM modules the system doesn't get unresponsive (you can unload all via https://github.com/linux-surface/surface-aggregator-module/blob/master/scripts/unload.sh)? I can't find any obvious connection in the acpidump/DSDT...

If you remove both the SAM modules and the `soc_button_array`, does IRQ 14 still trigger?

Does only removing `soc_button_array` stop it too? Also the volume switches do behave normally, so no constant/automatic increase/decrease after pressing?

It's good that you've found a workaround for now. I still have no real clue why this is happening and unfortunately not that much time to look into this at...

Since the root problem seems to also occur when the SAM modules are unloaded you could unload them and then get the dmesg log, that way that part at least...