Re: [PATCH] gtk: Add show_tabs=on|off command line option.
On Fri, Jul 01, 2022 at 09:14:02AM +, Zhang, Chen wrote: > > > > Signed-off-by: Felix "xq" Queißner > > Thanks your patch, but please use your real name to sign a patch. > For the details: > docs/devel/submitting-a-patch.rst Hmm? Felix Queißner looks like a real name to me ... take care, Gerd
Re: USB-MSD non-functional after merging v5.1 to v6.x (seems to be internal USB stack issue?)
Hi, > At some point during implementation of the STM USB stack must have run > into the same problem with the communications choking during MSD init. > And at the time (which involved a LOT of wireshark comparisons with a > real USB drive on the host and on the DCW2 Rpi2 stack) I'd added the > QEMU_PACKED directive to the usb_msd_csw struct. > Thoughts? Send a patch adding the QEMU_PACKED, that should indeed be the correct fix. thanks, Gerd
Re: USB-MSD non-functional after merging v5.1 to v6.x (seems to be internal USB stack issue?)
Hi, > I decided to bisect the merge in order to identify the commit that causes the > issue - and much to my surprise, it is this particular commit: > https://github.com/qemu/qemu/commit/bbd8323d3196c9979385cba1b8b38859836e63c3 Hmm, that is rather strange indeed. > Given this doesn't seem to be anything more than a relocation of > declarations (and I don't even use any of these types directly in my > code), this would seem to suggest an internal issue in linking or > memory initialization. I'm happy to assist in debugging this where I > can but I'm hoping someone more knowledgeable about the QEMU USB > innards might be able to point me to an area to start digging since > the change seems entirely orthogonal to the actual problem and could > be just about anywhere. Try run qemu with valgrind to see if there is any memory corruption? > I've been told this problem is not unique to my own development setup, > and a cursory investigation reveals one of the symptoms is a > divergence in the size of the incoming USB packets. Is this reproducable on master branch somehow? > (I'm hoping to set > up a more detailed packet capture when I have more spare time this > weekend). Oh, that is easy, all usb devices have a pcap= property to write out traces which you can then open in wireshark. HTH, Gerd
Re: nec-usb-xhci migration breakage
On Mon, Nov 16, 2020 at 05:18:22AM +, Sai Pavan Boddu wrote: > +Gerd > Hi David, > > Sorry for the delayed response. I was able to reproduce your issue with > nec-usb-xhci, in my previous testing we have tested with qemu-xhci model > which was good. > I would look further into this. > > @Gerd: Do you have any high level comments on this ? Already fixed in master, see commit 172bc8520db1cb98d09b367360068a675fbc9413 take care, Gerd
Re: ui: fix potential compile error.
Hi, > 1. CentOS7 with Python 2.7.5 > Root cause is my argparse and python version. But change the invoking order > can adapt both new and old argparse. python2 is EOL and not supported any more. please "yum install python3" (yes, centos7 has it, was added in 7.8). take care, Gerd
Re: sysbus usb xhci
On Thu, Jan 02, 2020 at 07:13:25AM +, Sai Pavan Boddu wrote: > Hi Gred, > > We are seeing of options to reuse the hcd-xhci model and use it over system > bus interface rather than pci. (for Xilinx ZynqMP SOC, usb emulation) > Are there any plans of implementing a sysbus device ? if none it would be > good if provided few pointers to start. There have been some discussions about this for a (IIRC) sbsa machine, but I'm not sure whenever that where just ideas or some code exists. > Im looking at hcd-ehci/ochi as a reference, let me know if there are any know > limitations for this usecase. Yep, the path for xhci would be quite simliar: Create a new XHCIPciState struct, move over all pci-specific bits from XHCIState, leaving the generic stuff in XHCIState for sharing with sysbus. Possibly move all pci-specific code bits into a new source file (for cleanup, will also allow to build qemu with CONFIG_PCI=n and still have XHCI enabled). Once this separation is done you should be able to create a sysbus device, reusing the generic xhci code and adding sysbus plumbing (mmio, irq, ...) cheers, Gerd
Re: [Qemu-devel] qemu vga crash
On Tue, May 21, 2019 at 01:52:31PM +, Vladimir Sementsov-Ogievskiy wrote:
> Could anybody help?
How about doing your homework properly?
> > Hi Gerd!
> >
> > Writing to you, as you were the last one who committed to vga_draw_graphic,
> > hope you can help.
> >
> > We faced the following crash in 2.12-based Qemu, but code seems not really
> > changed:
Pretty lame excuse for not testing a more recent release or git master.
And you are wrong. The code *has* changed,
and the bug has been fixed a year ago already.
commit a89fe6c329799e47aaa1663650f076b28808e186
Author: Gerd Hoffmann
Date: Mon May 14 12:31:17 2018 +0200
vga: catch depth 0
depth == 0 is used to indicate 256 color modes. Our region calculation
goes wrong in that case. So detect that and just take the safe code
path we already have for the wraparound case.
While being at it also catch depth == 15 (where our region size
calculation goes wrong too). And make the comment more verbose,
explaining what is going on here.
Without this windows guest install might trigger an assert due to trying
to check dirty bitmap outside the snapshot region.
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1575541
Signed-off-by: Gerd Hoffmann
Message-id: 20180514103117.21059-1-kra...@redhat.com
cheers,
Gerd
Re: [Qemu-devel] Guests are crashing on startup, seem related to usb-audio
On Mon, Dec 10, 2018 at 12:11:09PM +, Leonardo Soares Müller wrote:
> Hi, I did not save that Mageia 7 data as I was unaware I could do this.
> The data below is from another crash with openSUSE Leap, this time I
> saved this backtrace with generate-core-file.
> On #4 it shows:
> $2 = {pid = 225, id = 2027203168, ep = 0x57e46520, stream = 0, iov =
> {iov = 0x7fffc418d190, niov = 0, nalloc = 1, size = 0}, parameter = 0,
> short_not_ok = false, int_req = false, status = 0, actual_length = 0,
> state = USB_PACKET_SETUP, combined = 0x0, queue = {tqe_next = 0x0,
> tqe_prev = 0x0}, combined_entry = {tqe_next = 0x0, tqe_prev = 0x0}}
Hmm, zero-length usb package. Should be 192 bytes ...
Does anything change with
https://git.kraxel.org/cgit/qemu/log/?h=sirius/usb-audio-crash ?
thanks,
Gerd
Re: [Qemu-devel] Guests are crashing on startup, seem related to usb-audio
Hi, > #3 0x701be412 in __GI___assert_fail (assertion=0x55fb8738 > "p->actual_length + bytes <= iov->size", file=0x55fb8456 > "hw/usb/core.c", line=592, function=0x55fb8980 > <__PRETTY_FUNCTION__.26351> "usb_packet_copy") at assert.c:101 > #4 0x55bd5ed7 in usb_packet_copy (p=0x7fffc4722ea8, > ptr=0x7fffbc053ee0, bytes=192) at hw/usb/core.c:592 Can you "print *p" here? thanks, Gerd
Re: [Qemu-devel] [PATCH] input-linux: toggle for lock keys
On Thu, Aug 23, 2018 at 01:23:20AM +, Ryan El Kochta wrote: > This patch introduces three new options on the input-linux commandline: > > (a) ignore_caps_lock=[on|off] > (b) ignore_num_lock=[on|off] > (c) ignore_scroll_lock=[on|off] > > If enabled, the key will be disabled and not forwarded to the guest. > There are two main reasons for this: > > (a) Without keyboard LEDs, it can be difficult to tell whether it is > enabled or not > (b) Preparation for another patch which will allow changing the keys > used to toggle the input device's grab. If you set the key to > KEY_SCROLLLOCK for example, it can be frustrating disabling scroll lock > in the guest, as it will require pressing the key more than twice. Hmm. You have the same issue on the host, right? For the guest we can easily filter out the key events. For the host we can't. This is the reason I picked a key combination which has no side effects to switch between host and guest. And for the same reason I don't think it is useful to allow the user to specify arbitrary key combinations. Which combination do you want use instead of leftshift + rightshift? cheers, Gerd
Re: [Qemu-devel] [PATCH] ps2: check PS2Queue wptr pointer in post_load routine
On Thu, Jun 14, 2018 at 10:50:47AM +, liujunjie (A) wrote: > ping Not much activity on input devices, so we have rare pull requests ... Preparing one now, with this patch added. cheers, Gerd
