On Tue, Aug 04, 2015 at 11:07:16AM +0300, Vasiliy Tolstov wrote:
> 2015-08-03 3:41 GMT+03:00 Liu Yuan <namei.u...@gmail.com>:
> > What did you mean by 'not able to completely install'? It is a installation
> > problem or something else?
> >
>
> i have simple test that works as:
> 1) boot 3.18.x kernel and initrd with static compiled golang binary
> 2) binary bringup dhcp network
> 3) fetch from http gzipped raw qemu image
> 3) in parallel decompress gzipped image and write it to disk
>
> this use-case determine previous error in qemu (that brings this discussion)
>
> > My QEMU or my patch? I guess you can test the same QEMU with my patch and
> > with
> > Hitoshi's patch separately. You know, different QEMU base might cover the
> > difference.
> >
>
> I'm test you and Hitoshi patch with qemu 2.4-rc0, i'm compile two
> independent debian packages with you patch and with Hitoshi.
> Install qemu with you patch to one node and with Hitoshi on another.
> Runs sheep with local cluster driver.
> I don't know how to determine qemu segfault in my case, does it
> possible to build qemu with debugging via configure flags ang get more
> detailed descriptions?
>
Hi Vasiliy,
If you run configure with --disable-strip, it will not strip the
debugging symbols from the binary after the build. Then, you can run
gdb on qemu, and do a backtrace after you hit the segfault ('bt').
That may shed some light, and is a good place to start.
Thanks,
Jeff
