Re: [BUG] HID: amd_sfh (drivers/hid/amd-sfh-hid/): memory/page corruption

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 7/22/2024 10:00 PM, Benjamin Tissoires wrote:
> On Jul 21 2024, Chris Hixon wrote:
>> On 7/21/24 00:20, Basavaraj Natikar wrote:
>>
>>> On 7/17/2024 4:51 PM, Linux regression tracking (Thorsten Leemhuis) wrote:
>>>> On 15.07.24 06:39, Chris Hixon wrote:
>>>>> System: HP ENVY x360 Convertible 15-ds1xxx; AMD Ryzen 7 4700U with
>>>>> Radeon Graphics
>>>>>
>>>>> Problem commits (introduced in v6.9-rc1):
>>>>> 6296562f30b1 HID: amd_sfh: Extend MP2 register access to SFH
>>>>> 2105e8e00da4 HID: amd_sfh: Improve boot time when SFH is available
>>>>>> It appears amd_sfh commits 6296562f30b1 and 2105e8e00da4 correlate with
>>>>> some form of memory/page corruption. 
>>>> Hi! From a quick search on lore it looks like Basavaraj Natikar who
>>>> authored those two commits is inactive since a few days. This is totally
>>>> fine, but given the nature of the problem slightly unfortunate. That's
>>>> why I'm trying to raise awareness to this report by adding the
>>>> subsystems maintainers, a few lists, and a few people to the list of
>>>> recipients that were involved in the submission of those two patches.
>>>> With a bit of luck somebody might be able to help out. Ciao, Thorsten
>>>>
>>>>> On my system, this typically
>>>>> presents itself as a page dump followed by BTRFS errors, usually
>>>>> involving "corrupt leaf" (see dmesg output below); often the BTRFS
>>>>> filesystem becomes read-only afterwards. Note that the underlying NVME
>>>>> disk seems fine, and the BTRFS filesystem does not actually appear to be
>>>>> corrupt when booted/checked from kernels without this bug (no BTRFS
>>>>> errors or I/O errors reported on non-problem kernels).
>>>>>
>>>>> I have no problems when I blacklist the amd_sfh module (any kernel
>>>>> version), or revert both commits 6296562f30b1 and 2105e8e00da4 (on
>>>>> stable, linux-6.9.y). I have no problems on any recent linux-mainline
>>>>> (v6.10{,-rc*}) when reverting these two commits (in addition to
>>>>> reverting 7902ec988a9a and 6856f079cd45 to successfully build the
>>>>> kernel). I have had no problems with any 6.6.y, v6.7.y, or v6.8.y version.
>>>>>
>>>>> It is curious BTRFS always seems involved, but problems go away with
>>>>> these amd_sfh commits reverted (or amd_afh disabled).
>>>>>
>>>>> Further notes:
>>>>>
>>>>> I have not specifically used the amd_sfh module for anything. As far
>>>>> I've been able to determine, my system has the "Sensor Fusion Hub" mp2
>>>>> chip, but has no supported sensors/sub-devices (or I need to do
>>>>> something to enable them), (or there is an error while detecting
>>>>> sensors?). All logs I've checked contain something like:
>>>>>
>>>>> Jul 09 04:14:37 arch kernel: pcie_mp2_amd 0000:04:00.7: enabling device
>>>>> (0000 -> 0002)
>>>>> Jul 09 04:15:07 arch kernel: pcie_mp2_amd 0000:04:00.7: Failed to
>>>>> discover, sensors not enabled is 0
>>>>> Jul 09 04:15:07 arch kernel: pcie_mp2_amd 0000:04:00.7:
>>>>> amd_sfh_hid_client_init failed err -95
>>>>>
>>>>> Excerpt from lshw:
>>>>>            *-generic:1 UNCLAIMED
>>>>>                 description: Signal processing controller
>>>>>                 product: Sensor Fusion Hub
>>>>>                 vendor: Advanced Micro Devices, Inc. [AMD]
>>>>>                 physical id: 0.7
>>>>>                 bus info: pci@0000:04:00.7
>>>>>                 version: 00
>>>>>                 width: 32 bits
>>>>>                 clock: 33MHz
>>>>>                 capabilities: pm pciexpress msi msix cap_list
>>>>>                 configuration: latency=0
>>>>>                 resources: memory:fe000000-fe0fffff
>>>>> memory:fe4cc000-fe4cdfff
>>> Could you please check with the latest version, including the patch below?
>>>
>>> https://lore.kernel.org/all/20240718111616.3012155-1-Basavaraj.Natikar@xxxxxxx/
>>>
>>> Thanks,
>>> --
>>> Basavaraj
>>>
>> Hi,
>>
>> Unfortunately, that patch doesn't fix the issue. I do get different crashes...
> Thanks for the quick testing.
>
> Basavaraj, was the patch from above an attempt at fixing that particular
> regression or was it emerging from some other means?
>
> In other words: should I apply the fix even if it's still not the
> correct one for Chris?

yes Benjamin, Please apply fix and it looks like below crash is not related to amd_sfh driver.

Thanks,
--
Basavaraj

>
> Cheers,
> Benjamin




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux