[Expired for qemu (Ubuntu) because there has been no activity for 60
days.]
** Changed in: qemu (Ubuntu)
Status: Incomplete => Expired
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1896250
Tit
[Expired for virglrenderer (Ubuntu) because there has been no activity
for 60 days.]
** Changed in: virglrenderer (Ubuntu)
Status: Incomplete => Expired
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net
Ok, since you are ok with the alternative of GVT-g and other users have
SDL now I'll close this bug as incomplete (even though as stated in
comment 23 it isn't a real fix to the issues in the GTK backend for this
particular use case).
** Changed in: qemu (Ubuntu)
Status: New => Incomplete
Nice, thanks !
I've got a new laptop in the meantime, where I will likely use Intel's
GVT-g GPU virtualisation feature (my old hardware couldn't), hence no
need for virglrenderer, but of course that's only me. Moreover,
virglrenderer still has the advantage of being hardware-independent.
Addition
Update as I've not forgotten this.
So far I was still not able to reproduce this myself, I was either having cases
where GTK+virtgl worked fine for my simple testing OR I had it broken but even
when trying to add SDL it didn't help.
Still I appreciate all the debug you have done and while GTK is
While it seems to be a "virtual hardware" problem, I'm not sure the
problem comes from Qemu. Right now the problem doesn't change much for
me, as I have to patch Qemu for another bug that's not yet addressed, so
adding SDL in the process doesn't change anything timewise.
In fact we do have a crash
Thanks for the feedback Oliver!
IMHO re-enabling SDL for that is still no option for all the reasons
outlined and discussed when it was disabled. Since we still miss a good
"next step to go" other than trying new versions I'm unsure what to do
for now.
For the sake of trying - I have qemu 5.1 in
Hi Christian ! I just upgraded to Groovy and it still crashes on my
side.
As before, recompiling w/SDL and using it instead solves the problem.
I remember I tried to use some of those vhost devices (check "qemu-
system-x86_64 -device help | grep vhost") in the hope it would work
around the proble
You could give the involved components a try on Focal+[1].
That would allow to switch the components one by one while staying on Focal.
There is no linux-generic-hwe-20.04 yet that is on the new level. But
that you could try from [2] (even more versions to compare if needed).
[1]:
https://launch
I guess the next step would be to confirm that upgrading to Qemu 5.0
solves the problem. I'll try that either by directly compiling 5.0, or
I'll wait until november when I will upgrade to Groovy.
However, I doubt it will really solve the problem, now I tend to stick
to the idea that the problem co
I re-installed my test system (an older NUC) and it works just fine on Focal as
well.
I was running Android for ~10 minutes and on my former tests (other system) it
never made >4.
Software levels are mostly equal (a fully upgraded Focal).
But also the HW isn't "too" different:
Nuc:
lspci -s 02.
Laptop (Failing with Focal, unable to upgrade to Groovy)
$ lspci -s 00:02.0 -vvv
00:02.0 VGA compatible controller: Intel Corporation UHD Graphics 620 (rev 07)
(prog-if 00 [VGA controller])
Subsystem: Lenovo UHD Graphics 620
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoo
Thanks Olivier for the feedback.
Looking forward if groovy fixes things for you as well then - with graphics
things often seem "hard to ensure" so the more results = the better.
My test box that worked with groovy is similarly old to yours. So maybe
I should re-deploy it with focal and see if on
Hello Christian,
I should have pointed that the log is from the Android system, not Qemu
or my host system !
I got the failure message running the following command in an Android
shell :
logcat '*:F'
(which means display log entries from all facilities (*), with the Fatal
(F) severity)
It seem
qemu 4.2.1 / virglrenderer 0.8.2-1ubuntu1 - issues, see above
qemu 5.0 / virglrenderer 0.8.2-4 - Seems to work fine for me
That is interesting, I'll stop trying to prep an experimental 5.1 in
https://launchpad.net/~ci-train-ppa-
service/+archive/ubuntu/4302/+packages then.
I've seen acceleration
- The drop of the sound device nor the "bump the host UI to force updates"
didn't help the android case :-/
- The Android CD also has a "Live CD VESA Mode - No GPU hardware acceleration"
Trying that seems to work more smoothly at first, but later on fails for
other reasons and
obviously woul
Ha, I found something that fells like a stuck guest with Ubuntu as well, but it
wasn't "as stuck as Android".
I have found after a while that it seems infinitely happy to run without focus
(no mouse / keyboard events getting to the guest).
But when I focus the guest sometimes the glxgears in the
Fixes after 4.2:
Note we are on 4.2.1 already plus extra fixes as identified so far, but still:
$ git log --oneline upstream/master...v4.2.0 | grep -e virtio-gpu -e VirGL -e
gtk
4bf47f3634 virtio-gpu: set physical dimensions for EDID
3745d59ee4 virtio-gpu-3d: fix abnormal display after a warm re
2) The same image I used through lbivirt before
$ sudo qemu-system-x86_64 -machine q35,vmport=off -cpu host -accel kvm -smp 2
-m 4G -audiodev pa,id=pasound,timer-period=5000 -device ES1370,audiodev=pasound
-device virtio-vga,virgl=on -device virtio-mouse -device virtio-keyboard -drive
file=/var
I've tested on two systems
1. one comes with the usual defaults (no 3d), checked it to work fine as-is,
then enabled virtiogpu+3d. I added this case as sometimes libvirt fixes up some
rough edges, so it is useful to compare cases executed that way
2. a ubuntu live desktop installer booting into t
I got:
- Startup (bootloader) - ok
- Initial kernel messaged - ok, no errors
- Android load screen (shimmering android letters) - ok
- Config wizard - working and clickable
- ... clicking through the setup wizard a bit
=> Indeed it hangs after a while, but there is no message associated by qemu .
Most of the links are still down, but after some trying I found a working one
that is left on OSDN.
I'll give this a look, but UI is often terribly complex to track down, so no
promises in advance :-)
FYI A bug worth to watch that might be related is bug 1898490
--
You received this bug notifi
Hi Paride,
Sorry about that, they probably block direct linking.
Try that link instead : https://www.fosshub.com/Android-x86.html
Then, choose the "Android-x86 64-bit ISO file", version "9.0-r2". If it
still doesn't work, you could try the Android-x86 project web site :
https://www.android-x86.o
Hello Olivier,
I'm running Groovy and was curious to try to reproduce this, but I'm
getting 403 Forbidden errors when trying to download the Android ISO
image from the link you provided. Will try again in the next days.
--
You received this bug notification because you are a member of Ubuntu
Bug
Hi Christian,
Fairly easy to reproduce. I just tried with current qemu (version 4.2.1
(Debian 1:4.2-3ubuntu6.6)).
You need to download the Android 9.0r2 ISO image from the Android-x86
project. Here's a link for the 64-bit image (I chose the non k49 one) :
https://www.fosshub.com/Android-x86.html
Thanks Olivier for the report.
It is very unlikely that we'll be able or allowed [1] to enable SDL in Focal
after the fact. But I'd be very interested which problems you are seeing, what
the steps to recreate them are exactly and if you have reported (or found)
upstream discussions about these.
26 matches
Mail list logo
