On Fri, May 14, 2010 at 1:49 PM, Joe Korty joe.korty@ccur.com wrote:
On Fri, May 14, 2010 at 03:19:45PM -0400, Myles Watson wrote:
On Fri, May 14, 2010 at 1:11 PM, Joe Korty joe.korty@ccur.com wrote:
Promote heap sizing to first-class Kconfig citizenship.
Changing the heap size is something that those, like me, with large PCI device trees need to do. ?Therefore heap size should appear as a normal, user-answerable question within the Kconfig build system.
I think the difference here is that you're a developer (not a user) once you start touching the code. Users shouldn't have to worry about the heap size. It should be set larger in your mainboard Kconfig if the mainboard needs more heap space.
Some background: The reason I'm looking at coreboot is that standard BIOSes (apparently) run out of memory while doing the bus walk, when I plug a PCI-e expansion chassis into the motherboard and populate it. The BIOS will either lock up or the OS will boot but what the OS sees for a PCI Bus (via lspci -tv) is clearly corrupt.
I wonder if that could be partly due to the ACPI implementation too.
So my job was/is to do an experiment to see if our problems are indeed due to out-of-memory issues in standard BIOSes, and if so, if coreboot could be a useful way around this issue.
And indeed, the first time I booted coreboot with a populated PCI-e chassis attached, I got an out-of-memory halt from coreboot. Increasing CONFIG_HEAP_SIZE to 0x10000 (ie, 4x) got the system to boot, and lspci -tv looks good also. I have yet to try intermediate values.
It seems like you have a pretty specific special case. Maybe we should create a CONFIG_EXTRA_HEAP that depends on CONFIG_EXPERT that lets you add heap.
Unfortunately we have an even bigger PCI-e loaded expansion chassis (configuration #2), for which coreboot also hangs. It's not an out-of-memory hang; it happens (apparently) during the bus walk. I haven't looked into this hang in detail yet, so I don't have much to report. But I do fear it may be something more fundamental.
Sounds like fun.
Thanks, Myles