[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