Re: [BUG] pstore: failed to load 76 record(s) from 'efi'
It seems pstore dump the messages with a same guid. But when loading
them, pstore check if they are exist by id in pstore_mkfile():
list_for_each_entry(pos, allpstore, list) {
if (pos-type == type
pos-id == id
pos-psi == psi) {
rc = -EEXIST;
break;
}
}
So pstore incorrectly mark many entries as -EEXIST.
Please correct me if I am wrong. :-) And I'm preparing a patch for it.
c...@redhat.com writes:
Hi folks,
after mount pstore with efi as backend there are only 11 entries in
pstore dir. Although I have about 80 pstore entries in my nvram.
I can reproduce it 100% on my DELL XPS. And will try it on one more
vendor.
my kernel version is 3.12-rc4. Please let me know if it's not a kernel
bug but a buggy firmware. :-)
Here is my dmesg out put:
[ 17.076222] IPv6: ADDRCONF(NETDEV_CHANGE): p3p1: link becomes ready
[ 104.749604] pstore: failed to load 76 record(s) from 'efi' -- this
line appear when I mount pstore.
[ 104.749610] SELinux: initialized (dev pstore, type pstore), not
configured for labeling
Here is the output of `ls /sys/firmware/efi/vars`:
AcpiGlobalVariable-af9ffd67-ec10-488a-9dfc-6cbf5ee22c2e
AMITSESetup-c811fa38-42c8-4579-a9bb-60e94eddfb34
Boot-8be4df61-93ca-11d2-aa0d-00e098032b8c
Boot0001-8be4df61-93ca-11d2-aa0d-00e098032b8c
Boot0002-8be4df61-93ca-11d2-aa0d-00e098032b8c
Boot0003-8be4df61-93ca-11d2-aa0d-00e098032b8c
Boot0004-8be4df61-93ca-11d2-aa0d-00e098032b8c
Boot0005-8be4df61-93ca-11d2-aa0d-00e098032b8c
BootCurrent-8be4df61-93ca-11d2-aa0d-00e098032b8c
BootOptionSupport-8be4df61-93ca-11d2-aa0d-00e098032b8c
BootOrder-8be4df61-93ca-11d2-aa0d-00e098032b8c
CmosError-ceab3323-daab-92ee-c112-abee5a6ebe2c
ConIn-8be4df61-93ca-11d2-aa0d-00e098032b8c
ConInDev-8be4df61-93ca-11d2-aa0d-00e098032b8c
ConOut-8be4df61-93ca-11d2-aa0d-00e098032b8c
ConOutChild1-8be4df61-93ca-11d2-aa0d-00e098032b8c
ConOutChildNumber-8be4df61-93ca-11d2-aa0d-00e098032b8c
ConOutDev-8be4df61-93ca-11d2-aa0d-00e098032b8c
db-d719b2cb-3d3a-4596-a3bc-dad00e67656f
dbx-d719b2cb-3d3a-4596-a3bc-dad00e67656f
DebuggerSerialPortsEnabledVar-97ca1a5b-b760-4d1f-a54b-d19092032c90
DefaultConOutChild-8be4df61-93ca-11d2-aa0d-00e098032b8c
DefaultFBOSetDevOrder-0c923ca9-df73-4ac8-b6d2-98ddc30d99fc
DefaultFBOSetDevOrderUEFI-0c923ca9-df73-4ac8-b6d2-98ddc30d99fc
DELLDIAG_EEPROM-86fd3e21-8683-4f2e-bcc1-2c52493bd1f6
del_var
DriverHealthCount-7459a7d4-6533-4480-bba7-79e25a4443c9
DriverHlthEnable-0885f288-418c-4be1-a6af-8bad61da08fe
dump-type0-10-1-1379387013-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-10-1-1380015708-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-10-1-1380016446-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-10-1-1380441690-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-10-1-1380448560-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-10-1-1380460890-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-10-1-1380467798-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-10-1-1382496073-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-11-1-1379387013-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-11-1-1380015708-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-11-1-1380016446-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-11-1-1380441691-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-11-1-1380448560-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-11-1-1382496074-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-1-1-1379387012-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-1-1-1380015706-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-1-1-1380016444-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-1-1-1380441689-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-1-1-1380448559-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-1-1-1380460875-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-1-1-1380467797-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-1-1-1380524664-C-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-1-1-1380526061-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-1-1-1380527153-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-1-1-1382496055-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-2-1-1379387012-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-2-1-1380015706-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-2-1-1380016445-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-2-1-1380441689-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-2-1-1380448559-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-2-1-1380460888-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-2-1-1380467797-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-2-1-1380524664-C-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-2-1-1380526061-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-2-1-1382496055-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-3-1-1379387012-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
Re: [PATCH 12/12] EFI: Runtime services virtual mapping
On Wed, Oct 23, 2013 at 10:17:31AM +0800, Dave Young wrote: The reason is that I only pass runtime regions from 1st kernel to kexec kernel, your efi mapping function uses the region size to determin the virtual address from top to down. Because the passed-in md ranges in kexec kernel are different from ranges booting from firmware so the virtual address will be different. Well, this shouldn't be because SetVirtualAddressMap has already fixed the virtual addresses for us. And if they're different, then runtime services won't work anyway. Or am I missing something...? Even I pass the whole untouched ranges including BOOT_SERVICE there's still chance the function for reserving boot regions overwrite the boot region size to 0, and 1st kernel will leave it to be used as normal memory after efi init. I think we have talked about this issue previously. Matt, didn't you question the need to keep boot services regions mapped indefinitely? What was the story there? Thanks. -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 12/12] EFI: Runtime services virtual mapping
On Wed, Oct 23, 2013 at 02:25:31PM +0200, Borislav Petkov wrote: Matt, didn't you question the need to keep boot services regions mapped indefinitely? What was the story there? We shouldn't need boot services regions to be mapped after SetVirtualAddressMap is called. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 12/12] EFI: Runtime services virtual mapping
On 10/23/13 at 02:25pm, Borislav Petkov wrote: On Wed, Oct 23, 2013 at 10:17:31AM +0800, Dave Young wrote: The reason is that I only pass runtime regions from 1st kernel to kexec kernel, your efi mapping function uses the region size to determin the virtual address from top to down. Because the passed-in md ranges in kexec kernel are different from ranges booting from firmware so the virtual address will be different. Well, this shouldn't be because SetVirtualAddressMap has already fixed the virtual addresses for us. And if they're different, then runtime services won't work anyway. Or am I missing something...? Maybe I did not explain clear enough. Say first kernel mapping below regions: Region A (boot service):phys_start_a size_a - virt_start_a size_a Region B (runtime): phys_start_b size_b - virt_start_b size_b I will pass Range B into 2nd kernel (phys_start_b, size_b, virt_start_b) In kexed 2nd kernel, phys_start_b need to be mapped to virt_start_b Simply use efi_map_region from your patch does not work because it will map phys_start_b to a different virt address, isn't it? So I need simply map according to the kexec passed in mapping addr. Thanks Dave -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 12/12] EFI: Runtime services virtual mapping
On Wed, Oct 23, 2013 at 08:51:31PM +0800, Dave Young wrote: In kexed 2nd kernel, phys_start_b need to be mapped to virt_start_b Simply use efi_map_region from your patch does not work because it will map phys_start_b to a different virt address, isn't it? Oh ok, in the second kernel we're not mapping *all* regions we do map in the first kernel, right. So I need simply map according to the kexec passed in mapping addr. Yes, thanks for elaborating. -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] pstore: avoid incorrectly mark entry as duplicate
pstore try to find duplicate entries by check both ID, type and psi.
They are not really enough for efi backend. dumped vars always have
the same type, psi and ID. like follows:
dump-type0-9-1-1382511508-C-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-9-1-1382515661-C-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
The duplicate entries won't appear in pstorefs. And a complain will be
print -- pstore: failed to load 76 record(s) from 'efi'
So I add one more check: timespec.
Signed-off-by: Madper Xie c...@redhat.com
---
fs/pstore/inode.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/fs/pstore/inode.c b/fs/pstore/inode.c
index 1282384..f70f1e5 100644
--- a/fs/pstore/inode.c
+++ b/fs/pstore/inode.c
@@ -47,6 +47,7 @@ static LIST_HEAD(allpstore);
struct pstore_private {
struct list_head list;
struct pstore_info *psi;
+ struct timespec time;
enum pstore_type_id type;
u64 id;
int count;
@@ -290,7 +291,8 @@ int pstore_mkfile(enum pstore_type_id type, char *psname,
u64 id, int count,
list_for_each_entry(pos, allpstore, list) {
if (pos-type == type
pos-id == id
- pos-psi == psi) {
+ pos-psi == psi
+ !timespec_compare(pos-time, time)) {
rc = -EEXIST;
break;
}
@@ -312,6 +314,7 @@ int pstore_mkfile(enum pstore_type_id type, char *psname,
u64 id, int count,
private-id = id;
private-count = count;
private-psi = psi;
+ memcpy(private-time, time, sizeof(struct timespec));
switch (type) {
case PSTORE_TYPE_DMESG:
--
1.8.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-efi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pstore: avoid incorrectly mark entry as duplicate
richard.weinber...@gmail.com writes:
On Wed, Oct 23, 2013 at 4:55 PM, Madper Xie c...@redhat.com wrote:
pstore try to find duplicate entries by check both ID, type and psi.
They are not really enough for efi backend. dumped vars always have
the same type, psi and ID. like follows:
dump-type0-9-1-1382511508-C-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-9-1-1382515661-C-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
The duplicate entries won't appear in pstorefs. And a complain will be
print -- pstore: failed to load 76 record(s) from 'efi'
So I add one more check: timespec.
Signed-off-by: Madper Xie c...@redhat.com
---
fs/pstore/inode.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/fs/pstore/inode.c b/fs/pstore/inode.c
index 1282384..f70f1e5 100644
--- a/fs/pstore/inode.c
+++ b/fs/pstore/inode.c
@@ -47,6 +47,7 @@ static LIST_HEAD(allpstore);
struct pstore_private {
struct list_head list;
struct pstore_info *psi;
+ struct timespec time;
enum pstore_type_id type;
u64 id;
int count;
@@ -290,7 +291,8 @@ int pstore_mkfile(enum pstore_type_id type, char
*psname, u64 id, int count,
list_for_each_entry(pos, allpstore, list) {
if (pos-type == type
pos-id == id
- pos-psi == psi) {
+ pos-psi == psi
+ !timespec_compare(pos-time, time)) {
rc = -EEXIST;
break;
}
@@ -312,6 +314,7 @@ int pstore_mkfile(enum pstore_type_id type, char
*psname, u64 id, int count,
private-id = id;
private-count = count;
private-psi = psi;
+ memcpy(private-time, time, sizeof(struct timespec));
switch (type) {
case PSTORE_TYPE_DMESG:
As discussed on IRC, why don't you compare the variable names?
Howdy Richard,
Let's analyze the name of duplicate entries:
dump-type0-9-1-1382511508-C-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-9-1-1382515661-C-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
The have the same name except timestamp. In this case, there is no
difference between compare names and compare timestamps.
( Yeah, I'm pretty sure the guid will be the same one --
LINUX_EFI_CRASH_GUID )
But efi is only one backend. For other backends, we don't sure if they
will add timestamp to name. So...
--
Best,
Madper Xie.
--
To unsubscribe from this list: send the line unsubscribe linux-efi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pstore: avoid incorrectly mark entry as duplicate
On Wed, Oct 23, 2013 at 7:55 AM, Madper Xie c...@redhat.com wrote: The duplicate entries won't appear in pstorefs. And a complain will be print -- pstore: failed to load 76 record(s) from 'efi' Maybe I don't quite get this - but it sounds like you have a whole lot of entries using up space in efivars that have similar names - differing just in the timestamp - that won't show up in the pstore filesystem - because we'd try to name them all the same thing. How did all those things end up in efivars? Wouldn't the right fix be to make pstore allow them all to appear (using the timestamp to differentiate names?) so that we could see them, log them, and then remove them from pstore (in turn freeing up efivars space - which people keep telling me is in short supply). -Tony -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pstore: avoid incorrectly mark entry as duplicate
tony.l...@gmail.com writes:
On Wed, Oct 23, 2013 at 7:55 AM, Madper Xie c...@redhat.com wrote:
The duplicate entries won't appear in pstorefs. And a complain will be
print -- pstore: failed to load 76 record(s) from 'efi'
Maybe I don't quite get this - but it sounds like you have a whole lot
of entries using up space in efivars that have similar names - differing
just in the timestamp - that won't show up in the pstore filesystem - because
we'd try to name them all the same thing.
Maybe I misunderstand you...
Sure pstore try to name them all the same thing, but it's another
issue. and it doesn't prevent entries showing up in pstore fs.
Consider the following case: (after efi-pstore support append mode, it
always like this case):
I choose four dumped efivars from my DELL XPS:
dump-type0-9-1-1380441690-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-9-1-1380448560-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-9-1-1380460890-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-9-1-1382496073-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
^^ [ ^ ]
!! !
typetimestampGUID
When pstore load them from efivars, pstore incorrectly assuming that
efivars with the same TYPE, ID and GUID are duplicate.
list_for_each_entry(pos, allpstore, list) {
if (pos-type == type /---
pos-id == id -| as I said, it only check type,id,psi
pos-psi == psi) { \---
rc = -EEXIST;- then set -EEXIST, and ignore *dup* entry
break;
}
}
You can see the code above, for those four entries, only one could be
showed in pstorefs, all others will get a -EEXIST. So I add a timestamp
check here, it's the only different part.
How did all those things end up in efivars?
before the patch I can see
dmesg-efi-1 dmesg-efi-11 dmesg-efi-3 dmesg-efi-5 dmesg-efi-7 dmesg-efi-9
dmesg-efi-10 dmesg-efi-2 dmesg-efi-4 dmesg-efi-6 dmesg-efi-8
after apply the patch:
[root@dhcp-13-41 vars]# ls /dev/pstore/
dmesg-efi-1 dmesg-efi-1 dmesg-efi-11 dmesg-efi-2 dmesg-efi-3 dmesg-efi-5
dmesg-efi-6 dmesg-efi-8
dmesg-efi-1 dmesg-efi-10 dmesg-efi-11 dmesg-efi-2 dmesg-efi-3 dmesg-efi-5
dmesg-efi-7 dmesg-efi-8
dmesg-efi-1 dmesg-efi-10 dmesg-efi-12 dmesg-efi-2 dmesg-efi-4 dmesg-efi-5
dmesg-efi-7 dmesg-efi-8
dmesg-efi-1 dmesg-efi-10 dmesg-efi-13 dmesg-efi-2 dmesg-efi-4 dmesg-efi-5
dmesg-efi-7 dmesg-efi-9
dmesg-efi-1 dmesg-efi-10 dmesg-efi-14 dmesg-efi-2 dmesg-efi-4 dmesg-efi-5
dmesg-efi-7 dmesg-efi-9
dmesg-efi-1 dmesg-efi-10 dmesg-efi-15 dmesg-efi-2 dmesg-efi-4 dmesg-efi-5
dmesg-efi-7 dmesg-efi-9
dmesg-efi-1 dmesg-efi-10 dmesg-efi-16 dmesg-efi-3 dmesg-efi-4 dmesg-efi-5
dmesg-efi-7 dmesg-efi-9
dmesg-efi-1 dmesg-efi-10 dmesg-efi-2 dmesg-efi-3 dmesg-efi-4 dmesg-efi-6
dmesg-efi-7 dmesg-efi-9
dmesg-efi-1 dmesg-efi-10 dmesg-efi-2 dmesg-efi-3 dmesg-efi-4 dmesg-efi-6
dmesg-efi-7 dmesg-efi-9
dmesg-efi-1 dmesg-efi-10 dmesg-efi-2 dmesg-efi-3 dmesg-efi-4 dmesg-efi-6
dmesg-efi-8 dmesg-efi-9
dmesg-efi-1 dmesg-efi-11 dmesg-efi-2 dmesg-efi-3 dmesg-efi-4 dmesg-efi-6
dmesg-efi-8 dmesg-efi-9
dmesg-efi-1 dmesg-efi-11 dmesg-efi-2 dmesg-efi-3 dmesg-efi-4 dmesg-efi-6
dmesg-efi-8 dmesg-efi-9
dmesg-efi-1 dmesg-efi-11 dmesg-efi-2 dmesg-efi-3 dmesg-efi-5 dmesg-efi-6
dmesg-efi-8
dmesg-efi-1 dmesg-efi-11 dmesg-efi-2 dmesg-efi-3 dmesg-efi-5 dmesg-efi-6
dmesg-efi-8
dmesg-efi-1 dmesg-efi-11 dmesg-efi-2 dmesg-efi-3 dmesg-efi-5 dmesg-efi-6
dmesg-efi-8
Wouldn't the right fix be to make pstore allow them all to appear (using the
timestamp to differentiate names?) so that we could see them, log them,
and then remove them from pstore (in turn freeing up efivars space - which
people keep telling me is in short supply).
Yeah, many file have the same name, just like my case above. But it not
really block the file shows up and should be solved in another
patch. And I'm trying fix it.
-Tony
--
Best,
Madper Xie.
--
To unsubscribe from this list: send the line unsubscribe linux-efi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
