* OMAP2430: MUSB: Ethernet Gadget Issue
@ 2007-11-21 17:08 Hunter, Jon
2007-11-23 20:26 ` David Brownell
0 siblings, 1 reply; 14+ messages in thread
From: Hunter, Jon @ 2007-11-21 17:08 UTC (permalink / raw)
To: linux-omap-open-source
[-- Attachment #1: Type: text/plain, Size: 1597 bytes --]
All,
I am having an issue on the OMAP2430 with the Ethernet Gadget driver. I
have tried several different versions of the kernel and the problem
appears to still exist in 2.6.23 (using the Linux-2.6.23-omap1 patch).
Basically I have two applications running on the OMAP2430 SDP:
- the 1st application sends 1KB UDP packets using the g_ether driver
from my OMAP2430 SDP to a Linux Host PC (debian).
- the 2nd application on the OMAP2430 SDP receives 1KB UDP packets using
the g_ether driver from Linux Host PC (debian).
Please note that the application on the PC side is the exact same
application used on the OMAP. Hence, on the PC side there are also 2
applications running; one to send packets and one to receive.
When I run the applications one at a time, they will run all night and
all is well. However, when I run them at the same time the transfer will
stop after anywhere from a few secs to a few minutes. When the transfers
stop I observe the the MUSB driver is no longer generating interrupts
(viewing the /proc/interrupts). It appears to be some short of race
condition but I have not been able to track down exactly when things
stop.
I have observed that there has been a lot of activity with regard to the
MUSB driver but as of 2.6.23 this problem still exists.
I am attaching my test case if anyone would like to take a look.
Instructions for compiling and running are in the README.
I am curious if anyone has run into any similar issues. I am not
familiar with the USB driver and so let me know if you have any inputs.
Thanks
Jon
[-- Attachment #2: Makefile --]
[-- Type: application/octet-stream, Size: 2119 bytes --]
#TARGET_CC = arm_v6_vfp_le-gcc
TARGET_CC = arm-none-linux-gnueabi-gcc
HOST_CC = gcc
#TARGET_KERNEL_PATH =$(HOME)/workdir/omap/OMAPSW_Linux_8.19/src/linux/kernel_mv/2.6_kernel-arm11
TARGET_KERNEL_PATH =$(HOME)/workdir/omap/CSSD_Linux_12.9es2.0_ttm_2.0e/src/linux/kernel_org/2.6_kernel
INC_FILES =
SRC_FILES = udp-tx-test.c udp-rx-test.c
OBJ_FILES =
TARGET_DBG_CC_FLAGS = -g -DDEBUG -I$(TARGET_KERNEL_PATH)/include
HOST_DBG_CC_FLAGS = -g -DDEBUG
DBG_DIR = debug
DBG_OBJ_FILES = $(addprefix $(DBG_DIR)/,$(OBJ_FILES))
TARGET_REL_CC_FLAGS = -O3 -I$(TARGET_KERNEL_PATH)/include
HOST_REL_CC_FLAGS = -O3
REL_DIR = release
REL_OBJ_FILES = $(addprefix $(REL_DIR)/,$(OBJ_FILES))
.PHONY: debug release all
all: debug release
# -----------------------------
# ---- debug configuration ----
# -----------------------------
debug: $(DBG_DIR)/udp-tx-test.xARM $(DBG_DIR)/udp-tx-test.x86 $(DBG_DIR)/udp-rx-test.xARM $(DBG_DIR)/udp-rx-test.x86
$(DBG_DIR)/%.xARM: $(DBG_DIR)/%.oARM
$(TARGET_CC) $(TARGET_DBG_CC_FLAGS) -o $@ $<
$(DBG_DIR)/%.x86: $(DBG_DIR)/%.o86
$(HOST_CC) $(HOST_DBG_CC_FLAGS) -o $@ $<
$(DBG_DIR)/%.oARM: %.c
@mkdir -p $(DBG_DIR)
$(TARGET_CC) $(TARGET_DBG_CC_FLAGS) -o $@ -c $<
$(DBG_DIR)/%.o86: %.c
@mkdir -p $(DBG_DIR)
$(HOST_CC) $(HOST_DBG_CC_FLAGS) -o $@ -c $<
# -------------------------------
# ---- release configuration ----
# -------------------------------
release: $(REL_DIR)/udp-tx-test.xARM $(REL_DIR)/udp-tx-test.x86 $(REL_DIR)/udp-rx-test.xARM $(REL_DIR)/udp-rx-test.x86
$(REL_DIR)/%.xARM: $(REL_DIR)/%.oARM
$(TARGET_CC) $(TARGET_REL_CC_FLAGS) -o $@ $<
$(REL_DIR)/%.x86: $(REL_DIR)/%.o86
$(HOST_CC) $(HOST_REL_CC_FLAGS) -o $@ $<
$(REL_DIR)/%.oARM: %.c
@mkdir -p $(REL_DIR)
$(TARGET_CC) $(TARGET_REL_CC_FLAGS) -o $@ -c $<
$(REL_DIR)/%.o86: %.c
@mkdir -p $(REL_DIR)
$(HOST_CC) $(HOST_REL_CC_FLAGS) -o $@ -c $<
# ---------------
# ---- clean ----
# ---------------
.PHONY: cleandebug
cleandebug:
rm -rf $(DBG_DIR)
.PHONY: cleanrelease
cleanrelease:
rm -rf $(REL_DIR)
.PHONY: clean cleanall
clean: cleanall
cleanall: cleandebug cleanrelease
[-- Attachment #3: README --]
[-- Type: application/octet-stream, Size: 1658 bytes --]
Simple UDP Test Case
To compile the test case:
1) Edit the following definitions in the Makefile per your setup
TARGET_CC <-- defines ARM cross compiler you are using
TARGET_KERNEL_PATH <-- defines path to OMAP Linux kernel
2). Execute "make"
Make will generate the following files:
debug/udp-tx-test.xARM
debug/udp-tx-test.x86
debug/udp-rx-test.xARM
debug/udp-rx-test.x86
release/udp-tx-test.xARM
release/udp-tx-test.x86
release/udp-rx-test.xARM
release/udp-rx-test.x86
Where the *.x86 are executables for the Host and the *.xARM are the executables for the target
To run the test case:
1) Connect a USB cable between the OMAP2430 SDP (connector J11 - on VG5.0.1 board) and Host PC
2). On the Target, insert USB Ethernet Gadget driver and configure
# insmod g_ether
# ifconfig usb0 192.168.1.1 netmask 255.255.255.0
3). On the Host PC, configure USB Ethernet port
# ifconfig usb0 192.168.1.5
4). On the Target, start UDP receiver test
# ./release/udp-rx-test.xARM <port #>
Eg. ./release/udp-rx-test.xARM 2662
5). On the Host PC, start the UDP transmitter test (note the ip address and port number should match the target)
# ./release/udp-tx-test.x86 <ip addr> <port #>
Eg. ./release/udp-tx-test.x86 192.168.1.1 2662
6). On the Host PC, start the UDP receiver test
# ./release/udp-rx-test.x86 <port #>
Eg. ./release/udp-rx-test.x86 2662
7). On the target, start the UDP transmitter test (note the ip address and port number should match the target)
# ./release/udp-tx-test.xARM <ip addr> <port #>
Eg. ./release/udp-tx-test.xARM 192.168.1.5 2662
Note that a message will be displayed for every 100000 1KB packets sent/received.
[-- Attachment #4: udp-rx-test.c --]
[-- Type: application/octet-stream, Size: 2372 bytes --]
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <signal.h>
#define MAXBUFLEN 1024
int complete = 0;
void signal_handler(int sig)
{
complete = 1;
}
int main(int argc, char *argv[])
{
int sockfd;
unsigned int bufcnt;
unsigned int dropcnt;
unsigned int numbytes;
unsigned int totalbytes;
unsigned char bufidx;
unsigned char nextbufidx;
char buf[MAXBUFLEN];
struct sockaddr_in my_addr;
struct sockaddr_in their_addr;
socklen_t addr_len;
unsigned short port;
if(argc != 2)
{
printf("Usage: udp-rx-test <port>\n");
printf("Eg: udp-rx-test 2662\n");
exit(1);
}
// set callback function for Ctrl-C
signal(SIGINT, signal_handler);
port = (unsigned short)atoi(argv[1]);
if((sockfd = socket(AF_INET, SOCK_DGRAM, 0)) == -1)
{
printf("Error: Call to socket failed!\n");
exit(1);
}
my_addr.sin_family = AF_INET;
my_addr.sin_port = htons(port);
my_addr.sin_addr.s_addr = INADDR_ANY;
memset(my_addr.sin_zero, '\0', sizeof(my_addr.sin_zero));
if(bind(sockfd, (struct sockaddr *)&my_addr, sizeof(my_addr)) == -1)
{
printf("Error: Call to bind failed!\n");
exit(1);
}
printf("Socket opened. Listening for packets on port %d...\n", port);
addr_len = sizeof(their_addr);
bufcnt = 0;
dropcnt = 0;
totalbytes = 0;
nextbufidx = 0;
while(complete == 0)
{
numbytes = recvfrom(sockfd, buf, MAXBUFLEN, 0, (struct sockaddr *)&their_addr, &addr_len);
if(numbytes == -1)
{
printf("Error: Call to recvfrom failed!\n");
close(sockfd);
exit(1);
}
else
{
bufcnt++;
totalbytes += numbytes;
// check index value at start of buffer
bufidx = *buf;
if(bufidx != nextbufidx)
{
if(bufidx < nextbufidx)
dropcnt += (255-nextbufidx) + bufidx;
else
dropcnt += bufidx - nextbufidx;
}
if(bufidx == 255)
nextbufidx = 0;
else
nextbufidx = bufidx + 1;
}
if(bufcnt > 9999)
{
printf("Received %d packets, total bytes = %d, dropped packets = %d\n", bufcnt, totalbytes, dropcnt);
bufcnt = 0;
dropcnt = 0;
totalbytes = 0;
}
}
close(sockfd);
return 0;
}
[-- Attachment #5: udp-tx-test.c --]
[-- Type: application/octet-stream, Size: 1923 bytes --]
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <netdb.h>
#include <signal.h>
#define MAXBUFLEN 1024
int complete = 0;
void signal_handler(int sig)
{
complete = 1;
}
int main(int argc, char *argv[])
{
int sockfd;
unsigned int bufcnt;
unsigned int numbytes;
unsigned int totalbytes;
unsigned char bufidx;
char buf[MAXBUFLEN];
struct sockaddr_in their_addr;
char *their_ip;
unsigned short port;
if(argc != 3)
{
printf("Usage: udp-tx-test <dest ip addr> <port>\n");
printf("Eg: udp-tx-test 192.168.1.1 2662\n");
exit(1);
}
else
{
their_ip = argv[1];
port = (unsigned short)atoi(argv[2]);
}
// set callback function for Ctrl-C
signal(SIGINT, signal_handler);
if((sockfd = socket(PF_INET, SOCK_DGRAM, 0)) == -1)
{
printf("Error: Unable to open socket!\n");
exit(1);
}
their_addr.sin_family = AF_INET;
their_addr.sin_port = htons(port); // short, network byte order
if(inet_aton(their_ip, &(their_addr.sin_addr)) == 0)
{
printf("Error: Unable to convert ip address!\n");
}
memset(their_addr.sin_zero, '\0', sizeof(their_addr.sin_zero));
bufcnt = 0;
bufidx = 0;
totalbytes = 0;
while(complete == 0)
{
*buf = bufidx;
numbytes = sendto(sockfd, buf, MAXBUFLEN, 0, (struct sockaddr *)&their_addr, sizeof(struct sockaddr));
if(numbytes == -1)
{
printf("Error: Send message failed!\n");
close(sockfd);
exit(1);
}
else
{
if(bufidx == 255)
bufidx = 0;
else
bufidx++;
bufcnt++;
totalbytes += numbytes;
}
if(bufcnt > 99999)
{
printf("Sent %d packets, total bytes = %d\n", bufcnt, totalbytes);
bufcnt = 0;
totalbytes = 0;
}
}
close(sockfd);
return 0;
}
[-- Attachment #6: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: OMAP2430: MUSB: Ethernet Gadget Issue
2007-11-21 17:08 OMAP2430: MUSB: Ethernet Gadget Issue Hunter, Jon
@ 2007-11-23 20:26 ` David Brownell
2007-11-29 20:03 ` Foale, Jeff
2007-12-07 20:38 ` Hunter, Jon
0 siblings, 2 replies; 14+ messages in thread
From: David Brownell @ 2007-11-23 20:26 UTC (permalink / raw)
To: linux-omap-open-source
Your test scenario sounds not unlike the "run TTCP in both
directions" test, except that it uses UDP. The last time
I ran that test with the MUSB code was with DaVinci ... at
that time, it worked OK. That's older RTL than found in
the OMAP chips, and thus "different bugs".
Not entirely for kicks, it would be good to know whether
the use of TTCP vs your test program matters. TCP does
have some flow control, afster all!
On Wednesday 21 November 2007, Hunter, Jon wrote:
>
> When I run the applications one at a time, they will run all night and
> all is well. However, when I run them at the same time the transfer will
> stop after anywhere from a few secs to a few minutes. When the transfers
> stop I observe the the MUSB driver is no longer generating interrupts
> (viewing the /proc/interrupts). It appears to be some short of race
> condition but I have not been able to track down exactly when things
> stop.
A "cat /proc/driver/musb_hdrc" to see various state should
be informative.
- Dave
^ permalink raw reply [flat|nested] 14+ messages in thread
* RE: OMAP2430: MUSB: Ethernet Gadget Issue
2007-11-23 20:26 ` David Brownell
@ 2007-11-29 20:03 ` Foale, Jeff
2007-11-29 21:07 ` David Brownell
2007-12-07 20:55 ` Hunter, Jon
2007-12-07 20:38 ` Hunter, Jon
1 sibling, 2 replies; 14+ messages in thread
From: Foale, Jeff @ 2007-11-29 20:03 UTC (permalink / raw)
To: David Brownell, linux-omap-open-source
We discovered the root cause is that on the OMAP TX side, a DMA transfer
is initiated but never completes due to the completion interrupt never
happening.
We still do not know why the interrupt doesn't happen.
-----Original Message-----
From: linux-omap-open-source-bounces@linux.omap.com
[mailto:linux-omap-open-source-bounces@linux.omap.com] On Behalf Of
David Brownell
Sent: Friday, November 23, 2007 2:27 PM
To: linux-omap-open-source@linux.omap.com
Subject: Re: OMAP2430: MUSB: Ethernet Gadget Issue
Your test scenario sounds not unlike the "run TTCP in both
directions" test, except that it uses UDP. The last time
I ran that test with the MUSB code was with DaVinci ... at
that time, it worked OK. That's older RTL than found in
the OMAP chips, and thus "different bugs".
Not entirely for kicks, it would be good to know whether
the use of TTCP vs your test program matters. TCP does
have some flow control, afster all!
On Wednesday 21 November 2007, Hunter, Jon wrote:
>
> When I run the applications one at a time, they will run all night and
> all is well. However, when I run them at the same time the transfer
will
> stop after anywhere from a few secs to a few minutes. When the
transfers
> stop I observe the the MUSB driver is no longer generating interrupts
> (viewing the /proc/interrupts). It appears to be some short of race
> condition but I have not been able to track down exactly when things
> stop.
A "cat /proc/driver/musb_hdrc" to see various state should
be informative.
- Dave
_______________________________________________
Linux-omap-open-source mailing list
Linux-omap-open-source@linux.omap.com
http://linux.omap.com/mailman/listinfo/linux-omap-open-source
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: OMAP2430: MUSB: Ethernet Gadget Issue
2007-11-29 20:03 ` Foale, Jeff
@ 2007-11-29 21:07 ` David Brownell
2007-12-07 20:55 ` Hunter, Jon
1 sibling, 0 replies; 14+ messages in thread
From: David Brownell @ 2007-11-29 21:07 UTC (permalink / raw)
To: Foale, Jeff; +Cc: linux-omap-open-source
On Thursday 29 November 2007, Foale, Jeff wrote:
> We discovered the root cause is that on the OMAP TX side, a DMA transfer
> is initiated but never completes due to the completion interrupt never
> happening.
>
> We still do not know why the interrupt doesn't happen.
Curious. On DaVinci I observed similar problems ... at best,
documentation on the synchronization between DMA and rest of
the chip is incomplete, and in some cases the behavior seemed
more than a little bit confused.
Does that INVENTRA_DMA logic *really* need to be so different
from support for the two other DMA engines? Seeing three very
different chunks of DMA logic has always made me suspicious.
I don't want to believe that the DMA integration is so wildly
unconstrained that each silicon team *needed* incompatibility.
- Dave
> -----Original Message-----
> From: linux-omap-open-source-bounces@linux.omap.com
> [mailto:linux-omap-open-source-bounces@linux.omap.com] On Behalf Of
> David Brownell
> Sent: Friday, November 23, 2007 2:27 PM
> To: linux-omap-open-source@linux.omap.com
> Subject: Re: OMAP2430: MUSB: Ethernet Gadget Issue
>
> Your test scenario sounds not unlike the "run TTCP in both
> directions" test, except that it uses UDP. The last time
> I ran that test with the MUSB code was with DaVinci ... at
> that time, it worked OK. That's older RTL than found in
> the OMAP chips, and thus "different bugs".
>
> Not entirely for kicks, it would be good to know whether
> the use of TTCP vs your test program matters. TCP does
> have some flow control, afster all!
>
>
> On Wednesday 21 November 2007, Hunter, Jon wrote:
> >
> > When I run the applications one at a time, they will run all night and
> > all is well. However, when I run them at the same time the transfer
> will
> > stop after anywhere from a few secs to a few minutes. When the
> transfers
> > stop I observe the the MUSB driver is no longer generating interrupts
> > (viewing the /proc/interrupts). It appears to be some short of race
> > condition but I have not been able to track down exactly when things
> > stop.
>
> A "cat /proc/driver/musb_hdrc" to see various state should
> be informative.
>
> - Dave
>
>
^ permalink raw reply [flat|nested] 14+ messages in thread
* RE: OMAP2430: MUSB: Ethernet Gadget Issue
2007-11-29 20:03 ` Foale, Jeff
2007-11-29 21:07 ` David Brownell
@ 2007-12-07 20:55 ` Hunter, Jon
1 sibling, 0 replies; 14+ messages in thread
From: Hunter, Jon @ 2007-12-07 20:55 UTC (permalink / raw)
To: Foale, Jeff, David Brownell, linux-omap-open-source
> We discovered the root cause is that on the OMAP TX side, a
> DMA transfer
> is initiated but never completes due to the completion interrupt never
> happening.
>
> We still do not know why the interrupt doesn't happen.
Just to be clear, Jeff was able to track down the state the driver when
the failure occurs, but I would not say that we truly understand the
"root cause" of why the interrupt does not occur.
Jon
^ permalink raw reply [flat|nested] 14+ messages in thread
* RE: OMAP2430: MUSB: Ethernet Gadget Issue
2007-11-23 20:26 ` David Brownell
2007-11-29 20:03 ` Foale, Jeff
@ 2007-12-07 20:38 ` Hunter, Jon
2007-12-10 5:34 ` David Brownell
1 sibling, 1 reply; 14+ messages in thread
From: Hunter, Jon @ 2007-12-07 20:38 UTC (permalink / raw)
To: David Brownell, linux-omap-open-source
[-- Attachment #1: Type: text/plain, Size: 809 bytes --]
Hi Dave,
Thanks for the email. Sorry for the delay but I got tied up with other
problems, though this is still a problem!
> the use of TTCP vs your test program matters. TCP does
> have some flow control, afster all!
I wrote a similar test over the past few days to test TCP. I have found
that although it appears to take longer, it still ultimately fails at
some point. By fail, I mean that the transfers stop.
> A "cat /proc/driver/musb_hdrc" to see various state should
> be informative.
No probs. I have taken a cat of the above proc entry for both udp and
tcp case after the failure occurs. I am attaching the "dump" of the proc
entry for you to view. Let me know if you have any inputs on this. I am
not familiar enough to know how to interpret this info.
Cheers
Jon
[-- Attachment #2: musb_hdrc-tcp.txt --]
[-- Type: text/plain, Size: 869 bytes --]
Status: MHDRC, Mode=Peripheral (Power=f0, DevCtl=99)
OTG state: b_peripheral; active
Options: musb-dma, peripheral, debug=1 [eps=5]
Peripheral address: 19
Gadget driver: ether
ep0 (hw0): 1buf, csr 0000 maxp 0000
(queue empty)
ep1in (hw1): 1buf dma, csr b404 maxp 0200
req c1e74f60, zero, 0/1090
req c1e74a20, zero, 0/66
req c1d2a1e0, zero, 0/66
req c1e743a0, zero, 0/66
req c1e741a0, zero, 0/1514
req c1e74120, zero, 0/1514
req c1e74160, zero, 0/1514
req c1d2a1a0, zero, 0/1514
req c1e74c60, zero, 0/1514
req c1e743e0, zero, 0/1514
ep1out (hw1): 1buf dma, csr 2003 maxp 0200
req c1e747a0, 512/1536
req c1e746a0, 0/1536
req c1e74660, 0/1536
req c1e74fa0, 0/1536
req c1e742a0, 0/1536
req c1e745a0, 0/1536
req c1e74760, 0/1536
req c1e74220, 0/1536
req c1e74f20, 0/1536
req c1d2a7e0, 0/1536
ep2in (hw2): 1buf dma, csr 2004 maxp 0010
(queue empty)
[-- Attachment #3: musb_hdrc-udp.txt --]
[-- Type: text/plain, Size: 875 bytes --]
Status: MHDRC, Mode=Peripheral (Power=f0, DevCtl=99)
OTG state: b_peripheral; active
Options: musb-dma, peripheral, debug=1 [eps=5]
Peripheral address: 11
Gadget driver: ether
ep0 (hw0): 1buf, csr 0000 maxp 0000
(queue empty)
ep1in (hw1): 1buf dma, csr b404 maxp 0200
req c1e9a760, zero, 0/1066
req c1e9a720, zero, 0/1066
req c1e9afa0, zero, 0/1066
req c1e9a820, zero, 0/1066
req c1e9a7e0, zero, 0/1066
req c1e9a7a0, zero, 0/1066
req c1d1e5a0, zero, 0/1066
req c1d1e5e0, zero, 0/1066
req c1d1e560, zero, 0/1066
req c1e9a4e0, zero, 0/1066
ep1out (hw1): 1buf dma, csr 2003 maxp 0200
req c1e9a8e0, 512/1536
req c1e9a920, 0/1536
req c1e9a560, 0/1536
req c1e9a420, 0/1536
req c1e9a2a0, 0/1536
req c1e9a460, 0/1536
req c1e9a520, 0/1536
req c1e9a360, 0/1536
req c1e9a860, 0/1536
req c1e9a8a0, 0/1536
ep2in (hw2): 1buf dma, csr 2004 maxp 0010
(queue empty)
[-- Attachment #4: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: OMAP2430: MUSB: Ethernet Gadget Issue
2007-12-07 20:38 ` Hunter, Jon
@ 2007-12-10 5:34 ` David Brownell
2007-12-12 20:55 ` Hunter, Jon
2007-12-18 0:00 ` Hunter, Jon
0 siblings, 2 replies; 14+ messages in thread
From: David Brownell @ 2007-12-10 5:34 UTC (permalink / raw)
To: Hunter, Jon; +Cc: linux-omap-open-source
On Friday 07 December 2007, Hunter, Jon wrote:
> ep1in (hw1): 1buf dma, csr b404 maxp 0200
That's the same for both UDP and TCP cases:
8000 - AutoSet TxPktRdy after loading a complete packet
2000 - Mode TX (probably irrelevant here)
1000 - DMAReqEnab
0400 - DMAReqMode 1 (vs 0)
0004 - Underrun ... got IN packet with empty fifo
And the queues are sitting there with packets marked as
having transmitted no bits.
That underrun bit looks suspicious. ISTR having issues
with it before; it's stupid, there's basically no point
in the hardware even reporting such a routine case (no
sane driver could afford to care about it); it's only
there to cause trouble.
Understanding that the x430 uses Mentor's DMA engine
and that code has AFAIK not been stressed ... maybe it
has to learn more about how to ignore bogus faults.
I don't see signs of the 0080 Incomptx bit being set.
> ep1out (hw1): 1buf dma, csr 2003 maxp 0200
> req c1e9a8e0, 512/1536
Again, same for UDP and TCP.
0200 - DmaReqEnab (note gratuitous difference from TX side)
0002 - FifoFull
0001 - RxPktRdy
There what's odd is that nothing seems to have emptied the
FIFO. I've not looked at the Mentor DMA engine, but I'd kind
of hope that it's more sane than CPPI ... so that one could
let it offload entire IEEE 802 packets without needing to
wake up the CPU after each packet.
You did say the issue was on the TX side, not the RX side?
The "obvious problem" here is on the RX side, not TX...
- Dave
^ permalink raw reply [flat|nested] 14+ messages in thread
* RE: OMAP2430: MUSB: Ethernet Gadget Issue
2007-12-10 5:34 ` David Brownell
@ 2007-12-12 20:55 ` Hunter, Jon
2007-12-12 23:22 ` Hunter, Jon
2007-12-18 0:00 ` Hunter, Jon
1 sibling, 1 reply; 14+ messages in thread
From: Hunter, Jon @ 2007-12-12 20:55 UTC (permalink / raw)
To: David Brownell; +Cc: linux-omap-open-source
> You did say the issue was on the TX side, not the RX side?
> The "obvious problem" here is on the RX side, not TX...
Jeff said that he thought that issue was on the TX side, but I don't
have the knowledge to confirm that from my testing. So if you see
problems from the RX side then this is somewhere else for us to look.
Any thoughts on how we should be handling this overrun condition?
Thanks
Jon
^ permalink raw reply [flat|nested] 14+ messages in thread
* RE: OMAP2430: MUSB: Ethernet Gadget Issue
2007-12-10 5:34 ` David Brownell
2007-12-12 20:55 ` Hunter, Jon
@ 2007-12-18 0:00 ` Hunter, Jon
2007-12-18 1:05 ` Tony Lindgren
1 sibling, 1 reply; 14+ messages in thread
From: Hunter, Jon @ 2007-12-18 0:00 UTC (permalink / raw)
To: David Brownell; +Cc: linux-omap-open-source
> There what's odd is that nothing seems to have emptied the
> FIFO. I've not looked at the Mentor DMA engine, but I'd kind
> of hope that it's more sane than CPPI ... so that one could
> let it offload entire IEEE 802 packets without needing to
> wake up the CPU after each packet.
I do see from the driver that the Mentor DMA engine appears to have two
modes of operation, namely mode 0 and mode 1. When the DMA is configured
for Mode 0 then the DMA will only load/unload one packet at a time and
so the CPU will be interrupted for each packet. Whereas in Mode 1 the
DMA can load/unload all packets of the entire transfer. On the TX side
it appears to use Mode 1 and on the RX side it uses Mode 0. I did find
the following comment in the musb_gadget.c file:
/* We use DMA Req mode 0 in rx_csr, and DMA controller operates in
* mode 0 only. So we do not get endpoint interrupts due to DMA
* completion. We only get interrupts from DMA controller.
*
* We could operate in DMA mode 1 if we knew the size of the tranfer
* in advance. For mass storage class, request->length = what the host
* sends, so that'd work. But for pretty much everything else,
* request->length is routinely more than what the host sends. For
* most these gadgets, end of is signified either by a short packet,
* or filling the last byte of the buffer. (Sending extra data in
* that last pckate should trigger an overflow fault.) But in mode 1,
* we don't get DMA completion interrrupt for short packets.
*
* Theoretically, we could enable DMAReq irq (MUSB_RXCSR_DMAMODE = 1),
* to get endpoint interrupt on every DMA req, but that didn't seem
* to work reliably.
*
* REVISIT an updated g_file_storage can set req->short_not_ok, which
* then becomes usable as a runtime "use mode 1" hint...
*/
>From digging into this more, when the failure condition occurs, I see
that the DMA channels for both RX and TX are configured and enabled. The
strange thing is that neither DMA completes and so the driver is stuck
waiting for an interrupt from both the RX and the TX side. The DMA
registers do show that the DMA channels are configured to generate an
interrupt but the INTR (interrupt status register) for DMA controller
never shows an interrupt pending for either the RX or TX channel. It
seems that the DMA is setup correctly but never transfer the data.
Cheers
Jon
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: OMAP2430: MUSB: Ethernet Gadget Issue
2007-12-18 0:00 ` Hunter, Jon
@ 2007-12-18 1:05 ` Tony Lindgren
0 siblings, 0 replies; 14+ messages in thread
From: Tony Lindgren @ 2007-12-18 1:05 UTC (permalink / raw)
To: Hunter, Jon; +Cc: David Brownell, linux-omap-open-source
* Hunter, Jon <jon-hunter@ti.com> [071217 16:01]:
> > There what's odd is that nothing seems to have emptied the
> > FIFO. I've not looked at the Mentor DMA engine, but I'd kind
> > of hope that it's more sane than CPPI ... so that one could
> > let it offload entire IEEE 802 packets without needing to
> > wake up the CPU after each packet.
>
>
> I do see from the driver that the Mentor DMA engine appears to have two
> modes of operation, namely mode 0 and mode 1. When the DMA is configured
> for Mode 0 then the DMA will only load/unload one packet at a time and
> so the CPU will be interrupted for each packet. Whereas in Mode 1 the
> DMA can load/unload all packets of the entire transfer. On the TX side
> it appears to use Mode 1 and on the RX side it uses Mode 0. I did find
> the following comment in the musb_gadget.c file:
>
> /* We use DMA Req mode 0 in rx_csr, and DMA controller operates in
> * mode 0 only. So we do not get endpoint interrupts due to DMA
> * completion. We only get interrupts from DMA controller.
> *
> * We could operate in DMA mode 1 if we knew the size of the tranfer
> * in advance. For mass storage class, request->length = what the host
> * sends, so that'd work. But for pretty much everything else,
> * request->length is routinely more than what the host sends. For
> * most these gadgets, end of is signified either by a short packet,
> * or filling the last byte of the buffer. (Sending extra data in
> * that last pckate should trigger an overflow fault.) But in mode 1,
> * we don't get DMA completion interrrupt for short packets.
> *
> * Theoretically, we could enable DMAReq irq (MUSB_RXCSR_DMAMODE = 1),
> * to get endpoint interrupt on every DMA req, but that didn't seem
> * to work reliably.
> *
> * REVISIT an updated g_file_storage can set req->short_not_ok, which
> * then becomes usable as a runtime "use mode 1" hint...
> */
>
> >From digging into this more, when the failure condition occurs, I see
> that the DMA channels for both RX and TX are configured and enabled. The
> strange thing is that neither DMA completes and so the driver is stuck
> waiting for an interrupt from both the RX and the TX side. The DMA
> registers do show that the DMA channels are configured to generate an
> interrupt but the INTR (interrupt status register) for DMA controller
> never shows an interrupt pending for either the RX or TX channel. It
> seems that the DMA is setup correctly but never transfer the data.
The musb driver should be fixed to allow using mode 1 based on the fifo
interrupt. I never had much luck with mode 1 though on tusb :(
Tony
^ permalink raw reply [flat|nested] 14+ messages in thread
* RE: OMAP2430: MUSB: Ethernet Gadget Issue
@ 2007-12-05 22:10 Foale, Jeff
2007-12-06 16:17 ` David Brownell
0 siblings, 1 reply; 14+ messages in thread
From: Foale, Jeff @ 2007-12-05 22:10 UTC (permalink / raw)
To: David Brownell, linux-omap-open-source
I noticed some comments in the musb_gadget.c code:
/* REVISIT for high bandwidth, MUSB_TXCSR_P_INCOMPTX
* probably rates reporting as a host error
*/
The MUSB_TXCSR_P_INCOMPTX flag is set on the bad transfer. It seems to
not be handled correctly (at all).
Jeff
-----Original Message-----
From: Foale, Jeff
Sent: Thursday, November 29, 2007 2:04 PM
To: 'David Brownell'; linux-omap-open-source@linux.omap.com
Subject: RE: OMAP2430: MUSB: Ethernet Gadget Issue
We discovered the root cause is that on the OMAP TX side, a DMA transfer
is initiated but never completes due to the completion interrupt never
happening.
We still do not know why the interrupt doesn't happen.
-----Original Message-----
From: linux-omap-open-source-bounces@linux.omap.com
[mailto:linux-omap-open-source-bounces@linux.omap.com] On Behalf Of
David Brownell
Sent: Friday, November 23, 2007 2:27 PM
To: linux-omap-open-source@linux.omap.com
Subject: Re: OMAP2430: MUSB: Ethernet Gadget Issue
Your test scenario sounds not unlike the "run TTCP in both
directions" test, except that it uses UDP. The last time
I ran that test with the MUSB code was with DaVinci ... at
that time, it worked OK. That's older RTL than found in
the OMAP chips, and thus "different bugs".
Not entirely for kicks, it would be good to know whether
the use of TTCP vs your test program matters. TCP does
have some flow control, afster all!
On Wednesday 21 November 2007, Hunter, Jon wrote:
>
> When I run the applications one at a time, they will run all night and
> all is well. However, when I run them at the same time the transfer
will
> stop after anywhere from a few secs to a few minutes. When the
transfers
> stop I observe the the MUSB driver is no longer generating interrupts
> (viewing the /proc/interrupts). It appears to be some short of race
> condition but I have not been able to track down exactly when things
> stop.
A "cat /proc/driver/musb_hdrc" to see various state should
be informative.
- Dave
_______________________________________________
Linux-omap-open-source mailing list
Linux-omap-open-source@linux.omap.com
http://linux.omap.com/mailman/listinfo/linux-omap-open-source
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: OMAP2430: MUSB: Ethernet Gadget Issue
2007-12-05 22:10 Foale, Jeff
@ 2007-12-06 16:17 ` David Brownell
2007-12-07 20:55 ` Hunter, Jon
0 siblings, 1 reply; 14+ messages in thread
From: David Brownell @ 2007-12-06 16:17 UTC (permalink / raw)
To: Foale, Jeff; +Cc: linux-omap-open-source
On Wednesday 05 December 2007, Foale, Jeff wrote:
>
> I noticed some comments in the musb_gadget.c code:
>
> /* REVISIT for high bandwidth, MUSB_TXCSR_P_INCOMPTX
> * probably rates reporting as a host error
> */
> The MUSB_TXCSR_P_INCOMPTX flag is set on the bad transfer. It seems to
> not be handled correctly (at all).
So it's a silicon or RTL bug then? My generic MUSB docs say:
> > When the endpoint is being used for high-bandwidth Isochronous/Interrupt
> > transfers, this bit is set to indicate where a large packet has been split
> > into 2 or 3 packets for transmission but insufficient IN tokens have been
> > received to send all the parts. Note: In anything other than a high-
> > bandwidth transfer, this bit will always return 0.
Those endpoints aren't high bandwidth, or even ISO/INTR. And yet you
report that bit isn't set to zero ...
- Dave
^ permalink raw reply [flat|nested] 14+ messages in thread
* RE: OMAP2430: MUSB: Ethernet Gadget Issue
2007-12-06 16:17 ` David Brownell
@ 2007-12-07 20:55 ` Hunter, Jon
0 siblings, 0 replies; 14+ messages in thread
From: Hunter, Jon @ 2007-12-07 20:55 UTC (permalink / raw)
To: David Brownell, Foale, Jeff; +Cc: linux-omap-open-source
> So it's a silicon or RTL bug then? My generic MUSB docs say:
At this point I do not believe that we have enough evidence to say that
it is either a software or a hardware bug. However, if let me know if
you have any inputs on this.
As Jeff mentioned before we know that transfers stop because a interrupt
on the tx side from the DMA controller does not occur, but we still do
not know why and we are still trying to track down the root cause.
Cheers
Jon
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2007-12-18 1:05 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-11-21 17:08 OMAP2430: MUSB: Ethernet Gadget Issue Hunter, Jon
2007-11-23 20:26 ` David Brownell
2007-11-29 20:03 ` Foale, Jeff
2007-11-29 21:07 ` David Brownell
2007-12-07 20:55 ` Hunter, Jon
2007-12-07 20:38 ` Hunter, Jon
2007-12-10 5:34 ` David Brownell
2007-12-12 20:55 ` Hunter, Jon
2007-12-12 23:22 ` Hunter, Jon
2007-12-18 0:00 ` Hunter, Jon
2007-12-18 1:05 ` Tony Lindgren
-- strict thread matches above, loose matches on Subject: below --
2007-12-05 22:10 Foale, Jeff
2007-12-06 16:17 ` David Brownell
2007-12-07 20:55 ` Hunter, Jon
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox