65e962fb76
the kernel stack at all. The new USB stack simply caused a change in timing that triggered a firmware bug more often. The addition of PRINTF_BUFR_SIZE apparently triggered the same firmware bug even more reliably. But even with KSTACK_PAGES=5, one instance of the firmware bug remained: booting with a CD inserted. This problem was run into by accident after installing Debian and having to boot FreeBSD to fixup the GPT partitioning (Thanks... not). After bumping KSTACK_PAGES to 5, it was pretty unbelievable that the stack was still being too small. After updating the firmware we could boot with a CD inserted and KSTACK_PAGES could be lowered back to 4 pages without problems. Note: It is believed to be a timing related firmware bug, because the machine check information showed access to the serial console on one CPU and access to the EHCI HCD on the other CPU. Since both are devices on the management unit and thus virtualized in some way, any execution trace that does not include concurrent access to the BMC from both CPUs is fine. Note also that it's not understood exactly how increasing the kernel stack avoided hitting the firmware bug. A change in page faults does change timing, but it's not known if that's what's happening here. In any case: the problem is being monitored. Reverting back to 4 pages for the kernel stack is preferred, because it makes it easier to switch to 16K pages (double the page size) without wasting too much memory by not being able to half the number of pages... |
||
|---|---|---|
| .. | ||
| acpica | ||
| compile | ||
| conf | ||
| disasm | ||
| ia32 | ||
| ia64 | ||
| include | ||
| isa | ||
| pci | ||