* RE: [EXT] RE: Maintainer of ChipID
[not found] ` <JH0PR03MB7634A2DB4CC18ED8C438B9328481A@JH0PR03MB7634.apcprd03.prod.outlook.com>
@ 2026-01-12 17:55 ` tomer.maimon
0 siblings, 0 replies; 6+ messages in thread
From: tomer.maimon @ 2026-01-12 17:55 UTC (permalink / raw)
To: Xu Yang
Cc: Peter Chen (CIX), Uri.Trichter@nuvoton.com,
Avi.Fishman@nuvoton.com, linux-usb@vger.kernel.org
[-- Attachment #1.1.1: Type: text/plain, Size: 51721 bytes --]
Hi Xu,
I have also attached another test case that reproduces the issue; I would appreciate it if you could run it on your end.
Use these 3 scripts:
SoC:
1. Login to soc – run socstress_soc.sh at the background twice or multiple times to increase the net traffic (( each run will have 3 threads, normally I run 4 times give 12 threads which will be enough ping traffic)
2. Change the mode to executable: chmod +x socstress_soc.sh
root@localhost:/vol/data/persistent#./socstress_soc.sh<mailto:root@localhost:/vol/data/persistent#./socstress_soc.sh> & (for stos)
root@localhost:/vol/data/persistent#./socstress_soc.sh<mailto:root@localhost:/vol/data/persistent#./socstress_soc.sh> & (for stos)
root@localhost:/vol/data/persistent#./socstress_soc.sh<mailto:root@localhost:/vol/data/persistent#./socstress_soc.sh> & (for stos)
root@localhost:/vol/data/persistent#./socstress_soc.sh<mailto:root@localhost:/vol/data/persistent#./socstress_soc.sh> & (for stos)
BMC:
1. Login to the bmc – run socstress_bmc.sh at the background twice or multiple times ( each run will have 3 threads, normally I run 4 times give 12 threads) to increase the net traffic
admin@:~$./socstress_bmc.sh<mailto:admin@:~$./socstress_bmc.sh> &
admin@:~$./socstress_bmc.sh<mailto:admin@:~$./socstress_bmc.sh> &
admin@:~$./socstress_bmc.sh<mailto:admin@:~$./socstress_bmc.sh> &
admin@:~$./socstress_bmc.sh<mailto:admin@:~$./socstress_bmc.sh> &
1. Run ddrstress.sh only once, if you run twice, there will be no space left and the previous run will also fail
admin@:~$./ddrstress.sh<mailto:admin@:~$./ddrstress.sh> &
BTW, can you share on which boards you are running the tests.
Thanks,
Tomer
From: IS20 Tomer Maimon
Sent: Monday, January 12, 2026 6:42 PM
To: 'Xu Yang' <xu.yang_2@nxp.com>
Cc: Peter Chen (CIX) <peter.chen@kernel.org>; IV00 Uri Trichter <Uri.Trichter@nuvoton.com>; IS20 Avi Fishman <Avi.Fishman@nuvoton.com>; linux-usb@vger.kernel.org
Subject: RE: [EXT] RE: Maintainer of ChipID
Hi Xu,
Thanks for running the test, can I ask which Chipidea revision you have tested?
Tomer
From: Xu Yang <xu.yang_2@nxp.com<mailto:xu.yang_2@nxp.com>>
Sent: Monday, January 12, 2026 7:49 AM
To: IS20 Tomer Maimon <tomer.maimon@nuvoton.com<mailto:tomer.maimon@nuvoton.com>>
Cc: Peter Chen (CIX) <peter.chen@kernel.org<mailto:peter.chen@kernel.org>>; IV00 Uri Trichter <Uri.Trichter@nuvoton.com<mailto:Uri.Trichter@nuvoton.com>>; IS20 Avi Fishman <Avi.Fishman@nuvoton.com<mailto:Avi.Fishman@nuvoton.com>>; linux-usb@vger.kernel.org<mailto:linux-usb@vger.kernel.org>
Subject: RE: [EXT] RE: Maintainer of ChipID
CAUTION - External Email: Do not click links or open attachments unless you acknowledge the sender and content.
Hi Tomer,
I tried the test for more than 4 hours with kernel version v5.10, v5.15, v6.6 and v6.12 respectively, but I don’t see any issue on my side. iperf3 are still running and printing report on two boards.
Thanks,
Xu Yang
From: tomer.maimon@nuvoton.com<mailto:tomer.maimon@nuvoton.com> <tomer.maimon@nuvoton.com<mailto:tomer.maimon@nuvoton.com>>
Sent: Friday, January 2, 2026 3:05 AM
To: Xu Yang <xu.yang_2@nxp.com<mailto:xu.yang_2@nxp.com>>
Cc: Peter Chen (CIX) <peter.chen@kernel.org<mailto:peter.chen@kernel.org>>; Uri.Trichter@nuvoton.com<mailto:Uri.Trichter@nuvoton.com>; Avi.Fishman@nuvoton.com<mailto:Avi.Fishman@nuvoton.com>; linux-usb@vger.kernel.org<mailto:linux-usb@vger.kernel.org>
Subject: RE: [EXT] RE: Maintainer of ChipID
Caution: This is an external email. Please take care when clicking links or opening attachments. When in doubt, report the message using the 'Report this email' button
Hi Xu,
Sorry for the late reply and HAPPY NEW YEAR!
We are setting two EVB boards
1. EVB1 – UDC
2. EVB2 – Host
On EVB1
Setting RNDIS CDC ethernet gadget + ip address
mount -t configfs none /sys/kernel/config
mkdir -p /sys/kernel/config/usb_gadget/g1
cd /sys/kernel/config/usb_gadget/g1
echo "0x1d6b" > idVendor
echo "0x0104" > idProduct
mkdir strings/0x409
echo "My Manufacturer" > strings/0x409/manufacturer
echo "ECM Gadget" > strings/0x409/product
mkdir configs/c.1
mkdir functions/ecm.usb0
ln -s functions/ecm.usb0 configs/c.1/
echo "ci_hdrc.0" > UDC
ifconfig usb0 192.168.7.2 netmask 255.255.255.0 up
On EVB2
Set usb0 IP address.
ifconfig usb0 192.168.7.1 netmask 255.255.255.0 up
To reproduce the failure where UDC QH and TD are allocating memory from DDR, please follow these steps run in iperf3:
EVB1 On the UDC side (192.168.7.2):
iperf3 -s --port 5022 &
iperf3 -s --port 5021 &
iperf3 -c 127.0.0.1 -t 0 --port 5021 > /dev/null &
EVB2 On the Host side (192.168.7.1):
iperf3 -c 192.168.7.2 --bidir -t 86400 -i 1 --port 5022
The failure typically occurs within 1–2 hours.
Thanks,
Tomer
From: Xu Yang <xu.yang_2@nxp.com<mailto:xu.yang_2@nxp.com>>
Sent: Tuesday, 23 December 2025 5:26
To: IS20 Tomer Maimon <tomer.maimon@nuvoton.com<mailto:tomer.maimon@nuvoton.com>>
Cc: Peter Chen (CIX) <peter.chen@kernel.org<mailto:peter.chen@kernel.org>>; IV00 Uri Trichter <Uri.Trichter@nuvoton.com<mailto:Uri.Trichter@nuvoton.com>>; IS20 Avi Fishman <Avi.Fishman@nuvoton.com<mailto:Avi.Fishman@nuvoton.com>>; linux-usb@vger.kernel.org<mailto:linux-usb@vger.kernel.org>
Subject: RE: [EXT] RE: Maintainer of ChipID
CAUTION - External Email: Do not click links or open attachments unless you acknowledge the sender and content.
Hi Tomer,
For your issue, please check the state of ENDPTPRIME, ENDPTSTAT while HW req #10 and #11 are enqueued.
It seems like both ENDPTPRIME and ENDPTSTAT are cleared so that req #11 is force set as queue head. If so, you need to check why endpoint becomes not ready.
For your questions:
1. The following picture shows the detail steps to add a TD, and the driver follows these rules.
The ATDTW bit can’t be read as 1 (after write 1) during the device controller finishing current dTD and switch to next dTD. Otherwise, ATDTW bit can be read as 1 at other times.
Based on this, we need check ENDPTSTAT bit to decide if the new dTD should be set as queue head or keep at the tail of the list.
[cid:image001.png@01DC83FC.8CBFF5A0]
2. For the “Remark” in ENDPSTAT register, we confirm that it can’t be cleared during the HW re-priming operation unless the current dTD is the last one. Therefore, the “Remark” seems like a legacy thing.
3. When you flush the endpoint, the device controller will update the queue head as usual. If the dTD set IOC, the irq will be fired. To resume it, you need to prime the endpoint again.
4. If the endpoint is already primed and executing a dTD, the controller will continue to execute the current dTD and the prime operation should be invalid in HW. But in SW, if you call reprime_dtd() the
next link pointer will be updated based on the input parameter.
Could you share your test steps? And how do you do stress on the USB interface? Just want to check if I can reproduce the issue.
Thanks,
Xu Yang
From: tomer.maimon@nuvoton.com<mailto:tomer.maimon@nuvoton.com> <tomer.maimon@nuvoton.com<mailto:tomer.maimon@nuvoton.com>>
Sent: Thursday, December 18, 2025 7:49 PM
To: Xu Yang <xu.yang_2@nxp.com<mailto:xu.yang_2@nxp.com>>
Cc: Peter Chen (CIX) <peter.chen@kernel.org<mailto:peter.chen@kernel.org>>; Uri.Trichter@nuvoton.com<mailto:Uri.Trichter@nuvoton.com>; Avi.Fishman@nuvoton.com<mailto:Avi.Fishman@nuvoton.com>; linux-usb@vger.kernel.org<mailto:linux-usb@vger.kernel.org>
Subject: RE: [EXT] RE: Maintainer of ChipID
Hi Xu,
We suspect the TX stalls happens because one of the TD did not get transferred and the Queue Head move passed it. Thus, it did in fact got skipped.
Let's start with the latest debug dump of requests node after all my debug additions:
root@m1120-c4a14:/sys/kernel/debug/usb/ci_hdrc.3#<mailto:root@m1120-c4a14:/sys/kernel/debug/usb/ci_hdrc.3> cat requests
RX Endpoint 0 Information Dump:
-------------------------------------------------
RX Endpoint 1 Information Dump:
HW Req #0 (ptr=0xffffff8023bc7100):
struct usb_request (ptr=0xffffff8023bc7100) = {
.status=-114
.complete=(Registered)
.actual=0
.length=1534
.num_mapped_sqs=0
};
EP=01: TD=7B841400 RX Length=1534 Buffer=0x12AE9740
0000: 7B841280
0001: 05FE8080
0002: 12AE9740
0003: 12AEA000
0004: 12AEB000
0005: 12AEC000
0006: 12AED000
HW Req #1 (ptr=0xffffff8023bc7000):
struct usb_request (ptr=0xffffff8023bc7000) = {
.status=-114
.complete=(Registered)
.actual=0
.length=1534
.num_mapped_sqs=0
};
EP=01: TD=7B841280 RX Length=1534 Buffer=0x12AE8FC0
0000: 7B841300
0001: 05FE8080
0002: 12AE8FC0
0003: 12AE9000
0004: 12AEA000
0005: 12AEB000
0006: 12AEC000
HW Req #2 (ptr=0xffffff8025c48e00):
struct usb_request (ptr=0xffffff8025c48e00) = {
.status=-114
.complete=(Registered)
.actual=0
.length=1534
.num_mapped_sqs=0
};
EP=01: TD=7B841300 RX Length=1534 Buffer=0x12AE8840
0000: 7B841040
0001: 05FE8080
0002: 12AE8840
0003: 12AE9000
0004: 12AEA000
0005: 12AEB000
0006: 12AEC000
HW Req #3 (ptr=0xffffff8023bc7800):
struct usb_request (ptr=0xffffff8023bc7800) = {
.status=-114
.complete=(Registered)
.actual=0
.length=1534
.num_mapped_sqs=0
};
EP=01: TD=7B841040 RX Length=1534 Buffer=0x12AE80C0
0000: 7B841080
0001: 05FE8080
0002: 12AE80C0
0003: 12AE9000
0004: 12AEA000
0005: 12AEB000
0006: 12AEC000
HW Req #4 (ptr=0xffffff8023bc7700):
struct usb_request (ptr=0xffffff8023bc7700) = {
.status=-114
.complete=(Registered)
.actual=0
.length=1534
.num_mapped_sqs=0
};
EP=01: TD=7B841080 RX Length=1534 Buffer=0x2C0D78C0
0000: 7B8410C0
0001: 05FE8080
0002: 2C0D78C0
0003: 2C0D8000
0004: 2C0D9000
0005: 2C0DA000
0006: 2C0DB000
HW Req #5 (ptr=0xffffff8023bc7600):
struct usb_request (ptr=0xffffff8023bc7600) = {
.status=-114
.complete=(Registered)
.actual=0
.length=1534
.num_mapped_sqs=0
};
EP=01: TD=7B8410C0 RX Length=1534 Buffer=0x2C0D7140
0000: 7B841100
0001: 05FE8080
0002: 2C0D7140
0003: 2C0D8000
0004: 2C0D9000
0005: 2C0DA000
0006: 2C0DB000
HW Req #6 (ptr=0xffffff8023bc7500):
struct usb_request (ptr=0xffffff8023bc7500) = {
.status=-114
.complete=(Registered)
.actual=0
.length=1534
.num_mapped_sqs=0
};
EP=01: TD=7B841100 RX Length=1534 Buffer=0x2C0D69C0
0000: 7B841140
0001: 05FE8080
0002: 2C0D69C0
0003: 2C0D7000
0004: 2C0D8000
0005: 2C0D9000
0006: 2C0DA000
HW Req #7 (ptr=0xffffff8023bc7400):
struct usb_request (ptr=0xffffff8023bc7400) = {
.status=-114
.complete=(Registered)
.actual=0
.length=1534
.num_mapped_sqs=0
};
EP=01: TD=7B841140 RX Length=1534 Buffer=0x2C0D6240
0000: 7B841180
0001: 05FE8080
0002: 2C0D6240
0003: 2C0D7000
0004: 2C0D8000
0005: 2C0D9000
0006: 2C0DA000
HW Req #8 (ptr=0xffffff8023bc7300):
struct usb_request (ptr=0xffffff8023bc7300) = {
.status=-114
.complete=(Registered)
.actual=0
.length=1534
.num_mapped_sqs=0
};
EP=01: TD=7B841180 RX Length=1534 Buffer=0x2C0D5AC0
0000: 7B8411C0
0001: 05FE8080
0002: 2C0D5AC0
0003: 2C0D6000
0004: 2C0D7000
0005: 2C0D8000
0006: 2C0D9000
HW Req #9 (ptr=0xffffff8023bc7200):
struct usb_request (ptr=0xffffff8023bc7200) = {
.status=-114
.complete=(Registered)
.actual=0
.length=1534
.num_mapped_sqs=0
};
EP=01: TD=7B8411C0 RX Length=1534 Buffer=0x2C0D5340
0000: 00000001
0001: 05FE8080
0002: 2C0D5340
0003: 2C0D6000
0004: 2C0D7000
0005: 2C0D8000
0006: 2C0D9000
-------------------------------------------------
RX Endpoint 2 Information Dump:
-------------------------------------------------
TX Endpoint 0 Information Dump:
-------------------------------------------------
TX Endpoint 1 Information Dump:
HW Req #10 (ptr=0xffffff8025c44d00):
struct usb_request (ptr=0xffffff8025c44d00) = {
.status=-114
.complete=(Registered)
.actual=0
.length=98
.num_mapped_sqs=0
};
EP=01: TD=7B841380 TX Length=98 Buffer=0x0F6E9300
0000: 7B841240
0001: 00628080
0002: 0F6E9300 <--- Notice this value is the same af the buffer address. This means the TD got skipped.
0003: 0F6EA000
0004: 0F6EB000
0005: 0F6EC000
0006: 0F6ED000
HW Req #11 (ptr=0xffffff8025c44c00):
struct usb_request (ptr=0xffffff8025c44c00) = {
.status=-114
.complete=(Registered)
.actual=0
.length=98
.num_mapped_sqs=0
};
EP=01: TD=7B841240 TX Length=98 Buffer=0x19CAFD00
0000: 7B841340
0001: 00008000
0002: 19CAFD62
0003: 19CB055F
0004: 19CB1000
0005: 19CB2000
0006: 19CB3000
HW Req #12 (ptr=0xffffff8025c44f00):
struct usb_request (ptr=0xffffff8025c44f00) = {
.status=-114
.complete=(Registered)
.actual=0
.length=98
.num_mapped_sqs=0
};
EP=01: TD=7B841340 TX Length=98 Buffer=0x216BEB80
0000: 7B8413C0
0001: 00008000
0002: 216BEBE2
0003: 216BF55F
0004: 216C0000
0005: 216C1000
0006: 216C2000
HW Req #13 (ptr=0xffffff8025c44e00):
struct usb_request (ptr=0xffffff8025c44e00) = {
.status=-114
.complete=(Registered)
.actual=0
.length=98
.num_mapped_sqs=0
};
EP=01: TD=7B8413C0 TX Length=98 Buffer=0x216F3100
0000: 7B841480
0001: 00008000
0002: 216F3162
0003: 216F456B
0004: 216F5000
0005: 216F6000
0006: 216F7000
HW Req #14 (ptr=0xffffff8025c44b00):
struct usb_request (ptr=0xffffff8025c44b00) = {
.status=-114
.complete=(Registered)
.actual=0
.length=1514
.num_mapped_sqs=0
};
EP=01: TD=7B841480 TX Length=1514 Buffer=0x2AC74000
0000: 7B8414C0
0001: 00008000
0002: 2AC745EA
0003: 2AC7556B
0004: 2AC76000
0005: 2AC77000
0006: 2AC78000
HW Req #15 (ptr=0xffffff8025c44a00):
struct usb_request (ptr=0xffffff8025c44a00) = {
.status=-114
.complete=(Registered)
.actual=0
.length=1514
.num_mapped_sqs=0
};
EP=01: TD=7B8414C0 TX Length=1514 Buffer=0x2AC77800
0000: 7B841500
0001: 00008000
0002: 2AC77DEA
0003: 2AC78583
0004: 2AC79000
0005: 2AC7A000
0006: 2AC7B000
HW Req #16 (ptr=0xffffff8025c44900):
struct usb_request (ptr=0xffffff8025c44900) = {
.status=-114
.complete=(Registered)
.actual=0
.length=1514
.num_mapped_sqs=0
};
EP=01: TD=7B841500 TX Length=1514 Buffer=0x2AC73800
0000: 7B841540
0001: 00008000
0002: 2AC73DEA
0003: 2AC74590
0004: 2AC75000
0005: 2AC76000
0006: 2AC77000
HW Req #17 (ptr=0xffffff8025c44800):
struct usb_request (ptr=0xffffff8025c44800) = {
.status=-114
.complete=(Registered)
.actual=0
.length=1514
.num_mapped_sqs=0
};
EP=01: TD=7B841540 TX Length=1514 Buffer=0x2AC73000
0000: 7B841580
0001: 00008000
0002: 2AC735EA
0003: 2AC7459C
0004: 2AC75000
0005: 2AC76000
0006: 2AC77000
HW Req #18 (ptr=0xffffff8025c44700):
struct usb_request (ptr=0xffffff8025c44700) = {
.status=-114
.complete=(Registered)
.actual=0
.length=1514
.num_mapped_sqs=0
};
EP=01: TD=7B841580 TX Length=1514 Buffer=0x2AC75000
0000: 7B8415C0
0001: 00008000
0002: 2AC755EA
0003: 2AC765A8
0004: 2AC77000
0005: 2AC78000
0006: 2AC79000
HW Req #19 (ptr=0xffffff8025c44600):
struct usb_request (ptr=0xffffff8025c44600) = {
.status=-114
.complete=(Registered)
.actual=0
.length=98
.num_mapped_sqs=0
};
EP=01: TD=7B8415C0 TX Length=98 Buffer=0x216F3980
0000: 00000001
0001: 00008000
0002: 216F39E2
0003: 216F45B5
0004: 216F5000
0005: 216F6000
0006: 216F7000
-------------------------------------------------
TX Endpoint 2 Information Dump:
-------------------------------------------------
Hardware request #10 (highlighted in yellow above) reflects a single USB request (gadget level) from the higher layers. All Hardware request reflect a single USB request (i.e., the enqueue endpoint function call from higher layer). In this case, it's the USB gadget ethernet. The USB gadget ethernet makes a single USB request per ethernet packet. This is why you see a single TD per request since the size of a standard ethernet packet will always fit in a single TD. You need more than 20KB in size for a USB request to have more than one dTD.
Hardware request #10 is the one that got skipped.
To understand how, let's look at ChipIdea's driver's s core enqueue function:
static int _hardware_enqueue(struct ci_hw_ep *hwep, struct ci_hw_req *hwreq)
{
struct ci_hdrc *ci = hwep->ci;
int ret = 0;
struct td_node *firstnode, *lastnode;
/* don't queue twice */
if (hwreq->req.status == -EALREADY)
return -EALREADY;
hwreq->req.status = -EALREADY;
ret = usb_gadget_map_request_by_dev(ci->dev->parent,
&hwreq->req, hwep->dir);
if (ret)
return ret;
if (((u32) hwreq->req.buf) & 0x3) {
hwep->usb_request_buf_unaligned++;
}
if (hwreq->req.num_mapped_sgs)
ret = prepare_td_for_sg(hwep, hwreq);
else
ret = prepare_td_for_non_sg(hwep, hwreq);
if (ret)
return ret;
lastnode = list_entry(hwreq->tds.prev,
struct td_node, td);
lastnode->ptr->next = cpu_to_le32(TD_TERMINATE);
if (!hwreq->req.no_interrupt)
lastnode->ptr->token |= cpu_to_le32(TD_IOC);
list_for_each_entry_safe(firstnode, lastnode, &hwreq->tds, td)
trace_ci_prepare_td(hwep, hwreq, firstnode);
firstnode = list_first_entry(&hwreq->tds, struct td_node, td); ---------> Ref-A-Code
wmb();
hwreq->req.actual = 0;
if (!list_empty(&hwep->qh.queue)) {
struct ci_hw_req *hwreqprev;
int n = hw_ep_bit(hwep->num, hwep->dir);
int tmp_stat;
struct td_node *prevlastnode;
u32 next = firstnode->dma & TD_ADDR_MASK;
hwreqprev = list_entry(hwep->qh.queue.prev, -----> Ref-D-code-body
struct ci_hw_req, queue); ^
prevlastnode = list_entry(hwreqprev->tds.prev,--------|
struct td_node, td);
|
prevlastnode->ptr->next = cpu_to_le32(next); --------|
wmb();
if (ci->rev == CI_REVISION_22) {
if (!hw_read(ci, OP_ENDPTSTAT, BIT(n)))
reprime_dtd(ci, hwep, prevlastnode);
}
if (hw_read(ci, OP_ENDPTPRIME, BIT(n))) -------> Rev-B-0-code
goto done;
do {
hw_write(ci, OP_USBCMD, USBCMD_ATDTW, USBCMD_ATDTW);
tmp_stat = hw_read(ci, OP_ENDPTSTAT, BIT(n));
} while (!hw_read(ci, OP_USBCMD, USBCMD_ATDTW));
hw_write(ci, OP_USBCMD, USBCMD_ATDTW, 0);
if (tmp_stat)
goto done; Rev-B-1-Code
}
/* QH configuration */
hwep->qh.ptr->td.next = cpu_to_le32(firstnode->dma); ----> Ref-C-Code
hwep->qh.ptr->td.token &=
cpu_to_le32(~(TD_STATUS_HALTED|TD_STATUS_ACTIVE));
if (hwep->type == USB_ENDPOINT_XFER_ISOC && hwep->dir == RX) {
u32 mul = hwreq->req.length / hwep->ep.maxpacket;
if (hwreq->req.length == 0
|| hwreq->req.length % hwep->ep.maxpacket)
mul++;
hwep->qh.ptr->cap |= cpu_to_le32(mul << __ffs(QH_MULT));
}
ret = hw_ep_prime(ci, hwep, hwep->num, hwep->dir,
hwep->type == USB_ENDPOINT_XFER_CONTROL);
done:
return ret;
}
The bug happens when more than one USB request (i.e., a gadget level function request ... in this case, it's ethernet) gets added via the enqueue function. And there are already other TDs in progress or active and "timing" of other events have to occur just right need to happen for this scenario to spell out the way I described. So, doing a stress on the USB interface will bring this out more frequently as one of my counters told me. Yes, it happens more frequently than I thought but not every time. So timing of the scheduler and hardware state changes do need to happen at the correct moment.
In the scenario, the first request is HW req #10 and then followed by HW req #11. HW req #10 gets stitched into the dTD chain and may or may not get put into QH by the Ref-C-code line depending on whether the list is empty or whether Rev-B-0-code or Rev-B-1 code makes it jump to the done label. When HW req #11 comes in next, Rev-B-0-code and Rev-B-1-code line do not jump to done. This then makes it go to Ref-C-code.
And the problem is at Ref-C-code.
Note!!!!!!! what the firstnode points to. It points to the first TD of this new HW request that is passed into the enqueue function. It is NOT necessarily the first TD of the first HW request already in the queue that has not yet or is in progress of being transmitted. In other words, Rev-C-code allows the current/new hardware request to jump the line.
Look at Rev-D-code-body. These lines of code link all TDs **across** all HW request so that it is a single linked dTD chain. I believe this is done as an optimization so when there are more than one USB request in the queue, there is minimal performance loss when crossing USB request boundaries. But if you are going to do this, you have to ensure Ref-C-code is done correctly without skipping a hardware request (that can have one or more TDs) as well as ensuring that you append correctly.
Ref-C-code and the line after that violates the above highlighted text. We suspect ATDTW and ENDPTPRIME and ENDPSTAT plays here somehow but it's not clear how exactly to me. The "handshaking" between the hardware and software between QH, TD, ATDTW, ENDPTPRIME and ENDPSTAT is not clear to me when existing TDs are in progress/active.
Appreciate if you (or one of the HW engineers) can answer this questions:
1. How does ATDTW (bit 14) of the USBCMD register work for adding new descriptors? I know what the document says. But it's not clear how that affects the queue head that could already be in progress. Do we do add the TD while the bit is set?
1. For Endpoint priming (ENDPTPRIME) and endpoint status register (ENDPTSTAT), there is a statement in the document "Remark: These bits will be momentarily cleared by hardware during hardware endpoint
re-priming operations when a dTD is retired and the dQH is updated", how does the code know upon reading these registers that it being momentarily cleared by hardware or that the all TD transfers are complete? How long is a "moment"? This blimp in time can make Ref-B-1-code or Ref-B-0-code take the wrong path and ultimately lead to a skipped request.
1. When flushing an endpoint via ENDPTFLUSH, the current transfer completes. I assume this means the current TD in the queue head. But how does the queue head status get updated and how should we resume it?
1. What happens if I reprime an already primed endpoint and the TD in the QH is active?
Thanks a lot,
Tomer
From: Xu Yang <xu.yang_2@nxp.com<mailto:xu.yang_2@nxp.com>>
Sent: Monday, 15 December 2025 13:33
To: IS20 Tomer Maimon <tomer.maimon@nuvoton.com<mailto:tomer.maimon@nuvoton.com>>
Cc: Peter Chen (CIX) <peter.chen@kernel.org<mailto:peter.chen@kernel.org>>; IV00 Uri Trichter <Uri.Trichter@nuvoton.com<mailto:Uri.Trichter@nuvoton.com>>; IS20 Avi Fishman <Avi.Fishman@nuvoton.com<mailto:Avi.Fishman@nuvoton.com>>; linux-usb@vger.kernel.org<mailto:linux-usb@vger.kernel.org>
Subject: RE: [EXT] RE: Maintainer of ChipID
CAUTION - External Email: Do not click links or open attachments unless you acknowledge the sender and content.
Hi Tomer,
Please refer to the below dTD structure.
EP=01: TD=7B8424C0 USB-Request-Status=-114 CompleteCB=Yes Actual=0 TX
0000: 7B842340
0001: 00628080
0002: 2126AA02
0003: 2126B000
0004: 2126C000
0005: 2126D000
0006: 2126E000
#0001 describe Total Bytes + Status + others.
#0002 describe Buffer Pointer 0 + Current Offset.
So, we can’t get conclusion from #0002 that transfer did start. But we can compare #0001 before and after the transfer to see if something changes.
[cid:image002.png@01DC83FC.8CBFF5A0]
Thanks,
Xu Yang
From: tomer.maimon@nuvoton.com<mailto:tomer.maimon@nuvoton.com> <tomer.maimon@nuvoton.com<mailto:tomer.maimon@nuvoton.com>>
Sent: Sunday, December 14, 2025 11:54 PM
To: Xu Yang <xu.yang_2@nxp.com<mailto:xu.yang_2@nxp.com>>
Cc: Peter Chen (CIX) <peter.chen@kernel.org<mailto:peter.chen@kernel.org>>; Uri.Trichter@nuvoton.com<mailto:Uri.Trichter@nuvoton.com>; Avi.Fishman@nuvoton.com<mailto:Avi.Fishman@nuvoton.com>; linux-usb@vger.kernel.org<mailto:linux-usb@vger.kernel.org>
Subject: RE: [EXT] RE: Maintainer of ChipID
Caution: This is an external email. Please take care when clicking links or opening attachments. When in doubt, report the message using the 'Report this email' button
Hi Xu,
Could I know if TD 7B8424C0 is the very first one of the entire transfers on EP01TX?
Yes, it is the first TD in the link list.
If the queue head has already executed other TDs before 7B8424C0?
It is very likely the device controller have executed other TDs before this one because we see network
activity successfully completely. Those TD got completed successfully and removed from the list. That
is why you don't see anything before this TD.
Just wondering again about the first TD in the list, I don't think it was skipped too the more I looked at it.
I now think that the device controller did not perform the last update to the status field. So, when we dump it, it looks like the device
controller partially sent out the data and "moved on" to the next TD. Given a similar RX stall issue that saw earlier, the status field did not reflect what the CPU saw at time of ISR execution.
Therefore, I suspect that the device controller has a corner case where there is one more update to the status field that it should do but did not do or did do but should not have done.
In short, I think the status field is not consistent with actual hardware state.
You can see even in the below TD that in row 0002, that transfer did indeed start. Therefore, it was
not skipped. I suspect that the data get transmitted but a final update to the status field (marked in yellow)
did not occur.
EP=01: TD=7B8424C0 USB-Request-Status=-114 CompleteCB=Yes Actual=0 TX
0000: 7B842340
0001: 00628080
0002: 2126AA02
0003: 2126B000
0004: 2126C000
0005: 2126D000
0006: 2126E000
Do you agree with this theory?
Also, in failure scenarios, we observe that the QH is pointing to a TD that has the T (terminate) bit set (i.e., no Next pointer), making it the last entry in the BD chain.
When the IOC bit is set, an interrupt is triggered. In the interrupt handler, upon detecting the T (terminate) bit, the driver iterates over the entire list—from the Head (software pointer) to the Tail (current pointer)—to verify that the buffers were successfully transmitted.
Questions:
1. Why does the driver operate this way, iterating over the list upon encountering the Terminate bit? What is the rationale?
2. Is it possible that the Upper Layer has already begun writing the new chain?
Thanks a lot,
Tomer
From: Xu Yang <xu.yang_2@nxp.com<mailto:xu.yang_2@nxp.com>>
Sent: Thursday, 11 December 2025 4:52
To: IS20 Tomer Maimon <tomer.maimon@nuvoton.com<mailto:tomer.maimon@nuvoton.com>>
Cc: Peter Chen (CIX) <peter.chen@kernel.org<mailto:peter.chen@kernel.org>>; IV00 Uri Trichter <Uri.Trichter@nuvoton.com<mailto:Uri.Trichter@nuvoton.com>>; IS20 Avi Fishman <Avi.Fishman@nuvoton.com<mailto:Avi.Fishman@nuvoton.com>>; linux-usb@vger.kernel.org<mailto:linux-usb@vger.kernel.org>
Subject: RE: [EXT] RE: Maintainer of ChipID
CAUTION - External Email: Do not click links or open attachments unless you acknowledge the sender and content.
Hi Tomer,
Please note: the TD active bit is set by software and cleared by device controller once it completes the transfer.
If you provide the first TD contents before and after the transfer, we can have more clear understanding of the process. Such as if the Total byte fields are updated by device controller.
Could I know if TD 7B8424C0 is the very first one of the entire transfers on EP01TX? If the queue head has already executed other TDs before 7B8424C0?
For your wondering:
It’s also what I guess as I said before. But if the device controller is executing an old TD, it will continue to do that until this TD is completed.
BTW, can you try latest kernel?
Thanks,
Xu Yang
From: tomer.maimon@nuvoton.com<mailto:tomer.maimon@nuvoton.com> <tomer.maimon@nuvoton.com<mailto:tomer.maimon@nuvoton.com>>
Sent: Thursday, December 11, 2025 5:09 AM
To: Xu Yang <xu.yang_2@nxp.com<mailto:xu.yang_2@nxp.com>>
Cc: Peter Chen (CIX) <peter.chen@kernel.org<mailto:peter.chen@kernel.org>>; Uri.Trichter@nuvoton.com<mailto:Uri.Trichter@nuvoton.com>; Avi.Fishman@nuvoton.com<mailto:Avi.Fishman@nuvoton.com>; linux-usb@vger.kernel.org<mailto:linux-usb@vger.kernel.org>
Subject: RE: [EXT] RE: Maintainer of ChipID
Hi Xu,
Thank you very much for the quick response.
I'm not entirely convinced that the first TD was actually skipped. From my understanding, before priming, the very first TD in the queue should be in the Non-Active state (while all subsequent TDs in the chain are already marked Active).
Once the endpoint is primed, the hardware should start the DMA engine, which sets that first TD to Active and begins processing it.
If that's correct, then in this case the first TD was successfully primed (we can see the status changed to Active), but for some reason the DMA transfer either never started or started but didn't update the token bits / Actual Bytes / Status as expected.
EP=01: TD=7B8424C0 USB-Request-Status=-114 CompleteCB=Yes Actual=0 TX
0000: 7B842340
0001: 00628080
0002: 2126AA02
0003: 2126B000
0004: 2126C000
0005: 2126D000
0006: 2126E000
One thing I'm wondering: is it possible that, while the DMA is processing the current queue, a new TD gets inserted at the head of the queue (i.e., a new "first" TD is added in front of the one that was just primed)?
If that happened, would the hardware continue with the original TD or could it cause the behaviour we're seeing (Active bit set, but Actual Bytes remains 0 and the transfer appears stalled)?
Thanks again for your help!
Tomer
From: Xu Yang <xu.yang_2@nxp.com<mailto:xu.yang_2@nxp.com>>
Sent: Wednesday, 10 December 2025 8:07
To: IS20 Tomer Maimon <tomer.maimon@nuvoton.com<mailto:tomer.maimon@nuvoton.com>>
Cc: Peter Chen (CIX) <peter.chen@kernel.org<mailto:peter.chen@kernel.org>>; IV00 Uri Trichter <Uri.Trichter@nuvoton.com<mailto:Uri.Trichter@nuvoton.com>>; IS20 Avi Fishman <Avi.Fishman@nuvoton.com<mailto:Avi.Fishman@nuvoton.com>>; linux-usb@vger.kernel.org<mailto:linux-usb@vger.kernel.org>
Subject: RE: [EXT] RE: Maintainer of ChipID
CAUTION - External Email: Do not click links or open attachments unless you acknowledge the sender and content.
Hi Tomer,
Based on your info, the device controller has skipped dTD 7B8424C0 but still executed dTD 7B842340, 7B842280 - 7B842540. Finally, queue head stops at the last dTD.
I don’t think add CI_REVISION_25 check will cause reprime_dtd() be called when the device controller is executing the following dTDs. Because the endpoint is still in ready state, so “if (!hw_read(ci, OP_ENDPTSTAT, BIT(n)))” check will be false.
If the endpoint becomes not ready, then reprime the endpoint at dTD 7B8424C0 seems not also like a correct way. Because the data packet order will be corrupted.
So, for your issue, it seems like the queue head be force reset to 7B842340 when queue a new request which caused 7B8424C0 be skipped. I’m not sure for this.
I notice that you are using an old kernel version, can you try latest kernel, such as v6.18? Because the udc driver has some fix or improved patches.
Thanks,
Xu Yang
From: tomer.maimon@nuvoton.com<mailto:tomer.maimon@nuvoton.com> <tomer.maimon@nuvoton.com<mailto:tomer.maimon@nuvoton.com>>
Sent: Wednesday, December 10, 2025 12:47 AM
To: Xu Yang <xu.yang_2@nxp.com<mailto:xu.yang_2@nxp.com>>
Cc: Peter Chen (CIX) <peter.chen@kernel.org<mailto:peter.chen@kernel.org>>; Uri.Trichter@nuvoton.com<mailto:Uri.Trichter@nuvoton.com>; Avi.Fishman@nuvoton.com<mailto:Avi.Fishman@nuvoton.com>; linux-usb@vger.kernel.org<mailto:linux-usb@vger.kernel.org>
Subject: [EXT] RE: Maintainer of ChipID
Hi Xu,
Appreciate your assistance in the following issue,
The data below explains why the request queue did not complete and why the TX is stalled.
First, notice in the data below, highlighted text in red and yellow to point out the critical points.
Notice how the qeue head points to the ___end___ of the request list (It's highlighted in yellow).
However, the first request is NOT complete. The active bit (bit 7) is still set. But yet, the queue head has moved on.
They are dump of qhead and requests.
root@m1120-c4a14:/sys/kernel/debug/usb/ci_hdrc.3#<mailto:root@m1120-c4a14:/sys/kernel/debug/usb/ci_hdrc.3> cat requests
EP=01: TD=7B842480 USB-Request-Status=-114 CompleteCB=Yes Actual=0 RX
0000: 7B842300
0001: 05FE8080
0002: 0826A640
0003: 0826B000
0004: 0826C000
0005: 0826D000
0006: 0826E000
EP=01: TD=7B842300 USB-Request-Status=-114 CompleteCB=Yes Actual=0 RX
0000: 7B842200
0001: 05FE8080
0002: 08269EC0
0003: 0826A000
0004: 0826B000
0005: 0826C000
0006: 0826D000
EP=01: TD=7B842200 USB-Request-Status=-114 CompleteCB=Yes Actual=0 RX
0000: 7B842240
0001: 05FE8080
0002: 08269740
0003: 0826A000
0004: 0826B000
0005: 0826C000
0006: 0826D000
EP=01: TD=7B842240 USB-Request-Status=-114 CompleteCB=Yes Actual=0 RX
0000: 7B8421C0
0001: 05FE8080
0002: 08268FC0
0003: 08269000
0004: 0826A000
0005: 0826B000
0006: 0826C000
EP=01: TD=7B8421C0 USB-Request-Status=-114 CompleteCB=Yes Actual=0 RX
0000: 7B842140
0001: 05FE8080
0002: 08268840
0003: 08269000
0004: 0826A000
0005: 0826B000
0006: 0826C000
EP=01: TD=7B842140 USB-Request-Status=-114 CompleteCB=Yes Actual=0 RX
0000: 7B842580
0001: 05FE8080
0002: 082680C0
0003: 08269000
0004: 0826A000
0005: 0826B000
0006: 0826C000
EP=01: TD=7B842580 USB-Request-Status=-114 CompleteCB=Yes Actual=0 RX
0000: 7B8420C0
0001: 05FE8080
0002: 082178C0
0003: 08218000
0004: 08219000
0005: 0821A000
0006: 0821B000
EP=01: TD=7B8420C0 USB-Request-Status=-114 CompleteCB=Yes Actual=0 RX
0000: 7B8425C0
0001: 05FE8080
0002: 08217140
0003: 08218000
0004: 08219000
0005: 0821A000
0006: 0821B000
EP=01: TD=7B8425C0 USB-Request-Status=-114 CompleteCB=Yes Actual=0 RX
0000: 7B842040
0001: 05FE8080
0002: 082169C0
0003: 08217000
0004: 08218000
0005: 08219000
0006: 0821A000
EP=01: TD=7B842040 USB-Request-Status=-114 CompleteCB=Yes Actual=0 RX
0000: 00000001
0001: 05FE8080
0002: 08216240
0003: 08217000
0004: 08218000
0005: 08219000
0006: 0821A000
EP=01: TD=7B8424C0 USB-Request-Status=-114 CompleteCB=Yes Actual=0 TX
0000: 7B842340
0001: 00628080
0002: 2126AA02
0003: 2126B000
0004: 2126C000
0005: 2126D000
0006: 2126E000
EP=01: TD=7B842340 USB-Request-Status=-114 CompleteCB=Yes Actual=0 TX
0000: 7B842280
0001: 00008000
0002: 2126A064
0003: 2126B360
0004: 2126C000
0005: 2126D000
0006: 2126E000
EP=01: TD=7B842280 USB-Request-Status=-114 CompleteCB=Yes Actual=0 TX
0000: 7B842000
0001: 00008000
0002: 2126A264
0003: 2126B360
0004: 2126C000
0005: 2126D000
0006: 2126E000
EP=01: TD=7B842000 USB-Request-Status=-114 CompleteCB=Yes Actual=0 TX
0000: 7B842100
0001: 00008000
0002: 2126B864
0003: 2126C360
0004: 2126D000
0005: 2126E000
0006: 2126F000
EP=01: TD=7B842100 USB-Request-Status=-114 CompleteCB=Yes Actual=0 TX
0000: 7B842440
0001: 00008000
0002: 27F185EC
0003: 27F19361
0004: 27F1A000
0005: 27F1B000
0006: 27F1C000
EP=01: TD=7B842440 USB-Request-Status=-114 CompleteCB=Yes Actual=0 TX
0000: 7B842380
0001: 00008000
0002: 2126AC64
0003: 2126B361
0004: 2126C000
0005: 2126D000
0006: 2126E000
EP=01: TD=7B842380 USB-Request-Status=-114 CompleteCB=Yes Actual=0 TX
0000: 7B8423C0
0001: 00008000
0002: 2126A864
0003: 2126B361
0004: 2126C000
0005: 2126D000
0006: 2126E000
EP=01: TD=7B8423C0 USB-Request-Status=-114 CompleteCB=Yes Actual=0 TX
0000: 7B842400
0001: 00008000
0002: 2126AE64
0003: 2126B361
0004: 2126C000
0005: 2126D000
0006: 2126E000
EP=01: TD=7B842400 USB-Request-Status=-114 CompleteCB=Yes Actual=0 TX
0000: 7B842540
0001: 00008000
0002: 2126B664
0003: 2126C362
0004: 2126D000
0005: 2126E000
0006: 2126F000
EP=01: TD=7B842540 USB-Request-Status=-114 CompleteCB=Yes Actual=0 TX
0000: 00000001
0001: 00008000
0002: 2126BC64
0003: 2126C362
0004: 2126D000
0005: 2126E000
0006: 2126F000
root@m1120-c4a14:/sys/kernel/debug/usb/ci_hdrc.3#<mailto:root@m1120-c4a14:/sys/kernel/debug/usb/ci_hdrc.3> cat qheads
EP=00: RX=0E12E000 TX=0E12E040
0000: 20408000 20408000
0001: 7B842040 7B842080
0002: 00000001 00000001
0003: 00008000 00008000
0004: 00000000 00000000
0005: 000005A1 000005C2
0006: 00000000 00000000
0007: 00000000 00000000
0008: 00000000 00000000
0009: 00000000 00000000
000A: 000E4321 00000000
000B: 00000000 00000000
Last 16 RXs and TXs Completed (Most Recent First):
RX[0]=7B842040 TX[0]=7B842080
RX[1]=7B842040 TX[1]=7B842080
RX[2]=7B842000 TX[2]=7B842080
RX[3]=7B842000 TX[3]=7B842080
RX[4]=7B842300 TX[4]=7B842080
RX[5]=7B842300 TX[5]=7B842080
RX[6]=7B842300 TX[6]=7B842300
RX[7]=7B842300 TX[7]=7B842300
RX[8]=7B842300 TX[8]=7B8422C0
RX[9]=7B842300 TX[9]=7B8422C0
RX[10]=7B842300 TX[10]=7B8422C0
RX[11]=7B842300 TX[11]=7B8422C0
RX[12]=7B842300 TX[12]=7B8422C0
RX[13]=7B842300 TX[13]=7B8422C0
RX[14]=7B842080 TX[14]=7B8422C0
RX[15]=7B842080 TX[15]=7B8422C0
EP=01: RX=0E12E080 TX=0E12E0C0
0000: 22000000 22000000
0001: 7B8420C0 7B842540
0002: 7B8425C0 00000001
0003: 05FE8080 00008000
0004: 08211EC0 2126BC64
0005: 082125EC 2126C362
0006: 08213000 2126D000
0007: 08214000 2126E000
0008: 08215000 2126F000
0009: 00000000 00000000
000A: 00000000 00000000
000B: 00000000 00000000
Last 16 RXs and TXs Completed (Most Recent First):
RX[0]=7B842580 TX[0]=7B842500
RX[1]=7B842140 TX[1]=7B842340
RX[2]=7B8421C0 TX[2]=7B8424C0
RX[3]=7B842240 TX[3]=7B842340
RX[4]=7B842200 TX[4]=7B8424C0
RX[5]=7B842300 TX[5]=7B842340
RX[6]=7B842480 TX[6]=7B8424C0
RX[7]=7B842180 TX[7]=7B842340
RX[8]=7B842040 TX[8]=7B8424C0
RX[9]=7B8425C0 TX[9]=7B842500
RX[10]=7B8420C0 TX[10]=7B842280
RX[11]=7B842580 TX[11]=7B842000
RX[12]=7B842140 TX[12]=7B842100
RX[13]=7B8421C0 TX[13]=7B842440
RX[14]=7B842240 TX[14]=7B842100
RX[15]=7B842200 TX[15]=7B842000
EP=02: RX=0E12E100 TX=0E12E140
0000: 00000000 20100000
0001: 00000000 7B8422C0
0002: 00000000 00000001
0003: 00000000 00008000
0004: 00000000 213A4090
0005: 00000000 213A5620
0006: 00000000 213A6000
0007: 00000000 213A7000
0008: 00000000 213A8000
0009: 00000000 00000000
000A: 00000000 00000000
000B: 00000000 00000000
Last 16 RXs and TXs Completed (Most Recent First):
RX[0]=00000000 TX[0]=7B8422C0
RX[1]=00000000 TX[1]=7B842040
RX[2]=00000000 TX[2]=7B8422C0
RX[3]=00000000 TX[3]=00000000
RX[4]=00000000 TX[4]=00000000
RX[5]=00000000 TX[5]=00000000
RX[6]=00000000 TX[6]=00000000
RX[7]=00000000 TX[7]=00000000
RX[8]=00000000 TX[8]=00000000
RX[9]=00000000 TX[9]=00000000
RX[10]=00000000 TX[10]=00000000
RX[11]=00000000 TX[11]=00000000
RX[12]=00000000 TX[12]=00000000
RX[13]=00000000 TX[13]=00000000
RX[14]=00000000 TX[14]=00000000
RX[15]=00000000 TX[15]=00000000
We believe the completion interrupt did happen but if you look at the ISR code, it does this in _hardware_dequeue() function:
[cid:image003.png@01DC83FC.8CBFF5A0]
It enters the if-body at line 756 because the first request is still active and returns immediately. Nuvoton hardware is not CI_REVISION_24. However, if it could call reprime_dtd(), the queue head pointer would be updated to point to this "missed" or "unfinished" request and retried.
Could you explain why CI_REVISION_24 need to call reprime_dtd() at line 761?
But since the queue head points to the end and the ISR just returns at line 763 but does not go into the if-body of line 760 and 761, the USB device TX is stalled. That request won't ever be fulfilled because the Queue head pointer has moved beyond that. It's at the tail.
Should we add this WA in line 759 with the version we use CI_REVISION_25?
Thanks,
Tomer
-----Original Message-----
From: Xu Yang <xu.yang_2@nxp.com<mailto:xu.yang_2@nxp.com>>
Sent: Tuesday, 2 December 2025 5:29
To: IS20 Tomer Maimon <tomer.maimon@nuvoton.com<mailto:tomer.maimon@nuvoton.com>>
Cc: Peter Chen (CIX) <peter.chen@kernel.org<mailto:peter.chen@kernel.org>>; IV00 Uri Trichter <Uri.Trichter@nuvoton.com<mailto:Uri.Trichter@nuvoton.com>>; IS20 Avi Fishman <Avi.Fishman@nuvoton.com<mailto:Avi.Fishman@nuvoton.com>>; linux-usb@vger.kernel.org<mailto:linux-usb@vger.kernel.org>
Subject: Re: Maintainer of ChipID
CAUTION - External Email: Do not click links or open attachments unless you acknowledge the sender and content.
On Mon, Dec 01, 2025 at 01:59:21PM +0000, tomer.maimon@nuvoton.com<mailto:tomer.maimon@nuvoton.com> wrote:
> Hi Peter,
>
> Thanks for your prompt reply.
>
> In rare cases, during RX transactions, the UDC driver receives an interrupt that is supposed to indicate the completion of a DMA receive operation and that the data is now available in memory. However, the ACTION (or ACTIVE) bit still indicates that the DMA transfer is ongoing.
Which interrupt? Do you mean USBSTS.UI? What about ENDPTCOMPLETE?
How do you sure that the dTD is still doing DMA transfer rather than has not start transfer yet? Do you know the contents before and after this dTD transfer?
> If the driver enters a loop waiting for this Active bit become zero and indicate the DAM action finish to the handler becomes stuck indefinitely..
> Are you familiar with this behavior?
What is the behavior of the host in this case?
>
> Besides the ACTIVE bit, are there any other status bits that reliably indicate the actual end of a DMA receive transaction?
Maybe no other status bit for DMA operation.
Thanks,
Xu Yang
>
> Thanks,
>
> Tomer
________________________________
The privileged confidential information contained in this email is intended for use only by the addressees as indicated by the original sender of this email. If you are not the addressee indicated in this email or are not responsible for delivery of the email to such a person, please kindly reply to the sender indicating this fact and delete all copies of it from your computer and network server immediately. Your cooperation is highly appreciated. It is advised that any unauthorized use of confidential information of Nuvoton is strictly prohibited; and any information in this email irrelevant to the official business of Nuvoton shall be deemed as neither given nor endorsed by Nuvoton.
________________________________
The privileged confidential information contained in this email is intended for use only by the addressees as indicated by the original sender of this email. If you are not the addressee indicated in this email or are not responsible for delivery of the email to such a person, please kindly reply to the sender indicating this fact and delete all copies of it from your computer and network server immediately. Your cooperation is highly appreciated. It is advised that any unauthorized use of confidential information of Nuvoton is strictly prohibited; and any information in this email irrelevant to the official business of Nuvoton shall be deemed as neither given nor endorsed by Nuvoton.
________________________________
The privileged confidential information contained in this email is intended for use only by the addressees as indicated by the original sender of this email. If you are not the addressee indicated in this email or are not responsible for delivery of the email to such a person, please kindly reply to the sender indicating this fact and delete all copies of it from your computer and network server immediately. Your cooperation is highly appreciated. It is advised that any unauthorized use of confidential information of Nuvoton is strictly prohibited; and any information in this email irrelevant to the official business of Nuvoton shall be deemed as neither given nor endorsed by Nuvoton.
________________________________
The privileged confidential information contained in this email is intended for use only by the addressees as indicated by the original sender of this email. If you are not the addressee indicated in this email or are not responsible for delivery of the email to such a person, please kindly reply to the sender indicating this fact and delete all copies of it from your computer and network server immediately. Your cooperation is highly appreciated. It is advised that any unauthorized use of confidential information of Nuvoton is strictly prohibited; and any information in this email irrelevant to the official business of Nuvoton shall be deemed as neither given nor endorsed by Nuvoton.
________________________________
The privileged confidential information contained in this email is intended for use only by the addressees as indicated by the original sender of this email. If you are not the addressee indicated in this email or are not responsible for delivery of the email to such a person, please kindly reply to the sender indicating this fact and delete all copies of it from your computer and network server immediately. Your cooperation is highly appreciated. It is advised that any unauthorized use of confidential information of Nuvoton is strictly prohibited; and any information in this email irrelevant to the official business of Nuvoton shall be deemed as neither given nor endorsed by Nuvoton.
________________________________
The privileged confidential information contained in this email is intended for use only by the addressees as indicated by the original sender of this email. If you are not the addressee indicated in this email or are not responsible for delivery of the email to such a person, please kindly reply to the sender indicating this fact and delete all copies of it from your computer and network server immediately. Your cooperation is highly appreciated. It is advised that any unauthorized use of confidential information of Nuvoton is strictly prohibited; and any information in this email irrelevant to the official business of Nuvoton shall be deemed as neither given nor endorsed by Nuvoton.
[-- Attachment #1.1.2: Type: text/html, Size: 200162 bytes --]
[-- Attachment #1.2: image001.png --]
[-- Type: image/png, Size: 143263 bytes --]
[-- Attachment #1.3: image002.png --]
[-- Type: image/png, Size: 184502 bytes --]
[-- Attachment #1.4: image003.png --]
[-- Type: image/png, Size: 249265 bytes --]
[-- Attachment #2: ddrstress.sh --]
[-- Type: application/octet-stream, Size: 2914 bytes --]
#!/bin/sh
# Local DDR/memory stress using dd — no SSH/SFTP.
# Run this on the BMC/device.
BASE_DIR="/var/wcs_home"
STRESS_DIR="ddr_stress"
LOG_DIR="/tmp/ddr_logs"
FILE_SIZE_MB=512 # 512 MB file (4M * 128)
BS=4M
COUNT=128 # 4M * 128 = 512M
mkdir -p "$STRESS_DIR" "$LOG_DIR"
echo "== Local DDR/memory stress =="
echo "Stress dir: $STRESS_DIR"
echo "File size: ${FILE_SIZE_MB}MB"
echo
#############################################
# THREAD 1 — repeatedly create big file
#############################################
(
LOGFILE="$LOG_DIR/thread1_write_$(date +%s).log"
echo "[Thread1] Starting write loop at $(date)" >> "$LOGFILE"
while true; do
TS=$(date +%s)
FILE="$STRESS_DIR/test-write-$TS.bin"
echo "[Thread1] $(date): dd if=/dev/zero of=$FILE bs=$BS count=$COUNT" >> "$LOGFILE"
dd if=/dev/zero of="$FILE" bs="$BS" count="$COUNT" >> "$LOGFILE" 2>&1
echo "[Thread1] $(date): sync + rm $FILE" >> "$LOGFILE"
sync
rm -f "$FILE"
done
) &
PID1=$!
#############################################
# THREAD 2 — repeatedly read file into /dev/null
# (creates one base file first, then loops reads)
#############################################
BASE_FILE="$STRESS_DIR/test-read-base.bin"
echo "[Main] Creating base read file $BASE_FILE (${FILE_SIZE_MB}MB)..."
dd if=/dev/zero of="$BASE_FILE" bs="$BS" count="$COUNT" >/dev/null 2>&1
sync
echo "[Main] Base read file created."
(
LOGFILE="$LOG_DIR/thread2_read_$(date +%s).log"
echo "[Thread2] Starting read loop at $(date)" >> "$LOGFILE"
while true; do
echo "[Thread2] $(date): dd if=$BASE_FILE of=/dev/null bs=$BS" >> "$LOGFILE"
dd if="$BASE_FILE" of=/dev/null bs="$BS" >> "$LOGFILE" 2>&1
done
) &
PID2=$!
#############################################
# THREAD 3 — copy + checksum loop
#############################################
(
LOGFILE="$LOG_DIR/thread3_copy_$(date +%s).log"
echo "[Thread3] Starting copy/checksum loop at $(date)" >> "$LOGFILE"
while true; do
TS=$(date +%s)
COPY_FILE="$STRESS_DIR/test-copy-$TS.bin"
echo "[Thread3] $(date): cp $BASE_FILE $COPY_FILE" >> "$LOGFILE"
cp "$BASE_FILE" "$COPY_FILE" >> "$LOGFILE" 2>&1
echo "[Thread3] $(date): md5sum $COPY_FILE" >> "$LOGFILE"
md5sum "$COPY_FILE" >> "$LOGFILE" 2>&1
echo "[Thread3] $(date): rm $COPY_FILE" >> "$LOGFILE"
rm -f "$COPY_FILE"
done
) &
PID3=$!
#############################################
# PRINT THREAD PIDs
#############################################
echo "DDR/memory stress threads started:"
echo " Thread1 PID = $PID1 (write 512MB, sync, delete)"
echo " Thread2 PID = $PID2 (read 512MB -> /dev/null)"
echo " Thread3 PID = $PID3 (copy + md5sum, delete)"
echo
echo "Logs in: $LOG_DIR"
echo
echo "To stop all threads:"
echo " kill $PID1 $PID2 $PID3"
echo
[-- Attachment #3: socstress_bmc.sh --]
[-- Type: application/octet-stream, Size: 1823 bytes --]
#!/bin/sh
TARGET="10.235.100.1"
LOGDIR="/tmp/pingstress"
mkdir -p "$LOGDIR"
echo "Starting multi-thread ping stress to $TARGET"
echo "Logs stored in $LOGDIR"
#############################################
# THREAD 1 — ping flood with max-sized packet
#############################################
(
LOGFILE="$LOGDIR/thread1_pingf_$(date +%s).log"
echo "[Thread1] Starting: ping -f -s 1472 $TARGET" >> "$LOGFILE"
while true; do
ping -i 0.01 -s 1472 "$TARGET" >> "$LOGFILE" 2>&1
echo "[Thread1] ping exited — restarting" >> "$LOGFILE"
sleep 1
done
) &
PID1=$!
#############################################
# THREAD 2 — adaptive ping (can be very fast!)
#############################################
(
LOGFILE="$LOGDIR/thread2_pingA_$(date +%s).log"
echo "[Thread2] Starting: ping -A $TARGET" >> "$LOGFILE"
while true; do
ping -A "$TARGET" >> "$LOGFILE" 2>&1
echo "[Thread2] ping exited — restarting" >> "$LOGFILE"
sleep 1
done
) &
PID2=$!
#############################################
# THREAD 3 — normal ping, max size, steady load
#############################################
(
LOGFILE="$LOGDIR/thread3_ping1472_$(date +%s).log"
echo "[Thread3] Starting: ping -s 1472 $TARGET" >> "$LOGFILE"
while true; do
ping -i 0.1 -s 1472 "$TARGET" >> "$LOGFILE" 2>&1
echo "[Thread3] ping exited — restarting" >> "$LOGFILE"
sleep 1
done
) &
PID3=$!
#############################################
# PRINT THREAD PIDs
#############################################
echo "Ping stress threads started:"
echo " Thread1 PID = $PID1 (ping -f 1472)"
echo " Thread2 PID = $PID2 (ping -A)"
echo " Thread3 PID = $PID3 (ping -s 1472)"
echo
echo "To stop all threads:"
echo " kill $PID1 $PID2 $PID3"
echo
[-- Attachment #4: socstress_soc.sh --]
[-- Type: application/octet-stream, Size: 1818 bytes --]
#!/bin/sh
TARGET="10.235.100.0"
LOGDIR="pingstress"
mkdir -p "$LOGDIR"
echo "Starting multi-thread ping stress to $TARGET"
echo "Logs stored in $LOGDIR"
#############################################
# THREAD 1 — ping flood with max-sized packet
#############################################
(
LOGFILE="$LOGDIR/thread1_pingf_$(date +%s).log"
echo "[Thread1] Starting: ping -f -s 1472 $TARGET" >> "$LOGFILE"
while true; do
ping -i 0.01 -s 1472 "$TARGET" >> "$LOGFILE" 2>&1
echo "[Thread1] ping exited — restarting" >> "$LOGFILE"
sleep 1
done
) &
PID1=$!
#############################################
# THREAD 2 — adaptive ping (can be very fast!)
#############################################
(
LOGFILE="$LOGDIR/thread2_pingA_$(date +%s).log"
echo "[Thread2] Starting: ping -A $TARGET" >> "$LOGFILE"
while true; do
ping -A "$TARGET" >> "$LOGFILE" 2>&1
echo "[Thread2] ping exited — restarting" >> "$LOGFILE"
sleep 1
done
) &
PID2=$!
#############################################
# THREAD 3 — normal ping, max size, steady load
#############################################
(
LOGFILE="$LOGDIR/thread3_ping1472_$(date +%s).log"
echo "[Thread3] Starting: ping -s 1472 $TARGET" >> "$LOGFILE"
while true; do
ping -i 0.1 -s 1472 "$TARGET" >> "$LOGFILE" 2>&1
echo "[Thread3] ping exited — restarting" >> "$LOGFILE"
sleep 1
done
) &
PID3=$!
#############################################
# PRINT THREAD PIDs
#############################################
echo "Ping stress threads started:"
echo " Thread1 PID = $PID1 (ping -f 1472)"
echo " Thread2 PID = $PID2 (ping -A)"
echo " Thread3 PID = $PID3 (ping -s 1472)"
echo
echo "To stop all threads:"
echo " kill $PID1 $PID2 $PID3"
echo
^ permalink raw reply [flat|nested] 6+ messages in thread![[-- Attachment #1.2: image001.png --] [-- Type: image/png, Size: 143263 bytes --]](../../JH0PR03MB7634172ADEB1F481EE34E51F8481A@JH0PR03MB7634.apcprd03.prod.outlook.com/1.2-image001.png){kind=link}
![[-- Attachment #1.3: image002.png --] [-- Type: image/png, Size: 184502 bytes --]](../../JH0PR03MB7634172ADEB1F481EE34E51F8481A@JH0PR03MB7634.apcprd03.prod.outlook.com/1.3-image002.png){kind=link}
![[-- Attachment #1.4: image003.png --] [-- Type: image/png, Size: 249265 bytes --]](../../JH0PR03MB7634172ADEB1F481EE34E51F8481A@JH0PR03MB7634.apcprd03.prod.outlook.com/1.4-image003.png){kind=link}