Aiming to mostly replicate the build from @Stux (with some mods, hopefully around about as good as that link)
- 4 xSamsung 850 EVO Basic (500GB, 2.5″) — — VMs/Jails
- 1 xASUS Z10PA-D8 (LGA 2011-v3, Intel C612 PCH, ATX) — — Dual socket MoBo
2 xWD Green 3D NAND (120GB, 2.5″) — — Boot drives (maybe mess around trying out the thread to put swap here too link)- 1 x Kingston UV400 120GB SSD — boot drive (hit the 3D NAND/TRIM bug with the original WD green selection, failing scrub and showing as corrupted OS files) Decided to go with no mirror and use the config backup script
- 2 xIntel Xeon E5-2620 v4 (LGA 2011-v3, 2.10GHz) — — 8 core/16 threads per Chip
- 2 xNoctua NH-U9S (12.50cm)
- 1 xCorsair HX1200 (1200W) — PSU to support 24 HDD + several SSD and PCI cards
- 4 xKingston Value RAM (32GB, DDR4-2400, ECC RDIMM 288)
- 2 xNoctua NF-A8 PWM Premium 80mm PC Computer Case Fan
3 xNoctua NF-F12 PWM Cooling Fan- 3 xNoctua NF-F12 PPC 3000 PWM (120mm) * having noted later in Stux’s thread that 1500 RPM is not sufficient to cool the HDDs. Corsair Commander Pro to control the fans (see script and code)
- 1 xNORCO 4U Rack Mount 24 x Hot-Swappable SATA/SAS 6G Drive Bays Server Rack mount RPC-4224
- 6 xCableCreation Internal Mini SAS HD Cable, Mini SAS SFF-8643 to Mini SAS 36Pin SFF-8087 Cable
- 1 xLSI Logic Controller Card 05-25699-00 9305-24i 24-Port SAS 12Gb/s PCI-Express 3.0 Host Bus Adapter
- TrueNAS Core 13.0-U3.1
- Use existing Drives 8 x10TB WD Red, 8 x4TB WD Purple, + a mix of WD Purple and shucked WD Elements 12TB x 8
ESXi-pfSense-FreeNAS-Docker host
CASE: Fractal Node 804
MB: ASUS x-99M WS
CPU: Xeon E5-2620v4 + Corsair H60 Cooler block
RAM: CRUCIAL 64GB DDR4-2133 ECC RDIMMs
HDD: WD RED 3TBx8
SSD: 4 xSamsung 850 EVO Basic (500GB, 2.5″) — — VMs/Jails
HBA: LSI 9300-16i
OS: 1 x Kingston UV400 120GB SSD — boot drive
PSU: Corsair RM1000
Version: TrueNAS CORE 13.0 -U3.1
FANS: 3xFractal R3 120mm — 3 Front, 1 Rear. Corsair Commander Pro to control the fans (see script and code)
CPU FAN: 1xCorsair H60 CPU Radiator — Front
NIC: Intel EXPI9402PTBLK Pro, Dual-Gigabit Adapter (plus the 2 onboard Intel NICs, 1x 210, 1x 218)
VM/Docker host, using ESXi and running pfSense alongside FreeNAS (separate Dual Intel NIC added, dedicated to the pfSense VM)
Other Systems
TrueNAS CORE test system:
CASE: Old Silverstone HTPC case
MB: ASUS x-99M WS
CPU: Xeon E5-2620v4 + Corsair H60 Cooler block
RAM: CRUCIAL 32GB DDR4-2133 ECC RDIMMs
HDD: WD RED 8TBx3
OS: 1 x Kingston UV400 120GB SSD — boot drive
PSU: Corsair RM1000
Version: TrueNAS CORE 13.0-U3
SCALE Cluster:
2x Intel NUCs running TrueNAS SCALE 22.12 RC1
64GB RAM
10th Generation Intel i7
Samsung NVME SSD 1TB, QVO SSD 1TB
Boot from Samsung Portable T7 SSD USBC
CASE: Fractal Node 304 running TrueNAS SCALE 22.12 RC1
MB: ASUS P10S-I Series
RAM: 32 GB
CPU: Intel(R) Xeon(R) CPU E3-1240L v5 @ 2.10GHz
HDD: 3 WD REDs and a few SSDs
PSU: Fractal ION 2+ 650W
Кроме этой надписи есть проблемы? Если нет — забей, в биосе что-то кривое, он тебе просто об этом сообщил.
firkax ★★★
(06.01.22 19:29:28 MSK)
- Показать ответы
- Ссылка
Ответ на:
комментарий
от firkax 06.01.22 19:29:28 MSK
Кроме этой надписи есть проблемы?
Есть еще проблема… Внизу пишет «A start job is running for..» и грузит дополнительно полторы минуты.
- Ссылка
Error … broken
это он тебе напоминает, что на амд ecc везде работает, не то, что на интоле
anonymous
(06.01.22 19:35:02 MSK)
- Ссылка
Ответ на:
комментарий
от firkax 06.01.22 19:29:28 MSK
Ответ на:
комментарий
от i586 06.01.22 19:44:25 MSK
Ответ на:
комментарий
от TheLinuxUser 06.01.22 19:49:14 MSK
Ответ на:
комментарий
от i586 06.01.22 19:53:29 MSK
Какой-нибудь новомодный Ryzen, да?
Нет, материнка: Asus F2A85-M LE и процессор: AMD Athlon X4 740 (3.2-3.8)
- Показать ответы
- Ссылка
Ответ на:
комментарий
от TheLinuxUser 06.01.22 19:58:08 MSK
Ответ на:
комментарий
от gremlin_the_red 06.01.22 20:16:18 MSK
Биос до последнего обновлял?
Неа, как в 2012 купил, так и не трогал впринципе ) Стоит обновить и ошибка уйдет ?
- Показать ответы
- Ссылка
Ответ на:
комментарий
от TheLinuxUser 06.01.22 19:58:08 MSK
Раз ЕСС все равно нет – на это сообщение обращать внимание не надо. Биос обновлять тоже не надо.
i586 ★★★★
(06.01.22 20:24:49 MSK)
- Показать ответ
- Ссылка
Ответ на:
комментарий
от i586 06.01.22 20:24:49 MSK
Раз ЕСС все равно нет – на это сообщение обращать внимание не надо. Биос обновлять тоже не надо.
Так на Debian 9 такого не было.. Это с Debian 11 что-то поменялось?
- Показать ответ
- Ссылка
Ответ на:
комментарий
от TheLinuxUser 06.01.22 20:23:33 MSK
Человеку по ссылке помогло. На таком же чипсете. Причём в чейнджлоге нового биоса было прямо написано, что «улучшена совместимость с некоторыми модулями памяти».
- Ссылка
Ответ на:
комментарий
от TheLinuxUser 06.01.22 20:34:23 MSK
Так на Debian 9 такого не было.. Это с Debian 11 что-то поменялось?
В ядре с тех пор могли добавить/улучшить разные подсистемы диагностики.
- Показать ответ
- Ссылка
Тебе сообщили, что у тебя может не работать функция ECC для оперативной памяти. Это коррекция ошибок, но чтобы это работало, оперативная память тоже должна это поддерживать. Если у тебя обычная память — можешь забить.
- Ссылка
Ответ на:
комментарий
от gremlin_the_red 06.01.22 20:59:55 MSK
Ответ на:
комментарий
от gag 06.01.22 21:11:27 MSK
Так тож дэбиан! Закопать и забыть…
anonymous
(06.01.22 21:25:38 MSK)
- Ссылка
Ответ на:
комментарий
от anonymous 06.01.22 21:19:01 MSK
С новыми ядрами 5.14+ стало появляться предупреждение, до этого — всё в порядке. Возможно, регрессия.
gag ★★★★★
(06.01.22 21:26:41 MSK)
- Показать ответ
- Ссылка
Ответ на:
комментарий
от TheLinuxUser 06.01.22 19:58:08 MSK
материнка: Asus F2A85-M LE
Вам крупно повезло: ваша плата поддерживается опенсорсным БИОСом coreboot — который намного более высокого качества, чем проприетарщина лохматого года которая у вас сейчас стоит.
SakuraKun ★★★★★
(06.01.22 22:10:01 MSK)
- Показать ответы
- Ссылка
Ответ на:
комментарий
от gag 06.01.22 21:26:41 MSK
А регрессия-то в чём? До этого ядро незнакомые параметры просто заносило в environment, чтобы init дальше мог парсить и делать разное, теперь ещё и в лог пишет. Например, чтобы очевиднее находились опечатки (lapix=no
вместо lapic=no
etc), потому что иначе и работать, как ожидаемо, не будет, и ошибок в dmesg тоже не будет, вот и чеши репу.
- Показать ответ
- Ссылка
Ответ на:
комментарий
от SakuraKun 06.01.22 22:10:01 MSK
Так себе везение, сидеть с устаревшим хламом. ТС вероятно неспроста шарится по dmesg, видимо железо уже не устраивает подсознательно…
anonymous
(06.01.22 22:45:59 MSK)
- Ссылка
Ответ на:
комментарий
от gremlin_the_red 06.01.22 22:20:55 MSK
А регрессия-то в чём?
Типичный параметр, вдруг, перестал распознаваться. В данном случае оказалось, что это не регрессия, а хорошая фича. Но на багтрекере закрыли с утверждением без хотя бы краткого обоснования.
gag ★★★★★
(06.01.22 23:04:31 MSK)
- Показать ответы
- Ссылка
Ответ на:
комментарий
от gag 06.01.22 23:04:31 MSK
Это вообще не параметр ядра, и они никогда не «распознавался» и не должен был.
anonymous
(06.01.22 23:07:39 MSK)
- Показать ответ
- Ссылка
Ответ на:
комментарий
от anonymous 06.01.22 23:07:39 MSK
Тогда, как выше заметили, для облегчения диагностики, такие аргументы не для ядра следует помечать, а не бить тревогу при каждой загрузке.
gag ★★★★★
(06.01.22 23:20:26 MSK)
- Ссылка
Ответ на:
комментарий
от gag 06.01.22 23:04:31 MSK
Но на багтрекере закрыли с утверждением без хотя бы краткого обоснования
Возможно банальное непонимание проблем индейцев шерифом. Кто создавал баг просто не знал, что BOOT_IMAGE никогда не был параметром ядра, а кто закрывал, наоборот, всегда прекрасно это знал, вот и не подумал, что для кого-то это может быть неочевидно — ведь все официальные параметры есть в документации, которую, вроде как, положено читать.
- Ссылка
Ответ на:
комментарий
от TheLinuxUser 06.01.22 19:58:08 MSK
Была подобная проблема у клиента с этим процом не так давно. Как лечил не помню, но материнка была MSI.
sparkie ★★
(06.01.22 23:37:34 MSK)
- Ссылка
Ответ на:
комментарий
от TheLinuxUser 06.01.22 20:23:33 MSK
Неа, как в 2012 купил, так и не трогал впринципе
Сурово. Обновись.
- Ссылка
Ответ на:
комментарий
от SakuraKun 06.01.22 22:10:01 MSK
Псих? К врачу, срочно!
anonymous
(07.01.22 17:14:05 MSK)
- Ссылка
Description
Julian Sikorski
2020-12-09 20:48:33 UTC
I have just upgraded my Ryzen 5 2600 to a 5600x. Now dmesg contains a dozen or so messages like: [ 5.143217] EDAC amd64: F19h detected (node 0). [ 5.143225] EDAC amd64: Error: F0 not found, device 0x1650 (broken BIOS?) I am not sure whether it has any negative effects, the system seems stable when running Linux.
Comment 1
Julian Sikorski
2020-12-11 16:46:21 UTC
This is fixed in 5.10rc7.
Comment 2
Priit O.
2021-01-02 19:41:26 UTC
Not fixed! Using kernel 5.10.2, X570 motherboard, 5950X, Vega 64. EDAC amd64: Error: F0 not found, device 0x1650 (broken BIOS?)
Comment 4
Julian Sikorski
2021-01-16 16:21:47 UTC
With 5.10.6-200.fc33.x86_64: [ 4.899884] EDAC amd64: F19h_M20h detected (node 0). [ 4.899927] EDAC amd64: Node 0: DRAM ECC disabled. [ 4.942858] nct6775: Found NCT6792D or compatible chip at 0x2e:0x290 [ 4.942915] EDAC amd64: F19h_M20h detected (node 0). [ 4.943054] EDAC amd64: Node 0: DRAM ECC disabled.
Comment 5
Sophie
2021-01-18 09:44:52 UTC
(In reply to Priit O. from comment #2)
> Not fixed! Using kernel 5.10.2, X570 motherboard, 5950X, Vega 64.
>
> EDAC amd64: Error: F0 not found, device 0x1650 (broken BIOS?)
After upgrading to 5.10.7, I don't receive the original EDAC amd64: Error: F0 not found, device 0x1650 (broken BIOS?) that you mentioned. Can you confirm?
Comment 6
Priit O.
2021-01-18 21:38:30 UTC
Meanwhile I upgraded my MB bios from 7C84v14 -- AMD AGESA ComboAm4v2PI 1.1.0.0 Patch C to 7C84v153(Beta version) -- ComboAM4PIV2 1.1.9.0 and kernel remained the same 5.10.2 and I don't see the error anymore...
Comment 7
powderluv
2021-02-09 06:35:26 UTC
This is still reproducible on 5.11-rc7. I am on a 5950x on a MSI MEG X570 Godlike motherboard with their latest bios 7C34v1C6(Beta version) - Update to ComboAM4PIV2 1.2.0.0 - Support S.A.M technology (Re-size BAR function) to enhance GPU performance for AMD Radeon RX 6000 series.
Comment 8
powderluv
2021-02-09 18:55:43 UTC
reducing the DDR from 2666 to 2133 (and disable memory fast boot) seems to have solved the issue. Can't recreate it with a few (n=5) reboots. Now it says: [ 7.201069] EDAC amd64: F19h_M20h detected (node 0). [ 7.201133] EDAC amd64: Node 0: DRAM ECC disabled.
Comment 9
Gurenko Alex
2021-03-14 12:26:46 UTC
Still happening on kernel 5.11.5: [6.107573] EDAC amd64: F19h_M20h detected (node 0). [6.107608] EDAC amd64: Node 0: DRAM ECC disabled. 5900X, MSI X570 Tomahawk
Comment 10
Priit O.
2021-03-14 12:40:26 UTC
@Gurenko your message seems to be "OK" version ;) "bad" one was with "error" and "(broken BIOS?)" texts: [ 5.143225] EDAC amd64: Error: F0 not found, device 0x1650 (broken BIOS?)
Comment 11
Gurenko Alex
2021-03-14 12:54:29 UTC
(In reply to Priit O. from comment #10)
> @Gurenko your message seems to be "OK" version ;)
> "bad" one was with "error" and "(broken BIOS?)" texts:
> [ 5.143225] EDAC amd64: Error: F0 not found, device 0x1650 (broken BIOS?)
Right, sorry, too many tabs open, confused it with BZ for spamming this message that was also supposed to be fixed back around 5.5 kernel :)
Comment 12
Victor Yon
2021-04-30 14:55:50 UTC
I had a similar issue, same message but with an annoying keyboard problem (it randomly disabled during few seconds). And the issue wasn't specific to Linux, I had the same keyboard trouble on Windows. This happened after BIOS update (MPG B550 GAMING EDGE WIFI MS-7C91 V1.5) + installing a new CPU (Ryzen 5800x). I fixed this with another bios update (v1.5 -> V1.63 beta), without any kernel update. So it seems to be a BIOS issue, not a kernel issue.
This document (7024197) is provided subject to the disclaimer at the end of this document.
Environment
SUSE Linux Enterprise Server 15 Service Pack 1 (SLES 15 SP1)
Situation
On DELL EMC AMD Rome CPU based Servers, after booting into SUSE Linux Enterprise Server 15 SP1 the kernel log may contain ‘EDAC amd64: Error: F0 not found, device 0x1460 (broken BIOS?)’.
This issue may occur on the following platforms:
Dell EMC PowerEdge R6515
Dell EMC PowerEdge R6525
Dell EMC PowerEdge C6515
Dell EMC PowerEdge R7515
Dell EMC PowerEdge R7525
Resolution
Update the kernel to version 4.12.14-197.18.1 or higher.
Cause
The error ‘EDAC amd64: Error: F0 not found, device 0x1460 (broken BIOS?)’ is generated because the AMD ROME CPU enablement is not present in the kernel EDAC driver. Required enablement is added in the fixed SLES 15 SP1 kernel.
Disclaimer
This Support Knowledgebase provides a valuable tool for SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented «AS IS» WITHOUT WARRANTY OF ANY KIND.
- Document ID:7024197
- Creation Date:
22-Oct-2019 - Modified Date:23-Apr-2021
-
- SUSE Linux Enterprise Server
< Back to Support Search
For questions or concerns with the SUSE Knowledgebase please contact: tidfeedback[at]suse.com
SUSE Support Forums
Get your questions answered by experienced Sys Ops or interact with other SUSE community experts.
Join Our Community
Open an Incident
Open an incident with SUSE Technical Support, manage your subscriptions, download patches, or manage user access.
Go to Customer Center
Debian Bug report logs —
#975686
EDAC amd64: Error:F0 not found, device 0x1650 (broken BIOS?)
Toggle useless messages
Report forwarded
to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>
:
Bug#975686
; Package linux-image-amd64
.
(Wed, 25 Nov 2020 05:03:03 GMT) (full text, mbox, link).
Acknowledgement sent
to Mark James <tarotapprentice@yahoo.com>
:
New Bug report received and forwarded. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>
.
(Wed, 25 Nov 2020 05:03:03 GMT) (full text, mbox, link).
Message #5 received at submit@bugs.debian.org (full text, mbox, reply):
Package: linux-image-amd64 Version: 5.8.10-1~bpo10+1 Recently upgraded a Ryzen 3900X system to a 5900X. Upon boot I get this message repeated 24 times. EDAC amd64: Error: F0 not found, device 0x1650 (broken BIOS?) I also tried the 5.9.6 kernel from buster and it did the same. Is there an upstream patch to enable device 0x1650 in the amd64 EDAC code? A search suggests (for other Linux distributions) to upgrade the kernel, however I am running a fairly recent one from buster-backports and have tried the one from bullseye.
Information forwarded
to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>
:
Bug#975686
; Package linux-image-amd64
.
(Mon, 30 Nov 2020 12:30:03 GMT) (full text, mbox, link).
Acknowledgement sent
to TarotApprentice <tarotapprentice@yahoo.com>
:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>
.
(Mon, 30 Nov 2020 12:30:03 GMT) (full text, mbox, link).
Message #10 received at 975686@bugs.debian.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
Tried kernel 5.9.9 from bullseye and it has the same EDAC issue
[Message part 2 (text/html, inline)]
Information forwarded
to debian-bugs-dist@lists.debian.org, Debian Kernel Team <debian-kernel@lists.debian.org>
:
Bug#975686
; Package linux-image-amd64
.
(Mon, 14 Dec 2020 03:57:02 GMT) (full text, mbox, link).
Acknowledgement sent
to Mark James <tarotapprentice@yahoo.com>
:
Extra info received and forwarded to list. Copy sent to Debian Kernel Team <debian-kernel@lists.debian.org>
.
(Mon, 14 Dec 2020 03:57:02 GMT) (full text, mbox, link).
Message #15 received at 975686@bugs.debian.org (full text, mbox, reply):
According to the upstream bug #210593 the patch is in 5.10 rc7.
Marked as fixed in versions linux-signed-amd64/5.10~rc4+1~exp1.
Request was from Salvatore Bonaccorso <carnil@debian.org>
to control@bugs.debian.org
.
(Mon, 14 Dec 2020 10:24:02 GMT) (full text, mbox, link).
Marked Bug as done
Request was from Salvatore Bonaccorso <carnil@debian.org>
to control@bugs.debian.org
.
(Mon, 14 Dec 2020 10:24:03 GMT) (full text, mbox, link).
Notification sent
to Mark James <tarotapprentice@yahoo.com>
:
Bug acknowledged by developer.
(Mon, 14 Dec 2020 10:24:03 GMT) (full text, mbox, link).
Message sent on
to Mark James <tarotapprentice@yahoo.com>
:
Bug#975686.
(Mon, 14 Dec 2020 10:24:05 GMT) (full text, mbox, link).
Message #26 received at 975686-submitter@bugs.debian.org (full text, mbox, reply):
close 975686 5.10~rc4-1~exp1 thanks
Bug archived.
Request was from Debbugs Internal Request <owner@bugs.debian.org>
to internal_control@bugs.debian.org
.
(Tue, 12 Jan 2021 07:31:28 GMT) (full text, mbox, link).
Send a report that this bug log contains spam.
Debian bug tracking system administrator <owner@bugs.debian.org>.
Last modified:
Thu Feb 9 10:46:19 2023;
Machine Name:
bembo
Debian Bug tracking system
Debbugs is free software and licensed under the terms of the GNU
Public License version 2. The current version can be obtained
from https://bugs.debian.org/debbugs-source/.
Copyright © 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson,
2005-2017 Don Armstrong, and many other contributors.
-
#1
updated my system to new kernel 5.10.2 and now in addition to previous woes:
Code:
jaan 02 03:21:20 Zen kernel: [Hardware Error]: Corrected error, no action required.
jaan 02 03:21:20 Zen kernel: [Hardware Error]: CPU:0 (19:21:0) MC27_STATUS[Over|CE|MiscV|-|-|-|SyndV|-|-|-]: 0xd82000000002080b
jaan 02 03:21:20 Zen kernel: [Hardware Error]: IPID: 0x0001002e00000500, Syndrome: 0x000000005a020001
jaan 02 03:21:20 Zen kernel: [Hardware Error]: Power, Interrupts, etc. Ext. Error Code: 2, Link Error.
jaan 02 03:21:20 Zen kernel: [Hardware Error]: cache level: L3/GEN, mem/io: IO, mem-tx: GEN, part-proc: SRC (no timeout)
jaan 02 03:31:48 Zen kernel: [Hardware Error]: Corrected error, no action required.
jaan 02 03:31:48 Zen kernel: [Hardware Error]: CPU:0 (19:21:0) MC27_STATUS[-|CE|MiscV|-|-|-|SyndV|-|-|-]: 0x982000000002080b
jaan 02 03:31:48 Zen kernel: [Hardware Error]: IPID: 0x0001002e00000500, Syndrome: 0x000000005a020001
jaan 02 03:31:48 Zen kernel: [Hardware Error]: Power, Interrupts, etc. Ext. Error Code: 2, Link Error.
jaan 02 03:31:48 Zen kernel: [Hardware Error]: cache level: L3/GEN, mem/io: IO, mem-tx: GEN, part-proc: SRC (no timeout)
+
Code:
jaan 02 06:22:22 Zen kernel: __common_interrupt: 1.55 No irq handler for vector
jaan 02 06:22:22 Zen kernel: __common_interrupt: 2.55 No irq handler for vector
jaan 02 06:22:22 Zen kernel: __common_interrupt: 3.55 No irq handler for vector
jaan 02 06:22:22 Zen kernel: __common_interrupt: 4.55 No irq handler for vector
jaan 02 06:22:22 Zen kernel: __common_interrupt: 5.55 No irq handler for vector
jaan 02 06:22:22 Zen kernel: __common_interrupt: 6.55 No irq handler for vector
jaan 02 06:22:22 Zen kernel: __common_interrupt: 7.55 No irq handler for vector
jaan 02 06:22:22 Zen kernel: __common_interrupt: 8.55 No irq handler for vector
jaan 02 06:22:22 Zen kernel: __common_interrupt: 9.55 No irq handler for vector
jaan 02 06:22:22 Zen kernel: __common_interrupt: 10.55 No irq handler for vector
There are some new ones:
Code:
jaan 02 06:56:13 Zen kernel: EDAC amd64: Error: F0 not found, device 0x1650 (broken BIOS?)
jaan 02 06:56:13 Zen kernel: EDAC amd64: Error: F0 not found, device 0x1650 (broken BIOS?)
jaan 02 06:56:14 Zen kernel: EDAC amd64: Error: F0 not found, device 0x1650 (broken BIOS?)
jaan 02 06:56:14 Zen kernel: EDAC amd64: Error: F0 not found, device 0x1650 (broken BIOS?)
jaan 02 06:56:14 Zen kernel: EDAC amd64: Error: F0 not found, device 0x1650 (broken BIOS?)
jaan 02 06:56:14 Zen kernel: EDAC amd64: Error: F0 not found, device 0x1650 (broken BIOS?)
jaan 02 06:56:14 Zen kernel: EDAC amd64: Error: F0 not found, device 0x1650 (broken BIOS?)
jaan 02 06:56:14 Zen kernel: EDAC amd64: Error: F0 not found, device 0x1650 (broken BIOS?)
jaan 02 06:56:14 Zen kernel: EDAC amd64: Error: F0 not found, device 0x1650 (broken BIOS?)
Currently running the newest non-beta BIOS — 7C84v14
Not to mention we still don’t have the resizable BAR support here…
When can we expect the new stable BIOS with resizable BAR and other fixed things??
Last edited: Jan 2, 2021
-
#2
I recommend beta BIOS. Not running linux, but it solved my errors for Windows 10.
-
#3
Currently running the newest non-beta BIOS — 7C84v14
Not to mention we still don’t have the resizable BAR support here…When can we expect the new stable BIOS with resizable BAR and other fixed things??
Sounds like it may only work if you have compatible hardware and no one has dropped that list yet, I can only confirm it is working on my Setup that happens to be all PCI-E_4 hardware.
And well there is a BIOS for it all ready
MAG X570 TOMAHAWK WIFI BIOS
Version
7C84v151(Beta version)
Release Date
2020-11-16
File Size
10.27 MB
Description
— Support AMD SAM(SMART ACCESS MEMORY) function
-
#4
Installing beta software is like asking for trouble. Not paid by MSI to be their beta tester.
-
#5
Installing beta software is like asking for trouble. Not paid by MSI to be their beta tester.
![]()
Well I guess you have no room to complain that it is not available then. When it is up and working.
-
#6
I am on 5.11-rc7 with the latest beta bios 7C34v1C6(Beta version) and still see:
Jan 28 09:23:41 5950x kernel: EDAC amd64: F19h detected (node 0).
Jan 28 09:23:41 5950x kernel: EDAC amd64: Error: F0 not found, device 0x1650 (broken BIOS?)
Upstream kernel bug filed here: https://bugzilla.kernel.org/show_bug.cgi?id=210593
Last edited: Feb 9, 2021
Hi,
thanks for the feedback some comments to that.
why do you enable it then? this is not a bug.
?
Before i ask, what the hell i have enabled, what do i need to disable? xD
Because it’s almost a vanilla Proxmox install, the only thing i do, is:
Code:
- blacklist nvidia/radeon/nouveau/ixgbevf modules (gpu passthrough + x550 sriov virtualization)
- load this modules: vfio vfio_iommu_type1 vfio_pci vfio_virqfd overlay aufs (probably i don't need aufs, but overlay for docker in a container)
- GRUB_CMDLINE_LINUX_DEFAULT="quiet amd_iommu=on iommu=pt nvme_core.default_ps_max_latency_us=1200 textonly video=astdrmfb video=efifb:off SYSTEMD_RDRAND=0"
Then i have some custom scripts, that i wrapped into a Service:
Code:
[Unit]
Description=Script to enable SR-IOV on boot
[Service]
Type=oneshot
# Starting SR-IOV
ExecStart=/usr/bin/bash -c '/usr/bin/echo 2 > /sys/class/net/enp35s0f0/device/sriov_numvfs'
# Setting static MAC for VFs
ExecStart=/usr/bin/bash -c '/usr/bin/ip link set enp35s0f0 vf 0 mac d0:50:99:db:fb:75'
ExecStart=/usr/bin/bash -c '/usr/bin/ip link set enp35s0f0 vf 1 mac d0:50:99:db:fb:76'
# Allow OPNsense to change mac & more
ExecStart=/usr/bin/bash -c '/usr/bin/ip link set enp35s0f0 vf 0 trust on'
ExecStart=/usr/bin/bash -c '/usr/bin/ip link set enp35s0f0 vf 1 trust on'
# Add VM Mac-Addr to dev + myfixes
ExecStart=/usr/bin/bash -c '/root/scripts/vf_add_maddr.sh'
ExecStart=/usr/bin/bash -c '/root/scripts/checkservices.sh'
[Install]
WantedBy=multi-user.target
Code:
#!/usr/bin/bash
# vf_add_maddr.sh script
# script to register mac address of container or VM to the forwarding db of the bridge
# add it to contab for every minutes
#
CTCONFDIR=/etc/pve/nodes/proxmox/lxc
VMCONFDIR=/etc/pve/nodes/proxmox/qemu-server
IFBRIDGE=enp35s0f0
LBRIDGE=vmbr0
echo "=== start ==="
MAC_LIST_VMS=" $(cat ${VMCONFDIR}/*.conf | grep bridge | grep -Eo '([[:xdigit:]]{1,2}[:-]){5}[[:xdigit:]]{1,2}' | tr '[:upper:]' '[:lower:]') $(cat ${CTCONFDIR}/*.conf | grep hwaddr | grep -Eo '([[:xdigit:]]{1,2}[:-]){5}[[:xdigit:]]{1,2}' | tr '[:upper:]' '[:lower:]')"
MAC_ADD2LIST="$(cat /sys/class/net/$LBRIDGE/address)"
MAC_LIST="$MAC_LIST_VMS $MAC_ADD2LIST"
for mactoregister in ${MAC_LIST}
do
if (/usr/sbin/bridge fdb show | grep "${IFBRIDGE} self permanent" | grep -q $mactoregister)
then
echo "MAC $mactoregister already configured"
else
echo "MAC $mactoregister not configured"
echo "i add it with : /usr/sbin/bridge fdb add $mactoregister dev ${IFBRIDGE}"
/usr/sbin/bridge fdb add $mactoregister dev ${IFBRIDGE}
echo "Return code : $? : done for $mactoregister"
fi
done
echo "=== end ==="
Code:
#!/usr/bin/bash
# checkservices.sh script
systemctl is-active --quiet pve-firewall.service || systemctl restart pve-firewall.service
systemctl is-active --quiet pvestatd || systemctl restart pvestatd
systemctl is-active --quiet cron || systemctl restart cron
systemctl is-active --quiet pveproxy.service || systemctl restart pveproxy.service
systemctl is-active --quiet spiceproxy || systemctl restart spiceproxy
systemctl is-active --quiet pve-lxc-syscalld || systemctl restart pve-lxc-syscalld
systemctl is-active --quiet smartmontools || systemctl restart smartmontools
And as last thing, i compiled/installed ixgbe 5.10.2 from intel, because the 5.1 driver in the 5.4 Kernel, doesn’t support 2,5GB/s on x550-t2.
Sometimes it works with 5.1 ixgbe, i get a link with 2,5GB/s, but it randomly disconnects and is hella unstable.
5.10.2 with LRO disabled flag, works with 2,5GB/s!
Thats all my modifications to the default proxmox install xD
Unavailability of new features are not a bug, once a new Kernel is available with the next major release this is available too.
?
Thats the systemd that comes with debian/proxmox, not an updated one from buster-backports or something….
So the question should be then, why are new features included in systemd that aren’t included in Kernel 5.4 or 4.19.
That means, that we get halfbacked not checked updates that could cause issues. (systemd version is 241)
Huh? We do not make three services for the same thing…
But there was some improvement to «is a pool already mounted» detection in a libpve-storage-perl version 6.3-7, so maybe worth to try out that one.
Eham, (Sorry it’s 2 now, was pretty sure there were 3 xD), but still 2:
— zfs-import-cache.service
— zfs-import@.service
Okay, i found my error
HDD-Win doesn’t exist, i forgot that i deleted that pool xD
And i don’t remember if i destroyed that pool via cli or gui xD
So i can simply delete that Service or deactivate it. Sorry, this is my fault, didn’t checked
Older AMD CPU models had this problem and RDRAND was «disabled» (removed from CPUID info so software did not saw that it would be supported) there, but there’s no such patch in current linux tree from Linus, nor is there any patch posted to LKML I could find, here I’d actually perfer to hear this from an amd dev before starting to patch around in CPUID flags, which can be a bit of an delicate matter…
But thanks for posting a workaround, tip: you can use the [icode][/icode] for one liners and [code][/code] BBCode forum tags for multi line text which the forum should not touch (e.g., make smileys out of it) and should be formatted in monospace.
Stable updates nowadays seem lots of backporting, and if there are issues then often just pinging the right devs on a patch, suggesting stable inclusion will do the trick for those times something was not deemed worthy for a backport (or forgotten to think about that).
Proxmox VE 6.x will stay on the 5.4 LTS branch, but we may make a newer one available as opt-in, nothing set in stone yet, though.
About RDRAND, for me it looks clearly like bios/agesa/hardware Problem.
I did contacted Asrock Rack again, will see if they reply at all, because i sended them already a message (a month ago) and they ignored it simply xD
About the opt-in kernel, that would be just amazing
I have tryed already the pve-edge kernel from that github repo, and well, it booted, but almost nothing worked, so i keep my fingers away from that kernel xD
But i seen that many people had success with pve-edge. So yeah. As far i remember, many drivers were missing on my system.
Then i tryed to compile my own pve-5.4 Kernel (vanilla without modifications), the compilation itself was flawless. Then i installed that kernel on my Proxmox host and i had same issues as with pve-edge, almost nothing worked.
However, an opt-in version would be amazing!
If that ever comes, im here to try it
Cheers