Hi, Thank you for testing the patch. Michał Pecio <michal.pecio@xxxxxxxxx> 於 2024年9月12日 週四 下午3:12寫道： > > Hi, > > > > I'm aware of one more bug which affects my Etron: if an error occurs > > > on an isochronous TD, two events are generated: first the error, > > > then "success", even if the error is on the final TRB (the common > > > case). Then the "success" causes "TRB DMA not part of current TD" > > > warning. I suspect that all Etron chips are the same. This should > > > be easily reproducible by unpligging an audio/video device while > > > streaming. > > > > Hmm, I don't encounter this problem. > > OK, I know what happened. This bug only affects SuperSpeed isochronous > endpoints. If you don't have this kind of device, you will not see it. > I checked that High-speed isochronous errors are reported correctly. > > My motivation to develop a workaround for this bug has just decreased > another notch. > > > On the other hand, I was unable to reproduce the control transfer bug. > The exact chip I have is labeled "EtronTech EJ168A", for the record. > > You are right, not all transfers have the data stage and transactions > get out of sync with segment boundaries. I modified the patch to only > print a warning instead of queuing a No-Op and then did various things > which use control transactions: setting baud rate on serial, changing > the volume on audio, starting video recording on a webcam, running > ethtool on a NIC. > > The warning was printed a few times, but nothing interesting happened. > Dynamic debug was enabled on handle_tx_event() - no errors reported. > > Maybe a different silicon/firmware revision, or maybe it's another > SuperSpeed-only bug, or other special conditions for it to happen? Do you see any "Transfer error for slot..." error message? What is the speed of your device? high speed? I try to downgrade my ethernet adapter to high speed and do some tests, no errors are reported in dmesg if dynamic debug is enabled. I think it is a super speed issue, however, it doesn't happen on the high speed device, I am not sure. So the patch will not check the speed of the device. > > > Ok, I will use one quirk XHCI_ETRON_HOST for these workarounds in the > > next patch revision. > That was just a suggestion, you should ask Mathias Nyman, I suppose. OK, thanks. > > But, again, my impression of this hardware is that it's pretty bad > and full of bugs, and they are bizarre enough to likely be unique. > > Regards, > Michal Thanks, Kuangyi Chiang
