On Wed, Dec 30, 2020 at 01:06:45PM +0100, Evgeni Golov wrote: > > This doesn't happen on the buster cloud images, and a few "apt install" > > invocations later I could bisect the issue to be the upgrade of seabios > > from 1.12.0-1 to 1.14.0-2. > > > > I also can't repro this in vagrant (by using the buster64 box and > > upgrading it fully to testing) with libvirt/qemu as a backend instead of > > plain qemu. > > > > So there seem to be more levels of weirdness to this. > > > And the tuned line that breaks the whole thing is > > [sysctl] > kernel.sched_wakeup_granularity_ns = 15000000
This also happens on seabios 1.13.0-1 from snapshot.d.o. I originally wanted to go and bisect that with upstream seabios.git, but then couldn't reproduce with upstreams 1.14.0… Until I realized that I built it with CONFIG_ATA_DMA=y (as Debians 1.12) and indeed, this is what was changed in 1.13 to n (see [1]) and also what does trigger the bug you describe: with ATA_DMA=n the boot hangs, with ATA_DMA=y it boots fine. Now understanding *why* ATA_DMA=n and sched_wakeup_granularity_ns together have this result requires more scotch than I have at hand right now. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934134
