On Thu, 21 Mar 2019, Laurent Vivier wrote:
On 21/03/2019 11:15, BALATON Zoltan wrote:
On Thu, 21 Mar 2019, Laurent Vivier wrote:
Stop processing the descriptor list instead. The next frame timer tick
will
resume the work
Shoud this log something when the limit is reached to let the user know
why USB stopped working instead of silently ignoring frames?
I don't think frames are ignored, they are only delayed. The aim of
ED_LINK_LIMIT is to avoid an infinite loop inside QEMU.
Thanks,
Laurent
I don't know, just asked. It wasn't clear from commit message to me.
Regards,
BALATON Zoltan
Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1686705
Suggested-by: Gerd Hoffmann <kra...@redhat.com>
Signed-off-by: Laurent Vivier <lviv...@redhat.com>
---
hw/usb/hcd-ohci.c | 7 +------
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/hw/usb/hcd-ohci.c b/hw/usb/hcd-ohci.c
index 196a9f72002d..81cf5ab7a5a7 100644
--- a/hw/usb/hcd-ohci.c
+++ b/hw/usb/hcd-ohci.c
@@ -1200,7 +1200,7 @@ static int ohci_service_ed_list(OHCIState *ohci,
uint32_t head, int completion)
??? if (head == 0)
??????? return 0;
-??? for (cur = head; cur; cur = next_ed) {
+??? for (cur = head; cur && link_cnt++ < ED_LINK_LIMIT; cur = next_ed) {
??????? if (ohci_read_ed(ohci, cur, &ed)) {
??????????? trace_usb_ohci_ed_read_error(cur);
??????????? ohci_die(ohci);
@@ -1209,11 +1209,6 @@ static int ohci_service_ed_list(OHCIState
*ohci, uint32_t head, int completion)
??????? next_ed = ed.next & OHCI_DPTR_MASK;
-??????? if (++link_cnt > ED_LINK_LIMIT) {
-??????????? ohci_die(ohci);
-??????????? return 0;
-??????? }
-
??????? if ((ed.head & OHCI_ED_H) || (ed.flags & OHCI_ED_K)) {
??????????? uint32_t addr;
??????????? /* Cancel pending packets for ED that have been paused.? */
