G'day all,
Just wonder if anyone else is seeing this. I've not had a chance to track it down or try to debug it
yet.
I'm running latest QEMU CVS with kqemu and the -no-tsc patch on a vanilla
2.6.17.3 kernel with suspend2.
The VM behaves perfectly until I do a suspend/resume of the host. When
On Sun, 09 Jul 2006 17:56:31 +0200, 赵刚 <[EMAIL PROTECTED]> wrote:
I'm running BasicLinux3.4(Baslin3.4-qemu.img kernel 2.2.26) on Win98
,and I receive quite often this following messages:
probable hardware bug: clock timer configuration lost - probably a
VIA686a.
probable hardware bug: res
On Sun, Jul 09, 2006 at 05:03:12PM -0700, John R. wrote:
> On 7/8/06, Oliver Gerlich <[EMAIL PROTECTED]> wrote:
>
> >Is wxC still under active development? The CVS version seems to be quite
> >old, and I also couldn't find any documentation.
> >
>
> Well it wouldn't be the first unmaintained batc
On 7/8/06, Oliver Gerlich <[EMAIL PROTECTED]> wrote:
Is wxC still under active development? The CVS version seems to be quite
old, and I also couldn't find any documentation.
Well it wouldn't be the first unmaintained batch of code added to
QEMU... Slirp is the example that comes to mind. In
I'm running BasicLinux3.4(Baslin3.4-qemu.img kernel 2.2.26) on Win98 ,and I receive quite often this following messages:
probable hardware bug: clock timer configuration lost - probably a VIA686a. probable hardware bug: restoring chip configuration.
Does anyone know to fix this problem? Tha
Paul Brook wrote:
> qemu hardware does support DMA, but I don't think this matters.
> By my reading DMA writes don't need to wake mwait.
> The exact wording is "store operation", which I'd expect to mean
> execution of a store instruction (by a different CPU).
Hmm. x86 CPUs snoop writes by DMA as
R. Armiento wrote:
> I'm not sure if I have understood all sources from where such a
> memory write can come from while the processor is asleep. One
> source, I suppose, is from other processors in an SMP setup? Another
> source may be DMA? Does this mean that it is safe to emulate wmait
> as hlt i
Joachim Henke wrote:
> Currently the Linux kernel simply uses monitor/mwait as a faster
> 'hlt' replacement, so it should be "safe" there. I don't know about
> other guest OSs. Anyway, I proposed this hack only as a quick
> "solution" for local usage.
As long as there's only one CPU and 'mwa
Ok, I forgot about external kernel modules or patches, as I don't use
any. But in plain Linux 2.6.17 mwait is only used in the function
mwait_idle()
R. Armiento wrote:
But I just don't see how you can postulate that mwait is not used
anywhere else in the Linux kernel? There are many kernel
> > Worse, the guest might decide to swap out a page that's already
> > swapped in by the host, forcing it to be read in again only to be
> > immediately written out to disk by the guest :-(
>
> ...unless the guest's disk I/O is with simulated DMA or recognisable
> block-copy instruction sequences,
> > Problem is, at the moment I've no idea, how we could achieve this memory
> > monitoring in a safe and simple way in user space.
>
> I'm trying to read up on monitor and mwait. Apparently mwait puts the
> processor in low-power wait mode, waiting for a memory write in some
> select area defined
R. Armiento wrote:
Couldn't there be situations where someone depends on mwait waking up
without there being an event that wakes hlt? Or are we sure qemu's hlt
will happen to wake up anyway?
Joachim Henke wrote:
Currently the Linux kernel simply uses monitor/mwait as a faster 'hlt'
replacem
Hi!This updated patch against current CVS implements TCP segmentation offloading for RTL8139 in C+ mode.I fixed a couple of problems in implementation (wrong sequence number calculation), and now TCP performance seem to be normal.
Dependency on slirp.h header is now gone.Again tested with linux (et
R. Armiento wrote:
Is this hack really 'safe'? I don't claim to know much about modern
x86 instructions, but some googling tells me that mwait is supposed
to wake on a monitored memory write (but is allowed to wake up
earlier, hence it is acceptable but CPU consuming to emulate it
with a n
14 matches
Mail list logo
