Ingo Molnar wrote:
* H. Peter Anvin <[EMAIL PROTECTED]> wrote:
(If it's a qemu issue, I can go bother them. It's possible that qemu
isn't delivering interrupts as often as it expects, since that's
limited by the granularity of the host timer; I know the clock in
qemu can run a bit slow because it only gets clock interrupts when
the host system isn't too busy to schedule the emulator. But this
doesn't usually cause a problem. I _think_ the message is just a
"this should never happen" type warning, which is happening to me.
But I break stuff. :)
This is because Qemu spews data to the serial port without any rate
limiting; this causes the in-kernel serial port driver to think the
port is stuck. The serial port emulation needs to make it possible to
drain the virtual FIFO every now and then, as opposed to filling it
again immediately.
actually, the way i solved it for qemu+KVM+paravirt was to just turn off
this rather silly check in the serial driver if inside a paravirt guest.
When we are emulated then the serial 'hardware' is totally reliable and
we should just trust it. That way i never dropped a single bit of kernel
log output again.
Yes, but keying that on paravirt is silly in the extreme. After all,
there is no need for this to be paravirtualized.
-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
