On Sunday 17 September 2006 9:59 pm, Aras Vaichas wrote:
> I'm using an at91rm9200 with Linux 2.6.16. Under some unusual circumstances, I
> can create a failure.
Can you reproduce this with 2.6.18-rc7? That newer driver code may
be usable as a straight backport.
> Here is what I do to create the failure:
>
> * the device has both a USB device and a USB host port
> * the device has its USB device port configured as an ethernet gadget
> (g_ether)
> * connect the USB host port to the USB device port, "loopback" style
> * ifconfig usb1 <some IP address>
> * FTP into the device via ethernet
... forcing it to bypass the direct route in the IP stack?
> * send the list "ls" command a few times and I get a crash like so:
>
> ----- SNIP -----
>
> /root # at91_ohci at91_ohci: OHCI Unrecoverable Error, disabled
> at91_ohci at91_ohci: HC died; cleaning up
Hmm, a no-symbols stack trace is not at all useful. But it does
seem like this is another case where the usbcore cleanup after a
hardware fault ("Unrecoverable Error" = UE) is broken.
Normally a UE indicates some sort of DMA error, which you should
of course not be seeing, ever. A better problem report would include
not just kernel symbols, but also CONFIG_USB_DEBUG would be set so
that some potentially-useful data would be syslogged.
> irq23: nobody cared
>
> Pid: 322, comm: in.ftpd
> CPU: 0
> pc : [<c0038af8>] lr : [<c0038c80>] Not tainted
> sp : c1f97f44 ip : c1f97f68 fp : c1f97f64
> r10: c1f97fb0 r9 : c01df4a0 r8 : c01e7040
> r7 : 0000000a r6 : c1f96000 r5 : c1f96000 r4 : 00000022
> r3 : 20000013 r2 : 00000002 r1 : 00000001 r0 : 00000001
> Flags: nzCv IRQs on FIQs on Mode SVC_32 Segment user
> Control: C000317F Table: 2165C000 DAC: 00000015
> Function entered at [<c001fc14>] from [<c001ea54>]
> r4 = C1F97EFC
> Function entered at [<c001e9e8>] from [<c001ed74>]
> r5 = 00000017 r4 = C01DF94C
> Function entered at [<c001ecf4>] from [<c001ee04>]
> r6 = 00000017 r5 = C1F96000 r4 = FFFFFFFF
> Function entered at [<c001edb0>] from [<c001d998>]
> Function entered at [<c0038ab4>] from [<c0038c80>]
> r8 = 00000000 r7 = 00000001 r6 = 00000001 r5 = C1F96000
> r4 = C1F96000
> Function entered at [<c0038c3c>] from [<c001eed4>]
> r4 = FFFFFFFF
> Function entered at [<c001edb0>] from [<c001dbac>]
> handlers:
> [<c01188a8>]
> irq23: nobody cared
>
> ... repeats until the watchdog kicks in and resets the board
>
> ----- SNIP -----
>
> The strange thing is that I can send files via FTP and change directories but
> the problem doesn't appear. Only when I send the list command.
Yes, odd. :)
- Dave
> If I don't config usb1, the problem won't happen. i.e. "#config usb1 down"
> stops the problem.
>
> Is this an actual problem, or am I doing something really silly? I can easily
> avoid the situation where this bug/problem/craziness occurs but I thought that
> I'd at least report it.
>
> Why am I doing this? It's for a Production test. A simple loopback cable
> allows
> me to test the physical hardware of both USB ports by connecting only one
> cable
> and looking for:
> A) creation of directory /sys/class/net/usb1, and
> B) if /sys/class/net/usb0/carrier == 1
>
> We currently use another device as a portable USB port tester, but Production
> would like it all self contained and to be field testable using an easy to
> obtain cable with built-in test software.
>
>
> regards,
>
> Aras Vaichas
>
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
