Re: [PATCH 1/1] efi: cper: Support different length of Error Section
On Tue, Mar 4, 2014 at 3:41 PM, Matt Fleming wrote: >> Tested on v3.14-rc5 with Grantley platform and Intel RAStool. So - I've been playing with Grantley too - and didn't see these warnings about "error length section too small". I suspect this is because I've been toggling the BIOS option under: EDKII > Advanced > System Event Log > WHEA Settings > UEFI Version to request reports according to spec version 2.3.1 (to get the card handle and module handle fields) Does that fit with your experience too? -Tony [I note that there is a 2.4 version of UEFI ... are there more changes to the error record format there? I know there are plans to tweak even more bits because some of the 2-byte fields in the memory error description are not big enough to describe locations on 64GB DIMMs] -- 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 v4] efivars,efi-pstore: Hold off deletion of sysfs entry until the scan is completed
On Wed, Nov 6, 2013 at 12:51 AM, Matt Fleming wrote: > Tony, want me to pick this up since it touches various EFI bits? Since there are now no generic pstore changes - it is all in the efi backend ... yes, it makes sense for you to take this. Thanks [And thanks to Madper Xie for patiently coding through all these variations] -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] Make efi-pstore return a unique id
On Fri, Nov 1, 2013 at 1:57 PM, Seiji Aguchi wrote: >> What about feeding the bytes of all three integers into a non-cryptographic >> hash function? >> Using this way you get a cheap unique id. > > It is reasonable to me. How does efivars backend handle "unlink(2)" in the pstore file system. pstore will call the backend->erase function passing the "id". The backend should then erase the right record from persistent storage. With the ((timestamp * 100 + part) * 100 + count function - you can easily reverse it to find timestamp, part and count - would that make life easier for the backend to find the record to be erased? If you use a hash function you will need to check each record and compute the hash to see if it matches (probably not a big deal because the backend will generally only hold a handful of records). -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] Make efi-pstore return a unique id
>> +static u64 efi_generate_id(unsigned long timestamp, unsigned int part, int
>> count)
I don't think the "efi_" prefix is needed here. For one thing the
function is static, so
no name space pollution worries. For another - it makes it look like
this is some thing
defined in EFI standard. If "generate_id()" is too generic for your
tastes ... then a
"pstore_" prefix might be more appropriate.
>> +{
>> + char id_str[64];
>> + u64 id = 0;
>> +
>> + sprintf(id_str, "%lu%u%d", timestamp, part, count);
>> + if (kstrtoull(id_str, 10, &id))
>> + pr_warn("efi-pstore: failed to generate id\n");
>> + return id;
>> +}
>
> This is just odd. You make a string from three ints and then a parse
> it to a int again.
Agreed. I liked your ((timestamp * 100 + part) * 100 + count function much
more than this.
-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
On Wed, Oct 23, 2013 at 7:55 AM, Madper Xie 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 v2 1/5] ia64: add early_memremap() alias for early_ioremap()
On Mon, Aug 5, 2013 at 3:56 AM, Matt Fleming wrote: >> @@ -424,6 +424,7 @@ extern void __iomem * ioremap(unsigned long offset, >> unsigned long size); >> extern void __iomem * ioremap_nocache (unsigned long offset, unsigned long >> size); >> extern void iounmap (volatile void __iomem *addr); >> extern void __iomem * early_ioremap (unsigned long phys_addr, unsigned long >> size); >> +#define early_memremap(phys_addr, size)early_ioremap(phys_addr, >> size) >> extern void early_iounmap (volatile void __iomem *addr, unsigned long size); >> static inline void __iomem * ioremap_cache (unsigned long phys_addr, >> unsigned long size) > > Tony, can I get your Acked-by for this? Acked-by: Tony Luck [Cut & paste this ack to other parts of the series that touch ia64] -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 0/4] Make commonly useful UEFI functions common
On Tue, Jul 30, 2013 at 9:47 AM, Leif Lindholm wrote: > IA64 code compile tested only. Compiled on a bunch of ia64 configurations, Boot tested. But not on machine that does the PROCESSOR_ABSTRACTION_LAYER_OVERWRITE_GUID thingy. Code to do the arch specific thing looks ok though. -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 1/4] efi: provide a generic efi_config_init()
On Tue, Jul 30, 2013 at 11:02 AM, Leif Lindholm wrote: > So I guess the clean way to deal with that would be to make the > memremap definition a separate patch? Or just pull: +#define early_memremap(phys_addr, size)early_ioremap(phys_addr, size) out of part 3 and put it into part1 (along with some of the commit commentary). -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 1/4] efi: provide a generic efi_config_init()
On Tue, Jul 30, 2013 at 9:47 AM, Leif Lindholm wrote: > + /* > +* Let's see what config tables the firmware passed to us. > +*/ > + config_tables = early_mememap(efi.systab->tables, > + efi.systab->nr_tables * sz); Breaks bisection on ia64 ... you use early_mememap() here, but don't define it on ia64 until patch 3/4. So I get: drivers/firmware/efi/efi.c: In function 'efi_config_init': drivers/firmware/efi/efi.c:200: error: implicit declaration of function 'early_memremap' drivers/firmware/efi/efi.c:201: warning: assignment makes pointer from integer without a cast -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: [GIT PULL] EFI changes for v3.11
On Mon, Jul 8, 2013 at 11:36 AM, H. Peter Anvin wrote: >> I had hoped to have this patch follow in the same path that the >> one that changed the types and introduced the warnings took ... >> but since that didn't work perhaps I should just ask Linus to pull >> it from my ia64 tree. >> > > I can push it, although it seems a bit odd to me to push an ia64-only > patch through the x86 tree. > > Let me know what you prefer. I've sent Linus a "please pull" for this from my ia64 tree. -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 V3] ia64/mm: fix a bad_page bug when crash kernel booting
On Tue, Feb 19, 2013 at 5:38 PM, Xishi Qiu wrote: > Seems like a good idea, should we modify > "\linux\Documentation\kernel-parameters.txt"? Perhaps in Documentation/kdump/kdump.txt (which the crashkernel entry in kernel-parameters.txt points at). The ia64 section of kdump.txt notes that the start address will be rounded up to a GRANULE boundary, but doesn't talk about restrictions on the size. I wonder if any other architectures have alignment restrictions on the addresses in "crashkernel" parameters? Does x86 like them to be 2MB aligned? Second question is whether we should check and warn in parse_crashkernel_mem()? I think the answer is "yes" (since the consequences of getting this wrong don't show up till much later, and the errors aren't all that obviously connected back to the original mistake). Perhaps each architecture that cares could provide defines: #define ARCH_CRASH_KERNEL_START_ALIGN (... arch value here ...) #define ARCH_CRASH_KERNEL_SIZE_ALIGN (... arch value here ...) [Suggestion provided mostly to provoke somebody to provide a more elegant solution] -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 V3] ia64/mm: fix a bad_page bug when crash kernel booting
Foolishly sent an earlier reply from Outlook which appears to have mangled/lost it. Trying again ... > In efi_init() memory aligns in IA64_GRANULE_SIZE(16M). If set > "crashkernel=1024M-:600M" Is this where the real problem begins? Should we insist that users provide crashkernel parameters rounded to GRANULE boundaries? -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 V3] ia64/mm: fix a bad_page bug when crash kernel booting
On Tue, Feb 12, 2013 at 4:19 PM, Andrew Morton wrote: > But, umm, why am I sitting here trying to maintain an ia64 bugfix and > handling bug reports from the ia64 maintainer? Wanna swap? That sounds like a plan. I'll look out for a new version with the missing #include and less silly global variable names and try to take it before you pull it into -mm -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 V3] ia64/mm: fix a bad_page bug when crash kernel booting
Building linux-next today (tag next-20130212) I get the following errors when
building arch/ia64/configs/{tiger_defconfig, zx1_defconfig, bigsur_defconfig,
sim_defconfig}
arch/ia64/mm/init.c: In function 'free_initrd_mem':
arch/ia64/mm/init.c:215: error: 'max_addr' undeclared (first use in
this function)
arch/ia64/mm/init.c:215: error: (Each undeclared identifier is
reported only once
arch/ia64/mm/init.c:215: error: for each function it appears in.)
arch/ia64/mm/init.c:216: error: implicit declaration of function
'GRANULEROUNDDOWN'
with "git blame" saying that these lines in init.c were added/changed by
commit 5a54b4fb8f554b15c6113e30ca8412b7fe11c62e
Author: Xishi Qiu
Date: Thu Feb 7 12:25:59 2013 +1100
ia64/mm: fix a bad_page bug when crash kernel booting
-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
