On Tue, 18 Jun, at 10:12:22PM, Zachary Bobroff wrote: > > Okay, I'm fine with that aspect then. Let's hope everyone plays by > > that rule. > This is all according to specification, so if they are not following > these rules they should be corrected. The link to where the current > public version of the specification is available is here: > http://www.uefi.org/specs/agreement While I agree that the vendor should be informed if their implementation deviates from the spec in some way, the Linux kernel usually still needs to support these nonconforming machines once they end up in the hands of consumers (which is often the point at which we discover these kinds of issues). Sadly, we're still not in a position where firmware updates can be applied from OEMs ubiquitously, either because machines are End of Life'd or because the update needs to be run from Windows. We tend to adopt the approach of: let's try this until we get reports of a class of machines where this solution doesn't work. Though I do find it refreshing to hear engineers talking about the UEFI spec in such black and white terms. That is certainly the ideal we should be aiming for. > > Why by one? Splitting some 'free memory' block may result in an > > increase by more then one afaict. Assuming the increment can only be > > one is >implying you having knowledge of the allocator > > implementation and behavior, which shouldn't be made use of in > > kernel code. > We had to actually increment it by two to get it to work correctly. > This is all based upon the use of the low_alloc routine in the linux > kernel file. I agree there is still some outstanding issue based upon > this, but we put it through several different types of tests and it > continued to work correctly. The truest solution would be to us the > AllocateMaxAddress parameter when using AllocatePages. [...] > It was my understanding that the point of this was to allocate the > memory map below a certain address in memory because the kernel > required it. Matt, can you comment here? I am not aware of what > address it needs to be below, but using this function should do the > trick. Also, if you want to inform me better of what memory ceiling > restrictions there are at this early stage of the kernel, I can > rewrite the file without the need of the low_alloc routine entirely. The most important restriction is that all allocations in the EFI boot stub need to be below the 1GB mark, because only the first 1GB of virtual memory is mapped, unless certain flags are set in the xloadflags field of the boot_params header. See Documentation/x86/boot.txt. Further to that, I think I remember some restrictions on the location of the cmdline pointer - that it needs to be below 0xa0000. Again, Documentation/x86/boot.xt should have all the info you need. -- Matt Fleming, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html