Skip to content

ASoC: SOF: remove duplicate controller reset for HDA platforms - #373

Merged
plbossart merged 1 commit into
thesofproject:topic/sof-devfrom
ranj063:fix/suspend_stress_test
Dec 6, 2018
Merged

plbossart merged 1 commit into
thesofproject:topic/sof-devfrom
ranj063:fix/suspend_stress_test

Conversation

@ranj063

@ranj063 ranj063 commented Dec 5, 2018

Copy link
Copy Markdown
Collaborator

For HDA platforms, hda_dsp_ctrl_init_chip() does a full
controller reset. So remove the duplicate controller reset
calls that were added for non-HDA platforms into the else block.
This should fix the failures seen with suspend/resume
stress tests on GLK.

Signed-off-by: Ranjani Sridharan ranjani.sridharan@linux.intel.com

@ranj063
ranj063 requested review from lgirdwood and plbossart and removed request for plbossart December 5, 2018 16:29
@ranj063

ranj063 commented Dec 5, 2018

Copy link
Copy Markdown
Collaborator Author

This seems to fix #370 at least on one of boards where the suspend_stress_test failed earlier

@cujomalainey

Copy link
Copy Markdown

I'll test this out today

@ranj063

ranj063 commented Dec 5, 2018 •

Copy link
Copy Markdown
Collaborator Author

@cujomalainey, Thanks! Are you testing this with v0.6?

@cujomalainey

Copy link
Copy Markdown

I'll cherry-pick this right onto the kernel branch which is still v0.55

@ranj063

ranj063 commented Dec 5, 2018

Copy link
Copy Markdown
Collaborator Author

@cujomalainey this change wasnt added in v0.55. It was added only for v0.6

@cujomalainey

Copy link
Copy Markdown

Noted

For HDA platforms, hda_dsp_ctrl_init_chip() does a full
controller reset. So move the duplicate controller reset
calls that were added for non-HDA platforms into the else block.
This should fix the failures seen with suspend/resume
stress tests on GLK.

Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
@ranj063
ranj063 force-pushed the fix/suspend_stress_test branch from 090b3e3 to ea71772 Compare December 5, 2018 19:30

@plbossart plbossart left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Look good.
I think we should really find a way to disable HDMI in the machine driver so that we can test the two code paths, I am sure we have other cases of this nature.
I'll merge when @cujomalainey confirms that this works (or doesn't harm)

@ranj063

ranj063 commented Dec 5, 2018

Copy link
Copy Markdown
Collaborator Author

@plbossart Thanks! This also fixes the other issue with resume times being 3s long. I've verified that at my end.

We are cross-checking this on all our boards (~10 of them) and it takes 24 hours for the 2500 cycle test to finish. I will notify you when the test completes on all of them.

@cujomalainey

Copy link
Copy Markdown

This will likely take a while as it's an external team that reported the bug and they have the hardware that is repeatedly failing.

@plbossart

Copy link
Copy Markdown
Member

In that case, I am going to merge to make sure our validation folks see this. If there are other issues reported by this 'external team' it'll have to be a new PR

@plbossart
plbossart merged commit 4052ad8 into thesofproject:topic/sof-dev Dec 6, 2018
@ranj063
ranj063 deleted the fix/suspend_stress_test branch March 22, 2019 17:08
oder-chiou pushed a commit to oder-chiou/linux-soundwire that referenced this pull request May 5, 2026
If we get an error while looking up the inode item we'll simply bail
without cleaning up the delayed node.  This results in this style of
warning happening on commit:

  WARNING: CPU: 0 PID: 76403 at fs/btrfs/delayed-inode.c:1365 btrfs_assert_delayed_root_empty+0x5b/0x90
  CPU: 0 PID: 76403 Comm: fsstress Tainted: G        W         5.13.0-rc1+ thesofproject#373
  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014
  RIP: 0010:btrfs_assert_delayed_root_empty+0x5b/0x90
  RSP: 0018:ffffb8bb815a7e50 EFLAGS: 00010286
  RAX: 0000000000000000 RBX: ffff95d6d07e1888 RCX: ffff95d6c0fa3000
  RDX: 0000000000000002 RSI: 000000000029e91c RDI: ffff95d6c0fc8060
  RBP: ffff95d6c0fc8060 R08: 00008d6d701a2c1d R09: 0000000000000000
  R10: ffff95d6d1760ea0 R11: 0000000000000001 R12: ffff95d6c15a4d00
  R13: ffff95d6c0fa3000 R14: 0000000000000000 R15: ffffb8bb815a7e90
  FS:  00007f490e8dbb80(0000) GS:ffff95d73bc00000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 00007f6e75555cb0 CR3: 00000001101ce001 CR4: 0000000000370ef0
  Call Trace:
   btrfs_commit_transaction+0x43c/0xb00
   ? finish_wait+0x80/0x80
   ? vfs_fsync_range+0x90/0x90
   iterate_supers+0x8c/0x100
   ksys_sync+0x50/0x90
   __do_sys_sync+0xa/0x10
   do_syscall_64+0x3d/0x80
   entry_SYSCALL_64_after_hwframe+0x44/0xae

Because the iref isn't dropped and this leaves an elevated node->count,
so any release just re-queues it onto the delayed inodes list.  Fix this
by going to the out label to handle the proper cleanup of the delayed
node.

Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
oder-chiou pushed a commit to oder-chiou/linux-soundwire that referenced this pull request May 5, 2026
Hulk Robot reported a panic in put_page_testzero() when testing
madvise() with MADV_SOFT_OFFLINE.  The BUG() is triggered when retrying
get_any_page().  This is because we keep MF_COUNT_INCREASED flag in
second try but the refcnt is not increased.

    page dumped because: VM_BUG_ON_PAGE(page_ref_count(page) == 0)
    ------------[ cut here ]------------
    kernel BUG at include/linux/mm.h:737!
    invalid opcode: 0000 [thesofproject#1] PREEMPT SMP
    CPU: 5 PID: 2135 Comm: sshd Tainted: G    B             5.16.0-rc6-dirty thesofproject#373
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
    RIP: release_pages+0x53f/0x840
    Call Trace:
      free_pages_and_swap_cache+0x64/0x80
      tlb_flush_mmu+0x6f/0x220
      unmap_page_range+0xe6c/0x12c0
      unmap_single_vma+0x90/0x170
      unmap_vmas+0xc4/0x180
      exit_mmap+0xde/0x3a0
      mmput+0xa3/0x250
      do_exit+0x564/0x1470
      do_group_exit+0x3b/0x100
      __do_sys_exit_group+0x13/0x20
      __x64_sys_exit_group+0x16/0x20
      do_syscall_64+0x34/0x80
      entry_SYSCALL_64_after_hwframe+0x44/0xae
    Modules linked in:
    ---[ end trace e99579b570fe0649 ]---
    RIP: 0010:release_pages+0x53f/0x840

Link: https://lkml.kernel.org/r/20211221074908.3910286-1-liushixin2@huawei.com
Fixes: b94e028 ("mm,hwpoison: try to narrow window race for free pages")
Signed-off-by: Liu Shixin <liushixin2@huawei.com>
Reported-by: Hulk Robot <hulkci@huawei.com>
Reviewed-by: Oscar Salvador <osalvador@suse.de>
Acked-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
oder-chiou pushed a commit to oder-chiou/linux-soundwire that referenced this pull request May 5, 2026
Because srtt and mrtt_us are added as args in bpf_sock_ops at
BPF_SOCK_OPS_RTT_CB, a simple check is added to make sure they are both
non-zero.

$ ./test_progs -t tcp_rtt
  thesofproject#373     tcp_rtt:OK
  Summary: 1/0 PASSED, 0 SKIPPED, 0 FAILED

Suggested-by: Stanislav Fomichev <sdf@google.com>
Signed-off-by: Philo Lu <lulie@linux.alibaba.com>
Link: https://lore.kernel.org/r/20240425161724.73707-3-lulie@linux.alibaba.com
Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants