Re: [PATCH] mm: bootmem: Check pfn_valid() before accessing struct page
On 27 May 2014 19:45, Dave Hansen wrote: > > I don't think this is quite right. pfn_valid() tells us whether we have > a 'struct page' there or not. *BUT*, it does not tell us whether it is > RAM that we can actually address and than can be freed in to the buddy > allocator. > > I think sparsemem is where this matters. Let's say mem= caused lowmem > to end in the middle of a section (or that 896MB wasn't > section-aligned). Then someone calls free_bootmem_late() on an area > that is in the last section, but _above_ max_mapnr. It'll be > pfn_valid(), we'll free it in to the buddy allocator, and we'll blam the > first time we try to write to a bogus vaddr after a phys_to_virt(). Ah, the sparsemem case wasn't something I'd considered. Thanks Dave. > At a higher level, I don't like the idea of the bootmem code papering > over bugs when somebody calls in to it trying to _free_ stuff that's not > memory (as far as the kernel is concerned). > > I think the right thing to do is to call in to the e820 code and see if > the range is E820_RAM before trying to bootmem-free it. OK, this makes sense. I'll try that approach and see if it also fixes Alan's problem. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: bootmem: Check pfn_valid() before accessing struct page
On 27 May 2014 19:45, Dave Hansen dave.han...@intel.com wrote: I don't think this is quite right. pfn_valid() tells us whether we have a 'struct page' there or not. *BUT*, it does not tell us whether it is RAM that we can actually address and than can be freed in to the buddy allocator. I think sparsemem is where this matters. Let's say mem= caused lowmem to end in the middle of a section (or that 896MB wasn't section-aligned). Then someone calls free_bootmem_late() on an area that is in the last section, but _above_ max_mapnr. It'll be pfn_valid(), we'll free it in to the buddy allocator, and we'll blam the first time we try to write to a bogus vaddr after a phys_to_virt(). Ah, the sparsemem case wasn't something I'd considered. Thanks Dave. At a higher level, I don't like the idea of the bootmem code papering over bugs when somebody calls in to it trying to _free_ stuff that's not memory (as far as the kernel is concerned). I think the right thing to do is to call in to the e820 code and see if the range is E820_RAM before trying to bootmem-free it. OK, this makes sense. I'll try that approach and see if it also fixes Alan's problem. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] efi: Fix compiler warnings (unused, const, type)
On 2 June 2014 11:31, Catalin Marinas wrote: > This patch fixes a few compiler warning in the efi code for unused > variable, discarding const qualifier and wrong pointer type: > > drivers/firmware/efi/fdt.c|66 col 22| warning: unused variable ‘name’ > [-Wunused-variable] > drivers/firmware/efi/efi.c|368 col 3| warning: passing argument 3 of > ‘of_get_flat_dt_prop’ from incompatible pointer type [enabled by default] > drivers/firmware/efi/efi.c|368 col 8| warning: assignment discards ‘const’ > qualifier from pointer target type [enabled by default] > > Signed-off-by: Catalin Marinas > --- > > Matt, > > Unless you have fixed these already, please consider applying (warnings in > latest next/master branch). Thanks, applied to arm64-efi. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] efi: Fix compiler warnings (unused, const, type)
On 2 June 2014 11:31, Catalin Marinas catalin.mari...@arm.com wrote: This patch fixes a few compiler warning in the efi code for unused variable, discarding const qualifier and wrong pointer type: drivers/firmware/efi/fdt.c|66 col 22| warning: unused variable ‘name’ [-Wunused-variable] drivers/firmware/efi/efi.c|368 col 3| warning: passing argument 3 of ‘of_get_flat_dt_prop’ from incompatible pointer type [enabled by default] drivers/firmware/efi/efi.c|368 col 8| warning: assignment discards ‘const’ qualifier from pointer target type [enabled by default] Signed-off-by: Catalin Marinas catalin.mari...@arm.com --- Matt, Unless you have fixed these already, please consider applying (warnings in latest next/master branch). Thanks, applied to arm64-efi. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] export efi.flags to sysfs
On 29 May 2014 13:59, Vivek Goyal wrote: > > Only second kernel boots with "noefi" and this parameter is appened by > kexec-tools to second kernel command line. So first kernel will still > boot *without noefi* and kexec-tools wil think that this system support > booting second kernel with UEFI enabled. > > I don't know if we export /sys/firmware/efi/runtime-map/ in case of > non 1:1 mapping or not. Dave and Boris will know better. Looking at the code the answer is: yes. I think that's the bug right there. By exporting entries in /sys/firmware/efi/runtime-map we're saying "These mappings persist across kexec, you can trust that they won't change", for SGI UV (which currently uses the quirk) or if you boot with efi=old_map on the command line, that's simply not true. So, it would seem to me that we're missing a "if (efi_enabled(OLD_MAP))" in drivers/firmware/efi/runtime-map.c. Borislav, Dave? What do you guys think? This is all assuming that the root of the regression is that kexec-tools sees entries in /sys/firmware/efi/runtime-map/ and says "Yay! EFI boot!". -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] export efi.flags to sysfs
On 28 May 2014 20:04, Vivek Goyal wrote: > On Wed, May 28, 2014 at 10:51:04AM -0500, Alex Thorlton wrote: > > [..] >> A side note, though: We're going to have to figure out some way to >> determine whether or not to apply the old_map quirk on during boot >> anyway, so if it's easiest for you to just determine how the original >> kernel was booted and key off of that, then I wouldn't worry about >> finding a different method to get the firmware version in userspace, >> unless there are other reasons for you to do it that way. > > Agreed. Let kernel and firmware figure it out when to apply quirk and > user space should not worry about firmware version. > > I liked the other approach better where user space just needs to know > if 1:1 mapping are in effect or not and take decision based on that. The problem with going down this route is that if we ever change the way we map the EFI regions in the kernel corresponding changes will be required for kexec-tools. That's not ideal. Kexec-tools should not be interpreting /sys/firmware/efi/runtime-map/ any further than building a memory map, i.e. it has to understand how to build a memory region descriptor but it shouldn't care what *values* are in them. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] export efi.flags to sysfs
On 28 May 2014 15:51, Vivek Goyal wrote: > On Wed, May 28, 2014 at 10:09:35AM +0800, Dave Young wrote: > > [..] >> > I've only vaguely been following along with the other thread, so please >> > summarise everything again in your patch. Particularly, I need answers >> > to the following questions, >> > >> > - Are you trying to fix a kexec/kdump regression? >> >> Somehow it is a regression. > > Well, it is a *regression*. Previously kdump would work with > SGI UV machines as it used "noefi". Now kexec by default thinks that > efi is enabled and 1:1 mappings are in place and that does not work > with SGI UV machines. So, if someone boots an SGI UV machine with the "noefi" kernel command line parameter, the kernel still creates /sys/firmware/efi/runtime-map/ ? Why does kexec/kdump think a kernel booted with "noefi" supports EFI? Or are we talking about a different "noefi" parameter? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] export efi.flags to sysfs
On 28 May 2014 15:51, Vivek Goyal vgo...@redhat.com wrote: On Wed, May 28, 2014 at 10:09:35AM +0800, Dave Young wrote: [..] I've only vaguely been following along with the other thread, so please summarise everything again in your patch. Particularly, I need answers to the following questions, - Are you trying to fix a kexec/kdump regression? Somehow it is a regression. Well, it is a *regression*. Previously kdump would work with SGI UV machines as it used noefi. Now kexec by default thinks that efi is enabled and 1:1 mappings are in place and that does not work with SGI UV machines. So, if someone boots an SGI UV machine with the noefi kernel command line parameter, the kernel still creates /sys/firmware/efi/runtime-map/ ? Why does kexec/kdump think a kernel booted with noefi supports EFI? Or are we talking about a different noefi parameter? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] export efi.flags to sysfs
On 28 May 2014 20:04, Vivek Goyal vgo...@redhat.com wrote: On Wed, May 28, 2014 at 10:51:04AM -0500, Alex Thorlton wrote: [..] A side note, though: We're going to have to figure out some way to determine whether or not to apply the old_map quirk on during boot anyway, so if it's easiest for you to just determine how the original kernel was booted and key off of that, then I wouldn't worry about finding a different method to get the firmware version in userspace, unless there are other reasons for you to do it that way. Agreed. Let kernel and firmware figure it out when to apply quirk and user space should not worry about firmware version. I liked the other approach better where user space just needs to know if 1:1 mapping are in effect or not and take decision based on that. The problem with going down this route is that if we ever change the way we map the EFI regions in the kernel corresponding changes will be required for kexec-tools. That's not ideal. Kexec-tools should not be interpreting /sys/firmware/efi/runtime-map/ any further than building a memory map, i.e. it has to understand how to build a memory region descriptor but it shouldn't care what *values* are in them. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] export efi.flags to sysfs
On 29 May 2014 13:59, Vivek Goyal vgo...@redhat.com wrote: Only second kernel boots with noefi and this parameter is appened by kexec-tools to second kernel command line. So first kernel will still boot *without noefi* and kexec-tools wil think that this system support booting second kernel with UEFI enabled. I don't know if we export /sys/firmware/efi/runtime-map/ in case of non 1:1 mapping or not. Dave and Boris will know better. Looking at the code the answer is: yes. I think that's the bug right there. By exporting entries in /sys/firmware/efi/runtime-map we're saying These mappings persist across kexec, you can trust that they won't change, for SGI UV (which currently uses the quirk) or if you boot with efi=old_map on the command line, that's simply not true. So, it would seem to me that we're missing a if (efi_enabled(OLD_MAP)) in drivers/firmware/efi/runtime-map.c. Borislav, Dave? What do you guys think? This is all assuming that the root of the regression is that kexec-tools sees entries in /sys/firmware/efi/runtime-map/ and says Yay! EFI boot!. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] export efi.flags to sysfs
On 27 May 2014 04:00, Dave Young wrote: > On 05/26/14 at 04:39pm, Dave Young wrote: >> >> For efi=old_map and any old_map quirks like SGI UV in current >> tree kexec/kdump will fail because it depends on the new 1:1 mapping. >> >> Thus export the mapping method to sysfs so kexec tools can switch >> to original way to boot. >> >> Since we have efi.flags for all efi facilities so let's just export the >> efi.flags itself, it maybe useful for other arches and use cases. > > Rethink about this issue, export flags will expose the efi facility > macros to userspace, Matt, what's your opinion? It might be better to export > a file 'old_map' only which is '0|1' Exporting efi.flags is a non-starter. Those flags are part of an internal interface and I'm not prepared to turn them into a userspace ABI that we can never, ever change without a massive amount of pain. I've only vaguely been following along with the other thread, so please summarise everything again in your patch. Particularly, I need answers to the following questions, - Are you trying to fix a kexec/kdump regression? - Does SGI UV work with kexec + UEFI at all? The 1:1 mapping was required to make kexec + EFI work in the first instance. If a machine implements the EFI 1:1 mapping, kexec should work. If it doesn't implement the 1:1 mapping, then it's probably not going to work, right? The crux of the question: are you trying to fix a regression? If not, then we just need to get SGI UV working with the EFI 1:1 mapping. No? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] export efi.flags to sysfs
On 27 May 2014 04:00, Dave Young dyo...@redhat.com wrote: On 05/26/14 at 04:39pm, Dave Young wrote: For efi=old_map and any old_map quirks like SGI UV in current tree kexec/kdump will fail because it depends on the new 1:1 mapping. Thus export the mapping method to sysfs so kexec tools can switch to original way to boot. Since we have efi.flags for all efi facilities so let's just export the efi.flags itself, it maybe useful for other arches and use cases. Rethink about this issue, export flags will expose the efi facility macros to userspace, Matt, what's your opinion? It might be better to export a file 'old_map' only which is '0|1' Exporting efi.flags is a non-starter. Those flags are part of an internal interface and I'm not prepared to turn them into a userspace ABI that we can never, ever change without a massive amount of pain. I've only vaguely been following along with the other thread, so please summarise everything again in your patch. Particularly, I need answers to the following questions, - Are you trying to fix a kexec/kdump regression? - Does SGI UV work with kexec + UEFI at all? The 1:1 mapping was required to make kexec + EFI work in the first instance. If a machine implements the EFI 1:1 mapping, kexec should work. If it doesn't implement the 1:1 mapping, then it's probably not going to work, right? The crux of the question: are you trying to fix a regression? If not, then we just need to get SGI UV working with the EFI 1:1 mapping. No? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.13: disagrees about version of symbol
On 7 April 2014 21:42, Andi Kleen wrote: > > This sounds like the UEFI boot corrupts some memory? Hmpf, yeah. I'll take a look in the morning. Thomas, you mention you're running in a 32-bit vm earlier in this thread. Any chance you're using ovmf because that would make it much easier to track this down? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.13: module disagrees about version of symbol symbol
On 7 April 2014 21:42, Andi Kleen a...@linux.intel.com wrote: This sounds like the UEFI boot corrupts some memory? Hmpf, yeah. I'll take a look in the morning. Thomas, you mention you're running in a 32-bit vm earlier in this thread. Any chance you're using ovmf because that would make it much easier to track this down? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH v2] efivars,efi-pstore: Hold off deletion of sysfs entry until the scan is completed
On 4 October 2013 16:46, Seiji Aguchi wrote: > Are there anyone who can review this bugfix? Sorry I haven't got to it yet (or the previous version). It is on my TODO list. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH v2] efivars,efi-pstore: Hold off deletion of sysfs entry until the scan is completed
On 4 October 2013 16:46, Seiji Aguchi seiji.agu...@hds.com wrote: Are there anyone who can review this bugfix? Sorry I haven't got to it yet (or the previous version). It is on my TODO list. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] Make commonly useful UEFI functions common
On 1 August 2013 21:26, H. Peter Anvin wrote: > Matt, I assume you're picking this up once the missing bits are plugged > in, right? Yep, that was my plan. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] Make commonly useful UEFI functions common
On 1 August 2013 21:26, H. Peter Anvin h...@zytor.com wrote: Matt, I assume you're picking this up once the missing bits are plugged in, right? Yep, that was my plan. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [REGRESSION] "UEFI: Don't pass boot services regions to SetVirtualAddressMap()" breaks macbook efi boot
On 17 July 2013 01:32, H. Peter Anvin wrote: > On 07/10/2013 04:39 AM, Fleming, Matt wrote: >> On 10 July 2013 12:34, Maarten Lankhorst >> wrote: >>> Hey, >>> >>> It seems that in the merge window my macbook pro stopped working at some >>> point. I looked for suspicious >>> efi related commits, and found that reverting commit >>> 1acba98f810a14b1255e34bc620594f83de37e36 worked, >>> letting my macbook pro boot succesfully. >> >> Thanks for the report. I'm going to queue up a revert of this patch, >> Dave Young also reported a problem on his thinkpad. >> > > Can I grab this somewhere yet? http://article.gmane.org/gmane.linux.kernel.efi/1514 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [REGRESSION] UEFI: Don't pass boot services regions to SetVirtualAddressMap() breaks macbook efi boot
On 17 July 2013 01:32, H. Peter Anvin h...@zytor.com wrote: On 07/10/2013 04:39 AM, Fleming, Matt wrote: On 10 July 2013 12:34, Maarten Lankhorst maarten.lankho...@canonical.com wrote: Hey, It seems that in the merge window my macbook pro stopped working at some point. I looked for suspicious efi related commits, and found that reverting commit 1acba98f810a14b1255e34bc620594f83de37e36 worked, letting my macbook pro boot succesfully. Thanks for the report. I'm going to queue up a revert of this patch, Dave Young also reported a problem on his thinkpad. Can I grab this somewhere yet? http://article.gmane.org/gmane.linux.kernel.efi/1514 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [REGRESSION] "UEFI: Don't pass boot services regions to SetVirtualAddressMap()" breaks macbook efi boot
On 10 July 2013 12:34, Maarten Lankhorst wrote: > Hey, > > It seems that in the merge window my macbook pro stopped working at some > point. I looked for suspicious > efi related commits, and found that reverting commit > 1acba98f810a14b1255e34bc620594f83de37e36 worked, > letting my macbook pro boot succesfully. Thanks for the report. I'm going to queue up a revert of this patch, Dave Young also reported a problem on his thinkpad. > Is there anything I can do to help diagnose this issue? Matthew? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [REGRESSION] UEFI: Don't pass boot services regions to SetVirtualAddressMap() breaks macbook efi boot
On 10 July 2013 12:34, Maarten Lankhorst maarten.lankho...@canonical.com wrote: Hey, It seems that in the merge window my macbook pro stopped working at some point. I looked for suspicious efi related commits, and found that reverting commit 1acba98f810a14b1255e34bc620594f83de37e36 worked, letting my macbook pro boot succesfully. Thanks for the report. I'm going to queue up a revert of this patch, Dave Young also reported a problem on his thinkpad. Is there anything I can do to help diagnose this issue? Matthew? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [IA64] sim: Add casts to avoid assignment warnings
On 21 June 2013 00:43, Tony Luck wrote: > Oops - pasted in old e-mail address for Boris Applied, thanks Tony. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [IA64] sim: Add casts to avoid assignment warnings
On 21 June 2013 00:43, Tony Luck tony.l...@gmail.com wrote: Oops - pasted in old e-mail address for Boris Applied, thanks Tony. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Modify UEFI anti-bricking code
On 4 June 2013 04:35, joeyli wrote: > 於 一，2013-06-03 於 16:31 +，Matthew Garrett 提到： >> On Tue, 2013-06-04 at 00:13 +0800, joeyli wrote: >> >> > Oliver raised a question for if power fails between that succesful >> > attempt and the deletion? >> >> It's a pretty tiny window, but sure. Making sure we delete it seems >> sensible. In that case we should make the GUID a #define rather than >> write it out twice. >> > > Base on your patch, the following diff moved DUMMY GUID to #define, and > add a static efi name string: Folks, what do you want me to do with this? Merge it with Matthew's patch? The feedback from the original patch has been pretty good so I'm happy to pick it up and get it sent to Linus. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Modify UEFI anti-bricking code
On 4 June 2013 04:35, joeyli j...@suse.com wrote: 於 一，2013-06-03 於 16:31 +，Matthew Garrett 提到： On Tue, 2013-06-04 at 00:13 +0800, joeyli wrote: Oliver raised a question for if power fails between that succesful attempt and the deletion? It's a pretty tiny window, but sure. Making sure we delete it seems sensible. In that case we should make the GUID a #define rather than write it out twice. Base on your patch, the following diff moved DUMMY GUID to #define, and add a static efi name string: Folks, what do you want me to do with this? Merge it with Matthew's patch? The feedback from the original patch has been pretty good so I'm happy to pick it up and get it sent to Linus. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [tip:x86/efi2] efivars: efivar_entry API
On 26 April 2013 15:28, Seiji Aguchi wrote: > Matt, > > I built a tip tree With CONFIG_EFIVAR_FS=y. > But, I can't see any entries in the directory of /sys/firmware/efi/efivarfs... > > I'm not sure if it is a problem. > Just let you know. Did you mount the efivarfs file system there? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [tip:x86/efi2] efivars: efivar_entry API
On 26 April 2013 15:28, Seiji Aguchi seiji.agu...@hds.com wrote: Matt, I built a tip tree With CONFIG_EFIVAR_FS=y. But, I can't see any entries in the directory of /sys/firmware/efi/efivarfs... I'm not sure if it is a problem. Just let you know. Did you mount the efivarfs file system there? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
