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@gmx.net wrote:
On 23.05.2008 21:25, Myles Watson wrote:
On Fri, May 23, 2008 at 1:22 PM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
Print current and wanted LZMA scratchpad size in the decompression routine. That allows people to either adjust compression parameters or scratchpad size. Having a similar check during build time would be nice.
Signed-off-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net
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.
Right now the patch is a no-op except for the better error message.
Yes. I just thought it might be worth fixing the problem at the same time if it was simple enough.
Acked-by: Myles Watson mylesgw@gmail.com
Thanks, r684 and r685 (fixup of a compilation breakage typo in r684)
Regards, Carl-Daniel