[coreboot] [PATCH] v3: print current and wanted LZMA scratchpad size
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?
More information about the coreboot