I have sent a patch as directed. I hope it is correctly done.
Thank you.
Ben
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/2054889
Title:
pcap streams are text files which insert 0xD in Windows ve
Public bug reported:
Since Windows text files use CRLFs for all \n, the Windows version of
QEMU inserts a CR in the PCAP stream when a LF is encountered when using
USB PCAP files.
Starting at line 275 in hw/usb/bus (https://gitlab.com/qemu-
project/qemu/-/blob/master/hw/usb/bus.c?ref_type=heads#L
Public bug reported:
Per section 4.19.3 of the xHCI version 1.0 specification, when the Port
Power bit transitions from 0 to 1, if there is a connection on that
port, a Port Status Change Event should be issued.
Currently, when the port is powered, this event is not being issued.
I don't know th
Bug still exists, therefore I have marked as 'new' per your request.
Using latest version of QEMU for Windows (from
https://qemu.weilnetz.de/) still does not adjust the host window size if
a quest size changes while the host window is being moved.
Thank you,
Ben
** Changed in: qemu
Status
Public bug reported:
When using the EFI firmware from
https://www.kraxel.org/repos/jenkins/edk2/
(https://www.kraxel.org/repos/jenkins/edk2/edk2.git-
ovmf-x64-0-20200919.1453.g7faece6985.noarch.rpm) (OVMF-pure-efi.fd and
OVMF_VARS-pure-efi.fd) then using the GOP, setting the mode to 1366x768,
QEMU
For more information, Annex-E of the ACS-2 explains this as well.
http://www.t13.org/Documents/UploadedDocuments/docs2009/d2015r2
-ATAATAPI_Command_set_-_2_ACS-2.pdf
See the statement on the top of page 165 as well. "If bit 13 is set,
then bits 3:0 are valid".
Page 119 of that same document sta
Public bug reported:
The code at line 202 in hw/ide/core.c
(https://git.qemu.org/?p=qemu.git;a=blob;f=hw/ide/core.c;#l201)
hard codes bit 13 set. However, get_physical_block_exp() can and may return 0,
which is a valid response. If get_physical_block_exp() does return zero, bit 13
should not b
Since I posted this bug report, I have done a little more research and
this specific part of this command is actually quite obsolete. It use
to be documented (MMC v1.2 Draft), but later versions have actually
removed this part of the command, even stating "obsolete" in some of the
documentation.
Public bug reported:
cmd_mode_sense
https://git.qemu.org/?p=qemu.git;a=blob;f=hw/ide/atapi.c;hb=refs/heads/master#l852
always reports 0x70 in byte 2 returned, indicating no CD-ROM present.
If CD-ROM is present, should report 0x01 (or 0x11).
If CD-ROM absent, should report 0x70.
** Affects: qe
Hi Hector, guys,
I think I have found my/the error:
xHCI, version 1.0, Page 136:
"Note: The detection of a Cycle bit mismatch in an Event TRB processed
by software indicates the location of the xHC Event Ring Enqueue Pointer
and that the Event Ring is empty. Software shall write the ERDP with
I believe it is required to send an error event. It checked for the
STATUS TRB and found that it was missing, therefore it must send an
Error Event.
This is (not so clearly) stated in the specification and I have quoted
this in a previous comment.
I took it as:
If the controller checks for the e
The xHCI specification states that after processing the Event TRB,
software is to write the address of that TRB to the
xHC_INTERRUPTER_DEQUEUE. QEMU currently checks this value written and
compares it to its own current pointer, which is now incremented to the
next available TRB, therefore not mat
Just a little more information.
In section 4.11.2.2, page 159 of version 1.0 of the xHCI specification,
it states:
• The xHC shall NOT check for the following Control transfer error conditions.
• If a Data Stage TD follows a Setup Stage TD, where wLength = ‘0’.
• If a Status Stage TD does no
Removing this check will indeed require a bit of a re-write. The way
the code is now, the transfer expects a SETUP packet to be first. If
you remove the check I ask about above, will the next transfer show that
it is the STATUS packet? If so, then the check at line 1696 will indeed
catch and not
Public bug reported:
This may not necessarily be a bug, but more of a change.
A little background may need to be in order.
With all USB Control transfers, there is a SETUP transfer, zero or more
DATA transfers, and if successful, a STATUS transfer. This STATUS
transfer is used to indicate to th
My apologizes. I forgot that it was 2^ERSTMAX. I really need to get
some sleep :-)
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1859359
Title:
xHCI and event ring handling
Status in QEMU:
New
Please note that the current code reports zero (0)
https://git.qemu.org/?p=qemu.git;a=blob;f=hw/usb/hcd-xhci.c#l2737
Bits 7:4 is this limit and the current code has these bits as zero.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
I failed to note above that the HCSPARAMS2 register does indeed limit
the count of segments in the Event Ring. I guess as long as you never
change this value from one (1) you will be okay.
However, the spurious interrupt stuff still stands as a bug.
Thank you,
Ben
--
You received this bug noti
Public bug reported:
I believe that the Event Ring handling in QEMU is not correct. For
example, an Event Ring may have multiple segments. However, the code in
xhci_write_event() (https://git.qemu.org/?p=qemu.git;a=blob;f=hw/usb
/hcd-xhci.c;hb=HEAD#l645), starting with line 668, seems to only su
Public bug reported:
When QEMU is emulating a legacy text mode, then switches to a VESA mode,
if you happen to be moving the host window while the switch is made, the
host window never changes size. The emulated size does, but the host
window doesn't.
For example, at Legacy boot up, the screen m
bug report (Benjamin David Lunt):
>
> Back to the READ_DMA command, it is my conclusion that the
> READ_DMA command, more precisely, the BUS Master part of QEMU is
> in error. The tests that people have done to see if it works, is
> probably the guest finding out
- Original Message -
From: "J. Mayer" <[EMAIL PROTECTED]>
To:
Sent: Monday, December 17, 2007 7:40 AM
Subject: Re: [Qemu-devel] floppy disk
On Mon, 2007-12-17 at 03:28 +, Thiemo Seufer wrote:
Benjamin David Lunt wrote:
> Hi everyone,
>
> I only rec
- Original Message -
From: "Thiemo Seufer" <[EMAIL PROTECTED]>
To: "Benjamin David Lunt" <[EMAIL PROTECTED]>
Cc:
Sent: Sunday, December 16, 2007 8:28 PM
Subject: Re: [Qemu-devel] floppy disk
Benjamin David Lunt wrote:
Hi everyone,
I only recently h
Hi everyone,
I only recently have started to use QEmu due to a request
on the alt.os.development usenet group. My OS was not working
on QEmu due to it would not recognize the (emulated) floppy.
After a lot of testing, QEmu does not return the correct
values for a Sense Interrupt command and the
24 matches
Mail list logo
