[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:03:42 CEST 2008


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?


Regards,
Carl-Daniel




More information about the coreboot mailing list