Package: linux Version: 3.10.1-1 Severity: normal I have discovered a bug in the Linux kernel. This bug only occurs for the s390x port, only when running in a virtual machine under z/VM, only with conmode=3215, and only when the virtual machine is logged on to a 3270 terminal (not disconnected). I am using TERM=dumb as a kernel boot parameter, and the console definition in /etc/inittab looks like this:
T0:23:respawn:/sbin/getty -L --noclear ttyS0 9600 dumb The problem is that the kernel hangs during boot. The last message displayed on the console during boot before the hang varies. One common freeze point for the 3.13 kernel is PID hash table entries: 2048 (order: 2, 16384 bytes) Pressing the Enter key a couple of times gets it going again. Pressing it once puts the virtual machine into a "VM READ" state. Pressing it the second time causes console output to resume. However, due to buffering, I don't think the above message is indicative of where the kernel actually is in its processing. Many of the messages have time stamps on them. By comparing the time stamps, I can tell where the long pause actually was. In a recent boot, for example, I saw the following sequence of messages: ----- Begin: Loading essential drivers ... done. Begin: Running /scripts/init-premount ... done. Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done. Begin: Running /scripts/local-premount ... [ 1.973615] PM: Starting manual resume from disk done. [ 1.999199] EXT4-fs (dasdc1): mounting ext3 file system using the ext4 subsystem [ 2.042526] EXT4-fs (dasdc1): mounted filesystem with ordered data mode. Opts: (null) Begin: Running /scripts/local-bottom ... done. done. Begin: Running /scripts/init-bottom ... done. INIT: version 2.88 booting Using makefile-style concurrent boot in runlevel S. Starting the hotplug events dispatcher: udevd. Synthesizing the initial hotplug events... [ 164.525332] systemd-udevd[277]: starting version 204 done. Waiting for /dev to be fully populated... ----- (I have reformatted the above messages so that messages without a timestamp prefix and messages with a timestamp prefix line up starting with the main message text.) As you can see, there is a huge time gap between 2.042526 and 164.525332. That is where it was hung, waiting for me to press the Enter key. It is somewhere between mounting the permanent root file system read only and starting the second instance of the udev daemon. (The first instance of the udev daemon starts shortly after mounting the initial RAM file system.) By bisecting the kernel using official Debian kernel image packages only, it appears that the problem exists between 3.9.8-1 and 3.10.1-1. That is, linux-image-3.9-1-s390x_3.9.8-1_s390x.deb works, and linux-image-3.10-1-s390x_3.10.1-1_s390x.deb fails. And every version I have tried since 3.10.1-1 fails also. It should be noted that a kernel which fails does not always fail. Sometimes it does not hang. But it hangs the majority of the time. If the virtual machine is disconnected, that is, not logged on to a real terminal, it seems to always boot fine, whether the virtual machine has a SECUSER or not. When logged on to a terminal, the chances of failure are increased if the kernel is explicitly selected from the boot menu, such as with #CP VINPUT VMSG 1 as opposed to letting a timeout occur and letting the default kernel boot via a timeout. I don't know why that matters, but that has been my experience. I will be more than happy to assist in debugging this. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
