[Qemu-devel] [Bug 577908] Re: qemu 0.12.3 default networking DNS broken

[Thomas Orgis]

Just tested again with 0.12.5: It seems to work now. Closing?

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/577908

Title:
  qemu 0.12.3 default networking DNS broken

Status in QEMU:
  Incomplete

Bug description:
  This might be something simple and known, but I don't find such 
information... I installed qemu 0.12.3 from source on a Linux/x86-64 host and 
observe that, running a debian testing guest (squeeze netinst, also the 
installed system), the DNS setup that qemu's  DHCP provides is not working.

Namely, nameserver 10.0.2.3 in /etc/resolv.conf (as created by DHCP) does not 
help name resolution, but replacing the IP with my actual DNS server does work. 
Now this is still unfortunate as it is very cumbersome to replace the DNS for 
every system I run in qemu for testing... it used to work before with earlier 
versions.

If there is some easy means to help debug this, I'll try to help... but right 
now I am rather clueless.

[Qemu-devel] [Bug 577908] Re: qemu 0.12.3 default networking DNS broken

[Thomas Orgis]

Well... with the debian VM stored in debian.qcow, the minimal command
line to trigger the behaviour is

qemu -hda debian.qcow

I do not try anything fancy -- just the default, which worked in earlier
times.

-- 
qemu 0.12.3 default networking DNS broken
https://bugs.launchpad.net/bugs/577908
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.

Status in QEMU: Incomplete

Bug description:
This might be something simple and known, but I don't find such information... 
I installed qemu 0.12.3 from source on a Linux/x86-64 host and observe that, 
running a debian testing guest (squeeze netinst, also the installed system), 
the DNS setup that qemu's  DHCP provides is not working.

Namely, nameserver 10.0.2.3 in /etc/resolv.conf (as created by DHCP) does not 
help name resolution, but replacing the IP with my actual DNS server does work. 
Now this is still unfortunate as it is very cumbersome to replace the DNS for 
every system I run in qemu for testing... it used to work before with earlier 
versions.

If there is some easy means to help debug this, I'll try to help... but right 
now I am rather clueless.

Re: [Qemu-devel] QEMU Alpha target

[Thomas Orgis]

Well, since I am someone in the lucky position of having alpha hardware in use
I can offer to test stuff.
I saved two boxen basically from the dumpster, one of which being my
primary workstation and the other open for other experiments, even.
I don't have time, especially now, but in a month or two, I guess I could
take any preliminary alpha kqemu out for a spin happily;-)

I'm not sure if I could offer ssh user access, I should ask our admin for that.
But I can compile and test code you throw at me.

There are some alphas awaiting their retirement or being halfway in it around
here... They have largely been replaced by Intel P4s and AthlonXPs in the years,
with the return to 64bit recently, most workstations being em64t or x86-64 now.
Heck, the name tag on our admin's office door still says "CRAY admin"... but
that one is long gone... *snif*
Well, computer business is bound to screw history. I moves on.


Alrighty then,

Thomas.

PS: Isn't it astonishing that everytime you mention alpha, ppl go "Aaaah... 
Alpha!";-)
But I figure the sheer mass of registers to spill (to quote gcc's error message
that started this thread) must indeed be a joy for qemu code.
And in general;-)

Re: [Qemu-devel] 0.9.0 and svn don't build with -march=pentium2 etc.; was: Latest SVN fails to build on Fedora Core 6 (same with 0.9.0)

[Thomas Orgis]

Am Wed, 28 Mar 2007 15:56:59 -0400
schrieb Rob Landley <[EMAIL PROTECTED]>: 

> On Saturday 24 March 2007 8:32 am, Sunil Amitkumar Janki wrote:
> > Anyhow, I expect 32-bit hardware to gradually die because of wear and 
> > tear in the next few years and the replacement will be 64-bit hardware so
> > the problem will solve itself that way.
> 
> Specifically, in 2008 32-bit x86 hardware both drops below 50% of the 
> installed base and stops being a commercial viable option for new sales in 
> the desktop or laptop space.

Sure, 32bit is vanishing from new hardware sales.
But I got my first machine that is able to decentnly run qemu just half a year 
ago:
A used ThinkPad. I didn't buy a new computer system since my very first system
in 1995 (which had to return to shop because they put a broken video card in...
grmbl).
So for me, 32 bits are the state-of-the art, apart from my two machines at work,
which are Compaq XP1000's being 64 bit all-over, but as astonishing an
[EMAIL PROTECTED] still can be at crunching floating point numbers, it's not a 
host
for qemu VMs (esp. since it cannot use kqemu to accelerate x86 code ... hm,
would qemu/kqemu work to run Tru64 accelerated in a vm on alpha?;-).

And... I don't expect the 32bit hardware to die because of "wear and tear",
especially when thinking of the i486DX4 that handles my DSL NAT routing needs,
or about the Pentium 100 serving as music jukebox;-)
Not to forget a i386DX40 that still just works fine when I decide to power it 
up.

Well, I don't intend to run qemu on these old systems, and I only do it casually
on my ThinkPad to test some software under a different OS.
Sure, if becoming a qemu power user with several VMs doing work and
compiling stuff, I'd think about becoming a dual/quad AMD64 user.

On that edge, though, qemu should find a way to arrange with current
gcc versions... gcc3.4 won't hold forever.


Thomas.

Re: [Qemu-devel] 0.9.0 and svn don't build with -march=pentium2 etc.; was: Latest SVN fails to build on Fedora Core 6 (same with 0.9.0)

[Thomas Orgis]

Am Sat, 24 Mar 2007 12:55:16 +
schrieb Julian Seward <[EMAIL PROTECTED]>: 

> The problems of the gcc backend to qemu have already been discussed
> extensively on this list.  Stealing 3+ registers from gcc on x86 really
> is asking for trouble, and I believe it is generally understood that the
> best long term solution is to move to a self-contained back end that 
> does not use gcc for dynamic code generation.

An innocent question: Would _not_ stealing 3 registers be a short term option?
I am still quite new to qemu (as a user, even) so I don't really know anything
about the dynamic code generation and what affects qemu performance anyway.


Thomas.

Re: [Qemu-devel] 0.9.0 and svn don't build with -march=pentium2 etc.; was: Latest SVN fails to build on Fedora Core 6 (same with 0.9.0)

[Thomas Orgis]

Am Fri, 23 Mar 2007 15:45:49 +
schrieb Paul Brook <[EMAIL PROTECTED]>: 

> > I do not understand enough of QEMU yet, but I have checked out CVS and
> > am reading through its source. When I understand more I hope we can fix
> > this long-standing annoyance.
> 
> This is GCC PR16185 .

Hm, I think I stumbled over this before... so it is still valid.

> There's no fundamental reason why some options trigger it, and others don't. 
> It trigerrs fairly randomly depending on the code generation choices gcc 
> happens to make.

So it is indeed the case that nothing particular in qemu triggers it,
just the general grab on the registers.
And it is something that won't be fixed anytime soon (in gcc), apart
from ia32 going out of use...
Personally, I started using qemu with my Pentium-M 1.4GHz laptop... so
32bit is the way there for a few years.
So I'll check for every new qemu release and gcc version if it perhaps
builds with normal optimization settings... or one identifies a spot to
release a register for x86 where it doesn't hurt qemu (since it's 
always softmmu_template.h with helper.c).

Anyway, this sounds more and more like a FAQ entry.
Perhaps it should be mentioned in qemu docs.

> 
> The problem is that x86 is chronically short of registers. qemu makes this 
> significantly worse by telling gcc it can't use most of them. gcc simply 
> isn't designed to work in these extreme situations.

Yep, x86 is chronically short of many things and loaded with others.
At work I secured two good old XP1000 alphas for myself...
they're not really as fast as my laptop, but register starvation is nothing
I expect to happen there. They got .. hm, what's the correct term... 
a shitload of registers! ;-)
x86 really was the worst arch to become market leader for home computing.
On the other hand that leadership was what made the arch mutate in the
ways it did.


Thomas.


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] 0.9.0 and svn don't build with -march=pentium2 etc.; was: Latest SVN fails to build on Fedora Core 6 (same with 0.9.0)

[Thomas Orgis]

Am Thu, 22 Mar 2007 21:13:00 +0100
schrieb Sunil Amitkumar Janki <[EMAIL PROTECTED]>: 

> I have seen this error as well when building with i686/pentium3/athlon
> optimisations. As I am doing a course on x86 assembly programming
> at the moment I can tell you that it suffers from register starvation
> and the message tells you that there aren't enough registers left.

Yeah, that's the message... what I wonder is this is to be expected.
Does SSE steal or add registers?
-march=pentium-mmx -m3dnow
seems to work, though. Is it just a coincidence that gcc optimizattion
uses some registers with high march (and SSE) that it didn't use with lower 
march?
I'm wondering if it's the code that is just lucky to compile with some
march settings and not so lucky with others or if it's a gcc bug or
whatever...


Thomas.


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] 0.9.0 and svn don't build with -march=pentium2 etc.; was: Latest SVN fails to build on Fedora Core 6 (same with 0.9.0)

[Thomas Orgis]

Am Sun, 18 Mar 2007 09:18:40 +
schrieb Nigel Horne <[EMAIL PROTECTED]>: 

> The first part is true, the second is not, in that I already upgraded
> to the 686 kernel, so the qemu build on FC6 is not fixed by installing the 
> 686 kernel.

So, do we have any other clue about this?
Some qemu coder knows anything about this error?

> /opt/gcc34/bin/gcc -march=pentium2 -Wall -O2 -g -fno-strict-aliasing
> -fomit-frame-pointer -I. -I.. -I/usr/src/qemu-0.9.0/target-i386
> -I/usr/src/qemu-0.9.0 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64
> -D_LARGEFILE_SOURCE -I/usr/src/qemu-0.9.0/fpu -DHAS_AUDIO
> -I/usr/src/qemu-0.9.0/slirp  -c -o
> helper.o /usr/src/qemu-0.9.0/target-i386/helper.c ../softmmu_template.h:
> In function `__stq_mmu': ../softmmu_template.h:260: error: unable to
> find a register to spill in class
> `GENERAL_REGS' ../softmmu_template.h:260: error: this is the insn:
> (insn:HI 365 364 366 13 ../softmmu_template.h:290 (parallel [ (set
> (reg:DI 0 ax [216]) (lshiftrt:DI (reg/v:DI 59 [ val ]) (subreg:QI
> (reg:SI 0 ax [215]) 0))) (clobber (scratch:SI)) (clobber (reg:CC 17
> flags)) ]) 309 {lshrdi3_1} (insn_list 364 (nil)) (expr_list:REG_DEAD
> (reg:SI 0 ax [215]) (expr_list:REG_UNUSED (reg:CC 17 flags)
> (expr_list:REG_UNUSED (scratch:SI) (nil)
> ../softmmu_template.h:260: confused by earlier errors, bailing out

It is really persistent with any pentium/athlon march setting above
pentium-mmx and alone with the -msse flag.
If the answer is "Do Not Use GCC Arch Setting" then it would be nice to
have it spelled out by someone else than me... of course I'd prefer
this thing to work;-)


Thomas.


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] Latest SVN fails to build on Fedora Core 6 (same with 0.9.0)

[Thomas Orgis]

Am Sun, 18 Mar 2007 00:45:00 -0400
schrieb Tony Nelson <[EMAIL PROTECTED]>: 

> >We at SourceMage GNU/Linux got reports of failed builds with that error
> >that are apparently fixed by reducing -march cflag to pentium-mmx as
> >opposed to pentium2,3,4 or pentium-m as well as any athlon.
> >Any sse flags also seem to trigger this error.
> >qemu 0.8.6 built without probs with -march=pentium-m, for example (we
> >still use the same compiler gcc-3.4.6 for this).

> Could this be caused by having a 586 kernel installed?  There's a bug in
> FC6 anaconda that causes it to sometimes install the 586 kernel when it
> should have installed the 686 kernel.  The fix is to install the 686 kernel.

Now that surprises me. The chosen cpu setting for the kernel triggers
an error in _compiling_ qemu?
Or is this a special bug with the Fedora i586 kernel?

Well, my laptop system, where this also is reproducable, is totally
compiled with -march=pentium-m and the kernel is configured for a
Pentium-M.

Do you have more information on how the kernel triggering this is
possible? And why it is happening with wemu-0.9.0 but not with 0.8.6?


Thomas.




___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] Latest SVN fails to build on Fedora Core 6 (same with 0.9.0)

[Thomas Orgis]

I'd like to add that with qemu 0.9.0 release it's the same problem,
that somehow seems to recurr from time to time (seen old similar
reports with older qemu release(s)) in helper.c.

We at SourceMage GNU/Linux got reports of failed builds with that error
that are apparently fixed by reducing -march cflag to pentium-mmx as
opposed to pentium2,3,4 or pentium-m as well as any athlon.
Any sse flags also seem to trigger this error.
qemu 0.8.6 built without probs with -march=pentium-m, for example (we
still use the same compiler gcc-3.4.6 for this).

There's a thread on the user forum, too:
http://qemu-forum.ipi.fi/viewtopic.php?p=10045#10045

Is there actually some policy on CFLAGS settings? I didn't find a FAQ
like "do not set any -march other than the most basic, qemu performance
is ruled by hand-crafted assembler anyway and -msse won't also not
help anything" .. should there be one?
I guess there is something hand-crafted fighting with gcc over
registers...


Thomas.


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel