Well, my custom kernel (in which, on a hunch, I turned off timer
ticks) is still building, but I now have this diagnostic information:
If you (under VM) do a CP D P ALL you see that you're generally in
scheduler_tick, sometimes in account_user_time_scaled, sometimes
tick_switch_to_oneshot.
At any rate, it's always some timer routine.
So, this may just be telling us that the kernel keeps setting a timer
waiting for something to happen, waking up, seeing that whatever
hasn't happened, and trying again.
But there's another hunch I'm testing:
The default ticks Hz value on this kernel was 250. This problem has
only appeared on Flex and Hercules. What these have in common is that
they're emulated s390 machines, and they're very much slower than the
real iron. Might it be that having the jiffy timer popping every 4 ms
is interacting badly with what is, effectively, a very very slow
variable-clock machine?
If that's the case, turning off timer ticks (i.e. CONFIG_NO_HZ=y) may
be enough to let me boot, which would be cool. I don't know if that
will work on Hercules (or in an LPAR) though. For whatever it's
worth, on the etchnhalf system /proc/sys/kernel/hz_timer is 0, which I
*think* means the on-demand timer is enabled.
Unfortunately, on my system it takes a lot of hours to build a kernel,
so I'm not going to be able to test these hypotheses fast.
Adam
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
