clh: Set serial to "null" #2437
Comments
sboeuf
added
bug
The guest Linux kernel might try to access the serial port, and in case the serial is "off", this might cause some slowness because the port is not emulated at all. Problem is, when the port is not emulated, the default value when reading the I/O port will be 0, which has a special meaning in case of the serial port. It means there is some data ready to be read, which the kernel might try to read for some time, causing global system slowness. That's why it's safer to use "null" by default as this means the serial port will be emulated but anything written to it will be redirected to /dev/null. Fixes kata-containers#2437 Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
|
@sboeuf - I presume there is some way to debug kernel boot fails - to get the bootlog (other than |
|
@grahamwhaley problem is, it might not prevent the kernel from booting, but just causing the kernel to boot slow. The kernel might be trying to read from the serial (because the I/O port |
|
@sboeuf - sure. I meant more, is there some method to get the kernel boot messages - the boot log - out of clh, if we need to debug a bust boot? So, not 100% related to this Issue, but close :-). |
|
@grahamwhaley oh yes the best way to get the kernel logs from CH is to run it with |
The guest Linux kernel might try to access the serial port, and in case the serial is "off", this might cause some slowness because the port is not emulated at all. Problem is, when the port is not emulated, the default value when reading the I/O port will be 0, which has a special meaning in case of the serial port. It means there is some data ready to be read, which the kernel might try to read for some time, causing global system slowness. That's why it's safer to use "null" by default as this means the serial port will be emulated but anything written to it will be redirected to /dev/null. Fixes kata-containers#2437 Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
The guest Linux kernel might try to access the serial port, and in case the serial is "off", this might cause some slowness because the port is not emulated at all. Problem is, when the port is not emulated, the default value when reading the I/O port will be 0, which has a special meaning in case of the serial port. It means there is some data ready to be read, which the kernel might try to read for some time, causing global system slowness. That's why it's safer to use "null" by default as this means the serial port will be emulated but anything written to it will be redirected to /dev/null. Fixes kata-containers#2437 Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
The guest Linux kernel might try to access the serial port, and in case the serial is "off", this might cause some slowness because the port is not emulated at all. Problem is, when the port is not emulated, the default value when reading the I/O port will be 0, which has a special meaning in case of the serial port. It means there is some data ready to be read, which the kernel might try to read for some time, causing global system slowness. That's why it's safer to use "null" by default as this means the serial port will be emulated but anything written to it will be redirected to /dev/null. Fixes kata-containers#2437 Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
If we want to avoid any potential weird behavior regarding the boot of the guest kernel, it's better to provide an emulated serial port. Because we don't care about getting the logs from this port, we simply need to set it to "null" so that these logs get discarded.
The text was updated successfully, but these errors were encountered: