Bug#612105: qemu-kvm: hangs and "irq timeout" unless -no-kvm-irqchip passed
Jonathan Nieder
Version: 0.13.0+dfsg-2
Severity: important
Hi,
See [1] for the war story. When I boot the HURD without passing
-no-kvm-irqchip on the command line, the system usually will
print
hd2: irq timeout: status=0x50
hd2: irq timeout: status=0x50
hd2: irq timeout: status=0x50
hd2: unexpected_intr: status=0x58
[and so on]
at boot time and not get past that. If lucky, the system boots
up but still hangs (not responding to keyboard input) at seemingly
random moments.
Based on a hint from guillem, I tried passing -no-kvm-irqchip on
the kvm command line. And now it works great!
Known problem? Ideas for tracking it down?
Jonathan
$ : host
$ uname -a
Linux elie 2.6.38-rc3+ #2 SMP PREEMPT Thu Feb 3 17:51:50 CST 2011 x86_64 GNU/Linux
$ (cd ~/src/linux-2.6 && git rev-parse --short HEAD)
831d52b
$ dpkg-query -W qemu-kvm vde2 libaio1 libvdeplug2 iproute \
bridge-utils etherboot-qemu qemu-utils
bridge-utils 1.4-5
etherboot-qemu 5.4.4-9
iproute 20100519-3
libaio1 0.3.107-7
libvdeplug2 2.2.3-3
qemu-kvm 0.13.0+dfsg-2
qemu-utils 0.13.0+dfsg-2
vde2 2.2.3-3
[1]
I was installing the hurd using a Debian installation CD-ROM (see
<http://www.debian.org/ports/hurd/hurd-cd>) like so:
wget http://people.debian.org/~sthibault/hurd-i386/installer/cdimage/mini.iso
qemu-img create hurd-install.qemu 3G
kvm -m 512 -net nic,model=ne2k_pci -net user \
-hda hurd-install.qemu -cdrom mini.iso -boot d
Puzzlingly, the result would hang (and not respond to keyboard
input) at seemingly random moments. Sometimes right after "Enabling
FXSR" during bootup, sometimes after the text "auth" was printed,
sometimes later.
When it hangs, it is fairly easy to nudge it back into working again:
1. Hit ctrl-alt-2 to get a console.
2. Run "info registers"
I doubt the details matter --- it is just that some nudging got it
working again. By doing so and occasionally rebooting, I eventually
got a working installation.
Even after that, though, I was not able to boot hurd, instead
receiving the message described above.
Michael Tokarev
thanks
06.02.2011 02:09, Jonathan Nieder пишет:
I can't reproduce this with either of the released kernels -
neither standard 2.6.32, nor 2.6.37-trunk from unstable,
nor with my custom kernels (2.6.32 or 2.6.36). It works
with or without -no-kvm-irqchip, on 32 or 64bits (I did
about a dozen of boots, but I didn't try to actually install
hurd, just answering a few questions installer asks and
stopping there).
How about trying one of supported kernels first, instead
of (ab)using a development snapshot of the kernel?
/mjt
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Jonathan Nieder
#
# > tags 612105 + unreproducible moreinfo
#
# I can still reproduce it on demand...
tags 612105 - unreproducible
quit
> How about trying one of supported kernels first, instead
> of (ab)using a development snapshot of the kernel?
Okay, will try. (Is testing kernels before they flow into
Debian really abuse?)
Jonathan Nieder
> How about trying one of supported kernels first
- 2.6.37-trunk-amd64 from experimental has the same problem[1].
- 2.6.32-5-amd64 from squeeze works fine.
I'll try bisecting.
Thanks,
Jonathan
[1] kvm command line:
kvm -m 768 -net nic,model=ne2k_pci -net user hurd-installed.qemu
Result:
start ext2fs: Hurd server bootstrap: ext2fs[device:hd0s1] exec
[waits a long time, I hit ctrl+alt, "info registers", etc in the
hope of waking it up", and then]
kb_setleds1: unexpected state (1)
[a bunch of times]
hd0: irq timeout: status=0x58hd0: unexpected_intr: status=0x58 { DriveReady Seek
Complete DataRequest }
{ DriveReady SeekComplete DataRequest }
and it hangs again. Adding -no-kvm-irqchip to the kvm command line
fixes it.
Michael Tokarev
>
>> How about trying one of supported kernels first, instead
>> of (ab)using a development snapshot of the kernel?
>
> Okay, will try. (Is testing kernels before they flow into
> Debian really abuse?)
No, that's not what I mean. If it looked harsh to you,
please accept my apologies, it wasn't my intention.
What I mean is: it is unrealistic to deal with bug reports
when some of the main components involved are some randome
beta release candidates with its own pile of not-yet-settled
bugs. If you try such a combination, you'll have to
understand how to handle such situation yourself, and
especially how to contact upstream who understands the
whole picture much better. From my side it isn't
practical to act as a broken phone between you and
kernel developers, you've much shorter route and you
understand your own versions and configs much better
too.
If at least most important components are the ones
which are available in debian - from one of the
released (even in -experimental) versions, so at
least their respective maintainers checked the
configs, maybe tried to run that stuff themselves
on a few machines, and just know what it is all
about, -- in that case it is practical to file
bugreports against debian packages and use BTS.
In your case, - provided the original information,
namely using a 3rd release candidate of next kernel
version - and provided the behavour didn't exist
on previous released kernel - the best will be to
use upstream bugtracker or mailinglist (most
likely kvm@vger).
But since you observed it also happens on 2.6.37
as exists in debian (even experimental), and that
kernel is actually released, things may change.
I can't reproduce it on 2.6.37 still, but at least
now I'll try harder.
Thanks.
/mjt
Jonathan Nieder
quit
Jonathan Nieder wrote:
> When I boot the HURD without passing
> -no-kvm-irqchip on the command line, the system usually will
> print
>
> hd2: irq timeout: status=0x50
> hd2: irq timeout: status=0x50
> hd2: irq timeout: status=0x50
> hd2: unexpected_intr: status=0x58
> [and so on]
>
> at boot time and not get past that. If lucky, the system boots
> up but still hangs (not responding to keyboard input) at seemingly
> random moments.
09493165 (KVM: remove isr_ack logic from PIC, 2011-02-09) which can
be found at
git://git.kernel.org/pub/scm/virt/kvm/kvm.git master
fixes this for what it's worth.
Jonathan Nieder
Jonathan Nieder wrote:
> When I boot the HURD without passing
> -no-kvm-irqchip on the command line, the system usually will
> print
>
> hd2: irq timeout: status=0x50
> hd2: irq timeout: status=0x50
> hd2: irq timeout: status=0x50
> hd2: unexpected_intr: status=0x58
> [and so on]
Fix (for the KVM host) merged to linus's master as part of
kvm-updates/2.6.39, as a commit named 7049467b (KVM: remove isr_ack
logic from PIC, 2011-02-09).
So v2.6.39 will fix this.
Hope that helps,
Jonathan
Jonathan Nieder
> Jonathan Nieder, le Thu 24 Mar 2011 05:40:34 -0500, a écrit :
>> So v2.6.39 will fix this.
>
> Great! Thanks for the notice! Do you happen to know which version the
> bug was introduced it?
Yes, it bisects to v2.6.37-rc1~142^2~39 (KVM: Check for pending events
before attempting injection, 2010-07-27). The thread starting at [1]
has details.
Regards,
Jonathan
[1] http://thread.gmane.org/gmane.comp.emulators.kvm.devel/58669/focus=67483
--
To UNSUBSCRIBE, email to debian-hu...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Samuel Thibault
Jonathan Nieder, le Thu 24 Mar 2011 05:40:34 -0500, a �crit :
> Jonathan Nieder wrote:
> > When I boot the HURD without passing
> > -no-kvm-irqchip on the command line, the system usually will
> > print
> >
> > hd2: irq timeout: status=0x50
> > hd2: irq timeout: status=0x50
> > hd2: irq timeout: status=0x50
> > hd2: unexpected_intr: status=0x58
> > [and so on]
>
> Fix (for the KVM host) merged to linus's master as part of
> kvm-updates/2.6.39, as a commit named 7049467b (KVM: remove isr_ack
> logic from PIC, 2011-02-09).
>
> So v2.6.39 will fix this.
Great! Thanks for the notice! Do you happen to know which version the
bug was introduced it?
> Hope that helps,
Sure!
Samuel
Samuel Thibault
> [1] http://thread.gmane.org/gmane.comp.emulators.kvm.devel/58669/focus=67483
Cool! Thanks for having handled this.
Samuel
--
To UNSUBSCRIBE, email to debian-hu...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2011032412...@const.bordeaux.inria.fr