Re: [patch 3/6] Cleanup efi_enter_virtual_mode function
On Fri, Nov 01, 2013 at 09:18:25AM +0800, Dave Young wrote: Great, thank you. BTW, I have managed to test original patch set on a Macboot Air of my friend with usb boot, it works ok. Ok, that's actually a very good news - the apples tend to be special wrt uefi implementation. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- 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 10/11] EFI: Runtime services virtual mapping
On Fri, 01 Nov, at 11:35:08AM, Dave Young wrote: The conflict is caused by missing one commit in matt's efi next tree: commit 700870119f49084da004ab588ea2b799689efaf7 Author: Josh Boyer jwbo...@redhat.com Date: Thu Apr 18 07:51:34 2013 -0700 x86, efi: Don't map Boot Services on i386 Add patch to fix 32bit EFI service mapping (rhbz 726701) Multiple people are reporting hitting the following WARNING on i386, WARNING: at arch/x86/mm/ioremap.c:102 __ioremap_caller+0x3d3/0x440() Modules linked in: Pid: 0, comm: swapper Not tainted 3.9.0-rc7+ #95 Rethinking about above commit, it is actually a workaround for mapping boot service, I suspect the problem connect to the off-by-one problem in boot service reserve function. Matt, idea? No, it's not the same problem. And just to make absolutely sure I reverted the above commit and applied your patch, but I still see the WARN_ON() described above. -- Matt Fleming, Intel Open Source Technology Center -- 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
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. Seiji
Re: [PATCH] Make efi-pstore return a unique id
On Fri, Nov 1, 2013 at 1:57 PM, Seiji Aguchi seiji.agu...@hds.com 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
