February 2021 - Linux-stable-mirror

[PATCH] Revert "ath: add support for special 0x0 regulatory domain"

by Brian Norris

This reverts commit 2dc016599cfa9672a147528ca26d70c3654a5423. Users are reporting regressions in regulatory domain detection and channel availability. The problem this was trying to resolve was fixed in firmware anyway: QCA6174 hw3.0: sdio-4.4.1: add firmware.bin_WLAN.RMH.4.4.1-00042 https://github.com/kvalo/ath10k-firmware/commit/4d382787f0efa77dba40394e0bc… Link: https://bbs.archlinux.org/viewtopic.php?id=254535 Link: http://lists.infradead.org/pipermail/ath10k/2020-April/014871.html Link: http://lists.infradead.org/pipermail/ath10k/2020-May/015152.html Fixes: 2dc016599cfa ("ath: add support for special 0x0 regulatory domain") Cc: <stable(a)vger.kernel.org> Cc: Wen Gong <wgong(a)codeaurora.org> Signed-off-by: Brian Norris <briannorris(a)chromium.org> --- drivers/net/wireless/ath/regd.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/net/wireless/ath/regd.c b/drivers/net/wireless/ath/regd.c index bee9110b91f3..20f4f8ea9f89 100644 --- a/drivers/net/wireless/ath/regd.c +++ b/drivers/net/wireless/ath/regd.c @@ -666,14 +666,14 @@ ath_regd_init_wiphy(struct ath_regulatory *reg, /* * Some users have reported their EEPROM programmed with - * 0x8000 or 0x0 set, this is not a supported regulatory - * domain but since we have more than one user with it we - * need a solution for them. We default to 0x64, which is - * the default Atheros world regulatory domain. + * 0x8000 set, this is not a supported regulatory domain + * but since we have more than one user with it we need + * a solution for them. We default to 0x64, which is the + * default Atheros world regulatory domain. */ static void ath_regd_sanitize(struct ath_regulatory *reg) { - if (reg->current_rd != COUNTRY_ERD_FLAG && reg->current_rd != 0) + if (reg->current_rd != COUNTRY_ERD_FLAG) return; printk(KERN_DEBUG "ath: EEPROM regdomain sanitized\n"); reg->current_rd = 0x64; -- 2.27.0.rc0.183.gde8f92d652-goog

2 years, 3 months

8
10
0 0

[PATCH 1/2] x86/mpparse: avoid overwriting boot_cpu_physical_apicid

by Kevin Mitchell

When booting with ACPI unavailable or disabled, get_smp_config() ends up calling MP_processor_info() for each CPU found in the MPS table. Previously, this resulted in boot_cpu_physical_apicid getting unconditionally overwritten by the apicid of whatever processor had the CPU_BOOTPROCESSOR flag. This occurred even if boot_cpu_physical_apicid had already been more reliably determined in register_lapic_address() by calling read_apic_id() from the actual boot processor. Ordinariliy, this is not a problem because the boot processor really is the one with the CPU_BOOTPROCESSOR flag. However, kexec is an exception in which the kernel may be booted from any processor regardless of the MPS table contents. In this case, boot_cpu_physical_apicid may not indicate the actual boot processor. This was particularly problematic when the second kernel was booted with NR_CPUS fewer than the number of physical processors. It's the job of generic_processor_info() to decide which CPUs to bring up in this case. That obviously must include the real boot processor which it takes care to save a slot for. It relies upon the contents of boot_cpu_physical_apicid to do this, which if incorrect, may result in the boot processor getting left out. This condition can be discovered by smp_sanity_check() and rectified by adding the boot processor to the phys_cpu_present_map with the warning "weird, boot CPU (#%d) not listed by the BIOS". However, commit 3e730dad3b6da ("x86/apic: Unify interrupt mode setup for SMP-capable system") caused setup_local_APIC() to be called before this could happen resulting in a BUG_ON(!apic->apic_id_registered()): [ 0.655452] ------------[ cut here ]------------ [ 0.660610] Kernel BUG at setup_local_APIC+0x74/0x280 [verbose debug info unavailable] [ 0.669466] invalid opcode: 0000 [#1] SMP [ 0.673948] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.19.109.Ar-16509018.eostrunkkernel419 #1 [ 0.683670] Hardware name: Quanta Quanta LY6 (1LY6UZZ0FBC), BIOS 1.0.6.0-e7d6a55 11/26/2015 [ 0.693007] RIP: 0010:setup_local_APIC+0x74/0x280 [ 0.698264] Code: 80 e4 fe bf f0 00 00 00 89 c6 48 8b 05 0f 1a 8e 00 ff 50 10 e8 12 53 fd ff 48 8b 05 00 1a 8e 00 ff 90 a0 00 00 00 85 c0 75 02 <0f> 0b 48 8b 05 ed 19 8e 00 41 be 00 02 00 00 ff 90 b0 00 00 00 48 [ 0.719251] RSP: 0000:ffffffff81a03e20 EFLAGS: 00010246 [ 0.725091] RAX: 0000000000000000 RBX: 0000000000000003 RCX: 0000000000000000 [ 0.733066] RDX: 0000000000000000 RSI: 000000000000000f RDI: 0000000000000020 [ 0.741041] RBP: ffffffff81a03e98 R08: 0000000000000002 R09: 0000000000000000 [ 0.749014] R10: ffffffff81a204e0 R11: ffffffff81b50ea7 R12: 0000000000000000 [ 0.756989] R13: ffffffff81aef920 R14: ffffffff81af60a0 R15: 0000000000000000 [ 0.764965] FS: 0000000000000000(0000) GS:ffff888036800000(0000) knlGS:0000000000000000 [ 0.774007] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 0.780427] CR2: ffff888035c01000 CR3: 0000000035a08000 CR4: 00000000000006b0 [ 0.788401] Call Trace: [ 0.791137] ? amd_iommu_prepare+0x15/0x2a [ 0.795717] apic_bsp_setup+0x55/0x75 [ 0.799808] apic_intr_mode_init+0x169/0x16e [ 0.804579] x86_late_time_init+0x10/0x17 [ 0.809062] start_kernel+0x37e/0x3fe [ 0.813154] x86_64_start_reservations+0x2a/0x2c [ 0.818316] x86_64_start_kernel+0x72/0x75 [ 0.822886] secondary_startup_64+0xa4/0xb0 [ 0.827564] ---[ end trace 237b64da0fd9b22e ]--- This change avoids these issues by only setting boot_cpu_physical_apicid from the MPS table if it is not already set, which can occur in the construct_default_ISA_mptable() path. Otherwise, boot_cpu_physical_apicid will already have been set in register_lapic_address() and should therefore remain untouched. Looking through all the places where boot_cpu_physical_apicid is accessed, nearly all of them assume that boot_cpu_physical_apicid should match read_apic_id() on the booting processor. The only place that might intend to use the BSP apicid listed in the MPS table is amd_numa_init(), which explicitly requires boot_cpu_physical_apicid to be the lowest apicid of all processors. Ironically, due to the early exit short circuit in early_get_smp_config(), it instead gets boot_cpu_physical_apicid = read_apic_id() rather than the MPS table BSP. The behaviour of amd_numa_init() is therefore unaffected by this change. Fixes: 3e730dad3b6da ("x86/apic: Unify interrupt mode setup for SMP-capable system") Signed-off-by: Kevin Mitchell <kevmitch(a)arista.com> Cc: <stable(a)vger.kernel.org> --- arch/x86/kernel/mpparse.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/x86/kernel/mpparse.c b/arch/x86/kernel/mpparse.c index afac7ccce72f..6f22f09bfe11 100644 --- a/arch/x86/kernel/mpparse.c +++ b/arch/x86/kernel/mpparse.c @@ -64,7 +64,8 @@ static void __init MP_processor_info(struct mpc_cpu *m) if (m->cpuflag & CPU_BOOTPROCESSOR) { bootup_cpu = " (Bootup-CPU)"; - boot_cpu_physical_apicid = m->apicid; + if (boot_cpu_physical_apicid == -1U) + boot_cpu_physical_apicid = m->apicid; } pr_info("Processor #%d%s\n", m->apicid, bootup_cpu); -- 2.26.2

2 years, 7 months

1
1
0 0

[PATCH] mmc: sdhci-xenon: fix 1.8v regulator stabilization

by Marcin Wojtas

From: Alex Leibovich <alexl(a)marvell.com> Automatic Clock Gating is a feature used for the power consumption optimisation. It turned out that during early init phase it may prevent the stable voltage switch to 1.8V - due to that on some platfroms an endless printout in dmesg can be observed: "mmc1: 1.8V regulator output did not became stable" Fix the problem by disabling the ACG at very beginning of the sdhci_init and let that be enabled later. Fixes: 3a3748dba881 ("mmc: sdhci-xenon: Add Marvell Xenon SDHC core functionality") Signed-off-by: Alex Leibovich <alexl(a)marvell.com> Signed-off-by: Marcin Wojtas <mw(a)semihalf.com> Cc: stable(a)vger.kernel.org --- drivers/mmc/host/sdhci-xenon.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/mmc/host/sdhci-xenon.c b/drivers/mmc/host/sdhci-xenon.c index c67611fdaa8a..4b05f6fdefb4 100644 --- a/drivers/mmc/host/sdhci-xenon.c +++ b/drivers/mmc/host/sdhci-xenon.c @@ -168,7 +168,12 @@ static void xenon_reset_exit(struct sdhci_host *host, /* Disable tuning request and auto-retuning again */ xenon_retune_setup(host); - xenon_set_acg(host, true); + /* + * The ACG should be turned off at the early init time, in order + * to solve a possile issues with the 1.8V regulator stabilization. + * The feature is enabled in later stage. + */ + xenon_set_acg(host, false); xenon_set_sdclk_off_idle(host, sdhc_id, false); -- 2.29.0

2 years, 9 months

4
10
0 0

[PATCH v3] drm/ast: Don't check new mode if CRTC is being disabled

by Thomas Zimmermann

Suspending failed because there's no mode if the CRTC is being disabled. Early-out in this case. This fixes runtime PM for ast. v3: * fixed commit message v2: * added Tested-by/Reported-by tags * added Fixes tags and CC (Sam) * improved comment Signed-off-by: Thomas Zimmermann <tzimmermann(a)suse.de> Reported-by: Cary Garrett <cogarre(a)gmail.com> Tested-by: Cary Garrett <cogarre(a)gmail.com> Fixes: b48e1b6ffd28 ("drm/ast: Add CRTC helpers for atomic modesetting") Cc: Thomas Zimmermann <tzimmermann(a)suse.de> Cc: Gerd Hoffmann <kraxel(a)redhat.com> Cc: Dave Airlie <airlied(a)redhat.com> Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch> Cc: Sam Ravnborg <sam(a)ravnborg.org> Cc: <stable(a)vger.kernel.org> # v5.6+ --- drivers/gpu/drm/ast/ast_mode.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c index 7a9f20a2fd303..0cbbb21edb4e1 100644 --- a/drivers/gpu/drm/ast/ast_mode.c +++ b/drivers/gpu/drm/ast/ast_mode.c @@ -801,6 +801,9 @@ static int ast_crtc_helper_atomic_check(struct drm_crtc *crtc, return -EINVAL; } + if (!state->enable) + return 0; /* no mode checks if CRTC is being disabled */ + ast_state = to_ast_crtc_state(state); format = ast_state->format; -- 2.26.0

2 years, 11 months

3
3
0 0

[PATCH v2 07/17] irqchip/gic: Atomically update affinity

by Marc Zyngier

The GIC driver uses a RMW sequence to update the affinity, and relies on the gic_lock_irqsave/gic_unlock_irqrestore sequences to update it atomically. But these sequences only expend into anything meaningful if the BL_SWITCHER option is selected, which almost never happens. It also turns out that using a RMW and locks is just as silly, as the GIC distributor supports byte accesses for the GICD_TARGETRn registers, which when used make the update atomic by definition. Drop the terminally broken code and replace it by a byte write. Fixes: 04c8b0f82c7d ("irqchip/gic: Make locking a BL_SWITCHER only feature") Cc: stable(a)vger.kernel.org Signed-off-by: Marc Zyngier <maz(a)kernel.org> --- drivers/irqchip/irq-gic.c | 14 +++----------- 1 file changed, 3 insertions(+), 11 deletions(-) diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c index 00de05abd3c3..c17fabd6741e 100644 --- a/drivers/irqchip/irq-gic.c +++ b/drivers/irqchip/irq-gic.c @@ -329,10 +329,8 @@ static int gic_irq_set_vcpu_affinity(struct irq_data *d, void *vcpu) static int gic_set_affinity(struct irq_data *d, const struct cpumask *mask_val, bool force) { - void __iomem *reg = gic_dist_base(d) + GIC_DIST_TARGET + (gic_irq(d) & ~3); - unsigned int cpu, shift = (gic_irq(d) % 4) * 8; - u32 val, mask, bit; - unsigned long flags; + void __iomem *reg = gic_dist_base(d) + GIC_DIST_TARGET + gic_irq(d); + unsigned int cpu; if (!force) cpu = cpumask_any_and(mask_val, cpu_online_mask); @@ -342,13 +340,7 @@ static int gic_set_affinity(struct irq_data *d, const struct cpumask *mask_val, if (cpu >= NR_GIC_CPU_IF || cpu >= nr_cpu_ids) return -EINVAL; - gic_lock_irqsave(flags); - mask = 0xff << shift; - bit = gic_cpu_map[cpu] << shift; - val = readl_relaxed(reg) & ~mask; - writel_relaxed(val | bit, reg); - gic_unlock_irqrestore(flags); - + writeb_relaxed(gic_cpu_map[cpu], reg); irq_data_update_effective_affinity(d, cpumask_of(cpu)); return IRQ_SET_MASK_OK_DONE; -- 2.27.0

3 years, 3 months

5
11
0 0

[PATCH 1/4] cputime, cpuacct: Include guest time in user time in cpuacct.stat

by Andrey Ryabinin

cpuacct.stat in no-root cgroups shows user time without guest time included int it. This doesn't match with user time shown in root cpuacct.stat and /proc/<pid>/stat. Make account_guest_time() to add user time to cgroup's cpustat to fix this. Fixes: ef12fefabf94 ("cpuacct: add per-cgroup utime/stime statistics") Signed-off-by: Andrey Ryabinin <arbn(a)yandex-team.com> Cc: <stable(a)vger.kernel.org> --- kernel/sched/cputime.c | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/kernel/sched/cputime.c b/kernel/sched/cputime.c index 5f611658eeab..95a9c5603d29 100644 --- a/kernel/sched/cputime.c +++ b/kernel/sched/cputime.c @@ -139,8 +139,6 @@ void account_user_time(struct task_struct *p, u64 cputime) */ void account_guest_time(struct task_struct *p, u64 cputime) { - u64 *cpustat = kcpustat_this_cpu->cpustat; - /* Add guest time to process. */ p->utime += cputime; account_group_user_time(p, cputime); @@ -148,11 +146,11 @@ void account_guest_time(struct task_struct *p, u64 cputime) /* Add guest time to cpustat. */ if (task_nice(p) > 0) { - cpustat[CPUTIME_NICE] += cputime; - cpustat[CPUTIME_GUEST_NICE] += cputime; + task_group_account_field(p, CPUTIME_NICE, cputime); + task_group_account_field(p, CPUTIME_GUEST_NICE, cputime); } else { - cpustat[CPUTIME_USER] += cputime; - cpustat[CPUTIME_GUEST] += cputime; + task_group_account_field(p, CPUTIME_USER, cputime); + task_group_account_field(p, CPUTIME_GUEST, cputime); } } -- 2.26.2

3 years, 3 months

3
12
0 0

Re: System crash on Ubuntu 18, in netlink code when using iptables / netfilter

by Florian Westphal

Yuri Lipnesh <yuri.lipnesh(a)gmail.com> wrote: > Linux system crashed > > [ 0.000000] Linux version 5.4.0-54-generic (buildd@lcy01-amd64-008) (gcc version 7.5.0 (Ubuntu 7.5.0-3ubuntu1~18.04)) #60~18.04.1-Ubuntu SMP Fri Nov 6 17:25:16 UTC 2020 (Ubuntu 5.4.0-54.60~18.04.1-generic 5.4.65) > [ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-5.4.0-54-generic root=UUID=11885fd3-b840-4c9b-a500-532c73ac952a ro find_preseed=/preseed.cfg auto noprompt priority=critical locale=en_US quiet crashkernel=512M-:192M > > … > [ 156.321147] TCP: eth0: Driver has suspect GRO implementation, TCP performance may be compromised. > [ 177.519159] general protection fault: 0000 [#1] SMP PTI > [ 177.519737] CPU: 5 PID: 18484 Comm: worker-1 Kdump: loaded Not tainted 5.4.0-54-generic #60~18.04.1-Ubuntu > [ 177.519742] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 02/27/2020 > [ 177.519814] RIP: 0010:dev_hard_start_xmit+0x38/0x200 > [ 177.519827] Code: 55 41 54 53 48 83 ec 20 48 85 ff 48 89 55 c8 48 89 4d b8 0f 84 c1 01 00 00 48 8d 86 90 00 00 00 48 89 fb 49 89 f4 48 89 45 c0 <4c> 8b 2b 48 c7 c0 d0 f2 04 8f 48 c7 03 00 00 00 00 48 8b 00 4d 85 > [ 177.519829] RSP: 0018:ffffbc6d0609b5e8 EFLAGS: 00010286 > [ 177.519833] RAX: 0000000000000000 RBX: dead000000000100 RCX: ffff95cf4bcfe800 > [ 177.519835] RDX: 0000000000000000 RSI: ffff95cf4bcfe800 RDI: 0000000000000286 > [ 177.519837] RBP: ffffbc6d0609b630 R08: ffff95cf6a190ec8 R09: ffff95cf4a2f7438 > [ 177.519839] R10: ffffbc6d0609b6d0 R11: ffff95cf49d4d180 R12: ffff95cf51a5f000 > [ 177.519841] R13: dead000000000100 R14: 000000000000009c R15: ffff95d02996b400 > [ 177.519844] FS: 00007ff394cdfb20(0000) GS:ffff95d035d40000(0000) knlGS:0000000000000000 > [ 177.519846] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [ 177.519848] CR2: 00007fb4a9c2d000 CR3: 00000001049fa004 CR4: 00000000003606e0 > [ 177.519908] Call Trace: > [ 177.519917] __dev_queue_xmit+0x719/0x920 > [ 177.519930] ? ctnetlink_conntrack_event+0x8c/0x5e0 [nf_conntrack_netlink] Can you reproduce this on 5.7 or later, or with following patches backported to 5.4.y? dd3cc111f2e3220ddc9c4ab17f13dc97759b5163 119e52e664c57d5f7c0174dc2b3a296b1e40591d af370ab36fcd19f04e3408c402608e7e56e6f188 28f715b9e6dd7cbf07c2aea913fea7c87a56a3b5 The series fixed nfqueue reference counting.

3 years, 3 months

2
3
0 0

Re: [REGRESSION] "ALSA: HDA: Early Forbid of runtime PM" broke my laptop's internal audio

by Takashi Iwai

On Fri, 29 Jan 2021 17:12:08 +0100, Michael Catanzaro wrote: > > On Fri, Jan 29, 2021 at 9:30 am, Michael Catanzaro > <mcatanzaro(a)redhat.com> wrote: > > OK, I found "ALSA: hda/via: Apply the workaround generically for > > Clevo machines" which was just merged yesterday. So I will test > > again to find out. > > Hi Takashi, hi Harsha, > > I can confirm that the problem is fixed by this commit: > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… Thanks, good to hear. Then I think we can drop the entry from power_save_denylist in hda_intel.c. Could you try that it still works with the patch below? thanks, Takashi --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -2217,8 +2217,6 @@ static const struct snd_pci_quirk power_save_denylist[] = { /* https://bugzilla.redhat.com/show_bug.cgi?id=1525104 */ SND_PCI_QUIRK(0x1043, 0x8733, "Asus Prime X370-Pro", 0), /* https://bugzilla.redhat.com/show_bug.cgi?id=1525104 */ - SND_PCI_QUIRK(0x1558, 0x6504, "Clevo W65_67SB", 0), - /* https://bugzilla.redhat.com/show_bug.cgi?id=1525104 */ SND_PCI_QUIRK(0x1028, 0x0497, "Dell Precision T3600", 0), /* https://bugzilla.redhat.com/show_bug.cgi?id=1525104 */ /* Note the P55A-UD3 and Z87-D3HP share the subsys id for the HDA dev */

3 years, 4 months

3
6
0 0

Re: [PATCH v2 11/12] mac80211: drop data frames without key on encrypted links

by Sasha Levin

Hi [This is an automated email] This commit has been processed because it contains a -stable tag. The stable tag indicates that it's relevant for the following trees: all The bot has tested the following trees: v5.5.11, v5.4.27, v4.19.112, v4.14.174, v4.9.217, v4.4.217. v5.5.11: Build OK! v5.4.27: Build OK! v4.19.112: Failed to apply! Possible dependencies: 03512ceb60ae ("ieee80211: remove redundant leading zeroes") 09b4a4faf9d0 ("mac80211: introduce capability flags for VHT EXT NSS support") 0eeb2b674f05 ("mac80211: add an option for station management TXQ") 1c9559734eca ("mac80211: remove unnecessary key condition") 57a3a454f303 ("iwlwifi: split HE capabilities between AP and STA") 62872a9b9a10 ("mac80211: Fix PTK rekey freezes and clear text leak") 77f7ffdc335d ("mac80211: minstrel_ht: add flag to indicate missing/inaccurate tx A-MPDU length") 77ff2c6b4984 ("mac80211: update HE IEs to D3.3") 80aaa9c16415 ("mac80211: Add he_capa debugfs entry") 96fc6efb9ad9 ("mac80211: IEEE 802.11 Extended Key ID support") add7453ad62f ("wireless: align to draft 11ax D3.0") adf8ed01e4fd ("mac80211: add an optional TXQ for other PS-buffered frames") caf56338c22f ("mac80211: indicate support for multiple BSSID") daa5b83513a7 ("mac80211: update HE operation fields to D3.0") v4.14.174: Failed to apply! Possible dependencies: 110b32f065f3 ("iwlwifi: mvm: rs: add basic implementation of the new RS API handlers") 1c73acf58bd6 ("iwlwifi: acpi: move ACPI method definitions to acpi.h") 28e9c00fe1f0 ("iwlwifi: remove upper case letters in sku_capa_band_*_enable") 4ae80f6c8d86 ("iwlwifi: support api ver2 of NVM_GET_INFO resp") 4b82455ca51e ("iwlwifi: use flags to denote modifiers for the channel maps") 4c625c564ba2 ("iwlwifi: get rid of fw/nvm.c") 514c30696fbc ("iwlwifi: add support for IEEE802.11ax") 57a3a454f303 ("iwlwifi: split HE capabilities between AP and STA") 77ff2c6b4984 ("mac80211: update HE IEs to D3.3") 813df5cef3bb ("iwlwifi: acpi: add common code to read from ACPI") 8a6171a7b601 ("iwlwifi: fw: add FW APIs for HE") 9c4f7d512740 ("iwlwifi: move all NVM parsing code to the common files") 9f66a397c877 ("iwlwifi: mvm: rs: add ops for the new rate scaling in the FW") e7a3b8d87910 ("iwlwifi: acpi: move ACPI-related definitions to acpi.h") v4.9.217: Failed to apply! Possible dependencies: 01796ff2fa6e ("iwlwifi: mvm: always free inactive queue when moving ownership") 0aaece81114e ("iwlwifi: split firmware API from iwl-trans.h") 1ea423b0e047 ("iwlwifi: remove unnecessary dev_cmd_headroom parameter") 310181ec34e2 ("iwlwifi: move to TVQM mode") 5594d80e9bf4 ("iwlwifi: support two phys for a000 devices") 623e7766be90 ("iwlwifi: pcie: introduce split point to a000 devices") 65e254821cee ("iwlwifi: mvm: use firmware station PM notification for AP_LINK_PS") 6b35ff91572f ("iwlwifi: pcie: introduce a000 TX queues management") 727c02dfb848 ("iwlwifi: pcie: cleanup rfkill checks") 77ff2c6b4984 ("mac80211: update HE IEs to D3.3") 8236f7db2724 ("iwlwifi: mvm: assign cab queue to the correct station") 87d0e1af9db3 ("iwlwifi: mvm: separate queue mapping from queue enablement") bb49701b41de ("iwlwifi: mvm: support a000 SCD queue configuration") cf90da352a32 ("iwlwifi: mvm: use mvm_disable_queue instead of sharing logic") d172a5eff629 ("iwlwifi: reorganize firmware API") df88c08d5c7e ("iwlwifi: mvm: release static queues on bcast release") eda50cde58de ("iwlwifi: pcie: add context information support") v4.4.217: Failed to apply! Possible dependencies: 0aaece81114e ("iwlwifi: split firmware API from iwl-trans.h") 13555e8ba2f4 ("iwlwifi: mvm: add 9000-series RX API") 1a616dd2f171 ("iwlwifi: dump prph registers in a common place for all transports") 1e0bbebaae66 ("mac80211: enable starting BA session with custom timeout") 2f89a5d7d377 ("iwlwifi: mvm: move fw-dbg code to separate file") 39bdb17ebb5b ("iwlwifi: update host command messages to new format") 41837ca962ec ("iwlwifi: pcie: allow to pretend to have Tx CSUM for debug") 4707fde5cdef ("iwlwifi: mvm: use build-time assertion for fw trigger ID") 5b88792cd850 ("iwlwifi: move to wide ID for all commands") 6c4fbcbc1c95 ("iwlwifi: add support for 12K Receive Buffers") 77ff2c6b4984 ("mac80211: update HE IEs to D3.3") 92fe83430b89 ("iwlwifi: uninline iwl_trans_send_cmd") d172a5eff629 ("iwlwifi: reorganize firmware API") dcbb4746286a ("iwlwifi: trans: support a callback for ASYNC commands") NOTE: The patch will not be queued to stable trees until it is upstream. How should we proceed with this patch? -- Thanks Sasha

3 years, 4 months

5
8
0 0

Re: [PATCH v3] sched/fair: fix unthrottle_cfs_rq for leaf_cfs_rq list

by Vincent Guittot

On Thu, 19 Nov 2020 at 01:36, Tao Zhou <t1zhou(a)163.com> wrote: > > On Thu, Nov 19, 2020 at 07:50:15AM +0800, Tao Zhou wrote: > > On Wed, Nov 18, 2020 at 07:56:38PM -0300, Guilherme G. Piccoli wrote: > > > Hi Vincent (and all CCed), I'm sorry to ping about such "old" patch, but > > > we experienced a similar condition to what this patch addresses; it's an > > > older kernel (4.15.x) but when suggesting the users to move to an > > > updated 5.4.x kernel, we noticed that this patch is not there, although > > > similar ones are (like [0] and [1]). > > > > > > So, I'd like to ask if there's any particular reason to not backport > > > this fix to stable kernels, specially the longterm 5.4. The main reason > > > behind the question is that the code is very complex for non-experienced > > > scheduler developers, and I'm afraid in suggesting such backport to 5.4 > > > and introduce complex-to-debug issues. > > > > > > Let me know your thoughts Vincent (and all CCed), thanks in advance. > > > Cheers, > > > > > > > > > Guilherme > > > > > > > > > P.S. For those that deleted this thread from the email client, here's a > > > link: > > > https://lore.kernel.org/lkml/20200513135528.4742-1-vincent.guittot@linaro.o… > > > > > > > > > [0] > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… > > > > > > [1] > > > https://lore.kernel.org/lkml/20200506141821.GA9773@lorien.usersys.redhat.co… > > > <- great thread BTW! > > > > 'sched/fair: Fix unthrottle_cfs_rq() for leaf_cfs_rq list" failed to apply to > > 5.4-stable tree' > > > > You could check above. But I do not have the link about this. Can't search it > > on LKML web: https://lore.kernel.org/lkml/ > > > > BTW: 'ouwen210(a)hotmail.com' and 'zohooouoto(a)zoho.com.cn' all is myself. > > > > Sorry for the confusing.. > > > > Thanks. > > Sorry again. I forget something. It is in the stable. > > Here it is: > > https://lore.kernel.org/stable/159041776924279@kroah.com/ I think it has never been applied to stable. As you mentioned, the backport has been sent : https://lore.kernel.org/stable/20200525172709.GB7427@vingu-book/ I received another emailed in September and pointed out to the backport : https://www.spinics.net/lists/stable/msg410445.html >

3 years, 6 months

4
5
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror February 2021