summary refs log tree commit diff stats
path: root/results/classifier/108/other/1579
diff options
context:
space:
mode:
Diffstat (limited to '')
-rw-r--r--results/classifier/108/other/157919
-rw-r--r--results/classifier/108/other/157930687
-rw-r--r--results/classifier/108/other/1579327297
-rw-r--r--results/classifier/108/other/1579565101
4 files changed, 504 insertions, 0 deletions
diff --git a/results/classifier/108/other/1579 b/results/classifier/108/other/1579
new file mode 100644
index 00000000..29dd2891
--- /dev/null
+++ b/results/classifier/108/other/1579
@@ -0,0 +1,19 @@
+other: 0.956
+files: 0.917
+network: 0.856
+graphic: 0.853
+device: 0.751
+performance: 0.720
+boot: 0.358
+semantic: 0.349
+PID: 0.231
+debug: 0.204
+vnc: 0.180
+socket: 0.145
+KVM: 0.071
+permissions: 0.065
+
+Cache vdpa initialization & startup slow ioctls
+Additional information:
+* vring groups are cached in this patch, still not upstream [this example patch](https://lists.nongnu.org/archive/html/qemu-devel/2023-03/msg05961.html).
+* hw/virtio/vhost-vdpa.c and net/vhost-vdpa.c are both files that worth exploring.
diff --git a/results/classifier/108/other/1579306 b/results/classifier/108/other/1579306
new file mode 100644
index 00000000..8f3807ea
--- /dev/null
+++ b/results/classifier/108/other/1579306
@@ -0,0 +1,87 @@
+semantic: 0.868
+other: 0.852
+graphic: 0.849
+debug: 0.845
+device: 0.827
+performance: 0.808
+permissions: 0.803
+PID: 0.800
+vnc: 0.765
+socket: 0.762
+KVM: 0.736
+network: 0.707
+boot: 0.702
+files: 0.667
+
+usb-uas does not work in Windows (10) guest
+
+When I attach a "-device usb-uas" to a VM with Windows 10 10586, the device fail to start with the following error in the guest:
+
+"The device cannot start. (Code 10)
+
+{Operation Failed}
+The requested operation was unsuccessful"
+
+If the host controller is nec-usb-xhci, there will be two of the following error on the terminal of the host as well:
+
+"qemu-system-x86_64: usb_uas_handle_control: unhandled control request"
+
+If it's usb-ehci, ich9-usb-ehci1 or ich9-usb-echi2, this will not show up on the host side, but the device stil fails with the same error on the guest side.
+
+
+
+usb-bot works fine
+
+Also tried to "passthrough" the SCSI layer of an actual UASP drive with scsi-block. No luck either.
+
+Not sure if it's relevant, but when I try completely passthrough a UASP device to the VM through usb-host, only the BOT/MSC part is exposed. This is not the case when I do the same thing to a Linux guest (btw usb-uas apparently works fine in Linux guest as well).
+
+I am using qemu-2.5.1. Here are the commands I used in the test cases:
+
+qemu-system-x86_64 -enable-kvm -cpu host -m 2G -net none -full-screen -drive file=disks/uas.qcow2,format=qcow2,cache=none,aio=native -drive file=test.img,format=raw,if=none,id=test -device nec-usb-xhci -device usb-uas -device scsi-hd,drive=test
+
+qemu-system-x86_64 -enable-kvm -cpu host -m 2G -net none -full-screen -drive file=disks/uas.qcow2,format=qcow2,cache=none,aio=native -drive file=test.img,format=raw,if=none,id=test -device nec-usb-xhci -device usb-bot -device scsi-hd,drive=test
+
+qemu-system-x86_64 -enable-kvm -cpu host -m 2G -net none -full-screen -drive file=disks/uas.qcow2,format=qcow2,cache=none,aio=native -drive file=/dev/sdc,format=raw,if=none,id=test -device nec-usb-xhci -device usb-uas -device scsi-block,drive=test
+
+qemu-system-x86_64 -enable-kvm -cpu host -m 2G -net none -full-screen -drive file=disks/uas.qcow2,format=qcow2,cache=none,aio=native -device nec-usb-xhci -device usb-host,hostbus=2,hostport=6
+
+Also tried to "passthrough" the SCSI layer of an actual UASP drive with scsi-block. No luck either.
+
+Not sure if it's relevant, but when I try completely passthrough a UASP device to the VM through usb-host, only the BOT/MSC part is exposed. This is not the case when I do the same thing to a Linux guest (btw usb-uas apparently works fine in Linux guest as well).
+
+I am also facing this issue.
+
+On further probing, I found out that usb-uas in Qemu doesn't support "SET_SEL" control command due to which windows driver "uaspstor.sys" couldn't complete the enumeration.
+
+It is clearly mentioned in USB 3.1 specs that uasp devices should handle two new control commands - SET_SEL and SET_ISOCH_DELAY.
+
+
+
+Just echoing Tom Yan's comment; I've tried passing through what appears to be the very same device (if not, at least the same UAS-SATA bridge) to a VM in its entirety.
+
+I can confirm the same result - with an otherwise identical domain configuration, Linux guests correctly use the UAS driver:
+
+/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
+    |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=uas, 5000M
+/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 480M
+
+
+Whereas Windows guests fall back to BOT/MSC:
+
+<see attached image>
+
+
+In both cases, QEMU is being run via libvirt, which is generating the following command line:
+
+/usr/bin/qemu-system-x86_64 -name guest=Win10-Edge-IE11,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-13-Win10-Edge-IE11/master-key.aes -machine pc-q35-2.7,accel=kvm,usb=off,vmport=off,dump-guest-core=off -cpu host,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff -m 4096 -realtime mlock=off -smp 8,sockets=1,cores=4,threads=2 -uuid 47c39707-088c-4edc-8b6a-a7856e09f43d -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-13-Win10-Edge-IE11/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-hpet -no-shutdown -global ICH9-LPC.disable_s3=1 -global ICH9-LPC.disable_s4=1 -boot strict=on -device i82801b11-bridge,id=pci.1,bus=pcie.0,addr=0x1e -device pci-bridge,chassis_nr=2,id=pci.2,bus=pci.1,addr=0x0 -device nec-usb-xhci,id=usb,bus=pci.2,addr=0x6 -device virtio-scsi-pci,id=scsi0,bus=pci.2,addr=0x3 -device virtio-serial-pci,id=virtio-serial0,bus=pci.2,addr=0x4 -drive file=/home/jack/IMG/Win10-Edge-IE11.qcow2,format=qcow2,if=none,id=drive-scsi0-0-0-0,discard=unmap -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1 -drive if=none,id=drive-scsi0-0-0-1,readonly=on -device scsi-cd,bus=scsi0.0,channel=0,scsi-id=0,lun=1,drive=drive-scsi0-0-0-1,id=scsi0-0-0-1 -netdev tap,fd=22,id=hostnet0,vhost=on,vhostfd=24 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:27:94:5d,bus=pci.2,addr=0x1 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -device usb-tablet,id=input0,bus=usb.0,port=2 -spice port=5900,addr=127.0.0.1,disable-ticketing,image-compression=off,seamless-migration=on -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pcie.0,addr=0x1 -device intel-hda,id=sound0,bus=pci.2,addr=0x2 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0,bus=usb.0,port=3 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1,bus=usb.0,port=4 -device usb-host,hostbus=4,hostaddr=4,id=hostdev0,bus=usb.0,port=1 -device virtio-balloon-pci,id=balloon0,bus=pci.2,addr=0x5 -msg timestamp=on
+
+I think they are two separate issues in usb-uas and usb-host respectively. I probably should not have bring in the usb-host case here but create another report for it.
+
+Noted, I've created https://bugs.launchpad.net/qemu/+bug/1648726 to track the issue with passing through physical UAS devices.
+
+The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now.
+If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience.
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/108/other/1579327 b/results/classifier/108/other/1579327
new file mode 100644
index 00000000..7d1ca287
--- /dev/null
+++ b/results/classifier/108/other/1579327
@@ -0,0 +1,297 @@
+permissions: 0.758
+debug: 0.714
+vnc: 0.706
+KVM: 0.704
+device: 0.695
+graphic: 0.668
+performance: 0.667
+semantic: 0.644
+boot: 0.626
+PID: 0.619
+other: 0.619
+files: 0.578
+socket: 0.566
+network: 0.504
+
+emulation of vexpress-a9 vexpress-a15 in multicore mode seems to be broken
+
+Report based on:
+https://stackoverflow.com/questions/37068688/have-you-got-issues-with-running-u-boot-for-versatile-express-a9-platform-under
+
+I don't see any bug reports about vexpress boards emulation here, so I decided to let you know:
+
+version tested: qemu 2.0.0 on 32 bit Debian GNU/Linux
+
+There are issues with running u-boot on qemu vexpress-a9 ( it was reported to work ok at physical multicore board )  and vexpress-a15 with parameters -smp cores=2 r 3 or 4.
+So far those are two tested. I dont know ATM if any other board emulation works in multiprocessor mode
+
+Original post at stackoverflow:
+---------------------------------------------------------------------------------------------------
+I have tried numerous releases of u-boot since vexpress-a9 was introduced in u-bot stable release. Under qemu with multicore emulation its behaving unstable - mostly crashes instantly after loading. Sometimes it loads without issues but its rare. My version of qemu is 2.0.0 on x86 32bit Debian. I would be interested to hear if you succeeded in runing it under qemu with multicore emulation ( if yes which version of qemu and u-boot ) or physical versatile express board with multiple cores.
+
+Example outputs are
+
+$ qemu-system-arm -M vexpress-a9 -nographic -kernel u-boot -smp cores=2
+U-Boot 2013.01.01-dirty (May 05 2016 - 08:27:19)
+
+DRAM:  128 MiB
+WARNING: Caches not enabled
+undefined instruction
+pc : [<00000000>]      lr : [<00000000>]
+sp : 60000ef0  ip : 67eedfd8     fp : 00000000
+r10: 00000000  r9 : 00000000     r8 : 60000f00
+r7 : 00000000  r6 : 608146ac     r5 : 60828365  r4 : 0000004d
+r3 : 00000000  r2 : 00000000     r1 : 60000f80  r0 : 47cc9e10
+Flags: nzcv  IRQs on  FIQs on  Mode USER_26
+Resetting CPU ...
+resetting ...
+Flash: 256 MiB
+MMC:   MMC: 0
+*** Warning - bad CRC, using default environment
+
+In:    serial
+Out:   serial
+Err:   serial
+Net:   smc911x-0
+Warning: smc911x-0 using MAC address from net device
+
+Hit any key to stop autoboot:  0 
+Wrong Image Format for bootm command
+ERROR: can't get kernel image!
+VExpress# 
+
+This time it was loaded
+
+Other time it was not...
+
+$ qemu-system-arm -M vexpress-a9 -nographic -kernel u-boot -smp cores=2
+
+
+U-Boot 2013.01.01-dirty (May 05 2016 - 08:27:19)
+
+DRAM:  128 MiB
+WARNING: Caches not enabled
+
+
+U-Boot 2013.01.01-dirty (May 05 2016 - 08:27:19)
+
+DRAM:  128 MiB
+WARNING: Caches not enabled
+Flash: 256 MiB
+MMC:   MMC: 0
+*** Warning - bad CRC, using default environment
+
+In:    serial
+Out:   serial
+Err:   serial
+Net:   smc911x-0
+Warning: smc911x-0 using MAC address from net device
+
+Hit any key to stop autoboot:  2 qemu: fatal: Trying to execute code outside RAM or ROM at 0x6f71c004
+
+R00=00418937 R01=000003e8 R02=00418937 R03=00000000
+R04=00000000 R05=67eedf58 R06=67f8e000 R07=00000002
+R08=00418937 R09=0778e000 R10=6082f688 R11=00000000
+R12=67eedfd8 R13=00000000 R14=67fb82c0 R15=6f71c004
+PSR=200001db --C- A und32
+s00=00000000 s01=00000000 d00=0000000000000000
+s02=00000000 s03=00000000 d01=0000000000000000
+s04=00000000 s05=00000000 d02=0000000000000000
+s06=00000000 s07=00000000 d03=0000000000000000
+s08=00000000 s09=00000000 d04=0000000000000000
+s10=00000000 s11=00000000 d05=0000000000000000
+vs12=00000000 s13=00000000 d06=0000000000000000
+s14=00000000 s15=00000000 d07=0000000000000000
+s16=00000000 s17=00000000 d08=0000000000000000
+s18=00000000 s19=00000000 d09=0000000000000000
+s20=00000000 s21=00000000 d10=0000000000000000
+s22=00000000 s23=00000000 d11=0000000000000000
+s24=00000000 s25=00000000 d12=0000000000000000
+s26=00000000 s27=00000000 d13=0000000000000000
+s28=00000000 s29=00000000 d14=0000000000000000
+s30=00000000 s31=00000000 d15=0000000000000000
+s32=00000000 s33=00000000 d16=0000000000000000
+s34=00000000 s35=00000000 d17=0000000000000000
+s36=00000000 s37=00000000 d18=0000000000000000
+s38=00000000 s39=00000000 d19=0000000000000000
+s40=00000000 s41=00000000 d20=0000000000000000
+s42=00000000 s43=00000000 d21=0000000000000000
+s44=00000000 s45=00000000 d22=0000000000000000
+s46=00000000 s47=00000000 d23=0000000000000000
+s48=00000000 s49=00000000 d24=0000000000000000
+s50=00000000 s51=00000000 d25=0000000000000000
+s52=00000000 s53=00000000 d26=0000000000000000
+s54=00000000 s55=00000000 d27=0000000000000000
+s56=00000000 s57=00000000 d28=0000000000000000
+s58=00000000 s59=00000000 d29=0000000000000000
+s60=00000000 s61=00000000 d30=0000000000000000
+s62=00000000 s63=00000000 d31=0000000000000000
+FPSCR: 00000000
+-------------------------------------------------------------------------------------------------
+end of post
+
+Original discussion at ( includes comments of head custodian of Das U-boot about u-boot working on physical board versatile express a9 and him having issues with runing Linux distro at qemu vexpress-a9 board emulation ):
+https://stackoverflow.com/questions/37068688/have-you-got-issues-with-running-u-boot-for-versatile-express-a9-platform-under
+
+On 7 May 2016 at 09:08, embedded0n3 <email address hidden> wrote:
+> Public bug reported:
+>
+> Report based on:
+> https://stackoverflow.com/questions/37068688/have-you-got-issues-with-running-u-boot-for-versatile-express-a9-platform-under
+>
+> I don't see any bug reports about vexpress boards emulation here, so I
+> decided to let you know:
+>
+> version tested: qemu 2.0.0 on 32 bit Debian GNU/Linux
+
+This version of QEMU is now five major releases old. Please can
+you retry with the most recent the QEMU 2.6.0 release candidate,
+or with QEMU master from git and see if your problems are still
+present?
+
+thanks
+-- PMM
+
+
+Yes, there are still problems on qemu 2.6.0 release candidate and 2.5.1 with same version of u-boot as mentioned and with latest stable u-boot release. When qemu has parameter -smp cores=2 or 3 or 4.
+
+errors are:
+qemu: fatal: Trying to execute code outside RAM or ROM at 0x31306c70
+That adress changes but is mostly close to that example value ("8 digits" adress)
+as mentioned in previous posted bugreport
+
+Sometimes runing U-boot(?) hangs but I can exit qemu using keys Ctrl-a x 
+And that seems to be new behaviour.
+
+- - - - - - - - - - - -
+If someone is interested how to build u-boot for further testing of this issue on his own box
+
+  $ git clone git://git.denx.de/u-boot.git
+  $ cd u-boot
+  $ make vexpress_ca9x4_defconfig ARCH=arm CROSS_COMPILE=arm-none-eabi
+  $ make all_ca9x4_defconfig ARCH=arm CROSS_COMPILE=arm-none-eabi
+
+
+Sorry, missed '-' character at the end of command obviously. It shaould be:
+
+  $ make vexpress_ca9x4_defconfig ARCH=arm CROSS_COMPILE=arm-none-eabi-
+  $ make all_ca9x4_defconfig ARCH=arm CROSS_COMPILE=arm-none-eabi-
+
+
+And if this is not clear - in all cases everything was OK when emulation was started without -smp cors=2 or 3 or 4. By OK i mean there was no 
+ qemu: fatal: Trying to execute code outside RAM or ROM at 0xXXXXXXXX
+errors and I was able to execute some comands like help and printenv and nothing happened when qemu was left open for time of 15 minutes ( sometimes in multicoe mulation mode error appeaed after about one and half minute if that time it loaded without almost instant eror message ).
+
+Does the u-boot binary you're running expect to work with SMP? Usually "Trying to execute code outside RAM or ROM" means "the guest binary did something badly wrong and jumped off to an invalid address", rather than being a QEMU bug.
+
+
+Does -smp cores=4 means qemu is emulaing versatile espress a9 with 4 cores ( this is how versatile express board is designed - i mean it's a board with 4 cores cotex a9 ) and qemu without -smp parameter emalates jus single core ( unicore )? 
+
+In case of versatile express a9 u-boot binary:
+
+U-boot was compilled from cofig file  vexpress_ca9x4 - versatile express cortex a9 4cores
+
+U-boot configuration file is created to run on physical  versatile a9 board. And this was confirmed by Tom Rini (  the head custodian of Das U-boot project as I see on his stackoverflow page ) to run without problems on physical 4 core versatile express a9 board ( see stackoverflow disscussion link in 1st message of this bug report ):
+
+Here is citation of his comment:
+
+>I have recently gotten confirmation that the real HW does work on current mainline U-Boot,
+> but I can also replicate your failures. Interestingly, the real board is 4 cores, 
+> and I can (with the kernelci.org Linux kernel / device tree) run with -smp cores=2
+> but 3 and 4 result in soft lockups once userland starts. – Tom Rini 2 days ago 
+
+So he even had more erors as he get further in linux boot process ( I stopped tests so far on just loading u-boot and waiting few minutes if it will fail suddenly, what happend ). As I said errors were quiet random, and sometimes appeard just after more than minute of inactivity, other times almost instantly after boot ).
+
+On 9 May 2016 at 13:47, embedded0n3 <email address hidden> wrote:
+> Does -smp cores=4 means qemu is emulaing versatile espress a9 with 4
+> cores ( this is how versatile express board is designed - i mean it's a
+> board with 4 cores cotex a9 ) and qemu without -smp parameter emalates
+> jus single core ( unicore )?
+
+Yes.
+
+> U-boot configuration file is created to run on physical  versatile a9
+> board. And this was confirmed by Tom Rini (  the head custodian of Das
+> U-boot project as I see on his stackoverflow page ) to run without
+> problems on physical 4 core versatile express a9 board ( see
+> stackoverflow disscussion link in 1st message of this bug report ):
+>
+> Here is citation of his comment:
+>
+>>I have recently gotten confirmation that the real HW does work on current mainline U-Boot,
+>> but I can also replicate your failures. Interestingly, the real board is 4 cores,
+>> and I can (with the kernelci.org Linux kernel / device tree) run with -smp cores=2
+>> but 3 and 4 result in soft lockups once userland starts. – Tom Rini 2 days ago
+>
+> So he even had more erors as he get further in linux boot process ( I
+> stopped tests so far on just loading u-boot and waiting few minutes if
+> it will fail suddenly, what happend ). As I said errors were quiet
+> random, and sometimes appeard just after more than minute of inactivity,
+> other times almost instantly after boot ).
+
+The next phase is that somebody needs to debug what the u-boot code is
+doing that causes it to crash (this is largely working with the guest
+code, not trying to debug QEMU itself).
+
+thanks
+-- PMM
+
+
+I see. 
+I can take a look.
+Could this procedure be helpfull in this case? Error message was similar but it was related to loading coreboot
+http://blog.3mdeb.com/2014/08/07/debugging-coreboot-for-qemu-armv7-vexpress-a9-emulated-mainboard/
+Or there are better tools to do this job?
+
+
+I found another typo In comment from last night about compilling u-boot.
+This line 
+ $ make all_ca9x4_defconfig ARCH=arm CROSS_COMPILE=arm-none-eabi-
+should look:
+ $ make all ARCH=arm CROSS_COMPILE=arm-none-eabi-
+
+
+I can confirm this bug with vexpress-a9.
+I have tested with the following versions:
+QEMU emulator version 2.4.1 (qemu-2.4.1-11.fc23), Copyright (c) 2003-2008 Fabrice Bellard
+QEMU emulator version 2.7.0, Copyright (c) 2003-2016 Fabrice Bellard and the QEMU Project developers
+
+Here are the reproducing steps:
+Get an ARM cross-compiler, and latest u-boot.
+$ cd u-boot
+$ make ARCH=arm CROSS_COMPILE=${CROSS_COMPILE} vexpress_ca9x4_defconfig
+$ make ARCH=arm CROSS_COMPILE=${CROSS_COMPILE}
+
+# avoid audio errors
+$ export QEMU_AUDIO_DRV=none
+$ qemu-system-arm -M vexpress-a9 -m 1024 -smp 4 -nographic -kernel u-boot
+U-Boot 2016.11-rc2-00090-g5ac5861-dirty (Oct 27 2016 - 14:46:54 +0300)
+
+DRAM:  1 GiB
+WARNING: Caches not enabled
+Flash: 
+
+U-Boot 2016.11-rc2-00090-g5ac5861-dirty (Oct 27 2016 - 14:46:54 +0300)
+
+DRAM:  1 GiB
+WARNING: Caches not enabled
+Flash: 
+
+U-Boot 2016.11-rc2-00090-g5ac5861-dirty (Oct 27 2016 - 14:46:54 +0300)
+
+DRAM:  1 GiB
+WARNING: Caches not enabled
+Flash: 
+
+U-Boot 2016.11-rc2-00090-g5ac5861-dirty (Oct 27 2016 - 14:46:54 +0300)
+
+DRAM:  1 GiB
+WARNING: Caches not enabled
+Flash: Bad ram pointer (nil)
+Aborted (core dumped)
+
+
+I believe this is not a qemu boot since booting the kernel with -smp 4 works just fine, sorry for the noise
+
+Sounds like a U-Boot bug. Closing according to comment #11.
+
diff --git a/results/classifier/108/other/1579565 b/results/classifier/108/other/1579565
new file mode 100644
index 00000000..0ff90a85
--- /dev/null
+++ b/results/classifier/108/other/1579565
@@ -0,0 +1,101 @@
+other: 0.841
+permissions: 0.819
+debug: 0.808
+graphic: 0.806
+socket: 0.785
+files: 0.780
+semantic: 0.768
+PID: 0.760
+device: 0.747
+performance: 0.731
+vnc: 0.726
+boot: 0.702
+network: 0.693
+KVM: 0.662
+
+ERROR: sizeof(size_t) doesn't match GLIB_SIZEOF_SIZE_T.
+
+cont build from last 2.6 rc4
+
+~/Downloads/qemu-2.6.0-rc4$ ./configure 
+
+ERROR: sizeof(size_t) doesn't match GLIB_SIZEOF_SIZE_T.
+       You probably need to set PKG_CONFIG_LIBDIR
+       to point to the right pkg-config files for your
+       build target
+
+Os Ubuntu Mate 16.04 PPC64
+
+Please try this patch: http://patchwork.ozlabs.org/patch/616440/
+
+The problem could also be that your build environment is broken in the way the warning is trying to diagnose (for instance that you have the 32-bit PPC glib development packages installed and not the 64-bit ones.)
+
+
+thanks for the infos 
+Stefan  i will check tomorrow and report.
+Peter, yes this is an issue of the powerpc64 of ubuntu/debian the ppc64 libraries are half ported usually i fix changing in the makefile -m32 where -m64 is call i will try to force the flags on configure of qemu too. i  will report if success or not.
+
+Peter just try forcing the cpp flagas with -m32 without success.
+On this rc configure dont start build ..
+CPPFLAGS="-m32" CFLAGS="-g -O2 -mcpu=e5500 -mno-altivec -mtune=e5500" CXXFLAGS="-m32 -g -O2 -mcpu=e5500 -mno-altivec -mtune=e5500" ./configure --disable-werror 
+
+ERROR: sizeof(size_t) doesn't match GLIB_SIZEOF_SIZE_T.
+       You probably need to set PKG_CONFIG_LIBDIR
+       to point to the right pkg-config files for your
+       build target
+
+will check Stefan parch if something change and reports.
+
+Thanks
+
+If you can still see the bug after applying Stefan's patch, please attach the config.log file generated by configure
+
+Ok Daniel, will check and report.
+note usually on PPC we use ad default compiler GCC (5.3.1 now).
+I been installed clang 3.8 and will check report if all will right.
+
+Thanks
+
+Hi guys, did the patch but same error appear.
+i attached the config.log.
+
+
+
+Ok so the log message associated with the failure is this:
+
+cc -m32 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -fstack-protector-strong -I/usr/include/p11-kit-1 -I/usr/local/include -I/usr/include/libpng12 -pthread -I/usr/include/glib-2.0 -I/usr/lib/powerpc-linux-gnu/glib-2.0/include -g -o config-temp/qemu-conf.exe config-temp/qemu-conf.c -m32 -g -lgthread-2.0 -pthread -lglib-2.0 -lz
+In file included from /usr/include/glib-2.0/glib.h:79:0,
+                 from config-temp/qemu-conf.c:1:
+/usr/include/glib-2.0/glib/gstrfuncs.h:301:2: error: #endif without #if
+ #endif /* __G_STRFUNCS_H__ */
+
+
+Which rather suggests your glib header files are broken.
+
+Hi Daniel i dont know 
+from this last i have this issue other versions was building right .
+im affraid i deleted the rc3 i just make a test with 2.5.1 and you can see configure work, like was working in past.
+
+
+
+
+rc5 same issue 
+
+./configure 
+
+ERROR: sizeof(size_t) doesn't match GLIB_SIZEOF_SIZE_T.
+       You probably need to set PKG_CONFIG_LIBDIR
+       to point to the right pkg-config files for your
+       build target
+
+thanks
+
+I think Daniel is right -- your glib headers are broken, and we just weren't diagnosing it before. You need to fix your glib install.
+
+
+Hi  Perter, 
+probalby ... i found something wrongs inside my ppc64 library , im clearing and reinstall the glib . report it soon
+
+Yes Fixed guys.
+configure reply right . can close this bug , that was not a qemu bug.
+