[Qemu-discuss] Uncaught target signal 11 (Segmentation fault) - core dumped

[Mauro Molinari]

Hello,
I'm new to QEMU, so please sorry if I say something stupid.
I have an x86-64 VirtualBox machine with a Linux Debian Wheezy system on 
it that I use to do a sort of "cross compilation" of packages for an 
armhf embedded system. In short, the host x86-64 Debian has a script 
that chroots a guest ARM subsystem (which is Debian, too, either Wheezy 
or Jessie) which runs using qemu-arm-static and its purpose is just to 
download and build Debian packages (hence, for the ARM architecture) 
using apt-get & C.. The QEMU being used in the host system is from 
qemu-user-static Debian package, version 2.1+dfsg-2~bpo70+2 (installed 
from wheezy-backports).
All works fine, I built dozen packages in this way and they work on the 
target system, but with a couple of them the building process aborts 
with a segmentation fault which I think comes from QEMU. This is one 
example output:


qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault

followed by other error messages saying that the child process (the 
build one) failed.


What could I do to try to diagnose the problem?

Thanks in advance for any help.
Mauro

[Qemu-discuss] simple question about qemu -net nic option

[김찬]

Hello,
The QEMU manual says that -net nic option creates a new network interface card 
and connect it with vlan 'n'. This sounds like the qemu-system-sparc(my case) 
generates a default emulated nic for me and use it. (am I right?)
I have inserted a nic emulation model myself (for qemu-system-sparc, I inserted 
lan9220 model.) into the qemu source. I setup the tap networking (bridge) and 
ran qemu with
qemu-system-sparc -M ALDEBARAN -serial stdio -kernel sImage.elf -net nic -net 
tap,ifname=tap0
and this seems to work(ALDEBARAN is the sparc core we developed). (With this 
-net tap option, qeme automatically runs /etc/qemu-ifup tap0 to make br0 and 
tap0 interfaces and runs /etc/qemu-ifdown tap0 after pressing ctrl-C). I was 
running linux and I could do ifconfig eth0  and route add default gw  
and could do ping google.com. I inserted some prints in the linux ethernet card 
ISR to see actually packets are being processed when I setup ip address and add 
gateway and ping to google.com.
But on second thought, this qemu manual sounds like this -net nic option makes 
a default nic for me(not using the emulated nic I inserted). I tested it 
without -net nic and it didn't go through. (paging error while accessing some 
virtual address 0x8000 which is the location of the nic, so it seems this 
-net nic option really makes my inserted emulated nic envolved in the 
emulation).
Am I using the right emulated nic or qemu-provided default nic? or Do I still 
need -net nic option even though I have explicit emulated NIC instantiated 
inside qemu code?
Any hint would be deeply appreciated.
Best regards,
Chan Kim / ETRI

[Qemu-discuss] Another qemu chroot unsupported syscall question

[Dave Flogeras]

Similar to yesterday, in my qemu chroot
(armv6j-hardfloat-linux-musleabi) I am seeing un-supported syscalls
related to get/set/list xattr.  However, unlike yesterday, I looked
into the linux-user/arm/syscall_nr.h and those syscalls (226 through
237) seem to be wrapped.

The file system that I am running on does not in fact have extended
attribute support.  However the difference I am seeing is that on the
host system "getfattr ." returns nothing with a return code 0, while
inside of the chroot I see:

qemu: Unsupported syscall: 235
setfattr: /root/a.out: Function not implemented

and it returns 1.

I also notice while configuring/compiling software inside of the
chroot I get a multitude of other unsupported syscalls in the
NR_***attr family of functions.

What am I misunderstanding?

Dave

[Qemu-discuss] unsubscribe

[Bradley, Mike]

45:/lib/modules/2.6.32-358.2.1.el6.x86_64<mailto:ckim@stph45:/lib/modules/2.6.32-358.2.1.el6.x86_64>]
 arp -an ? (129.254.132.1) at  on eth0 ? (129.254.132.39) at 
f4:6d:04:05:6a:c9 [ether] on br0

This mean seen from the host, the router's mac address is 'incomplete' (what's 
it mean?) and my PC (not the host, or guest) is seen on br0. My PC should be 
seen on eth0 I think and only the virtual machine should be see from the br0.  
Hope somebody could tell me what is going on here.
Thanks!
Chan


?? ?? : "??" 
?? ?? : 2014-09-18 22:09:00 ( +09:00 )
?? ?? : qemu-discuss@nongnu.org  ?? :
?? : RE: need help in setting up tap networking for using qemu virtual machine


Forgot to mention that while qemu is running with RTEMS telnetd.exe, (with 
ETH0IP set to 48) from the host I get ping response from 47 and 48. But I 
cannot ping to google.com.
and when I type in the password at telnet, I can get in to both.
(but couple of times got 'connection close by foreign host.' I remember) Thanks 
a lot.
Chan Kim




?? ?? : "??"
?? ?? : 2014-09-18 22:00:32 ( +09:00 )
?? ?? : qemu-discuss@nongnu.org
?? :
?? : need help in setting up tap networking for using qemu virtual machine

Hello, everyone!

It's good to have some people to ask this.. I really need a help from you and 
this should be a basic question.
I'm trying to run a virtual machine (using qemu-system-sparc, I added lan9220 
emulation model inside) on my CentOS 6.4 machine.
I've read 
[url]http://www.linuxquestions.org/questions/linux-virtualization-and-cloud-90/centos-6-and-kvm-how-to-setup-bridged-networking-in-kvm-in-a-class-b-environment-4175433990/[/url]
 but my case seems different and I am not sure if this previous post is correct 
or not.

My host ip is 129.254.132.47. and I want my virtual machine to be 
129.254.132.48. (it's class B network)

I have /etc/qemu-ifup like this

- start - #!/bin/sh # # script to 
bring up the tun device in QEMU in bridged mode # first parameter is name of 
tap device (e.g. tap0) # # some constants specific to the local host - change 
to suit your host # # guest 132.48 host 132.47 bridge 132.64 set -x
ETH0IP=129.254.132.47
GATEWAY=129.254.132.1
BROADCAST=129.254.255.255
#
# First take eth0 down, then bring it up with IP address 0.0.0.0 # /sbin/ifdown 
eth0 /sbin/ifconfig eth0 0.0.0.0 promisc up # # Bring up the tap device (name 
specified as first argument, by QEMU) # /usr/sbin/openvpn --mktun --dev $1 
--user `id -un` /sbin/ifconfig $1 0.0.0.0 promisc up # # create the bridge 
between eth0 and the tap device # /usr/sbin/brctl addbr br0 /usr/sbin/brctl 
addif br0 eth0 /usr/sbin/brctl addif br0 $1 # # only a single bridge so loops 
are not possible, turn off spanning tree protocol # /usr/sbin/brctl stp br0 off 
# # Bring up the bridge with ETH0IP and add the default route # /sbin/ifconfig 
br0 $ETH0IP netmask 255.255.0.0 broadcast $BROADCAST /sbin/route add default gw 
$GATEWAY # # stop firewall - comment this out if you don't use Firestarter # 
#/sbin/service firestarter stop
- end -

and /etc/qemu-ifdown as

--- start -- #!/bin/sh # # Script to 
bring down and delete bridge br0 when QEMU exits # # Bring down eth0 and br0 # 
set -x /sbin/ifdown eth0 /sbin/ifdown br0 /sbin/ifconfig br0 down # # Delete 
the bridge # /usr/sbin/brctl delbr br0 # # bring up eth0 in "normal" mode # 
/sbin/ifconfig eth0 -promisc /sbin/ifup eth0 # # delete the tap device # 
/usr/sbin/openvpn --rmtun --dev $1 # # start firewall again # #/sbin/service 
firestarter start
 end --

and I start my virtual machine with this command :

qemu-system-sparc -M ALDEBARAN -serial stdio -kernel 
telnetd/o-optimize/telnetd.exe -net nic -net tap,ifname=tap0 (this makes 
/etc/qemu-ifup tap0 and /etc/qemu-ifdown tap0 run before and after qemu run.)

When I run above command, I can see the virtual machine's code is running. 
(it's RTEMS network-demo program. telnetd.exe) From outside the host, I can 
ping to host and the guest. So I thought everything is fine But I then I found 
something is wrong..
When I telnet to 129.254.132.47, it is centOS as expected.
But when I telnet to 129.254.132.48, it takes unusually long (like 10 seonds?) 
then I see the loging prompt coming from CentOS.(the host) I can log into it, 
and it's my host machine.
(By the way, both telnetting looked hampered by something, like interfering one 
another by wrong setting..)

I can run the same telnetd program using actual board the qemu emulator is 
emulating, and I can telnet to the board (and of course it's RTEMS). Only, when 
using actual board, I use physical network cable between my host and the board. 
(host 10.10.10.1 and the board 10.10.10.11)

I tried setting ETH0IP to 129.254.132.47 in qemu-ifup script but it didn't work.

Please anyone tell me what the problem is..

Kind regards,
Chan Kim
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.nongnu.org/archive/html/qemu-discuss/attachments/20140919/e3d6c144/attachment.html>

--

___
Qemu-discuss mailing list
Qemu-discuss@nongnu.org
https://lists.nongnu.org/mailman/listinfo/qemu-discuss


End of Qemu-discuss Digest, Vol 36, Issue 21

Re: [Qemu-discuss] Uncaught target signal 11 (Segmentation fault) - core dumped

[Peter Maydell]

On 19 September 2014 00:32, Mauro Molinari  wrote:
> qemu: uncaught target signal 11 (Segmentation fault) - core dumped
> Segmentation fault
>
> followed by other error messages saying that the child process (the build
> one) failed.

This doesn't inherently come from QEMU -- if the guest process
we're running segfaults we'll report it like this.

-- PMM

Re: [Qemu-discuss] Another qemu chroot unsupported syscall question

[Peter Maydell]

On 19 September 2014 05:11, Dave Flogeras  wrote:
> Similar to yesterday, in my qemu chroot
> (armv6j-hardfloat-linux-musleabi) I am seeing un-supported syscalls
> related to get/set/list xattr.  However, unlike yesterday, I looked
> into the linux-user/arm/syscall_nr.h and those syscalls (226 through
> 237) seem to be wrapped.
>
> The file system that I am running on does not in fact have extended
> attribute support.  However the difference I am seeing is that on the
> host system "getfattr ." returns nothing with a return code 0, while
> inside of the chroot I see:
>
> qemu: Unsupported syscall: 235
> setfattr: /root/a.out: Function not implemented
>
> and it returns 1.
>
> I also notice while configuring/compiling software inside of the
> chroot I get a multitude of other unsupported syscalls in the
> NR_***attr family of functions.
>
> What am I misunderstanding?

QEMU probes for whether the host system supports the *attr
library calls at configure time; if they don't exist it falls
back to providing a QEMU which doesn't implement these syscalls.
You need to install a recent glibc or (on older distros)
libattr. If you pass configure '--enable-attr' it will fail
noisily if the probe fails rather than quietly falling back
to not supporting the syscalls.

thanks
-- PMM

Re: [Qemu-discuss] Another qemu chroot unsupported syscall question

[Dave Flogeras]

On Fri, Sep 19, 2014 at 11:34 AM, Peter Maydell
 wrote:
> QEMU probes for whether the host system supports the *attr
> library calls at configure time; if they don't exist it falls
> back to providing a QEMU which doesn't implement these syscalls.
> You need to install a recent glibc or (on older distros)
> libattr. If you pass configure '--enable-attr' it will fail
> noisily if the probe fails rather than quietly falling back
> to not supporting the syscalls.

Ahhh ok.  Well I'm in luck, Gentoo provides a USE flag to control
--enable-attr, I just so happened to have it turned off on the host.

Thanks,
Dave

Re: [Qemu-discuss] need help in setting up tap networking for using qemu virtual machine

[Jakob Bohm]

On 19/09/2014 04:07, 김찬 wrote:



In this strainge state, when I type 'arp -an', I get
ckim@stph45:/lib/modules/2.6.32-358.2.1.el6.x86_64 
] arp -an

? (129.254.132.1) at  on eth0
? (129.254.132.39) at f4:6d:04:05:6a:c9 [ether] on br0

This mean seen from the host, the router's mac address is 'incomplete' 
(what's it mean?)

This means that when the Linux kernel inside your guest tried to
find the Ethernet MAC address for your default gateway (DG)
129.254.132.1, it did so by multicasting/broadcasting an ARP packet
on its (virtual) ethernet asking "whomever has the IP
129.254.132.1, please reply".  On your host, this would be
broadcast on your br0, which you have already connected to the real
world.  But either the query never reaches the gateway, or the
reply never reaches the guest.  So the ARP search for 129.254.132.1
is incomplete.

Possible causes:

- The host is really running a firewall, which you have not turned
 off
- Your physical ethernet switch is configured to only allow one MAC
 address on the port that is connected to your machine, so it won't
 allow traffic to the guest VM over the connection to your host.
  Turning ON STP (which is turned off by your current script) may or
 may not help on this possibility.
- The MAC address of your virtual machine conflicts with a real
 machine somewhere, perhaps somebody else's VM, perhaps the
 physical board where your code runs fine.  Note that some network
 hardware doesn't allow MAC addresses to roam around between
 different ethernet ports, at least not as fast as you can move it
 with your setup.
- Ditto for the IP address of your guest (129.254.132.48).
and my PC (not the host, or guest) is seen on br0. My PC should be 
seen on eth0 I think and only the virtual machine should be see from 
the br0.  Hope somebody could tell me what is going on here.

After running your script, your PC is connected to br0, which is
connected to eth0,so your PC should be seen from both sides and
so should the VM.  The problem isthat somehow the VM isn't seen
by (or cannot see) the DG.

Thanks!
Chan

*보낸 사람 : *"김찬" 
*보낸 날짜 : *2014-09-18 22:09:00 ( +09:00 )
*받는 사람 : *qemu-discuss@nongnu.org 
*참조 : *
*제목 : *RE: need help in setting up tap networking for using qemu 
virtual machine



Forgot to mention that while qemu is running with RTEMS telnetd.exe, 
(with ETH0IP set to 48)
from the host I get ping response from 47 and 48. But I cannot ping to 
google.com.

and when I type in the password at telnet, I can get in to both.
(but couple of times got 'connection close by foreign host.' I remember)
Thanks a lot.
Chan Kim




보낸 사람 : "김찬"
보낸 날짜 : 2014-09-18 22:00:32 ( +09:00 )
받는 사람 : qemu-discuss@nongnu.org
참조 :
제목 : need help in setting up tap networking for using qemu virtual 
machine


Hello, everyone!

It's good to have some people to ask this.. I really need a help from 
you and this should be a basic question.
I'm trying to run a virtual machine (using qemu-system-sparc, I added 
lan9220 emulation model inside) on my CentOS 6.4 machine.
I've read 
[url]http://www.linuxquestions.org/questions/linux-virtualization-and-cloud-90/centos-6-and-kvm-how-to-setup-bridged-networking-in-kvm-in-a-class-b-environment-4175433990/[/url] 
but my case seems different and I am not sure if this previous post is 
correct or not.


My host ip is 129.254.132.47. and I want my virtual machine to be 
129.254.132.48. (it's class B network)


I have /etc/qemu-ifup like this

- start -
#!/bin/sh
#
# script to bring up the tun device in QEMU in bridged mode
# first parameter is name of tap device (e.g. tap0)
#
# some constants specific to the local host - change to suit your host
#
# guest 132.48 host 132.47 bridge 132.64
set -x
ETH0IP=129.254.132.47
GATEWAY=129.254.132.1
BROADCAST=129.254.255.255
#
# First take eth0 down, then bring it up with IP address 0.0.0.0
#
/sbin/ifdown eth0
/sbin/ifconfig eth0 0.0.0.0 promisc up
#
# Bring up the tap device (name specified as first argument, by QEMU)
#
/usr/sbin/openvpn --mktun --dev $1 --user `id -un`
/sbin/ifconfig $1 0.0.0.0 promisc up
#
# create the bridge between eth0 and the tap device
#
/usr/sbin/brctl addbr br0
/usr/sbin/brctl addif br0 eth0
/usr/sbin/brctl addif br0 $1
#
# only a single bridge so loops are not possible, turn off spanning 
tree protocol

#
/usr/sbin/brctl stp br0 off
#
# Bring up the bridge with ETH0IP and add the default route
#
/sbin/ifconfig br0 $ETH0IP netmask 255.255.0.0 broadcast $BROADCAST
/sbin/route add default gw $GATEWAY
#
# stop firewall - comment this out if you don't use Firestarter
#
#/sbin/service firestarter stop
- end -

and /etc/qemu-ifdown as

--- start --
#!/bin/sh
#
# Script to bring down and delete bridge br0 when QEMU exits
#
# Bring down eth0 and br0