Am I the only one lucky enough to have kernel-5.18.11-200.fc36.x86_64 crash reliably, on particular hardware, after starting a VM in virt-manager?
At least I think it's a crash. One second after a VM start it's brick-city. Display frozen, no response from the network. I've got nothing: after a reboot there's nothing in journalctl -r -b -1. This brings up fond memories -- ages ago I had a null modem adapter hooked up to a serial port, the kernel configured for a serial console, thusly I was able to capture OOPSes over the serial console, in situations like these.
But, these days, no more RS-232 ports. I dimly recall that a USB-serial option is possible; but I don't have any of that in any case.
Anyway, reverting to 5.18.9 made this VM happy, and my VMs on another hardware, also running the same kernel, are also fine. But, 5.18.11 gets reliably clusterfarked by qemu on at least on some hardware combinations. I wish I had more useful data points, but I've got nuthin' worth putting into Bugzilla.
On Mon, 2022-07-18 at 17:42 -0400, Sam Varshavchik wrote:
But, these days, no more RS-232 ports.
If it's not a laptop, there may still be one. But just on a header that needs a flylead to an external connector.
On 19/07/2022 07.42, Sam Varshavchik wrote:
Am I the only one lucky enough to have kernel-5.18.11-200.fc36.x86_64 crash reliably, on particular hardware, after starting a VM in virt-manager?
At least I think it's a crash. One second after a VM start it's brick-city. Display frozen, no response from the network. I've got nothing: after a reboot there's nothing in journalctl -r -b -1. This brings up fond memories -- ages ago I had a null modem adapter hooked up to a serial port, the kernel configured for a serial console, thusly I was able to capture OOPSes over the serial console, in situations like these.
But, these days, no more RS-232 ports. I dimly recall that a USB-serial option is possible; but I don't have any of that in any case.
Anyway, reverting to 5.18.9 made this VM happy, and my VMs on another hardware, also running the same kernel, are also fine. But, 5.18.11 gets reliably clusterfarked by qemu on at least on some hardware combinations. I wish I had more useful data points, but I've got nuthin' worth putting into Bugzilla.
Just a data point for you.
I run 5.18.11-200.fc36.x86_64 on the host and on the guest (KVM). No crashes so far. However, sound is now broken, highly distorted, so maybe there is something bad with this kernel?
You bay want to set rsyslog to log to the host, hoping to catch messages that did not make it to the guests fs. I have all my machines log to my server (which is the host too).
A special, long incantation is appended to /etc/rsyslog.conf (on the guest). On the host I Provided TCP/UDP syslog reception in the same conf file.
On 7/18/22 14:42, Sam Varshavchik wrote:
Am I the only one lucky enough to have kernel-5.18.11-200.fc36.x86_64 crash reliably, on particular hardware, after starting a VM in virt-manager?
At least I think it's a crash. One second after a VM start it's brick-city. Display frozen, no response from the network. I've got nothing: after a reboot there's nothing in journalctl -r -b -1. This brings up fond memories -- ages ago I had a null modem adapter hooked up to a serial port, the kernel configured for a serial console, thusly I was able to capture OOPSes over the serial console, in situations like these.
But, these days, no more RS-232 ports. I dimly recall that a USB-serial option is possible; but I don't have any of that in any case.
Anyway, reverting to 5.18.9 made this VM happy, and my VMs on another hardware, also running the same kernel, are also fine. But, 5.18.11 gets reliably clusterfarked by qemu on at least on some hardware combinations. I wish I had more useful data points, but I've got nuthin' worth putting into Bugzilla.
Hi Sam,
Did you try <Ctrl><alt><f2>?
Fortunately, it is not happening to me, but I am still running 5.18.10-200.fc36.x86_64. I am getting paranoid about upgrading my kernel.
Did you report it to Bugzilla?
-T
ToddAndMargo via users writes:
On 7/18/22 14:42, Sam Varshavchik wrote:
Am I the only one lucky enough to have kernel-5.18.11-200.fc36.x86_64 crash reliably, on particular hardware, after starting a VM in virt-manager?
At least I think it's a crash. One second after a VM start it's brick-city. Display frozen, no response from the network. I've got nothing: after a reboot there's nothing in journalctl -r -b -1. This brings up fond memories -- ages ago I had a null modem adapter hooked up to a serial port, the kernel configured for a serial console, thusly I was able to capture OOPSes over the serial console, in situations like these.
But, these days, no more RS-232 ports. I dimly recall that a USB-serial option is possible; but I don't have any of that in any case.
Anyway, reverting to 5.18.9 made this VM happy, and my VMs on another hardware, also running the same kernel, are also fine. But, 5.18.11 gets reliably clusterfarked by qemu on at least on some hardware combinations. I wish I had more useful data points, but I've got nuthin' worth putting into Bugzilla.
Hi Sam,
Did you try <Ctrl><alt><f2>?
Yes. It's dead as a doornail.
Fortunately, it is not happening to me, but I am still running 5.18.10-200.fc36.x86_64. I am getting paranoid about upgrading my kernel.
Did you report it to Bugzilla?
No, there's nothing worthwhile to report. "Crashes with Qemu on some hardware" isn't a very useful bug report.
Here's an example of a useful bug report: 2107827
That one looks like like my bug, except that I do not have anything to conclusively prove it; but this sounds very promising.
On Jul 19, 2022, at 17:52, Sam Varshavchik mrsam@courier-mta.com wrote:
No, there's nothing worthwhile to report. "Crashes with Qemu on some hardware" isn't a very useful bug report.
Here's an example of a useful bug report: 2107827
That one looks like like my bug, except that I do not have anything to conclusively prove it; but this sounds very promising.
Sounds like you (or the bug you post) would benefit from setting up the kdump service to capture the kernel crash.
https://fedoraproject.org/wiki/How_to_use_kdump_to_debug_kernel_crashes
-- Jonathan Billings
On 19/07/2022 14.39, Eyal Lebedinsky wrote:
On 19/07/2022 07.42, Sam Varshavchik wrote:
Am I the only one lucky enough to have kernel-5.18.11-200.fc36.x86_64 crash reliably, on particular hardware, after starting a VM in virt-manager?
At least I think it's a crash. One second after a VM start it's brick-city. Display frozen, no response from the network. I've got nothing: after a reboot there's nothing in journalctl -r -b -1. This brings up fond memories -- ages ago I had a null modem adapter hooked up to a serial port, the kernel configured for a serial console, thusly I was able to capture OOPSes over the serial console, in situations like these.
But, these days, no more RS-232 ports. I dimly recall that a USB-serial option is possible; but I don't have any of that in any case.
Anyway, reverting to 5.18.9 made this VM happy, and my VMs on another hardware, also running the same kernel, are also fine. But, 5.18.11 gets reliably clusterfarked by qemu on at least on some hardware combinations. I wish I had more useful data points, but I've got nuthin' worth putting into Bugzilla.
Just a data point for you.
I run 5.18.11-200.fc36.x86_64 on the host and on the guest (KVM). No crashes so far. However, sound is now broken, highly distorted, so maybe there is something bad with this kernel?
You bay want to set rsyslog to log to the host, hoping to catch messages that did not make it to the guests fs. I have all my machines log to my server (which is the host too).
A special, long incantation is appended to /etc/rsyslog.conf (on the guest). On the host I Provided TCP/UDP syslog reception in the same conf file.
I now changed the guest machine from "sound ac97" to "sound ich6" and sound now works OK. The old setup was OK for a very long time.
It is a worry when a stable setup stops working, so the OP may consider trying different guest settings.
YMMV
On Wed, 2022-07-20 at 13:20 +1000, Eyal Lebedinsky wrote:
On 19/07/2022 14.39, Eyal Lebedinsky wrote:
On 19/07/2022 07.42, Sam Varshavchik wrote:
Am I the only one lucky enough to have kernel-5.18.11- 200.fc36.x86_64 crash reliably, on particular hardware, after starting a VM in virt-manager?
At least I think it's a crash. One second after a VM start it's brick-city. Display frozen, no response from the network. I've got nothing: after a reboot there's nothing in journalctl -r -b -
- This brings up fond memories -- ages ago I had a null modem
adapter hooked up to a serial port, the kernel configured for a serial console, thusly I was able to capture OOPSes over the serial console, in situations like these.
But, these days, no more RS-232 ports. I dimly recall that a USB- serial option is possible; but I don't have any of that in any case.
Anyway, reverting to 5.18.9 made this VM happy, and my VMs on another hardware, also running the same kernel, are also fine. But, 5.18.11 gets reliably clusterfarked by qemu on at least on some hardware combinations. I wish I had more useful data points, but I've got nuthin' worth putting into Bugzilla.
Just a data point for you.
I run 5.18.11-200.fc36.x86_64 on the host and on the guest (KVM). No crashes so far. However, sound is now broken, highly distorted, so maybe there is something bad with this kernel?
You bay want to set rsyslog to log to the host, hoping to catch messages that did not make it to the guests fs. I have all my machines log to my server (which is the host too).
A special, long incantation is appended to /etc/rsyslog.conf (on the guest). On the host I Provided TCP/UDP syslog reception in the same conf file.
I now changed the guest machine from "sound ac97" to "sound ich6" and sound now works OK. The old setup was OK for a very long time.
It is a worry when a stable setup stops working, so the OP may consider trying different guest settings.
IIRC ich6 has been preferred to ac97 for quite a long time now.
You may also want to check that you're using the i440FX chipset rather than the older one (the name of which escapes me).
poc
Patrick O'Callaghan writes:
On Wed, 2022-07-20 at 13:20 +1000, Eyal Lebedinsky wrote:
On 19/07/2022 14.39, Eyal Lebedinsky wrote:
On 19/07/2022 07.42, Sam Varshavchik wrote:
Am I the only one lucky enough to have kernel-5.18.11- 200.fc36.x86_64 crash reliably, on particular hardware, after starting a VM in virt-manager?
At least I think it's a crash. One second after a VM start it's brick-city. Display frozen, no response from the network. I've got nothing: after a reboot there's nothing in journalctl -r -b -
- This brings up fond memories -- ages ago I had a null modem
adapter hooked up to a serial port, the kernel configured for a serial console, thusly I was able to capture OOPSes over the serial console, in situations like these.
But, these days, no more RS-232 ports. I dimly recall that a USB- serial option is possible; but I don't have any of that in any case.
Anyway, reverting to 5.18.9 made this VM happy, and my VMs on another hardware, also running the same kernel, are also fine. But, 5.18.11 gets reliably clusterfarked by qemu on at least on some hardware combinations. I wish I had more useful data points, but I've got nuthin' worth putting into Bugzilla.
Just a data point for you.
I run 5.18.11-200.fc36.x86_64 on the host and on the guest (KVM). No crashes so far. However, sound is now broken, highly distorted, so maybe there is something bad with this kernel?
You bay want to set rsyslog to log to the host, hoping to catch messages that did not make it to the guests fs. I have all my machines log to my server (which is the host too).
A special, long incantation is appended to /etc/rsyslog.conf (on the guest). On the host I Provided TCP/UDP syslog reception in the same conf file.
I now changed the guest machine from "sound ac97" to "sound ich6" and sound now works OK. The old setup was OK for a very long time.
It is a worry when a stable setup stops working, so the OP may consider trying different guest settings.
IIRC ich6 has been preferred to ac97 for quite a long time now.
I had mine set to use ich9 and ich6 made no difference to me, it's still scratchy. It looks to me more fundamental than emulated audio, the entire VM became sluggish with the 5.18 kernel.
On Wed, 2022-07-20 at 06:50 -0400, Sam Varshavchik wrote:
Patrick O'Callaghan writes:
On Wed, 2022-07-20 at 13:20 +1000, Eyal Lebedinsky wrote:
On 19/07/2022 14.39, Eyal Lebedinsky wrote:
On 19/07/2022 07.42, Sam Varshavchik wrote:
Am I the only one lucky enough to have kernel-5.18.11- 200.fc36.x86_64 crash reliably, on particular hardware, after starting a VM in virt-manager?
At least I think it's a crash. One second after a VM start it's brick-city. Display frozen, no response from the network. I've got nothing: after a reboot there's nothing in journalctl -r -b -
- This brings up fond memories -- ages ago I had a null
modem adapter hooked up to a serial port, the kernel configured for a serial console, thusly I was able to capture OOPSes over the serial console, in situations like these.
But, these days, no more RS-232 ports. I dimly recall that a USB- serial option is possible; but I don't have any of that in any case.
Anyway, reverting to 5.18.9 made this VM happy, and my VMs on another hardware, also running the same kernel, are also fine. But, 5.18.11 gets reliably clusterfarked by qemu on at least on some hardware combinations. I wish I had more useful data points, but I've got nuthin' worth putting into Bugzilla.
Just a data point for you.
I run 5.18.11-200.fc36.x86_64 on the host and on the guest (KVM). No crashes so far. However, sound is now broken, highly distorted, so maybe there is something bad with this kernel?
You bay want to set rsyslog to log to the host, hoping to catch messages that did not make it to the guests fs. I have all my machines log to my server (which is the host too).
A special, long incantation is appended to /etc/rsyslog.conf (on the guest). On the host I Provided TCP/UDP syslog reception in the same conf file.
I now changed the guest machine from "sound ac97" to "sound ich6" and sound now works OK. The old setup was OK for a very long time.
It is a worry when a stable setup stops working, so the OP may consider trying different guest settings.
IIRC ich6 has been preferred to ac97 for quite a long time now.
I had mine set to use ich9 and ich6 made no difference to me, it's still scratchy. It looks to me more fundamental than emulated audio, the entire VM became sluggish with the 5.18 kernel.
Regarding sound, there are some suggestions here:
https://juho.tykkala.fi/Pulseaudio-and-latency#positive-effect-on-latency
However I haven't tried the latest kernel myself so can't really comment.
poc
-
Eyal Lebedinsky -
Jonathan Billings -
Patrick O'Callaghan -
Sam Varshavchik -
Tim -
ToddAndMargo