Hi Marty,
Dne 26. 10. 23 v 12:29 Marty E. Plummer via coreboot napsal(a):
It has been suggested to me in a few places that its a lack of a timer irq getting through, but I'm not certain that's actually it but its the only lead I have to go on right now. My current state of code is at: https://review.coreboot.org/c/coreboot/+/77879 and is largely based off the zork chromebooks and the mandolin devel board's code. As I can see no particular handling of timer irqs in either I'm at a loss as to what could be the missing piece of the puzzle.
I think it might be actually IRQ problem. Suppose your SATA is on wrong IRQ and on same IRQ there is also USB. Plugging and unplugging will generate the "needed" IRQs to unstuck. This might be true for any other desparate driver stucking the system on missing IRQ.
The inird+kernel are loaded via grub so they dont need to IRQ, but then block device is needed to load all the drivers and run programs so this is why it gets slower and slower. as the other drivers which kept it running are not generating the interrupts too often...
Any suggestions or solutions greatly appreciated.
can you provide cat /proc/interrupts (as root) from your system as well?
You can try to boot with "irqpoll" option and see what happens. Maybe it will work fine and then it is really IRQ issue.
What you can also do is to boot with init=/bin/bash which will drop you to the initrd minimal system (busybox) and there you can rmmod/modprobe drivers and see if SATA actually works without them. You can try reloading them to see who what is causing your issue.
It might be you are using MSI IRQ for AHCI, and this theory is wrong and problem is elsewhere. Maybe some other driver is waiting for IRQ and causes same issue... try to blacklist as much as possible (for full system boot) or try above.
Can you confirm that your rootfs is on AHCI/SATA and no NVMEs are in play?
Thanks, Rudolf