Bug 920655 - [abrt]: WARNING: at lib/kobject.c:196 kobject_add_internal+0x1f4/0x260()
Summary: [abrt]: WARNING: at lib/kobject.c:196 kobject_add_internal+0x1f4/0x260()
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 18
Hardware: x86_64
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: abrt_hash:cddf57f6d7df3cb8052a3e3c9c9...
: 866767 877884 951755 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-03-12 13:43 UTC by Moez Roy
Modified: 2013-05-08 00:36 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-05-07 13:15:27 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Comment (101.91 KB, text/plain)
2013-04-06 02:21 UTC, Moez Roy
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 826881 1 None None None 2021-01-20 06:05:38 UTC
Red Hat Bugzilla 878393 1 None None None 2021-01-20 06:05:38 UTC

Internal Links: 826881 878393

Description Moez Roy 2013-03-12 13:43:21 UTC
Additional info:
WARNING: at lib/kobject.c:196 kobject_add_internal+0x1f4/0x260()
Hardware name: To be filled by O.E.M.
kobject_add_internal failed for SbAslBufferPtrVar-01f33c25-764d-43ea-aeea-6b5a41f3f3e8 with -EEXIST, don't try to register things with the same name in the same directory.
Modules linked in:
Pid: 1, comm: swapper/0 Tainted: G        W    3.8.2-206.fc18.x86_64 #1
Call Trace:
 [<ffffffff8105e61f>] warn_slowpath_common+0x7f/0xc0
 [<ffffffff8105e716>] warn_slowpath_fmt+0x46/0x50
 [<ffffffff812f81e4>] kobject_add_internal+0x1f4/0x260
 [<ffffffff812f8773>] kobject_init_and_add+0x63/0x90
 [<ffffffff810593c3>] ? efi_call3+0x43/0x80
 [<ffffffff81501c84>] efivar_create_sysfs_entry+0x124/0x1b0
 [<ffffffff8150234d>] register_efivars+0xdd/0x420
 [<ffffffff81d3df6c>] ? dmi_sysfs_register_handle+0x1bb/0x1bb
 [<ffffffff81d3e026>] efivars_init+0xba/0x108
 [<ffffffff8100215a>] do_one_initcall+0x12a/0x180
 [<ffffffff81d00d9d>] kernel_init_freeable+0x150/0x1da
 [<ffffffff81d00610>] ? do_early_param+0x8c/0x8c
 [<ffffffff81634530>] ? rest_init+0x80/0x80
 [<ffffffff8163453e>] kernel_init+0xe/0xf0
 [<ffffffff816584ac>] ret_from_fork+0x7c/0xb0
 [<ffffffff81634530>] ? rest_init+0x80/0x80

Potential duplicate: bug 866767

Comment 1 Moez Roy 2013-03-12 13:45:36 UTC
[user@localhost ~]$ sudo ls /sys/firmware/efi/vars/
[sudo] password for user: 
AcpiGlobalVariable-af9ffd67-ec10-488a-9dfc-6cbf5ee22c2e
AMITSESetup-c811fa38-42c8-4579-a9bb-60e94eddfb34
BiosSetupType-ec87d643-eba4-4bb5-a1e5-3f3e36b20da9
Boot0000-8be4df61-93ca-11d2-aa0d-00e098032b8c
BootCurrent-8be4df61-93ca-11d2-aa0d-00e098032b8c
BootOptionSupport-8be4df61-93ca-11d2-aa0d-00e098032b8c
BootOrder-8be4df61-93ca-11d2-aa0d-00e098032b8c
ConInDev-8be4df61-93ca-11d2-aa0d-00e098032b8c
ConOutDev-8be4df61-93ca-11d2-aa0d-00e098032b8c
db-d719b2cb-3d3a-4596-a3bc-dad00e67656f
dbx-d719b2cb-3d3a-4596-a3bc-dad00e67656f
DefaultBootOrder-45cf35f6-0d6e-4d04-856a-0370a5b16f53
del_var
DriverHealthCount-7459a7d4-6533-4480-bba7-79e25a4443c9
DriverHlthEnable-0885f288-418c-4be1-a6af-8bad61da08fe
EasyHealthAddress-dd41adf5-4368-4654-b1ca-46a6b98d9e84
EasySmartFanAddress-dd41adf5-4368-4654-b1ca-46a6b98d9e84
EasyTuneSetupAddress-2a64d079-aceb-4ad9-afd5-252e35ba994a
EasyVoltageAddress-dd41adf5-4368-4654-b1ca-46a6b98d9e84
ErrOut-8be4df61-93ca-11d2-aa0d-00e098032b8c
ErrOutDev-8be4df61-93ca-11d2-aa0d-00e098032b8c
GnvsAreaVar-8be4df61-93ca-11d2-aa0d-00e098032b8c
HiiDB-1b838190-4625-4ead-abc9-cd5e6af18fe0
HobRomImage-dde1bc72-d45e-4209-ab85-14462d2f5074
KEK-8be4df61-93ca-11d2-aa0d-00e098032b8c
Lang-8be4df61-93ca-11d2-aa0d-00e098032b8c
LangCodes-8be4df61-93ca-11d2-aa0d-00e098032b8c
MemCeil.-8be4df61-93ca-11d2-aa0d-00e098032b8c
MemMitAttrib-ec87d643-eba4-4bb5-a1e5-3f3e36b20da9
MemoryTypeInformation-4c19049f-4137-4dd3-9c10-8b97a83ffdfa
ME VARIABLE-4b681db5-de3a-46ea-8e0c-a2f7eae1c4b8
ME VAR SHADOW-6b9cfdf4-fcd2-4ea2-d796-7fd06c91f491
MonotonicCounter-8be4df61-93ca-11d2-aa0d-00e098032b8c
MrcS3Resume-87f22dcb-7304-4105-bb7c-317143ccc23b
NBGopPlatformData-ec87d643-eba4-4bb5-a1e5-3f3e36b20da9
NBPlatformData-ec87d643-eba4-4bb5-a1e5-3f3e36b20da9
NetworkStackVar-d1405d16-7afc-4695-bb12-41459d3695a2
new_var
NvRamSpdMap-717fc150-abd9-4614-8015-0b3323eab95c
OA3MSDMvariable-8be4df61-93ca-11d2-aa0d-00e098032b8c
OsIndicationsSupported-8be4df61-93ca-11d2-aa0d-00e098032b8c
PchInit-e6c2f70a-b604-4877-85ba-deec89e117eb
PchS3Peim-e6c2f70a-b604-4877-85ba-deec89e117eb
PK-8be4df61-93ca-11d2-aa0d-00e098032b8c
PlatformLang-8be4df61-93ca-11d2-aa0d-00e098032b8c
PlatformLangCodes-8be4df61-93ca-11d2-aa0d-00e098032b8c
PNP0400_0_NV-560bf58a-1e0d-4d7e-953f-2980a261e031
PNP0400_0_VV-560bf58a-1e0d-4d7e-953f-2980a261e031
PNP0501_0_NV-560bf58a-1e0d-4d7e-953f-2980a261e031
PNP0501_0_VV-560bf58a-1e0d-4d7e-953f-2980a261e031
PNP0501_1_NV-560bf58a-1e0d-4d7e-953f-2980a261e031
PNP0501_1_VV-560bf58a-1e0d-4d7e-953f-2980a261e031
PNP0510_0_NV-560bf58a-1e0d-4d7e-953f-2980a261e031
PNP0510_0_VV-560bf58a-1e0d-4d7e-953f-2980a261e031
PNP0604_0_NV-560bf58a-1e0d-4d7e-953f-2980a261e031
PNP0604_0_VV-560bf58a-1e0d-4d7e-953f-2980a261e031
PreviousMemoryTypeInformation-4c19049f-4137-4dd3-9c10-8b97a83ffdfa
ProcMitAttrib-ec87d643-eba4-4bb5-a1e5-3f3e36b20da9
Profile0-b05e6b5f-6ed8-4015-b5c5-b1049faf3e5b
Profile-1-b05e6b5f-6ed8-4015-b5c5-b1049faf3e5b
Ps2KeyboardDetectRecord-5a47386b-4c41-43b6-a140-824b0260ca8d
Ps2MouseDetectRecord-09b5c46a-0f41-4cee-84ff-f3660a0b08d6
S3SS-4bafc2b4-02dc-4104-b236-d6f1b98d9e84
SaPegData-c4975200-64f1-4fb6-9773-f6a9f89d985e
SbAslBufferPtrVar-01f33c25-764d-43ea-aeea-6b5a41f3f3e8
ScramblerBaseSeed-87f22dcb-7304-4105-bb7c-317143ccc23b
SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c
Setup-80e1202e-2697-4264-9cc9-80762c3e5863
Setup-ec87d643-eba4-4bb5-a1e5-3f3e36b20da9
SetupMode-8be4df61-93ca-11d2-aa0d-00e098032b8c
SetupPlatformData-ec87d643-eba4-4bb5-a1e5-3f3e36b20da9
SetupSnbPpmFeatures-ec87d643-eba4-4bb5-a1e5-3f3e36b20da9
SignatureSupport-8be4df61-93ca-11d2-aa0d-00e098032b8c
StdDefaults-4599d26f-1a11-49b8-b91f-858745cff824
Timeout-8be4df61-93ca-11d2-aa0d-00e098032b8c
UsbMassDevNum-ec87d643-eba4-4bb5-a1e5-3f3e36b20da9
UsbMassDevValid-ec87d643-eba4-4bb5-a1e5-3f3e36b20da9
USB_POINT-8be4df61-93ca-11d2-aa0d-00e098032b8c
UsbSupport-ec87d643-eba4-4bb5-a1e5-3f3e36b20da9
WdtPersistentData-78ce2354-cfbc-4643-aeba-07a27fa892bf
[user@localhost ~]$

Comment 2 Moez Roy 2013-04-06 02:21:03 UTC
Created attachment 915703 [details]
Comment

(This comment was longer than 65,535 characters and has been moved to an attachment by Red Hat Bugzilla).

Comment 3 Josh Boyer 2013-04-11 19:39:00 UTC
I believe there are patches being worked on to cover this in the EFI subsystem for 3.9 or 3.10.

Comment 4 Josh Boyer 2013-04-15 13:02:33 UTC
*** Bug 951755 has been marked as a duplicate of this bug. ***

Comment 5 Moez Roy 2013-04-16 17:20:38 UTC
(In reply to comment #3)
> I believe there are patches being worked on to cover this in the EFI
> subsystem for 3.9 or 3.10.

Thank you.

Comment 6 Lingzhu Xiang 2013-05-07 04:21:25 UTC
*** Bug 877884 has been marked as a duplicate of this bug. ***

Comment 7 Lingzhu Xiang 2013-05-07 04:22:52 UTC
*** Bug 866767 has been marked as a duplicate of this bug. ***

Comment 8 Lingzhu Xiang 2013-05-07 05:59:04 UTC
This should be fixed in

3.0.72+
3.2.42+ 
3.4.39+
3.5.7.10+ (Ubuntu)
3.8.6+ 
3.9+

Comment 9 Lingzhu Xiang 2013-05-07 07:54:28 UTC
Let me explain this bug.

During boot kernel prints something like this

WARNING: at sysfs/dir.c:536 sysfs_add_one+0xd4/0x100()
sysfs: cannot create duplicate filename '/firmware/efi/vars/....'

WARNING: at lib/kobject.c:196 kobject_add_internal+0x204/0x220()
kobject_add_internal failed for XXXX-01f33c25-764d-43ea-aeea-6b5a41f3f3e8 with -EEXIST, don't try to register things with the same name in the same directory.

And it can keep printing this and get stuck forever, or print some more warnings and move on. The direct observation of this means that the efivars module tries to register two sysfs entries with the same name, which is not allowed.

efivars is a kernel module providing sysfs access to EFI variables in firmware. During initialization, efivars will call EFI interface GetNextVariableName() multiple times to collect all EFI variables, and register a sysfs entry for each variable, until this function return EFI_NOT_FOUND to indicate all variables have been done.

So if efivars tries to register duplicate entries, it is because the firmware interface GetNextVariableName() it calls returns duplicate variables on multiple invocations. As per UEFI spec, this is buggy behavior and indicates broken firmware, or more specifically, the EFI variable data store in NVRAM is corrupted. The way GetNextVariableName() works is like a linked list, in which the next node is always supposed to be unexplored. But in this bug when the next node is one that has been explored, the iteration gets stuck in a loop forever. This way the kernel will only keep printing and never boot.

It is still unclear how firmware gets corrupted in the first place. However, this often seems happening after firmware reflashing or fiddling, but there is no definite correlation.

This is a grave bug that could even prevent installer kernel from booting, effectively bricking the machine. And fixing firmware is often difficult or not an option. Obviously the only solution is kernel always continuing booting because efivars isn't essential to a running system.

The current fix is to bail out of the loop once duplicate variable is detected (also prints "efivars: duplicate variable: ..."). Some EFI variables might not be accessible, but the kernel can always boot. The fix is e971318bbed610e28bb3fde9d548e6aaf0a6b02e in 3.9-rc5 and has been backported to most 3.x kernels. The root cause of firmware corruption can only be resolved by reflashing to a clean state, if possible.

To reproduce the bug, a machine with firmware broken in the particular way is required. But that is hard to come by. Actually, I suppose most of who had this bug already have their firmware replaced or broken more deeply. Fortunately it's still possible to reproduce with QEMU and OVMF.[1] OVMF provides the implementation of an emulated NVRAM. "[In] OVMF, the Firmware Volume Block (FVB) services emulate non-volatile variable storage by pretending that a memory buffer is storage for the NV variables. See …/OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.c."[2] EmuVariableFvbRuntimeDxe reserves an area of memory (ReserveEmuVariableNvStore) for NVRAM data in early POST. But there seems to be some more caching layers above that and directly writing a new duplicate variable there won't make any difference. The delicate structure of that data store was incomprehensible for me. So I ended up writing an EFI app to scan the entire physical memory and replace all L"Boot0004" with L"Boot0001" (default variables generated by OVMF), which actually broke things. EFI shell command dmpstore will get stuck in a loop. Old kernel will get stuck. 3.9-rc3 + patch will survive.[3] Later tests on a similarly broken machine with 3.9 also proves the result. I've yet to do wider verification.

[1]: http://www.linux-kvm.org/page/OVMF
[2]: http://blog.fpmurphy.com/2012/07/problems-testing-uefi-apis-using-qemu-ovmf-and-gnu-efi.html
[3]: http://article.gmane.org/gmane.linux.kernel.efi/987

In retrospect, this fix might be an overkill for those who only get warnings without getting stuck. The downside is that they may have some EFI variables invisible. But again, there isn't another feasible way to detect the looping without adding much complexity.

Comment 10 Josh Boyer 2013-05-07 13:15:27 UTC
Thanks for the detailed description Lingzhu.  All Fedora branches should already contain the fix.

Comment 11 Moez Roy 2013-05-08 00:36:40 UTC
The motherboard I am using is: GA-B75M-D3H (rev. 1.1)

http://www.gigabyte.com/products/product-page.aspx?pid=4315&dl=1#bios

The bios version is F13g.

CPU = Intel i3-3225

GPU = Nvidia GT 520


Note You need to log in before you can comment on or make changes to this bug.