Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[5.4.y] Odroid-N2: USB did not work stable #396

Open
pvizeli opened this issue May 4, 2020 · 3 comments
Open

[5.4.y] Odroid-N2: USB did not work stable #396

pvizeli opened this issue May 4, 2020 · 3 comments

Comments

@pvizeli
Copy link

pvizeli commented May 4, 2020

If I start to add 2 USB device (i.e. zwave & zigbee) which are serial devices, the blue light start to going blink faster and the device going to be unstable. Without a plugin USB device, everything work fine. This is not happens with upstream 5.4 kernel.
@pvizeli
Copy link
Author

pvizeli commented May 5, 2020 •
edited
Loading

With 5.4.32 it worked stable -> 40b58dc
Maybe the new pci device-tree changes? Also sdcards have issues with latest 5.4.35 update. But only N2, C2 and XU4 works fine

@pvizeli
Copy link
Author

pvizeli commented May 25, 2020

Fix on latest commit

@pvizeli pvizeli closed this as completed May 25, 2020
@pvizeli pvizeli reopened this May 27, 2020
@pvizeli
Copy link
Author

pvizeli commented May 27, 2020 •
edited
Loading

I fix the issue with revert the thermal patches:
home-assistant/operating-system@0db61e8

Aka:

Currently, no clue what the issue is. Some users report HDMI issues other issues with USB. That patch fixes it. Special is, that not all devices are affected in the same way.

My patch with the latest 5.4 odroid branch (today) works on all our N2.

mdrjr pushed a commit that referenced this issue Dec 9, 2021
@vittyvk @gregkh
x86/hyperv: Protect set_hv_tscchange_cb() against getting preempted
7324419 
[ Upstream commit 285f68a ]

The following issue is observed with CONFIG_DEBUG_PREEMPT when KVM loads:

 KVM: vmx: using Hyper-V Enlightened VMCS
 BUG: using smp_processor_id() in preemptible [00000000] code: systemd-udevd/488
 caller is set_hv_tscchange_cb+0x16/0x80
 CPU: 1 PID: 488 Comm: systemd-udevd Not tainted 5.15.0-rc5+ #396
 Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.0 12/17/2019
 Call Trace:
  dump_stack_lvl+0x6a/0x9a
  check_preemption_disabled+0xde/0xe0
  ? kvm_gen_update_masterclock+0xd0/0xd0 [kvm]
  set_hv_tscchange_cb+0x16/0x80
  kvm_arch_init+0x23f/0x290 [kvm]
  kvm_init+0x30/0x310 [kvm]
  vmx_init+0xaf/0x134 [kvm_intel]
  ...

set_hv_tscchange_cb() can get preempted in between acquiring
smp_processor_id() and writing to HV_X64_MSR_REENLIGHTENMENT_CONTROL. This
is not an issue by itself: HV_X64_MSR_REENLIGHTENMENT_CONTROL is a
partition-wide MSR and it doesn't matter which particular CPU will be
used to receive reenlightenment notifications. The only real problem can
(in theory) be observed if the CPU whose id was acquired with
smp_processor_id() goes offline before we manage to write to the MSR,
the logic in hv_cpu_die() won't be able to reassign it correctly.

Reported-by: Michael Kelley <[email protected]>
Signed-off-by: Vitaly Kuznetsov <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Wei Liu <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@pvizeli