| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-Id: <20220926195307.110121-1-w36195@motorola.com>
Date: Mon, 26 Sep 2022 14:53:06 -0500
From: Dan Vacura <w36195@...orola.com>
To: linux-usb@...r.kernel.org
Cc: Thinh Nguyen <Thinh.Nguyen@...opsys.com>,
Dan Vacura <w36195@...orola.com>,
Laurent Pinchart <laurent.pinchart@...asonboard.com>,
Felipe Balbi <balbi@...nel.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Michael Grzeschik <m.grzeschik@...gutronix.de>,
linux-kernel@...r.kernel.org
Subject: [PATCH 0/1] uvc gadget sg performance issues
Hello uvc gadget developers,
I'm working on a 5.15.41 based kernel on a qcom chipset with the dwc3
controller and I'm encountering two problems related to the recent performance
improvement changes:
https://patchwork.kernel.org/project/linux-usb/patch/20210628155311.16762-5-m.grzeschik@pengutronix.de/ and
https://patchwork.kernel.org/project/linux-usb/patch/20210628155311.16762-6-m.grzeschik@pengutronix.de/
If I revert these two changes, then I have much improved stability and a
transmission problem I'm seeing is gone. Has there been any success from
others on 5.15 with this uvc improvement and any recommendations for my
current problems? Those being:
1) a smmu panic, snippet here:
<3>[ 718.314900][ T803] arm-smmu 15000000.apps-smmu: Unhandled arm-smmu context fault from a600000.dwc3!
<3>[ 718.314994][ T803] arm-smmu 15000000.apps-smmu: FAR = 0x00000000efe60800
<3>[ 718.315023][ T803] arm-smmu 15000000.apps-smmu: PAR = 0x0000000000000000
<3>[ 718.315048][ T803] arm-smmu 15000000.apps-smmu: FSR = 0x40000402 [TF R SS ]
<3>[ 718.315074][ T803] arm-smmu 15000000.apps-smmu: FSYNR0 = 0x5f0003
<3>[ 718.315096][ T803] arm-smmu 15000000.apps-smmu: FSYNR1 = 0xaa02
<3>[ 718.315117][ T803] arm-smmu 15000000.apps-smmu: context bank# = 0x1b
<3>[ 718.315141][ T803] arm-smmu 15000000.apps-smmu: TTBR0 = 0x001b0000c2a92000
<3>[ 718.315165][ T803] arm-smmu 15000000.apps-smmu: TTBR1 = 0x001b000000000000
<3>[ 718.315192][ T803] arm-smmu 15000000.apps-smmu: SCTLR = 0x0a5f00e7 ACTLR = 0x00000003
<3>[ 718.315245][ T803] arm-smmu 15000000.apps-smmu: CBAR = 0x0001f300
<3>[ 718.315274][ T803] arm-smmu 15000000.apps-smmu: MAIR0 = 0xf404ff44 MAIR1 = 0x0000efe4
<3>[ 718.315297][ T803] arm-smmu 15000000.apps-smmu: SID = 0x40
<3>[ 718.315318][ T803] arm-smmu 15000000.apps-smmu: Client info: BID=0x5, PID=0xa, MID=0x2
<3>[ 718.315377][ T803] arm-smmu 15000000.apps-smmu: soft iova-to-phys=0x0000000000000000
I can reduce this panic with the proposed patch, but it still happens until I
disable the "req->no_interrupt = 1" logic.
2) The frame is not fully transmitted in dwc3 with sg support enabled.
There seems to be a mapping limit I'm seeing where only the roughly first
70% of the total frame is sent. Interestingly, if I allocate a larger
size for the buffer upfront, in uvc_queue_setup(), like sizes[0] =
video->imagesize * 3. Then the issue rarely happens. For example, when I
do YUYV I see green, uninitialized data, at the bottom part of the
frame. If I do MJPG with smaller filled sizes, the transmission is fine.
+-------------------------+
| |
| |
| |
| Good data |
| |
| |
| |
+-------------------------+
|xxxxxxxxxxxxxxxxxxxxxxxxx|
|xxxx Bad data xxxxxxxxx|
|xxxxxxxxxxxxxxxxxxxxxxxxx|
+-------------------------+
Appreciate any thoughts or feedback related to these issues.
Dan Vacura (1):
usb: gadget: uvc: fix sg handling in error case
drivers/usb/gadget/function/uvc_queue.c | 8 +++++---
drivers/usb/gadget/function/uvc_queue.h | 2 +-
drivers/usb/gadget/function/uvc_video.c | 18 ++++++++++++++----
3 files changed, 20 insertions(+), 8 deletions(-)
--
2.20.4
Powered by blists - more mailing lists