On 16/12/2020 11:39, Paolo Bonzini wrote:
> On 16/12/20 12:07, Peter Maydell wrote:
>> Something has definitely changed here. What you had with 4.2.1
>> is what you should be getting. The obvious suspect is that
>> something weird happened in the meson conversion...
Ubuntu/Debian maintainer reprod
user --static builds are apparently resulting in dynamically linked
executables (to the glibc library, not other shared objects )
Concise summary:
$ file ../qemu-aarch64_v*
../qemu-aarch64_v4.2.1: ELF 64-bit LSB executable, x86-64, version 1
(GNU/Linux), statically linked,
BuildID[sha1]=70f5e10a
We're seeing this error on Ubuntu 20.04 amd64 host and aarch64
qemu-aarch64-static chroot when executing 'aptitude':
qemu:handle_cpu_signal received signal outside vCPU context
qemu:handle_cpu_signal received signal outside vCPU context
Research led us to an identical issue report against qemu-m6
** Also affects: qemu (Ubuntu)
Importance: Undecided
Status: New
** Changed in: qemu (Ubuntu)
Status: New => Confirmed
** Changed in: qemu (Ubuntu)
Milestone: None => ubuntu-16.04.5
--
You received this bug notification because you are a member of qemu-
devel-ml, which is s
This is a show-stopper and regression for many VM scenarios on Precise.
A year later we should have a fix for this.
** Changed in: qemu-kvm-spice (Ubuntu)
Importance: Undecided => High
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEM
Hello friend,
Great speakers are made not born and the best way to become one is by
emulating the masters. EASIER SAID THAN DONE, especially in Malaysia, but
not anymore.
That's because New York based international presentation, speaking and
media coach, TJ Walker is coming to Mal
gt;
>
> Yeah, that bit is a bit too gnarly for my tastes, but if you can resend the
> rest
> of it with a Signed-off-by, I'd appreciate.
>
> Regards,
>
> Anthony Liguori
>
>> -TJ
>>
>
Antonio,
Did anything come of this? I resubmitted
This is a small patch to slightly "intelligentify" usb device and
config descriptor parsing. MX-950 bug work-around is not included.
Signed-off-by: Timothy Jones
---
hw/usb.h|5 +
usb-linux.c | 34 +++---
2 files changed, 24 insertions(+), 15 deletions(-
On 11/16/2010 10:00 AM, Anthony Liguori wrote:
> On 11/02/2010 09:51 AM, TJ wrote:
>> Doesn't look like this has ever been committed. qemu-kvm-0.13 has just
>> arrived
>> to the portage tree, but I am still having problems with it. I checked the
>> git
>>
Doesn't look like this has ever been committed. qemu-kvm-0.13 has just arrived
to the portage tree, but I am still having problems with it. I checked the git
log and it's not there! Please commit.
-TJ
Original Message
Subject: [PATCH v2] Guest OS hangs on usb_add
Dat
This is a small patch to sligtly "intelligentify" usb device and
config descriptor parsing and to handle bug with certain usb
device (URC MX-950) reporting device desriptor length as 0x18
instead of 18 with added vendor_id/product_id check
---
hw/usb.h|5 +
usb-linux.c | 37 +
On 06/28/10 08:32, Gianni Tedesco wrote:
>
> FWIW, I am signing off on your approach :)
>
> Gianni Tedesco
>
Thank you Gianni :) I am gonna add simple vend/prod id check to my 0x18 hack and
resubmit final version.
-TJ
th the config descriptors, in which
case (config_descr_len < USB_DT_CONFIG_SIZE) without checking descriptor type
might unwittingly lead to failure.
-TJ
> diff --git a/hw/usb.h b/hw/usb.h
> index 00d2802..efd4a65 100644
> --- a/hw/usb.h
> +++ b/hw/usb.h
> @@ -117,6 +117,14
On 06/24/10 02:42, Markus Armbruster wrote:
> A botched up patch is often a pretty effective way to get somebody to
> fix the thing correctly.
OK, I gave it a shot and sent it to the list. Shoulda prolly added a disclaimer
in case it blows something up ;)
-TJ
This is a small patch to sligtly "intelligentify" usb device and
config descriptor parsing and to handle bug with certain usb
device reporting device desriptor length as 0x18 (instead of 18)
---
hw/usb.h|5 +
usb-linux.c | 36 +---
2 files changed, 26
On 06/24/10 13:59, David S. Ahern wrote:
>
>
> On 06/23/10 22:45, TJ wrote:
>>
>>> -- Forwarded message --
>>> From: Timothy Jones
>>> Date: Wed, Jun 23, 2010 at 9:07 PM
>>> Subject: Guest OS hangs on usb_add
>>> To:
> more intelligent, but I am very unfamiliar with the code, so I might
> botch things up. Or is the above data sufficient for one of the devs
> to take a look at the code and improve it?
>
> Thank you.
>
> -TJ
>
Here is small patch that fixed my problem
e and provide useful feedback and
ides I'd be grateful. I don't want to redo work others are already doing
or go against some implicit techniques hidden in the macro nesting in
particular.
This should be considered alongside Thayne Harbaugh's post "[RFC]
linux-user (mostly syscall
o implicit conversion from the
larger integer type to the pointer.
I'll post what I've written so far so it can be considered in
conjunction with your work.
The title is "RFC: x86_64 Best way to fix 'cast to pointer from integer
of different size' problems?"
TJ.
(new) static char 'usb_devfs_path' set to the path
that works, and it is subsequently used in usb_host_device_open().
TJ.
Index: usb-linux.c
===
RCS file: /sources/qemu/qemu/usb-linux.c,v
retrieving revision 1.15
diff -u -
20 matches
Mail list logo
