mailweb.openeuler.org
Manage this list

Keyboard Shortcuts

Thread View

  • j: Next unread message
  • k: Previous unread message
  • j a: Jump to all threads
  • j l: Jump to MailingList overview

Linuxarm

Threads by month
  • ----- 2025 -----
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2024 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2023 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2022 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2021 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2020 -----
  • December
linuxarm@openeuler.org

  • 1 participants
  • 803 discussions
[PATCH] percpu: set the pointer to NULL after free the memory in free_percpu
by Tian Tao 28 Jan '21

28 Jan '21
set the pointer to NULL after free the memory in free_percpu, so there is no need to set the pointer to NULL in the driver after calling free_percpu again. Signed-off-by: Tian Tao <tiantao6(a)hisilicon.com> --- mm/percpu.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/mm/percpu.c b/mm/percpu.c index f53b89b..af944cc 100644 --- a/mm/percpu.c +++ b/mm/percpu.c @@ -2121,6 +2121,8 @@ void free_percpu(void __percpu *ptr) if (need_balance) pcpu_schedule_balance_work(); + + ptr = NULL; } EXPORT_SYMBOL_GPL(free_percpu); -- 2.7.4
2 1
0 0
[PATCH RESEND] dma-mapping: benchmark: fix kernel crash when dma_map_single fails
by Barry Song 28 Jan '21

28 Jan '21
if dma_map_single() fails, kernel will give the below oops since task_struct has been destroyed and we are running into the memory corruption due to use-after-free in kthread_stop(): [ 48.095310] Unable to handle kernel paging request at virtual address 000000c473548040 [ 48.095736] Mem abort info: [ 48.095864] ESR = 0x96000004 [ 48.096025] EC = 0x25: DABT (current EL), IL = 32 bits [ 48.096268] SET = 0, FnV = 0 [ 48.096401] EA = 0, S1PTW = 0 [ 48.096538] Data abort info: [ 48.096659] ISV = 0, ISS = 0x00000004 [ 48.096820] CM = 0, WnR = 0 [ 48.097079] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000104639000 [ 48.098099] [000000c473548040] pgd=0000000000000000, p4d=0000000000000000 [ 48.098832] Internal error: Oops: 96000004 [#1] PREEMPT SMP [ 48.099232] Modules linked in: [ 48.099387] CPU: 0 PID: 2 Comm: kthreadd Tainted: G W [ 48.099887] Hardware name: linux,dummy-virt (DT) [ 48.100078] pstate: 60000005 (nZCv daif -PAN -UAO -TCO BTYPE=--) [ 48.100516] pc : __kmalloc_node+0x214/0x368 [ 48.100944] lr : __kmalloc_node+0x1f4/0x368 [ 48.101458] sp : ffff800011f0bb80 [ 48.101843] x29: ffff800011f0bb80 x28: ffff0000c0098ec0 [ 48.102330] x27: 0000000000000000 x26: 00000000001d4600 [ 48.102648] x25: ffff0000c0098ec0 x24: ffff800011b6a000 [ 48.102988] x23: 00000000ffffffff x22: ffff0000c0098ec0 [ 48.103333] x21: ffff8000101d7a54 x20: 0000000000000dc0 [ 48.103657] x19: ffff0000c0001e00 x18: 0000000000000000 [ 48.104069] x17: 0000000000000000 x16: 0000000000000000 [ 48.105449] x15: 000001aa0304e7b9 x14: 00000000000003b1 [ 48.106401] x13: ffff8000122d5000 x12: ffff80001228d000 [ 48.107296] x11: ffff0000c0154340 x10: 0000000000000000 [ 48.107862] x9 : ffff80000fffffff x8 : ffff0000c473527f [ 48.108326] x7 : ffff800011e62f58 x6 : ffff0000c01c8ed8 [ 48.108778] x5 : ffff0000c0098ec0 x4 : 0000000000000000 [ 48.109223] x3 : 00000000001d4600 x2 : 0000000000000040 [ 48.109656] x1 : 0000000000000001 x0 : ff0000c473548000 [ 48.110104] Call trace: [ 48.110287] __kmalloc_node+0x214/0x368 [ 48.110493] __vmalloc_node_range+0xc4/0x298 [ 48.110805] copy_process+0x2c8/0x15c8 [ 48.111133] kernel_clone+0x5c/0x3c0 [ 48.111373] kernel_thread+0x64/0x90 [ 48.111604] kthreadd+0x158/0x368 [ 48.111810] ret_from_fork+0x10/0x30 [ 48.112336] Code: 17ffffe9 b9402a62 b94008a1 11000421 (f8626802) [ 48.112884] ---[ end trace d4890e21e75419d5 ]--- Signed-off-by: Barry Song <song.bao.hua(a)hisilicon.com> --- kernel/dma/map_benchmark.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/kernel/dma/map_benchmark.c b/kernel/dma/map_benchmark.c index b1496e744c68..1b1b8ff875cb 100644 --- a/kernel/dma/map_benchmark.c +++ b/kernel/dma/map_benchmark.c @@ -147,8 +147,10 @@ static int do_map_benchmark(struct map_benchmark_data *map) atomic64_set(&map->sum_sq_unmap, 0); atomic64_set(&map->loops, 0); - for (i = 0; i < threads; i++) + for (i = 0; i < threads; i++) { + get_task_struct(tsk[i]); wake_up_process(tsk[i]); + } msleep_interruptible(map->bparam.seconds * 1000); @@ -183,6 +185,8 @@ static int do_map_benchmark(struct map_benchmark_data *map) } out: + for (i = 0; i < threads; i++) + put_task_struct(tsk[i]); put_device(map->dev); kfree(tsk); return ret; -- 2.25.1
2 1
0 0
[PATCH RFC 0/4] Fix arm64 crash for accessing unmapped IO port regions (reboot)
by John Garry 27 Jan '21

27 Jan '21
This is a reboot of my original series to address the problem of drivers for legacy ISA devices accessing unmapped IO port regions on arm64 systems and causing the system to crash. There was another recent report of such an issue [0], and some old ones [1] and [2] for reference. The background is that many systems do not include PCI host controllers, or they do and controller probe may have failed. For these cases, no IO ports are mapped. However, loading drivers for legacy ISA devices can crash the system as there is nothing to stop them accessing those IO ports (which have not been io remap'ed). My original solution tried to keep the kernel alive in these situations by rejecting logical PIO access to PCI IO regions until PCI IO port regions have been mapped. This series goes one step further, by just reserving the complete legacy IO port range in 0x0--0xffff for arm64. The motivation for doing this is to make the request_region() calls for those drivers fail, like this: root@ubuntu:/home/john# insmod mk712.ko [ 3415.575800] mk712: unable to get IO region insmod: ERROR: could not insert module mk712.ko: No such device Otherwise, in theory, those drivers could initiate rogue accesses to mapped IO port regions for other devices and cause corruptions or side-effects. Indeed, those drivers should not be allowed to access IO ports at all in such a system. As a secondary defence, for broken drivers who do not call request_region(), IO port accesses in range 0--0xffff will be ignored, again preserving the system. I am sending as an RFC as I am not sure of any problem with reserving first 0x10000 of IO space like this. There is reserve= commandline argument, which does allow this already. For reference, here's how /proc/ioports looks on my arm64 system with this change: root@ubuntu:/home/john# more /proc/ioports 00010000-0001ffff : PCI Bus 0002:f8 00010000-00010fff : PCI Bus 0002:f9 00010000-00010007 : 0002:f9:00.0 00010000-00010007 : serial 00010008-0001000f : 0002:f9:00.1 00010008-0001000f : serial 00010010-00010017 : 0002:f9:00.2 00010018-0001001f : 0002:f9:00.2 00020000-0002ffff : PCI Bus 0004:88 00030000-0003ffff : PCI Bus 0005:78 00040000-0004ffff : PCI Bus 0006:c0 00050000-0005ffff : PCI Bus 0007:90 00060000-0006ffff : PCI Bus 000a:10 00070000-0007ffff : PCI Bus 000c:20 00080000-0008ffff : PCI Bus 000d:30 [0] https://lore.kernel.org/linux-input/20210112055129.7840-1-song.bao.hua@hisi… [1] https://lore.kernel.org/linux-pci/56F209A9.4040304@huawei.com [2] https://lore.kernel.org/linux-arm-kernel/e6995b4a-184a-d8d4-f4d4-9ce75d8f47… Difference since v4: https://lore.kernel.org/linux-pci/1560262374-67875-1-git-send-email-john.ga… - Reserve legacy ISA region John Garry (4): arm64: io: Introduce IO_SPACE_BASE asm-generic/io.h: Add IO_SPACE_BASE kernel/resource: Make ioport_resource.start configurable logic_pio: Warn on and discard accesses to addresses below IO_SPACE_BASE arch/arm64/include/asm/io.h | 1 + include/asm-generic/io.h | 4 ++++ include/linux/logic_pio.h | 5 +++++ kernel/resource.c | 2 +- lib/logic_pio.c | 20 ++++++++++++++------ 5 files changed, 25 insertions(+), 7 deletions(-) -- 2.26.2
3 8
0 0
[PATCH v2 0/2] EDAC/ghes: Add EDAC device for reporting the CPU cache error count
by Shiju Jose 26 Jan '21

26 Jan '21
CPU cache corrected errors are detected occasionally on few of our ARM64 hardware boards. Though it is rare, the probability of the CPU cache errors frequently occurring can't be avoided. The earlier failure detection by monitoring the cache corrected errors for the frequent occurrences and taking preventive action could prevent more serious hardware faults. On Intel architectures, cache corrected errors are reported and the affected cores are offlined in the architecture specific method. http://www.mcelog.org/cache.html However for the firmware-first error reporting, specifically on ARM64 architectures, there is no provision present for reporting the cache corrected error count to the user-space and taking preventive action such as offline the affected cores. For this purpose, it was suggested to create the CPU EDAC device for the CPU caches for reporting the cache error count for the firmware-first error reporting. User-space application could monitor the recorded corrected error count for the earlier hardware failure detection and could take preventive action, such as offline the corresponding CPU core/s. Changes: RFC V1 -> RFC V2: 1. Fixed feedback by Boris. 1.1. Added reason of this patch. 1.2. Changed CPU errors to CPU cache errors in the drivers/edac/Kconfig 1.3 Changed EDAC cache list to percpu variables. 1.4 Changed configuration depends on ARM64. 1.5. Moved discovery of cacheinfo to ghes_scan_system(). 2. Changes in the descriptions. Shiju Jose (2): EDAC/ghes: Add EDAC device for reporting the CPU cache errors ACPI / APEI: Add reporting ARM64 CPU cache corrected error count Documentation/ABI/testing/sysfs-devices-edac | 15 ++ drivers/acpi/apei/ghes.c | 76 +++++++- drivers/edac/Kconfig | 12 ++ drivers/edac/ghes_edac.c | 186 +++++++++++++++++++ include/acpi/ghes.h | 27 +++ include/linux/cper.h | 4 + 6 files changed, 316 insertions(+), 4 deletions(-) -- 2.17.1
1 2
0 0
[PATCH] percpu: set the pointer to NULL after free the memory in free_percpu
by Tian Tao 26 Jan '21

26 Jan '21
set the pointer to NULL after free the memory in free_percpu, so there is no need to set the pointer to NULL in the driver after calling free_percpu again. Signed-off-by: Tian Tao <tiantao6(a)hisilicon.com> --- mm/percpu.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/mm/percpu.c b/mm/percpu.c index f53b89b..af944cc 100644 --- a/mm/percpu.c +++ b/mm/percpu.c @@ -2121,6 +2121,8 @@ void free_percpu(void __percpu *ptr) if (need_balance) pcpu_schedule_balance_work(); + + ptr = NULL; } EXPORT_SYMBOL_GPL(free_percpu); -- 2.7.4
1 0
0 0
[GIT PULL] arm64: dts: hisilicon dts updates for v5.12
by Wei Xu 26 Jan '21

26 Jan '21
Hi ARM-SoC team, Please consider to pull the following changes. Thanks! Best Regards, Wei --- The following changes since commit 5c8fe583cce542aa0b84adc939ce85293de36e5e: Linux 5.11-rc1 (2020-12-27 15:30:22 -0800) are available in the git repository at: git://github.com/hisilicon/linux-hisi.git tags/hisi-arm64-dt-for-5.12 for you to fetch changes up to 9091f9b9d2965983ee38dd68609002daeacf5199: arm64: dts: hisilicon: hi3670.dtsi: add I2C settings (2021-01-26 15:48:22 +0800) ---------------------------------------------------------------- ARM64: DT: Hisilicon ARM64 DT updates for 5.12 - Further cleanups of the hisilicon DTS to align with the dtschema - Add or update the I2C, pinctrl and reset nodes for Hikey970 ---------------------------------------------------------------- Mauro Carvalho Chehab (3): arm64: dts: hisilicon: hi3670.dtsi: add iomcu_rst arm64: dts: hisilicon: hikey970-pinctrl.dtsi: add missing pinctrl settings arm64: dts: hisilicon: hi3670.dtsi: add I2C settings Zhen Lei (7): arm64: dts: hisilicon: correct vendor prefix hisi to hisilicon arm64: dts: hisilicon: separate each group of data in the property "ranges" arm64: dts: hisilicon: place clock-names "bus" before "core" arm64: dts: hisilicon: normalize the node name of the module thermal arm64: dts: hisilicon: normalize the node name of the localbus arm64: dts: hisilicon: avoid irrelevant nodes being mistakenly identified as PHY nodes arm64: dts: hisilicon: delete unused property smmu-cb-memtype arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 10 +- arch/arm64/boot/dts/hisilicon/hi3670.dtsi | 79 ++- arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi | 8 +- arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 8 +- .../arm64/boot/dts/hisilicon/hikey970-pinctrl.dtsi | 632 ++++++++++++++++++++- arch/arm64/boot/dts/hisilicon/hip05.dtsi | 2 +- arch/arm64/boot/dts/hisilicon/hip06.dtsi | 6 +- arch/arm64/boot/dts/hisilicon/hip07.dtsi | 9 +- 8 files changed, 717 insertions(+), 37 deletions(-)
1 0
0 0
Re: [PATCH v2 plinth/topic-sas-5.10 3/4] {topost} scsi: hisi_sas: enable DFX by default
by John Garry 26 Jan '21

26 Jan '21
On 16/12/2020 10:38, Luo Jiaxing wrote: > This patch add a config option "CONFIG_SCSI_HISI_DEBUGFS_DEFAULT_ENABLE" I just noticed that this should really be CONFIG_SCSI_HISI_SAS_DEBUGFS_DEFAULT_ENABLE so, I will change it to be like that
1 0
0 0
[RFC PATCH] sched/fair: first try to fix the scheduling impact of NUMA diameter > 2
by Barry Song 26 Jan '21

26 Jan '21
This patch is a follow-up of the 3-hops issue reported by Valentin Schneider: [1] https://lore.kernel.org/lkml/jhjtux5edo2.mognet@arm.com/ [2] https://lore.kernel.org/lkml/20201110184300.15673-1-valentin.schneider@arm.… Here is a brief summary of the background: For a NUMA system with 3-hops, sched_group for NUMA 2-hops could be not a subset of sched_domain. For example, for a system with the below topology(two cpus in each NUMA node): node 0 1 2 3 0: 10 12 20 22 1: 12 10 22 24 2: 20 22 10 12 3: 22 24 12 10 For CPU0, domain-2 will span 0-5, but its group will span 0-3, 4-7. 4-7 isn't a subset of 0-5. CPU0 attaching sched-domain(s): domain-0: span=0-1 level=MC groups: 0:{ span=0 cap=989 }, 1:{ span=1 cap=1016 } domain-1: span=0-3 level=NUMA groups: 0:{ span=0-1 cap=2005 }, 2:{ span=2-3 cap=2028 } domain-2: span=0-5 level=NUMA groups: 0:{ span=0-3 cap=4033 }, 4:{ span=4-7 cap=3909 } ERROR: groups don't span domain->span domain-3: span=0-7 level=NUMA groups: 0:{ span=0-5 mask=0-1 cap=6062 }, 6:{ span=4-7 mask=6-7 cap=3928 } All other cpus also have the same issue: sched_group could be not a subset of sched_domain. Here I am trying to figure out the scheduling impact of this issue from two aspects: 1. find busiest cpu in load_balance 2. find idlest cpu in fork/exec/wake balance For case 1, load_balance() seems to be handling this issue correctly as it only fills cpus in sched_domain to the cpus of lb_env. Also, find_busiest_group() and find_busiest_queue() will result in scanning cpus within env.cpus only: static int load_balance(int this_cpu, struct rq *this_rq, struct sched_domain *sd, enum cpu_idle_type idle, int *continue_balancing) {` ... struct lb_env env = { ... .cpus = cpus, .fbq_type = all, .tasks = LIST_HEAD_INIT(env.tasks), }; /* added by barry: only cpus in sched_domain are put in lb_env */ cpumask_and(cpus, sched_domain_span(sd), cpu_active_mask); ... /* * added by barry: the below functions are only scanning cpus * in env.cpus */ group = find_busiest_group(&env); ... busiest = find_busiest_queue(&env, group); ... } But one thing which looks wrong is that update_sg_lb_stats() is only counting tasks in sched_domain, but sgs->group_capacity and sgs->group_weight are counting all cpus in the sched_group. Then finally, update_sg_lb_stats() uses the load of cpus which are in the sched_domain to calculate group_type and avg_load which can be seriously underestimated. This is explained in detail as the comments added by me in the code: static inline void update_sg_lb_stats() { int i, nr_running, local_group; /* added by barry: here it only counts cpu in the sched_domain */ for_each_cpu_and(i, sched_group_span(group), env->cpus) { ... sgs->group_load += cpu_load(rq); sgs->group_util += cpu_util(i); sgs->group_runnable += cpu_runnable(rq); sgs->sum_h_nr_running += rq->cfs.h_nr_running; nr_running = rq->nr_running; sgs->sum_nr_running += nr_running; ... } ... /* added by barry: here it count all cpus which might not be in the domain */ sgs->group_capacity = group->sgc->capacity; sgs->group_weight = group->group_weight; /* added by barry: finally the group_type and avg_load could be wrong */ sgs->group_type = group_classify(env->sd->imbalance_pct, group, sgs); if (sgs->group_type == group_overloaded) sgs->avg_load = (sgs->group_load * SCHED_CAPACITY_SCALE) / sgs->group_capacity; ... } For example, if we have 2 cpus in sched_domain and 4 cpus in sched_group, the code is using the load of 2 cpus to calculate the group_type and avg_load of 4 cpus, the sched_group is likely to get much lower load than the real case. This patch fixed it by only counting cpus within sched_domain for group_capacity and group_weight. For case 2, find_idlest_group() and find_idlest_group_cpu() don't use sched_domain for scanning at all. They are scanning all cpus in the sched_group though sched_group isn't a subset of sched_domain. So they can result in picking an idle cpu outside the sched_domain but inside the sched_group. This patch moved to only scan cpus within the sched_domain, which would be similar with load_balance(). For this moment, this is pretty much PoC code to get feedback. Signed-off-by: Barry Song <song.bao.hua(a)hisilicon.com> --- kernel/sched/fair.c | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 04a3ce20da67..f183dba4961e 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -5901,7 +5901,7 @@ find_idlest_group(struct sched_domain *sd, struct task_struct *p, int this_cpu); * find_idlest_group_cpu - find the idlest CPU among the CPUs in the group. */ static int -find_idlest_group_cpu(struct sched_group *group, struct task_struct *p, int this_cpu) +find_idlest_group_cpu(struct sched_domain *sd, struct sched_group *group, struct task_struct *p, int this_cpu) { unsigned long load, min_load = ULONG_MAX; unsigned int min_exit_latency = UINT_MAX; @@ -5916,6 +5916,10 @@ find_idlest_group_cpu(struct sched_group *group, struct task_struct *p, int this /* Traverse only the allowed CPUs */ for_each_cpu_and(i, sched_group_span(group), p->cpus_ptr) { + /* when sched_group isn't a subset of sched_domain */ + if (!cpumask_test_cpu(i, sched_domain_span(sd))) + continue; + if (sched_idle_cpu(i)) return i; @@ -5984,7 +5988,7 @@ static inline int find_idlest_cpu(struct sched_domain *sd, struct task_struct *p continue; } - new_cpu = find_idlest_group_cpu(group, p, cpu); + new_cpu = find_idlest_group_cpu(sd, group, p, cpu); if (new_cpu == cpu) { /* Now try balancing at a lower domain level of 'cpu': */ sd = sd->child; @@ -8416,6 +8420,8 @@ static inline void update_sg_lb_stats(struct lb_env *env, if ((env->flags & LBF_NOHZ_STATS) && update_nohz_stats(rq, false)) env->flags |= LBF_NOHZ_AGAIN; + sgs->group_capacity += capacity_of(i); + sgs->group_weight++; sgs->group_load += cpu_load(rq); sgs->group_util += cpu_util(i); sgs->group_runnable += cpu_runnable(rq); @@ -8462,10 +8468,6 @@ static inline void update_sg_lb_stats(struct lb_env *env, sgs->group_asym_packing = 1; } - sgs->group_capacity = group->sgc->capacity; - - sgs->group_weight = group->group_weight; - sgs->group_type = group_classify(env->sd->imbalance_pct, group, sgs); /* Computing avg_load makes sense only when group is overloaded */ @@ -8688,10 +8690,12 @@ static inline void update_sg_wakeup_stats(struct sched_domain *sd, memset(sgs, 0, sizeof(*sgs)); - for_each_cpu(i, sched_group_span(group)) { + for_each_cpu_and(i, sched_group_span(group), sched_domain_span(sd)) { struct rq *rq = cpu_rq(i); unsigned int local; + sgs->group_capacity += capacity_of(i); + sgs->group_weight++; sgs->group_load += cpu_load_without(rq, p); sgs->group_util += cpu_util_without(i, p); sgs->group_runnable += cpu_runnable_without(rq, p); @@ -8715,10 +8719,6 @@ static inline void update_sg_wakeup_stats(struct sched_domain *sd, sgs->group_misfit_task_load = 1; } - sgs->group_capacity = group->sgc->capacity; - - sgs->group_weight = group->group_weight; - sgs->group_type = group_classify(sd->imbalance_pct, group, sgs); /* -- 2.25.1
4 7
0 0
[PATCH v2 8/8] rasdaemon: Modify confiure.ac for Hisilicon Kunpeng errors
by Shiju Jose 26 Jan '21

26 Jan '21
Modify HIP07 SAS HW errors : $USE_HISI_NS_DECODE to HISI Kunpeng errors : $USE_HISI_NS_DECODE. Signed-off-by: Shiju Jose <shiju.jose(a)huawei.com> --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 9893bb4..3a8b0c7 100644 --- a/configure.ac +++ b/configure.ac @@ -191,7 +191,7 @@ compile time options summary EXTLOG : $USE_EXTLOG CPER non-standard : $USE_NON_STANDARD ABRT report : $USE_ABRT_REPORT - HIP07 SAS HW errors : $USE_HISI_NS_DECODE + HISI Kunpeng errors : $USE_HISI_NS_DECODE ARM events : $USE_ARM DEVLINK : $USE_DEVLINK Disk I/O errors : $USE_DISKERROR -- 2.17.1
1 0
0 0
[PATCH v2 7/8] rasdaemon: ras-mc-ctl: Add support for HiSilicon Kunpeng9xx common errors
by Shiju Jose 26 Jan '21

26 Jan '21
Add support for the HiSilicon Kunpeng9xx platforms common errors. Signed-off-by: Shiju Jose <shiju.jose(a)huawei.com> Reviewed-by: Xiaofei Tan <tanxiaofei(a)huawei.com> --- util/ras-mc-ctl.in | 44 ++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 42 insertions(+), 2 deletions(-) diff --git a/util/ras-mc-ctl.in b/util/ras-mc-ctl.in index 8befc5d..37a5042 100755 --- a/util/ras-mc-ctl.in +++ b/util/ras-mc-ctl.in @@ -1519,6 +1519,7 @@ sub errors # Definitions of the vendor platform IDs. use constant { HISILICON_KUNPENG_920 => "Kunpeng920", + HISILICON_KUNPENG_9XX => "Kunpeng9xx", }; sub vendor_errors_summary @@ -1526,7 +1527,7 @@ sub vendor_errors_summary require DBI; my ($num_args, $platform_id); my ($query, $query_handle, $count, $out); - my ($module_id, $sub_module_id, $err_severity, $err_sev); + my ($module_id, $sub_module_id, $err_severity, $err_sev, $err_info); $num_args = $#ARGV + 1; $platform_id = 0; @@ -1601,6 +1602,24 @@ sub vendor_errors_summary $query_handle->finish; } + # HiSilicon Kunpeng9xx common errors + if ($platform_id eq HISILICON_KUNPENG_9XX) { + $query = "select err_info, count(*) from hisi_common_section"; + $query_handle = $dbh->prepare($query); + $query_handle->execute(); + $query_handle->bind_columns(\($err_info, $count)); + $out = ""; + while($query_handle->fetch()) { + $out .= "\terrors: $count\n"; + } + if ($out ne "") { + print "HiSilicon Kunpeng9xx common error events summary:\n$out\n"; + } else { + print "No HiSilicon Kunpeng9xx common errors.\n\n"; + } + $query_handle->finish; + } + undef($dbh); } @@ -1610,7 +1629,7 @@ sub vendor_errors my ($num_args, $platform_id); my ($query, $query_handle, $id, $timestamp, $out); my ($version, $soc_id, $socket_id, $nimbus_id, $core_id, $port_id); - my ($module_id, $sub_module_id, $err_severity, $err_type, $regs); + my ($module_id, $sub_module_id, $err_severity, $err_type, $err_info, $regs); $num_args = $#ARGV + 1; $platform_id = 0; @@ -1696,6 +1715,26 @@ sub vendor_errors $query_handle->finish; } + # HiSilicon Kunpeng9xx common errors + if ($platform_id eq HISILICON_KUNPENG_9XX) { + $query = "select id, timestamp, err_info, regs_dump from hisi_common_section order by id"; + $query_handle = $dbh->prepare($query); + $query_handle->execute(); + $query_handle->bind_columns(\($id, $timestamp, $err_info, $regs)); + $out = ""; + while($query_handle->fetch()) { + $out .= "$id. $timestamp "; + $out .= "Error Info:$err_info \n" if ($err_info); + $out .= "Error Registers: $regs\n\n" if ($regs); + } + if ($out ne "") { + print "HiSilicon Kunpeng9xx common error events:\n$out\n"; + } else { + print "No HiSilicon Kunpeng9xx common errors.\n"; + } + $query_handle->finish; + } + undef($dbh); } @@ -1703,6 +1742,7 @@ sub vendor_platforms { print "\nSupported platforms for the vendor-specific errors:\n"; print "\tHiSilicon Kunpeng920, platform-id=\"", HISILICON_KUNPENG_920, "\"\n"; + print "\tHiSilicon Kunpeng9xx, platform-id=\"", HISILICON_KUNPENG_9XX, "\"\n"; print "\n"; } -- 2.17.1
1 0
0 0
  • ← Newer
  • 1
  • ...
  • 73
  • 74
  • 75
  • 76
  • 77
  • 78
  • 79
  • 80
  • 81
  • Older →

HyperKitty Powered by HyperKitty