All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Hatle <mark.hatle@windriver.com>
To: "Tian, Kevin" <kevin.tian@intel.com>
Cc: "poky@yoctoproject.org" <poky@yoctoproject.org>
Subject: Re: [PATCH 1/1] qemu: Use mesa's libGL rather than nVidia's to	avoid segfault of qemu
Date: Thu, 17 Mar 2011 21:42:40 -0500	[thread overview]
Message-ID: <4D82C6A0.8000202@windriver.com> (raw)
In-Reply-To: <625BA99ED14B2D499DC4E29D8138F1505834F2B2F0@shsmsx502.ccr.corp.intel.com>

On 3/17/11 7:41 PM, Tian, Kevin wrote:
>> From: Mark Hatle
>> Sent: Thursday, March 17, 2011 11:03 PM
>>
>> I reworked the patch slightly.. It's available on poky-contrib
>> mhatle/qemu-workaround.
>>
>> Specifically I changed:
>> - the warning message to make clarify it a bit.
>> - Changed the preload to be "libGL.so", so the rt-linker will now search for it
>> (/usr/lib/libGL.so may be wrong on some systems where /usr/lib64 is the
>> default
>> library path)
> 
> Just double confirm here. You are sure that just "libGL.so" will hit /usr/lib/libGL.so
> instead of the nvidia proprietary one, right? I'm interesting how nvidia 
> proprietary driver is linked to qemu binary then? I can understand why Edwin
> originally use full path to make sure default one being used, but of course it may
> be wrong as you said on some system.

By specifying "libGL.so", it will cause the ld.so to resolve the path using the
normal resolution.  Usually the nVidia stuff is linked in via libGL.so.1 or
similar.  libGL.so is usually only used for development linking.

>> - Added a second check to see if the workaround worked or not, if it didn't add
>> a second warning message
>> - To the QEMU run line, add "stty sane" in the case of a failure.  Otherwise
>> QEMU leaves the terminal/console in a confused state.
>>
>> Can you please verify that this still works on the Ubuntu systems and that I
>> didn't miss anything/break anything else?  If so I think this is the version we
>> should go with.
> 
> Edwin is out of office in the morning, and he will confirm them once he's back.

ok.

--Mark

> Thanks
> Kevin
> 
>>
>> --Mark
>>
>> On 3/17/11 7:22 AM, Zhai Edwin wrote:
>>> From: Zhai Edwin <edwin.zhai@intel.com>
>>>
>>> Proprietary nVidia driver introduce its own libGL that precede mesa's.
>>> qemu has segfault if linked with it. This fix try to use mesa's libGL
>>> if ldd find qemu linked with nVidia libGL.
>>>
>>> [YOCTO #649]
>>> [YOCTO #698]
>>>
>>>
>>> Signed-off-by: Zhai Edwin <edwin.zhai@intel.com>
>>> ---
>>>  scripts/poky-qemu-internal |   16 +++++++++++++++-
>>>  1 files changed, 15 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/scripts/poky-qemu-internal b/scripts/poky-qemu-internal
>>> index 3638a65..1f09fe7 100755
>>> --- a/scripts/poky-qemu-internal
>>> +++ b/scripts/poky-qemu-internal
>>> @@ -436,10 +436,24 @@ else
>>>      echo "Warning: distccd not present, no distcc support loaded."
>>>  fi
>>>
>>> +# qemu got segfault if linked with nVidia's libgl
>>> +GL_LD_PRELOAD=$LD_PRELOAD
>>> +
>>> +if ldd $QEMUBIN | grep -i nvidia &> /dev/null
>>> +then
>>> +    echo "************** !!!Warning!!! **************
>>> +    You installed nVidia's libGL.so that probably lead qemu segfault!
>>> +    Pls. uninstall proprietary nVidia driver or make mesa libgl precede
>> nvidia's."
>>> +
>>> +    # To avoid segfault of qemu, skip nVidia's libGL and use mesa's instead
>>> +    echo "Skip nVidia's libGL!"
>>> +    GL_LD_PRELOAD="/usr/lib/libGL.so $LD_PRELOAD"
>>> +fi
>>> +
>>>  echo "Running $QEMU..."
>>>  # -no-reboot is a mandatory option - see bug #100
>>>  echo $QEMUBIN -kernel $KERNEL $QEMUOPTIONS $SERIALOPTS
>> -no-reboot $SCRIPT_QEMU_OPT $SCRIPT_QEMU_EXTRA_OPT --append
>> '"'$KERNCMDLINE $SCRIPT_KERNEL_OPT'"'
>>> -$QEMUBIN -kernel $KERNEL $QEMUOPTIONS $SERIALOPTS -no-reboot
>> $SCRIPT_QEMU_OPT $SCRIPT_QEMU_EXTRA_OPT --append "$KERNCMDLINE
>> $SCRIPT_KERNEL_OPT" || /bin/true
>>> +LD_PRELOAD="$GL_LD_PRELOAD" $QEMUBIN -kernel $KERNEL
>> $QEMUOPTIONS $SERIALOPTS -no-reboot $SCRIPT_QEMU_OPT
>> $SCRIPT_QEMU_EXTRA_OPT --append "$KERNCMDLINE
>> $SCRIPT_KERNEL_OPT" || /bin/true
>>>
>>>  cleanup
>>>
>>
>> _______________________________________________
>> poky mailing list
>> poky@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/poky



  reply	other threads:[~2011-03-18  2:42 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-17 12:22 [PATCH 0/1] v2 fix qemu segfault with nVidia proprietary driver Zhai Edwin
2011-03-17 12:22 ` [PATCH 1/1] qemu: Use mesa's libGL rather than nVidia's to avoid segfault of qemu Zhai Edwin
2011-03-17 15:03   ` Mark Hatle
2011-03-18  0:41     ` Tian, Kevin
2011-03-18  2:42       ` Mark Hatle [this message]
2011-03-18  2:46         ` Tian, Kevin
2011-03-18  2:54         ` Zhai, Edwin
2011-03-17 15:17   ` Darren Hart

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4D82C6A0.8000202@windriver.com \
    --to=mark.hatle@windriver.com \
    --cc=kevin.tian@intel.com \
    --cc=poky@yoctoproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.