On 20.06.2009 20:08, Ward Vandewege wrote:
On Sat, Jun 20, 2009 at 10:13:04AM -0700, ron minnich wrote:
That is fine. That's a simple and straightforward change. How about we start with that. But let's not do THAT change until we fix ward's problem, and this has nothing to do with Ward's problem.
Sorry for opening this can of worms ;)
So, Stepan thinks that perhaps the stack is too small for the lzma decompression. I'm going to test next week with a 32KB stack (right now its at the default 8KB).
Wait a second. We have two different possible problems to consider. 1. Every core which uses LZMA decompression needs at least 24k stack. 2. AP stacks are a lot smaller than the BSP stack by design, so even if you have a 24k stack for the BSP, it is unlikely you have sufficient stack size for the APs.
Can you test with 32k BSP stack size, but uncompressed AP code and default AP stack size? Unless CBFS code has some internal design/code limitations (and I didn't see any regarding the stack), the lzma stack requirements should not show up on APs for uncompressed AP code.
This might solve booting, but I'll still have APs and BSP talking all at once, which I'm also seeing on K10.
That's the locking problem which we can fix separately.
Regards, Carl-Daniel