[coreboot] [PATCH] v3: print current and wanted LZMA scratchpad size

Carl-Daniel Hailfinger c-d.hailfinger.devel.2006 at gmx.net
Fri May 23 22:10:49 CEST 2008


On 23.05.2008 22:03, Carl-Daniel Hailfinger wrote:
> On 23.05.2008 21:45, Myles Watson wrote:
>   
>> On Fri, May 23, 2008 at 1:32 PM, Carl-Daniel Hailfinger
>> <c-d.hailfinger.devel.2006 at gmx.net> wrote:
>>   
>>     
>>> On 23.05.2008 21:25, Myles Watson wrote:
>>>     
>>>       
>>>> On Fri, May 23, 2008 at 1:22 PM, Carl-Daniel Hailfinger wrote:
>>>>
>>>>       
>>>>         
>>>>> Index: LinuxBIOSv3-tmp/lib/lzma.c
>>>>> ===================================================================
>>>>> --- LinuxBIOSv3-tmp/lib/lzma.c  (Revision 682)
>>>>> +++ LinuxBIOSv3-tmp/lib/lzma.c  (Arbeitskopie)
>>>>> @@ -14,6 +14,7 @@
>>>>>  #include "string.h"
>>>>>  #include "console.h"
>>>>>
>>>>> +#define LZMA_SCRATCHPAD_SIZE 15980
>>>>>
>>>>>         
>>>>>           
>>>> What's the reason for 15980?  What's the downside to increasing it further?
>>>>
>>>>       
>>>>         
>>> It's the value I picked during OLPC early bringup, based on compression
>>> efficiency measurements correlated with stack requirements. It seemed to
>>> be the sweet spot on Geode back then. Besides that, v3 relies on the
>>> stack not to outgrow 32k IIRC, otherwise stack and printk buffer will
>>> corrupt each other.
>>>     
>>>       
>> I don't know enough about the state of v3 at the point of
>> decompression, but it seems like if you could allocate the buffer on
>> the heap instead of the stack, it would make this better.  I also
>> think that it should be an error, not a warning if it can't decompress
>> the next stage.
>>   
>>     
>
> And you're absolutely right that it has to error out instead of warning
> and causing memory corruption. The same is true for in check for
> incorrect stream properties a few lines above. Care to send a patch?
>   

By the way, this is unfixable in v2 and requires a change of ulzma()
return type in v3. v3 discards the return value (outsize) of ulzma()
anyway, so we might as well change ulzma() to return a meaningful error
code.

Regards,
Carl-Daniel




More information about the coreboot mailing list