Автор Тема: странен (хардуерен) проблем с памет  (Прочетена 1040 пъти)

dilyan

  • Напреднали
  • *****
  • Публикации: 189
  • Distribution: Debian, OpenBSD
  • Window Manager: Gnome, xfce
    • Профил
Привет,
изчерпвам се от troubleshooting опции, за това питам за акъл.
Dell Precision 5810. Сменен проецсор, сменена памет, сменен диск. Debian 12, нова инсталация. Всичко е up-to-date - BIOS, пакети и т.н.

От време на време, в dmesg и в # journalctl -f се появява следното:


Jun 17 22:13:16 debian kernel: EDAC sbridge MC0: HANDLING MCE MEMORY ERROR
Jun 17 22:13:16 debian kernel: EDAC sbridge MC0: CPU 0: Machine Check Event: 0 Bank 13: 8c00004a000800c0
Jun 17 22:13:16 debian kernel: EDAC sbridge MC0: TSC 1859b6d484e3
Jun 17 22:13:16 debian kernel: EDAC sbridge MC0: ADDR 1605ad6000
Jun 17 22:13:16 debian kernel: EDAC sbridge MC0: MISC 90000008000948c
Jun 17 22:13:16 debian kernel: EDAC sbridge MC0: PROCESSOR 0:406f1 TIME 1718651596 SOCKET 0 APIC 0
Jun 17 22:13:16 debian kernel: EDAC MC1: 1 CE memory scrubbing error on CPU_SrcID#0_Ha#1_Chan#0_DIMM#0 (channel:0 page:0x1605ad6 offset:0x0 grain:32 syndrome:0x0 -  area:DRAM err_code:0008:00c0 socket:0 ha:1 channel_mask:1 rank:255 )
---
[10074.494184] mce: [Hardware Error]: Machine check events logged
[10074.494192] EDAC sbridge MC0: HANDLING MCE MEMORY ERROR
[10074.494195] EDAC sbridge MC0: CPU 0: Machine Check Event: 0 Bank 13: 8c00004a000800c0
[10074.494200] EDAC sbridge MC0: TSC 1859b6d484e3
[10074.494202] EDAC sbridge MC0: ADDR 1605ad6000
[10074.494204] EDAC sbridge MC0: MISC 90000008000948c
[10074.494206] EDAC sbridge MC0: PROCESSOR 0:406f1 TIME 1718651596 SOCKET 0 APIC 0
[10074.494225] EDAC MC1: 1 CE memory scrubbing error on CPU_SrcID#0_Ha#1_Chan#0_DIMM#0 (channel:0 page:0x1605ad6 offset:0x0 grain:32 syndrome:0x0 -  area:DRAM err_code:0008:00c0 socket:0 ha:1 channel_mask:1 rank:255 )

после следват и дъмпове:

Jun 17 22:35:43 debian kernel: ------------[ cut here ]------------
Jun 17 22:35:43 debian kernel: WARNING: CPU: 4 PID: 8050 at drivers/iommu/dma-iommu.c:1041 iommu_dma_unmap_page+0x79/0x90
Jun 17 22:35:43 debian kernel: Modules linked in: ccm rfcomm snd_seq_dummy snd_hrtimer snd_seq snd_seq_device qrtr cmac algif_hash algif_skcipher af_alg bnep binfmt_misc squashfs intel_rapl_msr intel_rapl_common intel_uncore_frequency intel_uncore_frequency_common sb_edac x86_pkg_temp_thermal intel_powerclamp coretemp btusb btrtl kvm_intel btbcm btintel btmtk kvm bluetooth irqbypass rtl8188ee rtl_pci snd_hda_codec_realtek rtlwifi ghash_clmulni_intel sha256_ssse3 sha1_ssse3 snd_hda_codec_generic mac80211 snd_hda_codec_hdmi ledtrig_audio aesni_intel snd_hda_intel crypto_simd libarc4 cryptd jitterentropy_rng snd_intel_dspcfg snd_intel_sdw_acpi sha512_ssse3 rapl sha512_generic cfg80211 snd_hda_codec ctr snd_hda_core intel_cstate snd_hwdep mei_wdt drbg snd_pcm dell_smm_hwmon ansi_cprng iTCO_wdt snd_timer intel_pmc_bxt dell_smbios mei_me iTCO_vendor_support ecdh_generic snd dcdbas mei intel_wmi_thunderbolt dell_wmi_descriptor wmi_bmof pcspkr rfkill ecc soundcore watchdog intel_uncore joydev sg evdev msr
Jun 17 22:35:43 debian kernel:  parport_pc ppdev lp parport dm_mod fuse loop efi_pstore configfs ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 crc32c_generic hid_generic usbhid hid nouveau sd_mod t10_pi sr_mod cdrom crc64_rocksoft crc64 crc_t10dif crct10dif_generic video i2c_algo_bit drm_display_helper cec rc_core ahci drm_ttm_helper libahci ttm libata drm_kms_helper xhci_pci ehci_pci xhci_hcd ehci_hcd mxm_wmi drm scsi_mod crct10dif_pclmul usbcore crct10dif_common crc32_pclmul e1000e crc32c_intel i2c_i801 lpc_ich i2c_smbus scsi_common usb_common wmi button
Jun 17 22:35:43 debian kernel: CPU: 4 PID: 8050 Comm: kworker/u48:1 Not tainted 6.1.0-18-amd64 #1  Debian 6.1.76-1
Jun 17 22:35:43 debian kernel: Hardware name: Dell Inc. Precision Tower 5810/0K240Y, BIOS A34 10/19/2020
Jun 17 22:35:43 debian kernel: Workqueue: phy0 ieee80211_iface_work [mac80211]
Jun 17 22:35:43 debian kernel: RIP: 0010:iommu_dma_unmap_page+0x79/0x90
Jun 17 22:35:43 debian kernel: Code: 2b 48 3b 28 72 26 48 3b 68 08 73 20 4d 89 f8 44 89 f1 4c 89 ea 48 89 ee 48 89 df 5b 5d 41 5c 41 5d 41 5e 41 5f e9 a7 b9 a6 ff <0f> 0b 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 66 0f 1f 44 00
Jun 17 22:35:43 debian kernel: RSP: 0018:ffffb41f6108f938 EFLAGS: 00010046
Jun 17 22:35:43 debian kernel: RAX: 0000000000000000 RBX: ffff8fb4c29150d0 RCX: 0000000000000012
Jun 17 22:35:43 debian kernel: RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003
Jun 17 22:35:43 debian kernel: RBP: ffffb41f6108fa10 R08: 0000000000000002 R09: 0000000000000000
Jun 17 22:35:43 debian kernel: R10: 00000000ffffffa0 R11: 0000000000000000 R12: 0000000000000000
Jun 17 22:35:43 debian kernel: R13: 0000000000000300 R14: 0000000000000001 R15: 0000000000000000
Jun 17 22:35:43 debian kernel: FS:  0000000000000000(0000) GS:ffff8fd36f900000(0000) knlGS:0000000000000000
Jun 17 22:35:43 debian kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Jun 17 22:35:43 debian kernel: CR2: 00007f5f0802a048 CR3: 0000000109424002 CR4: 00000000003706e0
Jun 17 22:35:43 debian kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Jun 17 22:35:43 debian kernel: DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Jun 17 22:35:43 debian kernel: Call Trace:
Jun 17 22:35:43 debian kernel:  <TASK>
Jun 17 22:35:43 debian kernel:  ? __warn+0x7d/0xc0
Jun 17 22:35:43 debian kernel:  ? iommu_dma_unmap_page+0x79/0x90
Jun 17 22:35:43 debian kernel:  ? report_bug+0xe2/0x150
Jun 17 22:35:43 debian kernel:  ? handle_bug+0x41/0x70
Jun 17 22:35:43 debian kernel:  ? exc_invalid_op+0x13/0x60
Jun 17 22:35:43 debian kernel:  ? asm_exc_invalid_op+0x16/0x20
Jun 17 22:35:43 debian kernel:  ? iommu_dma_unmap_page+0x79/0x90
Jun 17 22:35:43 debian kernel:  ? iommu_dma_unmap_page+0x2e/0x90
Jun 17 22:35:43 debian kernel:  rtl88ee_set_hw_reg+0x12fe/0x16f0 [rtl8188ee]
Jun 17 22:35:43 debian kernel:  ? rtl88ee_set_check_bssid+0xb6/0x120 [rtl8188ee]
Jun 17 22:35:43 debian kernel:  rtl_op_bss_info_changed+0x1c8/0x8a0 [rtlwifi]
Jun 17 22:35:43 debian kernel:  ? ieee80211_recalc_chanctx_min_def+0x14/0x60 [mac80211]
Jun 17 22:35:43 debian kernel:  ieee80211_bss_info_change_notify+0xcf/0x2a0 [mac80211]
Jun 17 22:35:43 debian kernel:  ieee80211_rx_mgmt_assoc_resp.cold+0x1946/0x198d [mac80211]
Jun 17 22:35:43 debian kernel:  ieee80211_sta_rx_queued_mgmt+0x2d6/0x820 [mac80211]
Jun 17 22:35:43 debian kernel:  ? psi_group_change+0x145/0x360
Jun 17 22:35:43 debian kernel:  ieee80211_iface_work+0x325/0x440 [mac80211]
Jun 17 22:35:43 debian kernel:  process_one_work+0x1c7/0x380
Jun 17 22:35:43 debian kernel:  worker_thread+0x4d/0x380
Jun 17 22:35:43 debian kernel:  ? rescuer_thread+0x3a0/0x3a0
Jun 17 22:35:43 debian kernel:  kthread+0xda/0x100
Jun 17 22:35:43 debian kernel:  ? kthread_complete_and_exit+0x20/0x20
Jun 17 22:35:43 debian kernel:  ret_from_fork+0x22/0x30
Jun 17 22:35:43 debian kernel:  </TASK>
Jun 17 22:35:43 debian kernel: ---[ end trace 0000000000000000 ]---
----
# uname -a
Linux debian 6.1.0-18-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.76-1 (2024-02-01) x86_64 GNU/Linux
----
На пръв поглед проблем с паметта, която (евентуално) прави проблем с wifi картата.
Обаче:
# ras-mc-ctl --errors
No Memory errors.

No PCIe AER errors.

No Extlog errors.

No MCE errors.
----

# ras-mc-ctl --error-count
Label                            CE   UE
CPU_SrcID#0_Ha#0_Chan#1_DIMM#0   0   0
CPU_SrcID#0_Ha#1_Chan#1_DIMM#0   0   0
CPU_SrcID#0_Ha#0_Chan#0_DIMM#0   0   0
CPU_SrcID#0_Ha#1_Chan#0_DIMM#0   0   0

-----
Тестовете от BIOS-a на Dell не показват грешки (последна версия е BIOS-a).
memtest86+ не показва грешки.
---
За да стане по-интересно, имам стари плочки памет 4х 4G, 2133 Mhz - като ги сложа грешки няма.
Като сложа 4х 32G, 2400 Mhz - започват проблемите. Сменям плочките като позиция, няма промяна. Вадя  плочки една по една - с 1х 32 работи добре, с 2х  32 работи добре, с 3х 32 работи добре, с 4х дава грешките по-горе.
Официално системата поддържа 256 G РАМ на 2400 Mhz.

някакви идеи как да хвана проблема от къде идва?

Едната ми теория е, че има проблем с 4-тия слот на паметта на 2400 Mhz ... но нямам доказателства.

четох за проблем с edac модулите - https://www.dell.com/support/kbdoc/en-us/000177028/edac-errors-in-messages-log-in-redhat-enterprise-linux-rhel-and-poweredge като ги blacklist-на в

# cat edac_blacklist.conf
blacklist i5000_edac
blacklist igen6_edac
blacklist i7core_edac
blacklist pnd2_edac
blacklist i82975x_edac
blacklist skx_edac
blacklist ie31200_edac
blacklist sb_edac
blacklist i5400_edac
blacklist e752x_edac
blacklist i10nm_edac
blacklist edac_mce_amd
blacklist i5100_edac
blacklist i3200_edac
blacklist i7300_edac
blacklist i3000_edac
blacklist x38_edac
blacklist amd64_edac
 е една идея по-добре с грешките, но без тези модули не работи ras-mc-ctl .....
--
Какво съм пробвал (освен описаното до тук):
- преинсталирах Debian-a
- смених PCI слота на wifi картата
- сменях позиции на плочките памет
- сложих FreeBSD - пак има проблеми в dmesg, даже забива
- махнах wifi картата и карах на кабел - няма дъмповете свързани с wifi-a. Също (ми се струва), че грепките на паметта са по-малко.

Какво не съм пробвал:
- да сваля процесора да видя дали няма огънати пинове които да накъсяват.

по някаква странна причина ubuntu 24.04 не зарежда от USB (дори и 8 GB флашка, защото доказано не зарежда 16G). От същата флашка зарежда debian (в BIOS-a e на legacy).
компа го имам от месец, не се изкл проблем с дъното, с чипсета).

Няма проблем с прегряването:
# sensors
coretemp-isa-0000
Adapter: ISA adapter
Package id 0:  +43.0°C  (high = +85.0°C, crit = +95.0°C)
Core 0:        +39.0°C  (high = +85.0°C, crit = +95.0°C)
Core 1:        +39.0°C  (high = +85.0°C, crit = +95.0°C)
Core 2:        +38.0°C  (high = +85.0°C, crit = +95.0°C)
Core 3:        +38.0°C  (high = +85.0°C, crit = +95.0°C)
Core 4:        +40.0°C  (high = +85.0°C, crit = +95.0°C)
Core 5:        +39.0°C  (high = +85.0°C, crit = +95.0°C)
Core 8:        +38.0°C  (high = +85.0°C, crit = +95.0°C)
Core 9:        +39.0°C  (high = +85.0°C, crit = +95.0°C)
Core 10:       +40.0°C  (high = +85.0°C, crit = +95.0°C)
Core 11:       +39.0°C  (high = +85.0°C, crit = +95.0°C)
Core 12:       +39.0°C  (high = +85.0°C, crit = +95.0°C)
Core 13:       +39.0°C  (high = +85.0°C, crit = +95.0°C)

nouveau-pci-0300
Adapter: PCI adapter
GPU core:      1.01 V  (min =  +0.60 V, max =  +1.20 V)
fan1:        1530 RPM
temp1:        +47.0°C  (high = +95.0°C, hyst =  +3.0°C)
                       (crit = +105.0°C, hyst =  +5.0°C)
                       (emerg = +135.0°C, hyst =  +5.0°C)

dell_smm-isa-0000
Adapter: ISA adapter
Processor Fan: 1056 RPM  (min =    0 RPM, max = 4520 RPM)
Other Fan:        0 RPM
Other Fan:     1001 RPM  (min =    0 RPM, max = 5000 RPM)
CPU:            +43.0°C 
SODIMM:         +26.0°C 
SODIMM:         +42.0°C 
SODIMM:         +40.0°C 

---
Всяка идея за локализиране на проблема е донре дошла :)
Активен

Acho

  • Напреднали
  • *****
  • Публикации: 5445
  • Distribution: Slackware, MikroTik - сървърно
  • Window Manager: console only
    • Профил
    • WWW
Re: странен (хардуерен) проблем с памет
« Отговор #1 -: Jun 18, 2024, 07:24 »
Без да съм изчел целия този ферман (няма да имам чак толкова нервички за хабене), щом има някакво съмнение за проблем с паметта, пускан ли е някакъв MemTest ?

Ама не набързо, там на две на три. Ами да си мине целия тест, колкото време му е нужно.
Активен

CPU - Intel Quad-Core Q8400, 2.66 GHz; Fan - Intel Box; MB - Intel G41M-T2; RAM - DDR2-800, Kingston HyperX, 2X2048 MB; VC - onboard, Intel G41 Express Chipset; HDD - Toshiba, 500 GB, SATAII; SB - Realtek HD Audio; DVD-RW - TSSTcorp DVD-RW; LAN - Realtek PCI-E GBE Controller; PSU - Fortron 350 Watt.

Naka

  • Напреднали
  • *****
  • Публикации: 3422
    • Профил
Re: странен (хардуерен) проблем с памет
« Отговор #2 -: Jun 18, 2024, 12:48 »
много пъти съ го писал тук, но когато има съмнения за памет....или изобщо нещо по веригиата процесор-дъно-памет.

Най-добре си личи по чексумите. Даде ли ти само един път грешна чек сума - значи 100% има хардуерни грешки!!!

Как става на практика. Правиш си на някой друг компютър една sha1sum или md5sum(по бърза е) на един гоилям файл 1-4Гб (например на накой филм). sha1sum filma.avi > filma.sha1
Алтернативно може да си смъкнеш някакво iso на дистро. Вървят си с чек суми.



Връщаш се в проблемия компютър и почваш sha1sum -c filma.sha1

и така поне 10-20 пъти. Само един път да избие -значи имаш хардуерен проблем.
« Последна редакция: Jun 18, 2024, 12:51 от Naka »
Активен

Perl - the only language that looks the same before and after encryption.

Naka

  • Напреднали
  • *****
  • Публикации: 3422
    • Профил
Re: странен (хардуерен) проблем с памет
« Отговор #3 -: Jun 18, 2024, 13:00 »
Цитат
някакви идеи как да хвана проблема от къде идва?

паметите нали подържаха два профайла на циклите. Единият е XMP (на intel), другия май беше стандартния на JEDEC. пробвай от биоса да ги смениш, (ако ти дава така възможност де). Или си поиграй с циклите. Само онова първото число. CAS latency.


Цитат
За да стане по-интересно, имам стари плочки памет 4х 4G, 2133 Mhz - като ги сложа грешки няма.
Като сложа 4х 32G, 2400 Mhz - започват проблемите.

голям праз като не ти работи на 2400. Няма да стане кой знае колко по-бавно.
« Последна редакция: Jun 18, 2024, 13:04 от Naka »
Активен

Perl - the only language that looks the same before and after encryption.

kuunlaaksot

  • Напреднали
  • *****
  • Публикации: 177
  • Distribution: CRUX
    • Профил
Re: странен (хардуерен) проблем с памет
« Отговор #4 -: Jun 18, 2024, 14:59 »
Ама не набързо, там на две на три. Ами да си мине целия тест, колкото време му е нужно.

мдам, аз едно време го оставях по цяла нощ да си бичи.
Активен

lunarvalleys

Naka

  • Напреднали
  • *****
  • Публикации: 3422
    • Профил
Re: странен (хардуерен) проблем с памет
« Отговор #5 -: Jun 18, 2024, 16:12 »
Мемтест може въобще да не покаже проблем с паметта, докато чексумите ще избият.

--

В нета пише че това са грешки по ECC и паметта ти е ЕСС.
 Има много такива рапорти по redhat.. И другите.. Може и изобщо да не е хардуерен проблем, а да е някакъв бъг по кърнела. Тази грешка търсил ли си я по нета?

Опитай с лайв диск и някой съвсем по нов кърнел и дистро.

--
Тая памет 2133 дето си я пробвал и няма проблеми и тя ли е ECC?


« Последна редакция: Jun 18, 2024, 18:58 от Naka »
Активен

Perl - the only language that looks the same before and after encryption.

dilyan

  • Напреднали
  • *****
  • Публикации: 189
  • Distribution: Debian, OpenBSD
  • Window Manager: Gnome, xfce
    • Профил
Re: странен (хардуерен) проблем с памет
« Отговор #6 -: Jun 18, 2024, 22:39 »
Всички памети са ЕСС.

Съгласен за чексумите, ама са чисти, докато dmsg показва грешки:

# ras-mc-ctl --error-count
Label                            CE   UE
CPU_SrcID#0_Ha#0_Chan#1_DIMM#0   0   0
CPU_SrcID#0_Ha#1_Chan#1_DIMM#0   0   0
CPU_SrcID#0_Ha#0_Chan#0_DIMM#0   0   0
CPU_SrcID#0_Ha#1_Chan#0_DIMM#0   0   0

пуска ни са мем тестове до край - на БИОС-а и на memtest86+ - чисти като момина сълза.

че имам хардуерен проблем е ясно, но не е ясно къде.
Ще пробвам с друга дистрибуция, белким дебиан нещо не се разбира с таз машина.
Активен

remotexx

  • Напреднали
  • *****
  • Публикации: 3383
    • Профил
Re: странен (хардуерен) проблем с памет
« Отговор #7 -: Jun 19, 2024, 09:17 »
CE - Correctable Error(s)  са коригиращи се т.е. коригирани (вече) грешки а твоите са само такива
UE - Uncorrectable Error(s) не се виждат в лога който си дал
а па в табличката въобще няма нито от едните нито от другите та....

1. не съм сигурен меметест-а лови ли CE или само UE
2. ако и той е като това дето ти вади табличката и той няма да изкара
3. някой грешки се п(р)оявяват само под (як) товар
4. като CE грешки няма да повлияят много на чексумите - пак ще излязат верни (е верно след корекцията на грешките която обаче е  хардуерна и прозрачна т.е. невидима за инструмента)

Как да тестваш - не че ще помогне особено щото то е ясно че проблема е хардуерен, но

1. каза че с 3 работи, а с 4 не работи независимо дали коя плочка е на последния слот - значи не е от памет (предполагам си слагал работещата от слот 3 на 4 с оная неработещата от 4 на 3 и пак само 4 се дъни - нали т.е. не е от паметта)
2. пробвай ако има такава възможност с 3 но последния/проблемния да е зает а някой друг работещ да е свободен... внимавай там с 2 и 3-каналните дъна каква точно требе да е конфугурацията че да е валидна с последен слот зает а други 1-2 свободни (може и да няма такава) - така ще тестваш дали е от слота
3. ако горното (2.) си работи значи не е от слота ами контролера фърля кърпата под товар и не може да насмогва на 4 х 2400 и както казаха там колегите пробвай с underclock или па що да не и с overclock (ако е бъг некъв дето само на 2400 се изявява - цикада неква синеока.. дето веднъж на 17 години или както му вукат вече - черен лебед)


П.П. има ли нещо подобно на edac-utils за твоето дистро?
Код
GeSHi (Bash):
  1. [root@centos7 ~]# edac-util -v
  2. mc0: 0 Uncorrected Errors with no DIMM info
  3. mc0: 0 Corrected Errors with no DIMM info
  4. mc0: csrow0: 0 Uncorrected Errors
  5. mc0: csrow0: CPU_SrcID#0_Ha#0_Chan#1_DIMM#0: 2187 Corrected Errors
  6. mc0: csrow0: CPU_SrcID#0_Ha#0_Chan#2_DIMM#0: 0 Corrected Errors
  7. mc0: csrow1: 0 Uncorrected Errors
  8. mc0: csrow1: CPU_SrcID#0_Ha#0_Chan#1_DIMM#1: 24464678 Corrected Errors
  9. mc0: csrow1: CPU_SrcID#0_Ha#0_Chan#2_DIMM#1: 3874265 Corrected Errors
  10. mc1: 0 Uncorrected Errors with no DIMM info
  11. mc1: 0 Corrected Errors with no DIMM info
  12. mc1: csrow0: 0 Uncorrected Errors
  13. mc1: csrow0: CPU_SrcID#1_Ha#0_Chan#1_DIMM#0: 0 Corrected Errors
  14. mc1: csrow0: CPU_SrcID#1_Ha#0_Chan#2_DIMM#0: 0 Corrected Errors
  15. mc1: csrow1: 0 Uncorrected Errors
  16. mc1: csrow1: CPU_SrcID#1_Ha#0_Chan#1_DIMM#1: 0 Corrected Errors
  17. mc1: csrow1: CPU_SrcID#1_Ha#0_Chan#2_DIMM#1: 0 Corrected Errors

ако няма - дай едно
Код
GeSHi (Bash):
  1. [root@centos7 ~]# grep "[0-9]" /sys/devices/system/edac/mc/mc*/csrow*/ch*_ce_count
  2. /sys/devices/system/edac/mc/mc0/csrow0/ch1_ce_count:2187
  3. /sys/devices/system/edac/mc/mc0/csrow0/ch2_ce_count:0
  4. /sys/devices/system/edac/mc/mc0/csrow1/ch1_ce_count:24464678
  5. /sys/devices/system/edac/mc/mc0/csrow1/ch2_ce_count:3874265
  6. /sys/devices/system/edac/mc/mc1/csrow0/ch1_ce_count:0
  7. /sys/devices/system/edac/mc/mc1/csrow0/ch2_ce_count:0
  8. /sys/devices/system/edac/mc/mc1/csrow1/ch1_ce_count:0
  9. /sys/devices/system/edac/mc/mc1/csrow1/ch2_ce_count:0
« Последна редакция: Jun 19, 2024, 09:31 от remotexx »
Активен

remotexx

  • Напреднали
  • *****
  • Публикации: 3383
    • Профил
Re: странен (хардуерен) проблем с памет
« Отговор #8 -: Jun 19, 2024, 09:36 »
интересно обик. препоръчват само blacklist sb_edac - пробвай само с него пак ли няма да ти работи там каквото ти трябваше да работи

или поне само тия: lsmod | grep -i edac

--
Cause
The Linux kernel module sb_edac and the hardware EDAC conflicts with each other and this causes the hardware errors to not write to hardware logs.
-
The memory errors mentioned above don't get logged to hardware logs due to a bug in firmware.
Cisco recommends to disable the "edac" kernel module
by adding blacklist sb_edac to /etc/modprobe.d/50-blacklist.conf

To do that, run the command:

Код
GeSHi (Bash):
  1. echo "blacklist sb_edac" >> /etc/modprobe.d/50-blacklist.conf


Then reboot for the setting to take effect.
« Последна редакция: Jun 19, 2024, 09:38 от remotexx »
Активен

dilyan

  • Напреднали
  • *****
  • Публикации: 189
  • Distribution: Debian, OpenBSD
  • Window Manager: Gnome, xfce
    • Профил
Re: странен (хардуерен) проблем с памет
« Отговор #9 -: Jun 24, 2024, 22:26 »
ами за да стане още по-заплетен случая, смених Debian 12 -> Ubuntu 24.04, махнах wi-fi картата, сложих всичката памет 4х 32 х2400  Mhz... и няма нищо в dmesg свързано с памет, няма грешки, няма лаг, няма забивания.

От време на време се появява някаква драма с nVidia (к2200) dmesg:
[   17.251277] [drm:nv_drm_master_set [nvidia_drm]] *ERROR* [nvidia-drm] [GPU ID 0x00000300] Failed to grab modeset ownership

има и един странен Call trace дето нищо не ми говори:
[ 5867.304389] Call Trace:
[ 5867.304392]  <TASK>
[ 5867.304396]  ? show_regs+0x6d/0x80
[ 5867.304402]  ? __warn+0x89/0x160
[ 5867.304409]  ? drm_gem_shmem_vmap+0x1a5/0x1e0
[ 5867.304412]  ? report_bug+0x17e/0x1b0
[ 5867.304420]  ? handle_bug+0x51/0xa0
[ 5867.304425]  ? exc_invalid_op+0x18/0x80
[ 5867.304429]  ? asm_exc_invalid_op+0x1b/0x20
[ 5867.304437]  ? drm_gem_shmem_vmap+0x1a5/0x1e0
[ 5867.304440]  ? drm_gem_shmem_vmap+0x1a5/0x1e0
[ 5867.304443]  drm_gem_shmem_object_vmap+0x9/0x20
[ 5867.304447]  drm_gem_vmap+0x26/0x80
[ 5867.304454]  drm_gem_vmap_unlocked+0x2b/0x50
[ 5867.304460]  drm_gem_fb_vmap+0x40/0x150
[ 5867.304467]  drm_gem_begin_shadow_fb_access+0x25/0x40
[ 5867.304472]  drm_atomic_helper_prepare_planes.part.0+0x142/0x1e0
[ 5867.304477]  drm_atomic_helper_prepare_planes+0x5d/0x70
[ 5867.304482]  drm_atomic_helper_commit+0x84/0x160
[ 5867.304487]  drm_atomic_commit+0x99/0xd0
[ 5867.304492]  ? __pfx___drm_printfn_info+0x10/0x10
[ 5867.304499]  drm_atomic_helper_set_config+0x82/0xd0
[ 5867.304503]  drm_mode_setcrtc+0x535/0x8b0
[ 5867.304509]  ? nv_drm_gem_prime_fence_attach_ioctl+0x1ff/0x390 [nvidia_drm]
[ 5867.304528]  ? __pfx_drm_mode_setcrtc+0x10/0x10
[ 5867.304531]  drm_ioctl_kernel+0xbc/0x120
[ 5867.304536]  drm_ioctl+0x2d4/0x550
[ 5867.304540]  ? __pfx_drm_mode_setcrtc+0x10/0x10
[ 5867.304546]  __x64_sys_ioctl+0xa3/0xf0
[ 5867.304551]  x64_sys_call+0x143b/0x25c0
[ 5867.304555]  do_syscall_64+0x7f/0x180
[ 5867.304562]  ? do_syscall_64+0x8c/0x180
[ 5867.304567]  ? do_syscall_64+0x8c/0x180
[ 5867.304572]  ? irqentry_exit+0x43/0x50
[ 5867.304576]  ? exc_page_fault+0x94/0x1b0
[ 5867.304579]  entry_SYSCALL_64_after_hwframe+0x78/0x80
[ 5867.304584] RIP: 0033:0x752f325bdded
[ 5867.304606] Code: 04 25 28 00 00 00 48 89 45 c8 31 c0 48 8d 45 10 c7 45 b0 10 00 00 00 48 89 45 b8 48 8d 45 d0 48 89 45 c0 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff ff 77 1a 48 8b 45 c8 64 48 2b 04 25 28 00 00 00
[ 5867.304609] RSP: 002b:00007ffce13e5230 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
[ 5867.304613] RAX: ffffffffffffffda RBX: 000062e0645d90c0 RCX: 0000752f325bdded
[ 5867.304616] RDX: 00007ffce13e52c0 RSI: 00000000c06864a2 RDI: 0000000000000014
[ 5867.304618] RBP: 00007ffce13e5280 R08: 0000000000000000 R09: 000062e064920c20
[ 5867.304620] R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffce13e52c0
[ 5867.304622] R13: 00000000c06864a2 R14: 0000000000000014 R15: 000062e06447c418
[ 5867.304627]  </TASK>
[ 5867.304628] ---[ end trace 0000000000000000 ]---

за сега не пипам нищо и пасувам.
Активен

remotexx

  • Напреднали
  • *****
  • Публикации: 3383
    • Профил
Re: странен (хардуерен) проблем с памет
« Отговор #10 -: Jun 25, 2024, 08:44 »
...само да не се окаже че "странния Call trace" е баш когато/защото се опитва да логва е те точно тия грешки  ;D
« Последна редакция: Jun 25, 2024, 08:46 от remotexx »
Активен

Naka

  • Напреднали
  • *****
  • Публикации: 3422
    • Профил
Re: странен (хардуерен) проблем с памет
« Отговор #11 -: Jun 25, 2024, 14:29 »
Цитат
От време на време се появява някаква драма с nVidia

На nvidia не разчитай на драйвера от дистрото. Независимо дали е свободния или затворения.

Аз винаги съм си смъквал драйвера от сайта на nvidia. И съм го билдвал. Има си прекрасен инсталационен скрип. Само ти трябват да имаш инсталирани кърнелските хедъръри. Скрипта всичко сам си прави… Компирира кърлеския модул, инсталира го, инсталира nvidia-иските OpenGL библиотеки (затворени) прави си промени по системата - линкове и т.н. Изобщо много културно направено. След това забравяш, че имаш нвидиа.

----
Имаше и едно меню на инсталационния скрип - дето те пита дали при смяна на кърнела, да се прекомилира автоматично модула .... как се казваше това??? Ползата е че ако утре си ъпгрейтнеш кърнела....при рестарт първия път се завърта някакъв скрипт и модула се ъпгрейтва автоматично....Иначе ако не си отговорил с [Y], ще трябва пак да пускаш инсталационния скрип на драйвера и то в конзола, без X.
« Последна редакция: Jun 25, 2024, 14:49 от Naka »
Активен

Perl - the only language that looks the same before and after encryption.

Naka

  • Напреднали
  • *****
  • Публикации: 3422
    • Профил
Re: странен (хардуерен) проблем с памет
« Отговор #12 -: Jun 25, 2024, 14:43 »
Цитат
сложих всичката памет 4х 32 х2400  Mhz... и няма нищо в dmesg свързано с памет, няма грешки,

Е 1-2 пъти в годината, може да се случи някоя ECC грешка. Това било свързано с alpha радиоктивен разпад в корпуса на паметта. Цепи се някой атом...най вероятно радиоактивни примеси/замърсявания в пласмасата. алфа частицата удря чипа и преобръща някоя клетка.

Но това и е смисъла на ECC. Да корегира точно такива случайни грешки. Много ми е любопитно колко често се случват такива събития???

« Последна редакция: Jun 25, 2024, 14:46 от Naka »
Активен

Perl - the only language that looks the same before and after encryption.

Nik123

  • Напреднали
  • *****
  • Публикации: 3300
  • Distribution: Mageia, Q4OS
    • Профил
Re: странен (хардуерен) проблем с памет
« Отговор #13 -: Jun 25, 2024, 15:37 »
..
----
Имаше и едно меню на инсталационния скрип - дето те пита дали при смяна на кърнела, да се прекомилира автоматично модула .... как се казваше това??? Ползата е че ако утре си ъпгрейтнеш кърнела....при рестарт първия път се завърта някакъв скрипт и модула се ъпгрейтва автоматично....Иначе ако не си отговорил с [Y], ще трябва пак да пускаш инсталационния скрип на драйвера и то в конзола, без X.

В магеята има подобно чудо, но доколкото се сещам, не беше от нвидията, а от дистрото- dkms (dynamic kernel module support). Нвидията  я имаше в мирърите и си идваше оттам, барабар с тая екстра (пакетирано),  казваше се  dkms-nvidia, по спомен. За дебиан-базираните не знам (вероятно и там си е налице, но не съм се интересувал), при по-известните .рпм (магея, федора, РХЕЛ) го има това dkms.

П.П. Извинявам се за офтопика.

П.П.П. Даже на който му се играе, може сам да си го направи dkms пакета на нвидията (за .рпм-ските, за дебиана да кажат запознатите):
https://github.com/NVIDIA/yum-packaging-dkms-nvidia
« Последна редакция: Jun 25, 2024, 16:11 от Nik123 »
Активен

Naka

  • Напреднали
  • *****
  • Публикации: 3422
    • Профил
Re: странен (хардуерен) проблем с памет
« Отговор #14 -: Jun 25, 2024, 16:39 »
Да бе. Dkms се казваше. Този скрипт от nvidia като те попиташе дали да ти направи DKMS 'драйвер' се отговаряше с YES. Обикновенно казвах No, щото не знаех какво е, ама след време като се научих на убавото почнах го ползвам и този 'тарикатлък'
Активен

Perl - the only language that looks the same before and after encryption.