EDAC DIMM CE Error错误导致服务器重启

最新推荐文章于 2024-11-11 15:44:47 发布
最新推荐文章于 2024-11-11 15:44:47 发布
阅读量1.7w 收藏 10
点赞数
CC 4.0 BY-SA版权
分类专栏： Oracle 错误解决 Linux 系统
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/lichangzai/article/details/46989273
本文介绍了一例华为RH2285服务器频繁自动重启的现象及原因分析，通过对EDAC日志的解析定位到了具体故障内存条，并给出了相应的解决措施。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

 现象：

 

最近几天一个华为RH2285服务器一直不定时自动重启，基本每天一两次，查看系统日志报下面的错误，每秒记录一条错误日志

 

OS：OEL 6.5

 

$ more /var/log/message

Jul 21 08:54:32 customerkernel: EDAC MC1: 5486 CE error on CPU#1Channel#2_DIMM#1 (channel:2 slot:1page:0x0 offset:0x0 grain:8 syndrome:0x0)

Jul 21 08:54:33 customerkernel: EDAC MC1: 11480 CE error on CPU#1Channel#2_DIMM#1 (channel:2 slot:1page:0x0 offset:0x0 grain:8 syndrome:0x0)

Jul 21 08:54:34 customerkernel: EDAC MC1: 11330 CE error on CPU#1Channel#2_DIMM#1 (channel:2 slot:1page:0x0 offset:0x0 grain:8 syndrome:0x0)

Jul 21 08:54:35 customerkernel: EDAC MC1: 6584 CE error on CPU#1Channel#2_DIMM#1 (channel:2 slot:1page:0x0 offset:0x0 grain:8 syndrome:0x0)

Jul 21 08:54:36 customerkernel: EDAC MC1: 27428 CE error on CPU#1Channel#2_DIMM#1 (channel:2 slot:1page:0x0 offset:0x0 grain:8 syndrome:0x0)

Jul 21 08:54:37 customerkernel: EDAC MC1: 30113 CE error on CPU#1Channel#2_DIMM#1 (channel:2 slot:1page:0x0 offset:0x0 grain:8 syndrome:0x0)

Jul 21 08:54:38 customerkernel: EDAC MC1: 4453 CE error on CPU#1Channel#2_DIMM#1 (channel:2 slot:1page:0x0 offset:0x0 grain:8 syndrome:0x0)

Jul 21 08:54:39 customerkernel: EDAC MC1: 6269 CE error on CPU#1Channel#2_DIMM#1 (channel:2 slot:1page:0x0 offset:0x0 grain:8 syndrome:0x0)

Jul 21 08:54:40 customer kernel:EDAC MC1: 15720 CE error on CPU#1Channel#2_DIMM#1 (channel:2 slot:1 page:0x0offset:0x0 grain:8 syndrome:0x0)

Jul 21 08:54:41 customerkernel: EDAC MC1: 16107 CE error on CPU#1Channel#2_DIMM#1 (channel:2 slot:1page:0x0 offset:0x0 grain:8 syndrome:0x0)

 

 

分析解决：

 

这个是[EDAC (Error Detection AndCorrection)](https://www.kernel.org/doc/Documentation/edac.txt) 的日志.

 

CE Error 是 Correctable Error 的简称，另外还有 UE(Uncorrectable Error)

 

按照上面的文档, 找出错误的DIMM:

[root@customer log]# grep "[0-9]" /sys/devices/system/edac/mc/mc*/csrow*/ch*_ce_count

/sys/devices/system/edac/mc/mc0/csrow0/ch0_ce_count:0

/sys/devices/system/edac/mc/mc0/csrow0/ch1_ce_count:0

/sys/devices/system/edac/mc/mc0/csrow0/ch2_ce_count:0

/sys/devices/system/edac/mc/mc0/csrow1/ch0_ce_count:0

/sys/devices/system/edac/mc/mc0/csrow1/ch1_ce_count:0

/sys/devices/system/edac/mc/mc0/csrow1/ch2_ce_count:0

/sys/devices/system/edac/mc/mc1/csrow0/ch0_ce_count:0

/sys/devices/system/edac/mc/mc1/csrow0/ch1_ce_count:0

/sys/devices/system/edac/mc/mc1/csrow0/ch2_ce_count:0

/sys/devices/system/edac/mc/mc1/csrow1/ch0_ce_count:0

/sys/devices/system/edac/mc/mc1/csrow1/ch1_ce_count:0

/sys/devices/system/edac/mc/mc1/csrow1/ch2_ce_count:554836518

 

查到是 /mc1/csrow1/ch2, 根据结构图:

 

       Channel 0   Channel 1

===================================

csrow0 | DIMM_A0   | DIMM_B0 |

csrow1 | DIMM_A0   | DIMM_B0 |

===================================

===================================

csrow2 | DIMM_A1   | DIMM_B1 |

csrow3 | DIMM_A1   | DIMM_B1 |

===================================

 

然后通过dmidecode查看：

[root@customer log]# dmidecode -t memory |grep 'Locator: DIMM'

       Locator: DIMM_D0

       Locator: DIMM_D1

       Locator: DIMM_E0

       Locator: DIMM_E1

       Locator: DIMM_F0

       Locator: DIMM_F1

       Locator: DIMM_A0

       Locator: DIMM_A1

       Locator: DIMM_B0

       Locator: DIMM_B1

       Locator: DIMM_C0

       Locator: DIMM_C1

       

通过服务器控制台查看内存：

 

主板上内存插槽的分布：


 

结合报错日志：kernel: EDAC MC1: 16107 CE error on CPU#1Channel#2_DIMM#1 (channel:2slot:1

应该是内存插槽DIMM_F1的问题。

 

解决：

最后我们要做的就是，把有问题的F1插槽上的内存拔出来或是更换到其它的内存插槽上面，之后系统启动后不再报错。

 

参考：

http://blog.tankywoo.com/2014/12/02/edac-dimm-ce-error.html

http://serverfault.com/questions/648240/how-can-i-find-which-memory-have-ce-error

 

 

 

 

 


 

 

 

EDAC DIMM CE Error 错误导致服务器重启
chunnizai4487的博客
03-03 2384
故障现象： EDAC sbridge: Lost 1569 memory errors （内存校验错误） 处理过程： 查看日志：cat /var/log/messages Feb 27 10:18:02 localhost kernel: EDAC MC1: 864 CE me...
kernel: [ 3166.869181] EDAC MC2: 1 CE memory read error on CPU_SrcID#1_Ha#1_Chan#1_DIMM#0
qq_36772716的博客
11-15 2244
Sysptom: Sun Nov 14 19:08:17 2021 ID ffff P1 ECC CE /SYS/MB/P1/D3, 1 errors on MC1-CH1, dimm 0, rank 0. Sun Nov 14 19:08:17 2021 ID ffff ******** Home Agent(HA1) Shadow Errors ******** Sun Nov 14 19:15:08 2021 ID ffff P1 ECC CE /SYS/MB/P1/D3, 1 errors on.
EDAC检查内存错误
撞强※非专业，更专注
06-11 7151
开启EDAC服务或加载EDAC内核模块后：   [root@node10 ssh]#grep"[0-9]" /sys/devices/system/edac/mc/mc*/csrow*/ch*_ce_count   /sys/devices/system/edac/mc/mc0/csrow2/ch0_ce_count:42457 /sys/devices/system/edac/mc/m
Error Detection And Correction (EDAC)
一棹春风一叶舟，一纶茧缕一轻钩
12-17 5584
COPIED FROM: http://fibrevillage.com/sysadmin/243-edac-error-detection-and-correction https://01.org/linuxgraphics/gfx-docs/drm/driver-api/edac.html 1. Error Detection And Correction (EDAC) D...
网卡bond和信息查看 EDACDIMMCEError错误导致服务器重启
weixin_45720992的博客
09-12 421
结合报错日志：kernel: EDAC MC1: 16107 CE error on CPU#1Channel#2_DIMM#1 (channel:2slot:1。CE Error 是 Correctable Error 的简称，另外还有 UE(Uncorrectable Error)最近几天一个华为RH2285服务器一直不定时自动重启，基本每天一两次，查看系统日志报下面的错误，每秒记录一条错误日志。最后我们要做的就是，把有问题的F1插槽上的内存拔出来或是更换到其它的内存插槽上面，之后系统启动后不再报错。
内存故障：CE error on CPU#0Channel#1_DIMM#1 (channel:1 slot:1 page:0x0 offset:0x0 grain:8 syndrom
weixin_50877409的博客
11-02 4499
EDAC MC0: 1 CE error on CPU#0Channel#1_DIMM#1 (channel:1 slot:1 page:0x0 offset:0x0 grain:8 syndrome:0x0)
曙光&宁畅Intel G40&G41双路服务器主板ECC内存对应表&故障内存定位
qq_27815483的博客
08-02 723
本文主要介绍曙光&宁畅Intel G40&G41双路服务器Linux系统下内存报错定位方法
服务器内存故障预测居然可以这样做
JavaMonsterr的博客
07-26 963
随着互联网业务的快速发展，基础设施的可用性也越来越受到业界的关注。然而硬件故障一直以来都是一种普遍存在的现象，由于硬件故障而造成的损失往往是巨大的。在服务器各个部件中，除硬盘故障以外，内存故障是第二大常见的硬件故障类型。并且服务器内存的数量众多，vivo的内存数量达到40w+条，内存故障造成的最严重的后果是会直接导致系统崩溃，服务器宕机，这些对于上层业务而言都是不能接受的。内存故障可分为UCE（UncorrectableError）和CE（CorrectableError）。标记CE错误。...
曙光&宁畅服务器65GA24主板ECC内存对应表&故障内存定位（AMD Genoa CPU）
qq_27815483的博客
11-11 1914
曙光&宁畅服务器65GA24主板ECC内存对应表&故障内存定位故障内存位置（AMD Genoa CPU）
CPU_SrcID#1_Channel#0_DIMM#0error(s): memory scrubbing on FATAL area OVERFLOW 求解
weixin_34417183的博客
09-27 1584
Sep2722:29:09athCompute77kernel:EDACMC1:CErow0,channel0,label"CPU_SrcID#1_Channel#0_DIMM#0":2Unknownerror(s):memoryscrubbingonFATALareaOVERFLOW:cpu=1Err=0008:00c2(c...
服务器内存故障预测居然可以这样做！
vivo互联网技术
07-26 3602
。本文主要介绍EDAC（Error Detection And Correction）框架在内存预测方面的应用。首先介绍了EDAC应用的背景，接着是EDAC的原理介绍，然后通过EDAC安装——配置——测试过程详细的介绍了EDAC在vivo服务器上的应用，最后提出了内存预测使用EDAC的方案总结以及服务器RAS（Reliability, Availability and Serviceability）应用减小硬件故障对系统的影响的展望。...
EDAC_MC模块大量输出报警信息的临时解决办法
肥三的专栏
12-11 5609
前两天在日志里提到了一个Linux内核的BUG。 现在找到一个临时办法可以关闭这些信息执行一下echo "0" >/sys/devices/system/edac/mc/log_ueecho "0" >/sys/devices/system/edac/mc/log_ce那些报警信息就看不到了 关于edac_mc模块，可以看看 http://buttersideup.co
机器重启原因排查
任我行的博客
02-06 3521
现象： 环境中出现一台服务器间歇性自动重启 排查问题 查看操作记录是否有人为重启过？无人为重启操作 查看是否生产crash文件？/var/crash物理无crash文件生成 查看message日志是否有正常？message文件正常 查看sudo journalctl -k 结果 kernel: EDAC MC3: 1 CE memory scrubbing error on CPU_SrcID#1_MC#1_Chan#1_DIMM#0 (channel:1 slot:0 page:0x343acff o
填坑日常之 EDAC DIMM CE Error
...的博客
11-21 3015
2015-12-30 下午 ngaios 监控发现硬盘满报警 2015-12-31 早上开始排查原因经过排查发现 log 目录下的三个系统日志非常大，竟有 8.7G 大小读日志内容后发现有大量的 EDAC DIMM CE Error 出现经过一番 Google 后得知这是由于内存错误，导致系统自动启动错误恢复机制，但恢复失败写入日志，继续修复，循环下去导致日志文件大小暴增粗略看了看 linux 的
Centos 服务器系统内存故障排查
Free雅轩的博客
06-10 2327
1.内存故障排查因为 68 – 71 软SBC服务器都是Centos7系统，所以我们可以通过以下命令来排查内存是否出现损坏。 grep "[0-9]" /sys/devices/system/edac/mc/mc/csrow/ch*_ce_count 1> count不为0表示有错误 2> mc代表第几个cpu， 3> csrow内存通道， 4> ch第几个内存 EDAC即error detection and correction（错误检测与纠
内存故障EDAC技术原理
存储随笔
06-10 2219
其中，`edac_mc`子系统是内存错误收集的核心，它利用一系列精心设计的函数，如`edac_mc_alloc()`、`edac_device_handle_ce()`、`edac_device_handle_ue()`等，来管理内存控制器报告的CE（Correctable Errors，可纠正错误）和UCE（Uncorrectable Errors，不可纠正错误）。例如，/sys/devices/system/edac/mc/mc0/csrow0/下的文件提供了csrow级别的错误统计和信息。
linux edac服务,linux – 内核：dmesg中的EDAC MC0垃圾邮件
weixin_39802784的博客
05-09 938
我在dmesg中有垃圾邮件,其中包含：kernel:EDAC MC0: UE page 0x0,offset 0x0,grain 1073741824,row 3,labels ":": i3200 UE知道什么是假的吗？这里是加载模块：# lsmod | grep edaci3200_edac 3330 0edac_core 46581 2...
如何通过Linux内核日志（`dmesg`）区分tRP和tRFC错误？
最新发布
07-29
<think>我们正在讨论如何通过Linux内核日志（dmesg）区分tRP和tRFC引起的内存错误。根据之前对内存时序错误的讨论，我们知道这两种错误有不同的触发机制和表现特征。在Linux内核日志中，内存错误通常会被记录为EDAC（Error Detection and Correction）消息或MCA（Machine Check Architecture）事件。我们可以通过分析日志中的错误类型、发生场景和附加信息来区分。 ### 一、tRP与tRFC错误在dmesg中的典型特征 #### 1. **tRP（行预充电时间）错误特征** - **错误类型**：多为单比特可纠正错误（Correctable Error, CE），但频繁发生可能导致不可纠正错误（Uncorrectable Error, UE）。 - **触发场景**：当系统频繁切换内存行（如高负载多任务处理）时出现。 - **日志关键词**： - `EDAC MC#: CE row X, channel Y`（可纠正错误，指明行和通道） - `Corrected memory error at physical address XXXXXXXX`（物理地址随机） - 可能伴随`tRP violation`或`precharge timing`等描述（取决于内核版本和硬件支持） - **错误分布**：错误地址分散在不同Bank的行切换点。 示例日志片段： ``` [ 1234.567890] EDAC MC0: 1 CE on mc#0csrow#1channel#0 (csrow:1 channel:0 page:0x12345 offset:0x0 grain:8 syndrome:0x0) [ 1234.567891] EDAC sbridge MC0: HANDLING MCE MEMORY ERROR [ 1234.567892] EDAC sbridge MC0: CPU 0: Machine Check Event: 0 Bank 5: 8c00004000010090 [ 1234.567893] EDAC sbridge MC0: TSC 0 [ 1234.567894] EDAC sbridge MC0: ADDR 12345678 [ 1234.567895] EDAC sbridge MC0: MISC 0 [ 1234.567896] EDAC sbridge MC0: PROCESSOR 0:306a9 TIME 1234567890 SOCKET 0 APIC 0 ``` #### 2. **tRFC（刷新周期）错误特征** - **错误类型**：常为多比特不可纠正错误（UE），因为刷新失败会影响整行数据。 - **触发场景**：周期性出现（与刷新周期同步），尤其在高温环境下。 - **日志关键词**： - `EDAC MC#: UE row X, channel Y`（不可纠正错误） - `Uncorrected memory error at physical address XXXXXXXX` - `refresh timeout`或`tRFC violation`（直接提示刷新问题） - 可能记录温度传感器数据（如`thermal: temp=75C`） - **错误间隔**：错误时间戳间隔接近内存刷新周期（DDR4典型值约350ns，但日志中可能以毫秒级间隔出现，因为错误累积后才会被记录）。 示例日志片段： ``` [ 5678.901234] EDAC MC0: 1 UE on mc#0csrow#0channel#1 (csrow:0 channel:1 page:0x67890 offset:0x0 grain:8 syndrome:0x0) [ 5678.901235] EDAC sbridge MC0: HANDLING MCE MEMORY ERROR [ 5678.901236] EDAC sbridge MC0: CPU 0: Machine Check Event: 0 Bank 7: 9c0000800002009f [ 5678.901237] EDAC sbridge MC0: TSC 0 [ 5678.901238] EDAC sbridge MC0: ADDR 6789abcd [ 5678.901239] EDAC sbridge MC0: MISC 0 [ 5678.901240] EDAC sbridge MC0: PROCESSOR 0:306a9 TIME 5678901234 SOCKET 0 APIC 0 [ 5678.901241] thermal thermal_zone0: temp=82C ``` ### 二、诊断步骤 #### 1. **过滤关键错误消息** 使用`dmesg`配合`grep`过滤内存错误： ```bash # 查看所有内存错误 dmesg | grep -i "memory error" # 区分CE（可纠正错误）和UE（不可纠正错误） dmesg | grep -iE "CE|UE" # 检查是否提及刷新或预充电 dmesg | grep -iE "refresh|precharge|tRP|tRFC" ``` #### 2. **分析错误模式** - **时间分布**：使用`dmesg -T`（显示人类可读时间戳）观察错误间隔： ```bash dmesg -T | grep -i "memory error" | awk '{print $1,$2,$3}' ``` 若错误间隔均匀（如每30秒出现UE），则指向tRFC问题。 - **温度关联**：检查错误发生时的温度记录（需硬件支持）： ```bash dmesg -T | grep -iE "memory error|thermal|temp" ``` #### 3. **结合硬件信息定位** 从日志中提取物理地址（ADDR字段），使用`decode-dimms`工具（需安装`i2c-tools`）映射到具体内存模块： ```bash # 安装工具 sudo apt install i2c-tools # 解码DIMM信息 sudo decode-dimms | grep -A10 "Memory Device" ``` 若tRFC错误多集中在高温模块上，或tRP错误在频繁访问的Bank上。 ### 三、高级诊断工具 1. **edac-utils**：专用内存错误分析工具包 ```bash sudo apt install edac-utils sudo edac-util --status ``` 输出示例： ``` mc0: 0 UE 1 CE # 若UE为主，则更可能为tRFC问题 mc1: 12 CE 0 UE # 若CE为主，则更可能为tRP或tRCD问题 ``` 2. **mcelog**：解析Machine Check错误 ```bash sudo mcelog --ascii ``` 输出中关键字段： - `bank`：错误类型编号（参考CPU手册） - `status`：错误代码（十六进制，高位比特指示错误类型） ### 四、总结区分要点 | **特征** | **tRP错误** | **tRFC错误** | |-------------------|-----------------------------|-------------------------------| | **错误类型** | 多为CE（可纠正） | 多为UE（不可纠正） | | **触发场景** | 高频率行切换 | 高温或长时间运行 | | **日志关键词** | `CE`, `precharge` | `UE`, `refresh`, `timeout` | | **时间模式** | 随机 | 周期性（≈刷新周期） | | **温度关联** | 弱 | 强（>70°C时错误率剧增） | | **物理地址分布** | 分散在不同Bank的行边界 | 可能集中在特定温度敏感区域 | > 注：现代Linux内核（≥5.10）的EDAC驱动可能直接报告时序违规类型[^3]。 ### §§相关问题§§ 1. 如何在Linux下实时监控内存时序错误的发生？ 2. DDR5内存的tRFC错误在dmesg中是否有新的特征？ 3. 没有EDAC支持的老旧Linux系统如何诊断内存时序问题？</think>通过分析 Linux 内核日志 (`dmesg`) 区分 tRP 和 tRFC 内存时序错误，需结合错误类型、发生模式、环境因素和系统行为综合判断。以下是关键区分方法： --- ### 一、核心特征对比 | **特征** | **tRP 错误** | **tRFC 错误** | |--------------------|-------------------------------|--------------------------------| | **错误类型** | 多为可纠正错误 (CE) | 多为不可纠正错误 (UE) | | **触发模式** | 内存行频繁切换时突发 | 周期性出现（≈刷新周期） | | **典型日志关键词** | `Corrected memory error`<br>`row precharge timeout` | `Uncorrectable memory error`<br>`refresh timeout` | | **温度关联** | 弱相关性 | 高温时错误率显著增加（>70°C）[^1] | | **地址分布** | 随机地址 | 可能集中在特定物理区域 | | **系统表现** | 应用崩溃但系统可能存活 | 系统级死锁或硬重启 | --- ### 二、诊断步骤详解 #### 1. **过滤关键日志** ```bash # 查找内存错误基础命令 dmesg | grep -i "memory error" # 区分错误类型（重点过滤CE/UE） dmesg | grep -iE "corrected memory error|uncorrectable memory error" # 检查时序相关关键词 dmesg | grep -iE "precharge|refresh|timeout" ``` #### 2. **分析错误模式** - **tRP 错误特征**： - 日志中出现大量 `Corrected memory error`（CE） - 错误发生在不同内存行切换时（如日志中多行地址差异大） - 示例日志： ``` [ 123.456] EDAC MC0: 1 CE memory error on DIMM0 (channel:0 rank:0 bank:8 row:0x12345) [ 123.457] mce: [Hardware Error]: Corrected memory error at physical address 0x7f89a2d40 ``` - **tRFC 错误特征**： - 周期性出现 `Uncorrectable memory error`（UE） - 错误间隔接近刷新周期（DDR4 典型值 350ns，日志中可能每 10-30 分钟集中出现） - 常伴随温度警告： ``` [ 567.890] thermal thermal_zone0: critical temperature reached (85°C) [ 567.891] EDAC MC0: UE row refresh timeout on DIMM1 ``` #### 3. **结合系统监控** - **温度关联检查**： ```bash # 提取错误时间点温度 dmesg -T | grep -iE "memory error|thermal" ``` 若 UE 错误总在 >75°C 时出现，强烈指向 tRFC 问题。 - **地址分布分析**： ```bash # 统计错误地址分布 dmesg | grep "physical address" | awk '{print $NF}' | sort | uniq -c ``` tRP 错误地址随机分散，tRFC 错误可能集中在高温敏感区域。 --- ### 三、高级诊断工具 1. **edac-utils** 工具包： ```bash sudo apt install edac-utils edac-util --status # 显示CE/UE计数 ``` - **tRP 倾向**：CE 计数远高于 UE - **tRFC 倾向**：UE 计数占比 >40% 2. **mcelog 解析**： ```bash sudo mcelog --ascii ``` 输出中关注： - `bank` 字段：Bank 5/6 错误常关联 tRFC - `status` 值：0x8c000040... 类代码提示刷新超时[^3] --- ### 四、验证方法 1. **tRP 压力测试**： ```bash stress-ng --vm 8 --vm-bytes 2G --vm-stride 512 # 强制行切换 ``` 若触发大量 CE 错误，确认 tRP 问题。 2. **tRFC 高温测试**： ```bash watch -n 60 "dmesg -c | grep memory" # 每60秒检查 ``` 同时提高环境温度，若 UE 错误率随温度上升，确认 tRFC 问题。 > **关键公式**：tRFC 错误间隔 $T_{error}$ 与刷新周期 $t_{RFC}$ 满足 $T_{error} \approx \frac{N_{banks} \times t_{RFC}}{t_{CK}}$，其中 $N_{banks}$ 为内存 Bank 数[^2]。 --- ### 五、典型日志案例 #### **tRP 错误日志** ``` [ 12.345] mce: [Hardware Error]: Corrected memory error [ 12.346] EDAC sbridge MC0: HANDLING MCE MEMORY ERROR [ 12.347] MC0: row=0xabcd, channel=1, offset=0x0 # 行地址随机变化 ``` #### **tRFC 错误日志** ``` [ 45.678] thermal: Critical temperature reached (89°C) [ 45.679] mce: [Hardware Error]: Uncorrectable memory error [ 45.680] EDAC MC0: UE refresh timeout on DIMM2 [ 45.681] Kernel panic - not syncing: Fatal machine check # 系统级崩溃 ``` --- ###
评论 2
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值