From: Deren Wu <deren.wu(a)mediatek.com>
Hi,
The bug is found on some devices which power off pcie bus
in suspend mode. In this case, mt7921 would resume fail on
interactive commands. This patch could recover the failure in
command timeout.
Need to apply patches below for dependency. Those patches work
for stability improvment as well.
upstream patches:
commit f92f81d35ac2 ("mt76: mt7921: check mcu returned values in mt7921_start")
commit d32464e68ffc ("mt76: mt7921: introduce mt7921_run_firmware utility routine.")
commit 1f7396acfef4 ("mt76: mt7921: introduce __mt7921_start utility routine")
commit 3990465db682 ("mt76: dma: introduce mt76_dma_queue_reset routine")
commit c001df978e4c ("mt76: dma: export mt76_dma_rx_cleanup routine")
commit 0c1ce9884607 ("mt76: mt7921: add wifi reset support")
commit e513ae49088b ("mt76: mt7921: abort uncompleted scan by wifi reset")
Lorenzo Bianconi (1):
mt76: mt7921: get rid of mcu_reset function pointer
drivers/net/wireless/mediatek/mt76/mt7921/mcu.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--
2.25.1
From: Kan Liang <kan.liang(a)linux.intel.com>
A warning as below may be occasionally triggered in an ADL machine when
these conditions occur,
- Two perf record commands run one by one. Both record a PEBS event.
- Both runs on small cores.
- They have different adaptive PEBS configuration (PEBS_DATA_CFG).
[ 673.663291] WARNING: CPU: 4 PID: 9874 at
arch/x86/events/intel/ds.c:1743
setup_pebs_adaptive_sample_data+0x55e/0x5b0
[ 673.663348] RIP: 0010:setup_pebs_adaptive_sample_data+0x55e/0x5b0
[ 673.663357] Call Trace:
[ 673.663357] <NMI>
[ 673.663357] intel_pmu_drain_pebs_icl+0x48b/0x810
[ 673.663360] perf_event_nmi_handler+0x41/0x80
[ 673.663368] </NMI>
[ 673.663370] __perf_event_task_sched_in+0x2c2/0x3a0
Different from the big core, the small core requires the ACK before
re-enabling counters in the NMI handler, otherwise a stale PEBS record
may be dumped into the later NMI handler, which trigger the warning.
Add late_ack in the struct x86_hybrid_pmu to track the late_ack flag for
different types of PMUs. Apply late ACK only for the big cores on an
Alder Lake machine.
The existing hybrid() macro has a compile error when taking address of a
bit-field variable. Add a new macro hybrid_bit() to get the bit-field
value of a given PMU.
Fixes: f83d2f91d259 ("perf/x86/intel: Add Alder Lake Hybrid support")
Reported-by: Ammy Yi <ammy.yi(a)intel.com>
Reviewed-by: Andi Kleen <ak(a)linux.intel.com>
Signed-off-by: Kan Liang <kan.liang(a)linux.intel.com>
Cc: stable(a)vger.kernel.org
---
arch/x86/events/intel/core.c | 11 +++++------
arch/x86/events/perf_event.h | 12 ++++++++++++
2 files changed, 17 insertions(+), 6 deletions(-)
diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
index a0dfa82..430a24d 100644
--- a/arch/x86/events/intel/core.c
+++ b/arch/x86/events/intel/core.c
@@ -2904,14 +2904,13 @@ static int handle_pmi_common(struct pt_regs *regs, u64 status)
*/
static int intel_pmu_handle_irq(struct pt_regs *regs)
{
- struct cpu_hw_events *cpuc;
+ struct cpu_hw_events *cpuc = this_cpu_ptr(&cpu_hw_events);
+ bool late_ack = hybrid_bit(cpuc->pmu, late_ack);
int loops;
u64 status;
int handled;
int pmu_enabled;
- cpuc = this_cpu_ptr(&cpu_hw_events);
-
/*
* Save the PMU state.
* It needs to be restored when leaving the handler.
@@ -2921,7 +2920,7 @@ static int intel_pmu_handle_irq(struct pt_regs *regs)
* No known reason to not always do late ACK,
* but just in case do it opt-in.
*/
- if (!x86_pmu.late_ack)
+ if (!late_ack)
apic_write(APIC_LVTPC, APIC_DM_NMI);
intel_bts_disable_local();
cpuc->enabled = 0;
@@ -2969,7 +2968,7 @@ static int intel_pmu_handle_irq(struct pt_regs *regs)
* have been reset. This avoids spurious NMIs on
* Haswell CPUs.
*/
- if (x86_pmu.late_ack)
+ if (late_ack)
apic_write(APIC_LVTPC, APIC_DM_NMI);
return handled;
}
@@ -6116,7 +6115,6 @@ __init int intel_pmu_init(void)
static_branch_enable(&perf_is_hybrid);
x86_pmu.num_hybrid_pmus = X86_HYBRID_NUM_PMUS;
- x86_pmu.late_ack = true;
x86_pmu.pebs_aliases = NULL;
x86_pmu.pebs_prec_dist = true;
x86_pmu.pebs_block = true;
@@ -6154,6 +6152,7 @@ __init int intel_pmu_init(void)
pmu = &x86_pmu.hybrid_pmu[X86_HYBRID_PMU_CORE_IDX];
pmu->name = "cpu_core";
pmu->cpu_type = hybrid_big;
+ pmu->late_ack = true;
if (cpu_feature_enabled(X86_FEATURE_HYBRID_CPU)) {
pmu->num_counters = x86_pmu.num_counters + 2;
pmu->num_counters_fixed = x86_pmu.num_counters_fixed + 1;
diff --git a/arch/x86/events/perf_event.h b/arch/x86/events/perf_event.h
index bc8836b..40fa3b1 100644
--- a/arch/x86/events/perf_event.h
+++ b/arch/x86/events/perf_event.h
@@ -656,6 +656,8 @@ struct x86_hybrid_pmu {
struct event_constraint *event_constraints;
struct event_constraint *pebs_constraints;
struct extra_reg *extra_regs;
+
+ unsigned int late_ack:1;
};
static __always_inline struct x86_hybrid_pmu *hybrid_pmu(struct pmu *pmu)
@@ -686,6 +688,16 @@ extern struct static_key_false perf_is_hybrid;
__Fp; \
}))
+#define hybrid_bit(_pmu, _field) \
+({ \
+ bool __Fp = x86_pmu._field; \
+ \
+ if (is_hybrid() && (_pmu)) \
+ __Fp = hybrid_pmu(_pmu)->_field; \
+ \
+ __Fp; \
+})
+
enum hybrid_pmu_type {
hybrid_big = 0x40,
hybrid_small = 0x20,
--
2.7.4
The standard printk() tries to flush the message to the console
immediately. It tries to take the console lock. If the lock is
already taken then the current owner is responsible for flushing
even the new message.
There is a small race window between checking whether a new message is
available and releasing the console lock. It is solved by re-checking
the state after releasing the console lock. If the check is positive
then console_unlock() tries to take the lock again and process the new
message as well.
The commit 996e966640ddea7b535c ("printk: remove logbuf_lock") causes that
console_seq is not longer read atomically. As a result, the re-check might
be done with an inconsistent 64-bit index.
Solve it by using the last sequence number that has been checked under
the console lock. In the worst case, it will take the lock again only
to realized that the new message has already been proceed. But it
was possible even before.
The variable next_seq is marked as __maybe_unused to call down compiler
warning when CONFIG_PRINTK is not defined.
Fixes: commit 996e966640ddea7b535c ("printk: remove logbuf_lock")
Reported-by: kernel test robot <lkp(a)intel.com> # unused next_seq warning
Cc: stable(a)vger.kernel.org # 5.13
Signed-off-by: Petr Mladek <pmladek(a)suse.com>
Acked-by: Sergey Senozhatsky <senozhatsky(a)chromium.org>
---
Changes in v2:
- fixed warning about unused next_seq variable reported by kernel test robot
kernel/printk/printk.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 142a58d124d9..6dad7da8f383 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -2545,6 +2545,7 @@ void console_unlock(void)
bool do_cond_resched, retry;
struct printk_info info;
struct printk_record r;
+ u64 __maybe_unused next_seq;
if (console_suspended) {
up_console_sem();
@@ -2654,8 +2655,10 @@ void console_unlock(void)
cond_resched();
}
- console_locked = 0;
+ /* Get consistent value of the next-to-be-used sequence number. */
+ next_seq = console_seq;
+ console_locked = 0;
up_console_sem();
/*
@@ -2664,7 +2667,7 @@ void console_unlock(void)
* there's a new owner and the console_unlock() from them will do the
* flush, no worries.
*/
- retry = prb_read_valid(prb, console_seq, NULL);
+ retry = prb_read_valid(prb, next_seq, NULL);
printk_safe_exit_irqrestore(flags);
if (retry && console_trylock())
--
2.26.2
"Hello,
We are interested in advertising. We want to advertise guest article
on your site planet.kernel.org. Our article will be written according
to your site theme and will include a link to a betting site.
What is the rate for this?
IMPORTANT: If you are not accepting links to gambling site we might be
still interested, Please mention the rate for regular links as well
Skype: shanker2020
Telegram 9966160005
WhatsApp number: 9966160005
Thank you"