On Feb 13, Michael Biebl bi...@debian.org wrote:
If the kernel is supposed to support such timeouts, this looks like a
hardware/qemu issue to me then.
Apparently Red Hat has a fix:
https://bugzilla.redhat.com/show_bug.cgi?id=1173038
I can reproduce the issue with Debian KVM and a RHEL7 guest,
Am 25.02.2015 um 19:33 schrieb Marco d'Itri:
On Feb 13, Michael Biebl bi...@debian.org wrote:
If the kernel is supposed to support such timeouts, this looks like a
hardware/qemu issue to me then.
Apparently Red Hat has a fix:
https://bugzilla.redhat.com/show_bug.cgi?id=1173038
I don't see
clone 35 -1
reassign -1 qemu-system-x86
retile -1 setting unsupported timeout for i6300esb watchdog causes reset
thanks
Am 13.02.2015 um 08:55 schrieb Peter Colberg:
On Fri, Feb 13, 2015 at 08:02:09AM +0100, Michael Biebl wrote:
Am 13.02.2015 um 07:44 schrieb Michael Biebl:
I went on and
Am 13.02.2015 um 08:55 schrieb Peter Colberg:
In the linux-3.16.7-ckt4 source the range of the timeout value for
the i6300esb is 1s timeout 2*1023s. In theory it should work
with the default shutdown timeout of 10min.
This again might suggest, that his is a hardware, i.e. qemu bug?
For the
On Thu, Feb 12, 2015 at 08:50:59AM +0100, Michael Biebl wrote:
Some more findings: Aside from only happening on reboot, but not
shutdown, it also seems to only happen with i6300esb. Switching the qemu
config to use ib700 instead of i6300esb, I am not able to trigger the
problem. This confirm's
Am 13.02.2015 um 07:44 schrieb Michael Biebl:
I went on and looked what the watchdog package does. Interestingly, it
clamps any timeout value to 254s, thus not hitting this issue.
Apparently, i6300esb is able to deal with such a timeout.
Peter, I therefore recommend you set
Am 12.02.2015 um 09:54 schrieb Peter Colberg:
[ 11.473895] systemd[1]: Failed to set timeout to 600s: Invalid argument
[ 11.474649] ib700wdt: WDT device closed unexpectedly. WDT will not stop!
Both watchdogs close unexpectedly, but i6300esb immediately resets the
machine, while ib700wdt
On Fri, Feb 13, 2015 at 08:02:09AM +0100, Michael Biebl wrote:
Am 13.02.2015 um 07:44 schrieb Michael Biebl:
I went on and looked what the watchdog package does. Interestingly, it
clamps any timeout value to 254s, thus not hitting this issue.
Apparently, i6300esb is able to deal with such a
control: tags -1 moreinfo unreproducible
Am 12.02.2015 um 03:19 schrieb Peter Colberg:
Package: systemd
Version: 215-11
Severity: grave
Justification: causes non-serious data loss
Dear Maintainer,
After upgrading to jessie from wheezy, I noticed that some of the
system logs experience
Package: systemd
Version: 215-11
Severity: grave
Justification: causes non-serious data loss
Dear Maintainer,
After upgrading to jessie from wheezy, I noticed that some of the
system logs experience corruption when rebooting the system.
After rebooting the system using the command ‘reboot’ or
Am 12.02.2015 um 07:34 schrieb Michael Biebl:
Am 12.02.2015 um 07:29 schrieb Peter Colberg:
On Thu, Feb 12, 2015 at 07:14:05AM +0100, Michael Biebl wrote:
It is curious that the bug only manifests itself with the qemu watchdog.
Two physical machines using the hardware iTCO_wdt watchdog
Am 12.02.2015 um 07:34 schrieb Michael Biebl:
Am 12.02.2015 um 07:29 schrieb Peter Colberg:
On Thu, Feb 12, 2015 at 07:14:05AM +0100, Michael Biebl wrote:
It is curious that the bug only manifests itself with the qemu watchdog.
Two physical machines using the hardware iTCO_wdt watchdog
Am 12.02.2015 um 08:31 schrieb Michael Biebl:
Am 12.02.2015 um 07:34 schrieb Michael Biebl:
Am 12.02.2015 um 07:29 schrieb Peter Colberg:
On Thu, Feb 12, 2015 at 07:14:05AM +0100, Michael Biebl wrote:
It is curious that the bug only manifests itself with the qemu watchdog.
Two physical
Am 12.02.2015 um 07:29 schrieb Peter Colberg:
On Thu, Feb 12, 2015 at 07:14:05AM +0100, Michael Biebl wrote:
It is curious that the bug only manifests itself with the qemu watchdog.
Two physical machines using the hardware iTCO_wdt watchdog reboot fine.
In my tests, I did indeed have an
On Thu, Feb 12, 2015 at 05:44:59AM +0100, Michael Biebl wrote:
Fwiw, I pulled the debian_wheezy_amd64_desktop.qcow2 qemu-kvm image from
[1], started it with qemu-system-x86_64 -enable-kvm -hda
debian_wheezy_amd64_standard.qcow2.
Then did a dist-upgrade to jessie, which replaced sysvinit with
control: tags -1 = confirmed
control: retitle -1 data corruption on reboot when using watchdog/qemu
Am 12.02.2015 um 06:57 schrieb Peter Colberg:
On Thu, Feb 12, 2015 at 05:44:59AM +0100, Michael Biebl wrote:
Fwiw, I pulled the debian_wheezy_amd64_desktop.qcow2 qemu-kvm image from
[1], started
On Thu, Feb 12, 2015 at 07:14:05AM +0100, Michael Biebl wrote:
Thanks, I was able to reproduce the issue this way (marking the bug
accordingly).
It's likely that the watchog is resetting systemd/rsyslog before it has
a chance to stop properly.
Let's see, where we can go from here.
In a
On Thu, Feb 12, 2015 at 04:28:38AM +0100, Michael Biebl wrote:
Just to be clear here: Is this only happening once after the
dist-upgrade from wheezy (sysvinit) to jessie (systemd-sysv) on reboot
or everytime you reboot your jessie system?
It happens everytime I reboot from within the VM.
control: severity -1 important
Am 12.02.2015 um 04:28 schrieb Michael Biebl:
I could reproduce this issue with three machines that are virtualized
with qemu-kvm. On the other hand, I did not see this issue with two
physical machines. All of these are running the above version of
systemd.
19 matches
Mail list logo
