Closed strongly-typed closed 8 years ago
popcornmix
commented
9 years ago Some info: https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=39567 https://www.raspberrypi.org/forums/viewtopic.php?f=66&t=34557
Seems to be a bug with the hardware/driver writing beyond the end of the buffer.
ping @P33M
P33M
commented
9 years ago The driver for the hardware is broken. Devices using this chipset are few and far between, as there are superior devices available from SMSC and ASIX.
The chipset itself is registering as a full-speed device (max 12mbit/s, including overhead) which is a severe constraint to ethernet throughput.
It'd be easier and simpler to just buy a high-speed adapter that can do fast ethernet.
strongly-typed
commented
9 years ago Thanks for clarifying. The 12 MBit USB 1.1 is no problem for my application.
If the driver is broken, the issue is known and no effort is made to fix these problems, this broken and useless driver should be removed from the kernel tree, asap.
popcornmix
commented
9 years ago That would be better reported upstream: https://www.kernel.org/pub/linux/docs/lkml/reporting-bugs.html
OmgImAlexis
commented
9 years ago Any updates on this?
strongly-typed
commented
9 years ago I'm still able to reproduce this bug with
Linux raspberrypi 4.1.10-v7+ #821 SMP PREEMPT Sat Oct 10 00:16:28 BST 2015 armv7l GNU/Linux
[ 240.955434] ------------[ cut here ]------------
[ 240.961501] kernel BUG at net/core/skbuff.c:102!
[ 240.967571] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARMHowever, I did not yet reported the bug upstream. I may do this today.
strongly-typed
commented
9 years ago Actually, the device works with OpenWRT without oopsing with
Linux OpenWrt 4.1.10 #12 Thu Oct 22 18:30:56 CEST 2015 mips GNU/Linuxon TPLink WR703
root@OpenWrt:/tmp# cat /proc/cpuinfo
system type : Atheros AR9330 rev 1
machine : TP-LINK TL-WR703N v1
processor : 0
cpu model : MIPS 24Kc V7.4
BogoMIPS : 265.42
wait instruction : yes
microsecond timers : yes
tlb_entries : 16
extra interrupt vector : yes
hardware watchpoint : yes, count: 4, address/irw mask: [0x0ffc, 0x0ffc, 0x0ffb, 0x0ffb]
isa : mips1 mips2 mips32r1 mips32r2
ASEs implemented : mips16
shadow register sets : 1
kscratch registers : 0
package : 0
core : 0
VCED exceptions : not available
VCEI exceptions : not available
root@OpenWrt:/tmp# wget -O - http://cachefly.cachefly.net/100mb.test | md5sum
Connecting to cachefly.cachefly.net (205.234.175.175:80)
- 18% |***** | 19317k 0:01:51 ETA[ 1700.380400] usb 1-1: unexpected tiny rx frame
[ 1700.803401] usb 1-1: unexpected tiny rx frame
- 19% |****** | 20095k 0:01:50 ETA[ 1701.356400] usb 1-1: unexpected tiny rx frame
[ 1701.810399] usb 1-1: unexpected tiny rx frame
- 20% |****** | 20863k 0:01:49 ETA[ 1702.395401] usb 1-1: unexpected tiny rx frame
[ 1702.454399] usb 1-1: unexpected tiny rx frame
[ 1702.512420] usb 1-1: unexpected tiny rx frame
[ 1702.714398] usb 1-1: unexpected tiny rx frame
[ 1702.932399] usb 1-1: unexpected tiny rx frame
[ 1702.936377] usb 1-1: unexpected tiny rx frame
[ 1703.279401] usb 1-1: unexpected tiny rx frame
- 21% |****** | 21625k 0:01:48 ETA[ 1703.716399] usb 1-1: unexpected tiny rx frame
[ 1703.800400] usb 1-1: unexpected tiny rx frame
- 23% |******* | 24549k 0:01:44 ETA[ 1707.939400] usb 1-1: unexpected tiny rx frame
[ 1707.962410] usb 1-1: unexpected tiny rx frame
- 24% |******* | 24899k 0:01:45 ETA[ 1709.004399] usb 1-1: unexpected tiny rx frame
- 25% |******* | 25678k 0:01:44 ETA[ 1709.710421] usb 1-1: unexpected tiny rx frame
[ 1710.323409] usb 1-1: unexpected tiny rx frame
- 25% |******** | 26443k 0:01:43 ETA[ 1710.572399] usb 1-1: unexpected tiny rx frame
[ 1710.962401] usb 1-1: unexpected tiny rx frame
[ 1711.334399] usb 1-1: unexpected tiny rx frame
- 26% |******** | 27221k 0:01:42 ETA[ 1712.006414] usb 1-1: unexpected tiny rx frame
- 27% |******** | 28011k 0:01:40 ETA[ 1712.584400] usb 1-1: unexpected tiny rx frame
- 28% |******** | 28783k 0:01:39 ETA[ 1714.334400] usb 1-1: unexpected tiny rx frame
- 29% |********* | 30326k 0:01:37 ETA[ 1716.017409] usb 1-1: unexpected tiny rx frame
- 30% |********* | 31104k 0:01:36 ETA[ 1716.614420] usb 1-1: unexpected tiny rx frame
[ 1716.959400] usb 1-1: unexpected tiny rx frame
- 31% |********* | 32666k 0:01:33 ETA[ 1718.946400] usb 1-1: unexpected tiny rx frame
- 32% |********** | 33444k 0:01:32 ETA[ 1720.212400] usb 1-1: unexpected tiny rx frame
- 33% |********** | 34229k 0:01:31 ETA[ 1720.617409] usb 1-1: unexpected tiny rx frame
[ 1721.138400] usb 1-1: unexpected tiny rx frame
[ 1721.269399] usb 1-1: unexpected tiny rx frame
- 34% |********** | 34998k 0:01:30 ETA[ 1721.621400] usb 1-1: unexpected tiny rx frame
- 34% |********** | 35782k 0:01:29 ETA[ 1722.947402] usb 1-1: unexpected tiny rx frame
- 36% |*********** | 37160k 0:01:27 ETA[ 1724.633406] usb 1-1: unexpected tiny rx frame
- 39% |************ | 40271k 0:01:23 ETA[ 1728.641400] usb 1-1: unexpected tiny rx frame
[ 1728.983400] usb 1-1: unexpected tiny rx frame
[ 1729.340398] usb 1-1: unexpected tiny rx frame
- 40% |************ | 41033k 0:01:22 ETA[ 1729.981399] usb 1-1: unexpected tiny rx frame
- 40% |************ | 41822k 0:01:21 ETA[ 1730.397408] usb 1-1: unexpected tiny rx frame
[ 1730.488410] usb 1-1: unexpected tiny rx frame
[ 1730.498411] usb 1-1: unexpected tiny rx frame
- 41% |************ | 42402k 0:01:20 ETA[ 1731.515401] usb 1-1: unexpected tiny rx frame
- 42% |************* | 43197k 0:01:19 ETA[ 1732.525399] usb 1-1: unexpected tiny rx frame
[ 1732.640414] usb 1-1: unexpected tiny rx frame
- 42% |************* | 43972k 0:01:18 ETA[ 1733.662436] usb 1-1: unexpected tiny rx frame
[ 1734.040407] usb 1-1: unexpected tiny rx frame
- 43% |************* | 44754k 0:01:17 ETA[ 1734.527402] usb 1-1: unexpected tiny rx frame
- 45% |************* | 46094k 0:01:15 ETA[ 1736.641415] usb 1-1: unexpected tiny rx frame
- 47% |************** | 48247k 0:01:12 ETA[ 1740.019400] usb 1-1: unexpected tiny rx frame
- 56% |***************** | 57619k 0:01:00 ETA[ 1752.718401] usb 1-1: unexpected tiny rx frame
- 57% |***************** | 58386k 0:00:59 ETA[ 1753.819407] usb 1-1: unexpected tiny rx frame
- 57% |***************** | 59159k 0:00:58 ETA[ 1754.740421] usb 1-1: unexpected tiny rx frame
[ 1754.813400] usb 1-1: unexpected tiny rx frame
- 59% |****************** | 60710k 0:00:56 ETA[ 1756.820411] usb 1-1: unexpected tiny rx frame
- 60% |****************** | 61488k 0:00:55 ETA[ 1757.668399] usb 1-1: unexpected tiny rx frame
- 60% |****************** | 62266k 0:00:54 ETA[ 1758.672420] usb 1-1: unexpected tiny rx frame
[ 1758.714400] usb 1-1: unexpected tiny rx frame
[ 1758.720393] usb 1-1: unexpected tiny rx frame
[ 1759.043400] usb 1-1: unexpected tiny rx frame
- 61% |******************* | 63042k 0:00:53 ETA[ 1760.060399] usb 1-1: unexpected tiny rx frame
- 62% |******************* | 63826k 0:00:51 ETA[ 1761.050399] usb 1-1: unexpected tiny rx frame
- 63% |******************* | 64598k 0:00:50 ETA[ 1761.651399] usb 1-1: unexpected tiny rx frame
- 63% |******************* | 65367k 0:00:49 ETA[ 1762.651400] usb 1-1: unexpected tiny rx frame
[ 1763.051400] usb 1-1: unexpected tiny rx frame
- 65% |******************** | 66901k 0:00:47 ETA[ 1764.645400] usb 1-1: unexpected tiny rx frame
[ 1764.666407] usb 1-1: unexpected tiny rx frame
[ 1765.261402] usb 1-1: unexpected tiny rx frame
- 70% |********************* | 72040k 0:00:40 ETA[ 1771.889402] usb 1-1: unexpected tiny rx frame
- 72% |********************** | 74078k 0:00:38 ETA[ 1774.912431] usb 1-1: unexpected tiny rx frame
- 75% |*********************** | 76982k 0:00:34 ETA[ 1778.927402] usb 1-1: unexpected tiny rx frame
- 79% |************************ | 81141k 0:00:28 ETA[ 1784.809400] usb 1-1: unexpected tiny rx frame
- 80% |************************* | 82711k 0:00:26 ETA[ 1786.807402] usb 1-1: unexpected tiny rx frame
- 83% |************************* | 85843k 0:00:22 ETA[ 1790.825401] usb 1-1: unexpected tiny rx frame
- 84% |************************** | 86620k 0:00:21 ETA[ 1791.833401] usb 1-1: unexpected tiny rx frame
- 86% |************************** | 88950k 0:00:18 ETA[ 1794.818401] usb 1-1: unexpected tiny rx frame
- 89% |*************************** | 92098k 0:00:13 ETA[ 1798.837419] usb 1-1: unexpected tiny rx frame
- 92% |**************************** | 94437k 0:00:10 ETA[ 1802.981401] usb 1-1: unexpected tiny rx frame
- 100% |*******************************| 100M 0:00:00 ETA
9b5183f05b62ca114c467945467050be - The md5sum is correct.
OmgImAlexis
commented
9 years ago @strongly-typed are they using a patched version of the kernel?
strongly-typed
commented
9 years ago OpenWRT uses a lot of patches, but I was not able to spot one for the DM9601 driver
https://dev.openwrt.org/browser/trunk/target/linux/ar71xx/patches-4.1
https://dev.openwrt.org/browser/trunk/target/linux/ar71xx/files/arch/mips/ath79To me, it seems that the stock version of the module is compiled.
strongly-typed
commented
8 years ago The maintainer Peter (....@sunsite.dk) is not reachable by mail
delivery temporarily suspended: lost connection withI reported the kernel crash to the Linux netdev mailing list [1] but did not receive any response until now. So I do not think this issue will get any attention by the Linux kernel developers.
IvanExpert
commented
8 years ago Even though it sounds like fixing this needs to happen upstream, I thought I'd mention that I'm seeing failure (unsurprisingly, given the above) with this chipset on a Raspberry Pi Zero using the current Jessie image, though with slightly different symptoms. I was hoping to use a single OTG USB hub + Ethernet adapter as the perfect companion, and I found this one: http://www.amazon.com/gp/product/B016ERI1JY
It uses the DM9601 chipset for the Ethernet. It doesn't work. The interface shows up, but it never receives an IP address, and there's a pages and pages of this from dmesg:
[ 282.195687] dm9601 1-1.2:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0xFFFF [ 282.212272] dm9601 1-1.2:1.0 eth0: kevent 11 may have been dropped [ 282.301127] dm9601 1-1.2:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0xFFFF [ 287.140890] dm9601 1-1.2:1.0 eth0: kevent 4 may have been dropped [ 287.142852] dm9601 1-1.2:1.0 eth0: kevent 4 may have been dropped [ 287.152886] dm9601 1-1.2:1.0 eth0: kevent 4 may have been dropped [ 287.183960] dm9601 1-1.2:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0xFFFF [ 287.289712] dm9601 1-1.2:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0xFFFF
I tried a 2.1A power adapter but no improvement.
DonHege
commented
8 years ago I'm experiencing the same issue. Ping, SSH etc. works, but apt-get update causes a Kernel panic. So a fix would be highly appreciated. ;)
Tried it with Raspberry Pi Zero, lastest Debian and a Micro-USB-Ethernet-Adapter labeled as "High Speed USB 2.0 to 10/100 Mbps RJ45 LAN", product code: "SKU154626".
mw9
commented
8 years ago @popcornmix You commented:
Seems to be a bug with the hardware/driver writing beyond the end of the buffer.
It seems to me that the dwc_otg driver is implicated in this.
When I made an experimental switch from the dwc_otg driver to the dwc2 driver (in host mode) the kernel 'Oops' was replaced by kernel log lines of the the following nature:
[ 336.364148] dwc2 20980000.usb: dwc2_update_urb_state(): trimming xfer length
[ 337.366541] dwc2 20980000.usb: dwc2_update_urb_state(): trimming xfer length
[ 344.851911] dwc2 20980000.usb: dwc2_update_urb_state(): trimming xfer lengthThe story seems to be this:
The dm9601 driver expects to receive a single encapsulated ethernet frame from the device in one URB transfer, and it provides an URB buffer of length 1,522 to receive it. This is not a round multiple of USB transfer packets.
The device in question [1] provides a stream of such frames and it does not conveniently slice them up as the dm9601 driver expects. We can end up with 1,536 (0x600) bytes returned by the device in response to the URB request. This may include several encapsulated ethernet frames, and/or fragments thereof.
It seems to me that the kernel 'Oops' arises because the dwc_otg driver does not notice that the destination buffer is too small to receive the full 1,536 bytes. Comparing dwc_otg's update_urb_state_xfer_comp with dwc2's dwc2_update_urb_state is suggestive.
https://github.com/raspberrypi/linux/blob/d2b2388d05d8a97b0ba14fcf2b71f19f66bc4d02/drivers/usb/host/dwc_otg/dwc_otg_hcd_intr.c#L739 https://github.com/raspberrypi/linux/blob/d2b2388d05d8a97b0ba14fcf2b71f19f66bc4d02/drivers/usb/dwc2/hcd_intr.c#L460
[1] ID 0fe6:9700 Kontron (Industrial Computer Source / ICS Advent) DM9601 Fast Ethernet Adapter
popcornmix
commented
8 years ago ping @P33M
campag
commented
8 years ago @popcornmix Rebuilding the kernel with those lines alluded to by @mw9 does appear to work (I commented out the log message to get it to compile). I can't immediately see how to fix the log line, but no doubt someone who is familiar with the code could fix this in dwc_otg rather than upstream on the dm9601 side as reported in #1207.
Edited to add: I think @6by9 has one of these ridiculously cheap 3-port usb2.0 hub inc usb1.1 dm9601 ethernet devices if you need hardware to test.
6by9
commented
8 years ago I do have a couple of these hubs/LAN adapters if Pi Towers don't already have some. @campag Can you add your diff just to save me a few minutes, and I'll rebuild a kernel to see what's going on. A PR with a fix is easier to deal with than having to hack through a hypothesis.
campag
commented
8 years ago Sure @6by9, with this I have success with the DM9601 hub/LAN on my RPi2. Lines copied straight from dwc2 hcd_initr.c as referenced above. No panics when I do an apt-get, large downloads etc.
--- /home/pi/dwc_otg_hcd_intr.c 2016-02-11 17:27:05.191326624 +0000
+++ linux/drivers/usb/host/dwc_otg/dwc_otg_hcd_intr.c 2016-02-11 17:21:21.143342785 +0000
@@ -737,6 +737,11 @@
DWC_OTG_HC_XFER_COMPLETE,
&short_read);
+ if (urb->actual_length + xfer_length > urb->length) {
+ /* dev_warn(hsotg->dev, "%s(): trimming xfer length\n", __func__);*/
+ xfer_length = urb->length - urb->actual_length;
+ }
+
/* non DWORD-aligned buffer case handling. */
if (hc->align_buff && xfer_length && hc->ep_is_in) {
dwc_memcpy(urb->buf + urb->actual_length, hc->qh->dw_align_buf,@campag I think there may be other places within the dwc_otg driver that would also need this treatment. Perhaps I should refile the dwc_otg issue under a more appropriate heading.
As far as the specific device is concerned, I would think the real solution is to create a modified driver that handles the device properly. I have a rough draft of that which I will endeavour to make available in some form.
I have two of these things, which were also ridiculously cheap, and despite their considerable shortcomings could work well enough with the Pi Zero in some circumstances.
Shortcomings include: USB 1.1, despite marketing as USB 2. So slow transfer speeds. Don't seem to carry out on chip CRC checking. Don't seem to carry out filtering, so it's promiscuous mode if you want to participate in multicast. Don't support MII interface, so existing drivers get lied to. No EPROM, so they all have the same MAC address. So need to manually set if you have more than one on your network. One of the devices seems to have a magnetics chip on board, the other (RD9700) seems to eschew such an arrangement.
Etc.
Oh, and all chips nicely sanded off, so no markings discernible.
campag
commented
8 years ago @mw9 with those patches you hinted at (thanks!), I've spent this evening surfing & downloading - the $4/£3 device seems quite usable there. In that time I've seen these in the kernel log:
[43757.720292] dm9601 1-1.5.2:1.0 eth1: kevent 4 may have been dropped
[43757.750845] dm9601 1-1.5.2:1.0 eth1: link up, 100Mbps, full-duplex, lpa 0xFFFF
[43757.854206] dm9601 1-1.5.2:1.0 eth1: link up, 100Mbps, full-duplex, lpa 0xFFFF
[44204.429655] usb 1-1.5.2: unexpected tiny rx frame@campag I haven't hinted at any patch, yet ! When I do, it won't apply to dwc_otg, but it will prevent unexpected tiny rx frame. The dropped kevents may remain.
I've been a bit busy over the last three/four weeks, otherwise I would have already posted.
6by9
commented
8 years ago dwc_otg seems to be a Pi only driver (at least it's not upstreamed), so if there are issues then it is up to Pi Towers and the community to fix. I'd say you have found a genuine issue there that needs fixing as it could hit almost any USB device driver that uses it as the transport layer.
Creating a new driver that works around the shortcomings of these specific USB devices (and that is quite a list!) would be nice, but I don't see how that new driver can work around the dwc_otg issue without just overallocating the packet buffer to be a multiple of the URB size.
@campag DWC_WARN("%s(): trimming xfer length\n", __func__); should give you the warning message. It is ugly as it is still using printk directly, but that seems to be how the whole driver is set up to do logging.
popcornmix
commented
8 years ago I've no objection to adding the patch in https://github.com/raspberrypi/linux/issues/1045#issuecomment-182999937 to dwc_otg driver. From @P33M
It is however a broken driver that's not allocating enough space and then either lying that it wants a URB of size N or failing to take into account the device may occasionally return more data than it thinks it's asked for.
So really the DM9601 device/driver should be fixed, but avoiding a crash when being given malformed data is good, so I'll add the patch to next kernel update.
mw9
commented
8 years ago @popcornmix @campag
There is at least one other location that would need the same treatment, I think. Compare also:
https://github.com/raspberrypi/linux/blob/d2b2388d05d8a97b0ba14fcf2b71f19f66bc4d02/drivers/usb/dwc2/hcd_intr.c#L1137 https://github.com/raspberrypi/linux/blob/d2b2388d05d8a97b0ba14fcf2b71f19f66bc4d02/drivers/usb/host/dwc_otg/dwc_otg_hcd_intr.c#L1418
There are other points at which get_actual_xfer_length is called. Figuring out if similar precautions are warranted in those cases is beyond beyond my pay grade.
popcornmix
commented
8 years ago I've added second "trim" to rpi-4.4.y tree: https://github.com/raspberrypi/linux/commit/52d3149aba3c684db1b6c739ca794dc330d92929 If no problems reported will add to rpi-4.1.y soon.
popcornmix
commented
8 years ago The trims have been added to both normal and BRANCH=next rpi-update firmware. I suspect you will get dmesg warnings with DM9601, but does it fix the hangs?
mw9
commented
8 years ago Hangs are fixed:
Feb 13 17:50:01 raspberrypi kernel: [ 728.099408] WARN::update_urb_state_xfer_comp:741: update_urb_state_xfer_comp(): trimming xfer length
Feb 13 17:50:01 raspberrypi kernel: [ 728.099408]
Feb 13 17:50:01 raspberrypi kernel: [ 728.800010] WARN::update_urb_state_xfer_comp:741: update_urb_state_xfer_comp(): trimming xfer length
Feb 13 17:50:01 raspberrypi kernel: [ 728.800010]
Feb 13 17:50:01 raspberrypi kernel: [ 728.862762] WARN::update_urb_state_xfer_comp:741: update_urb_state_xfer_comp(): trimming xfer length
Feb 13 17:50:01 raspberrypi kernel: [ 728.862762]
Feb 13 17:50:01 raspberrypi kernel: [ 728.919271] WARN::update_urb_state_xfer_comp:741: update_urb_state_xfer_comp(): trimming xfer length
Feb 13 17:50:01 raspberrypi kernel: [ 728.919271] I don't see where the extra blank lines come from, perhaps something to do with how DWC_WARN operates.
No dm9601 dmesg warnings on this occasion, but that is likely to be a quirk of particular packet lengths present during the test.
The driver:
The 'correct' driver to use is the sr9700 driver, not the dm9601 driver. It appears to have been submitted by the manufacture. [https://lkml.org/lkml/2013/8/20/241]
sr9700 is based on dm9601 but handles the stream of frames that USB device ID 0fe6:9700 delivers. In other respects it is fundamentally the same as dm9601, so I suppose that the device manufacturer, Corechip Technology Shenzhen Co., chose to support the Davicom chip command set (at least to some extent). The buffer size is, unsurprisingly, a multiple of URB size. I would suppose that the overallocation wastage is unlikely to be of much consequence in such a slow device.
I assume that the author of dm9601 was unaware of the frame streaming feature when that driver was changed to claim USB 0fe6:9700. The dm9601 driver will simply silently drop frames when large transfers are in progress, and occasionally log unexpected tiny rx frame messages.
So it should be a simple matter of blacklisting dm9601, and allowing sr9700 to operate instead. Unfortunately sr9700 breaks at the first hurdle, through what appears to have been a simple typographical error in the code. This is easily fixed.
Perhaps the manufacturer's original chip would work without the fix, but the clones I have don't. Anyway, no one would have noticed because the dm9601 driver is run instead of the sr9700 driver (I assume an alphabetical preference somewhere, perhaps in udev).
So where to go from here ?
a) Assemble patches and submit them, and hope to get them accepted in due course.
b) In the meantime, would there be any mileage in including a fixed up 'son of sr9700' driver, named, say, 'clone9700', in the Rpi tree until such time as the upstream issues are fixed ?
popcornmix
commented
8 years ago We really don't want to handle bug fixes in upstream code here. If there are upstream bugs then please submit fixes upstream. Assuming they are accepted we can cherry-pick them early (knowing they have been peer reviewed and will disappear with a future upstream bump).
campag
commented
8 years ago @popcornmix all working well, but the kernel log gets spammed frequently by the current log message, which itself is not fully informative. I propose:
--- dwc_otg_hcd_intr.c 2016-02-16 11:29:14.618359617 +0000
+++ linux/drivers/usb/host/dwc_otg/dwc_otg_hcd_intr.c 2016-02-17 08:05:47.762555196 +0000
@@ -738,7 +738,8 @@
&short_read);
if (urb->actual_length + xfer_length > urb->length) {
- DWC_WARN("%s(): trimming xfer length\n", __func__);
+ printk_once(KERN_DEBUG "dwc_otg: DEVICE:%03d : %s:%d:trimming xfer length\n",
+ hc->dev_addr, __func__, __LINE__);
xfer_length = urb->length - urb->actual_length;
}
@@ -1430,7 +1431,8 @@
halt_status, NULL);
if (urb->actual_length + bytes_transferred > urb->length) {
- DWC_WARN("%s(): trimming xfer length\n", __func__);
+ printk_once(KERN_DEBUG "dwc_otg: DEVICE:%03d : %s:%d:trimming xfer length\n",
+ hc->dev_addr, __func__, __LINE__);
bytes_transferred = urb->length - urb->actual_length;
}The old log lines (with function name printed twice, double line-feed)
WARN::update_urb_state_xfer_comp:741: update_urb_state_xfer_comp(): trimming xfer length
become a once-only kernel message of
dwc_otg: DEVICE:008 : update_urb_state_xfer_comp:742:trimming xfer lengthshowing which module it came from, which USB device etc.
mw9
commented
8 years ago For completeness, I have drafted and attached three patches to the existing sr700 driver. These seem to be working ok.
It seems clear to me that the output of lsusb misidentifies the device [1], and that the (patched) sr9700 driver is better suited than the dm9601 driver. Issues around packet filtering, etc., still remain, but the dm9601 driver offers no solution to those.
[1] ID 0fe6:9700 Kontron (Industrial Computer Source / ICS Advent) DM9601 Fast Ethernet Adapter
0001-usbnet-sr9700-Fix-incorrect-write-command.patch.txt 0002-usbnet-sr9700-Work-around-skb_try_coalesce-kernel-wa.patch.txt 0003-usbnet-sr9700-Add-packet-integrity-checks.patch.txt
popcornmix
commented
8 years ago @campag I've added your suggested patch to kernel tree.
@mw9 Your patches would be best submitted upstream. I'm not the best person to review them. I can cherry-pick them when they have been reviewed.
sej7278
commented
8 years ago is this fixed in the new 4.4 kernel?
popcornmix
commented
8 years ago The patch from @campag is present in 4.4 tree, so I expect it is still fixed (but I don't have a DM9601 to test). @strongly-typed is this still an issue with latest 4.4 kernel?
campag
commented
8 years ago @sej7278 @popcornmix I'm seeing the patch's printk_once() kernel log message in 4.4, so the patch is there and working to prevent the crash. All OK here.
sej7278
commented
8 years ago yup, i rsynced the entire sdcard on my zero and it didn't crash, so i'd say its fixed in 4.4 thanks!
Daveke
commented
8 years ago It's fixed the problem for me, too, thanks (DM9601).
popcornmix
commented
8 years ago Closing as believed to be fixed.
edd3a
commented
7 years ago Is this supposed to be solved because a different module is being used (sr9700) iso dm9601? I am using Linux LibreELEC 4.4.13 #1 Sat Jun 25 04:53:15 BST 2016 armv6l GNU/Linux on a pi zero with Kontron DM9601 (USB: 0fe6:9700). On the mentioned kernel, dm9601 is still loaded, and still crashes the system.
6by9
commented
7 years ago It's fixed on this kernel tree. Whether it is fixed on a LibreELEC release is up to the LibreELEC developers to have pulled in the change. The workaround was in the USB host driver, not the network device driver, so it shouldn't matter that the driver has changed from dm9601 to sr9700.
Seeing as LibreELEC is now seemingly using a 4.9 kernel, I'd make sure you're using an up to date image before trying to chase down an issue.
popcornmix
commented
7 years ago Yes, I'd suggest updating to a Krypton build which is using a newer kernel. There will be no more updates to Jarvis builds.
edd3a
commented
7 years ago Problem continues to exist on LibreELEC-RPi.arm-7.90.010.img with a 4.9 kernel. It crashes the network, and results in complete lock up.
So, this device will go the the trash and I will get a ASIX AX88772B based one.
[ 1093.507337] ERROR::handle_hc_chhltd_intr_dma:2214: handle_hc_chhltd_intr_dma: Channel 2, DMA Mode -- ChHltd set, but reason for halting is unknown, hcint 0x00000002, intsts 0x06200021 [ 1093.507337] [ 1093.507398] ERROR::handle_hc_chhltd_intr_dma:2214: handle_hc_chhltd_intr_dma: Channel 7, DMA Mode -- ChHltd set, but reason for halting is unknown, hcint 0x00000002, intsts 0x06200001 [ 1093.507398] [ 1093.507435] ERROR::handle_hc_chhltd_intr_dma:2214: handle_hc_chhltd_intr_dma: Channel 3, DMA Mode -- ChHltd set, but reason for halting is unknown, hcint 0x00000002, intsts 0x06200001 [ 1093.507435] [ 1093.530352] usb usb1-port1: disabled by hub (EMI?), re-enabling... [ 1093.530384] usb 1-1: USB disconnect, device number 62 [ 1093.530732] dm9601 1-1:1.0 eth0: unregister 'dm9601' usb-20980000.usb-1, Davicom DM96xx USB 10/100 Ethernet [ 1093.673673] Indeed it is in host mode hprt0 = 00021d01 [ 1094.070263] usb 1-1: new full-speed USB device number 63 using dwc_otg [ 1094.072954] Indeed it is in host mode hprt0 = 00021d01 [ 1094.431149] usb 1-1: New USB device found, idVendor=0fe6, idProduct=9700 [ 1094.431168] usb 1-1: New USB device strings: Mfr=0, Product=2, SerialNumber=0 [ 1094.431176] usb 1-1: Product: USB 2.0 10/100M Ethernet Adaptor [ 1094.521999] dm9601 1-1:1.0 eth0: register 'dm9601' at usb-20980000.usb-1, Davicom DM96xx USB 10/100 Ethernet, 00:e0:4c:53:44:58 [ 1094.621164] dm9601 1-1:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0xFFFF [ 1095.742135] dm9601 1-1:1.0 eth0: kevent 4 may have been dropped [ 1095.752150] dm9601 1-1:1.0 eth0: kevent 4 may have been dropped [ 1095.758138] dm9601 1-1:1.0 eth0: kevent 4 may have been dropped [ 1095.767167] dm9601 1-1:1.0 eth0: kevent 4 may have been dropped [ 1095.824200] dm9601 1-1:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0xFFFF [ 1095.959331] dm9601 1-1:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0xFFFF [ 1112.731934] usb 1-1: unexpected tiny rx frame [ 1120.601305] usb 1-1: unexpected tiny rx frame [ 1121.573243] usb 1-1: unexpected tiny rx frame [ 1127.033208] usb 1-1: unexpected tiny rx frame [ 1132.215250] usb 1-1: unexpected tiny rx frame [ 1146.698286] usb 1-1: unexpected tiny rx frame [ 1151.109939] usb 1-1: unexpected tiny rx frame
locngy
commented
7 years ago The problem still exist in Raspbian Jessie Lite:
Version: November 2016 Release date: 2016-11-25 Kernel version: 4.4
6by9
commented
7 years ago Doing a quick test with my Pi Zero and DM9601 I'm not currently seeing any problems. Admittedly my Raspbian Lite release is an old one, but I've done an rpi-update to grab kernel and firmware from 15th Dec and that is all happy. Transfers are running at 420-430KB/s as limited by USB1.1.
(I did manage to have two of them connected to my LAN at the same time, which isn't the best idea seeing as they all share the same MAC address. That shouldn't have any link to this issue anyway.)
sentriz
commented
7 years ago how would I go about updating to the latest version of the kernel to fix this issue? I get the kernel panic during rpi-update. seems like a bit of a catch 22.
thank you.
campag
commented
7 years ago Hi - as you have realised, there's no way round it. You'll have to use another network adapter to update your system, just the once.
btw if running Raspbian, there's no need for rpi-update: running "sudo apt-get dist-upgrade" will update your distro and kernel with stable releases.
sentriz
commented
7 years ago @campag ok, thank you for the info
karser
commented
3 years ago they all share the same MAC address No EPROM, so they all have the same MAC address
Sorry for the off top, but this is no longer a problem. I have attached 7 Kontron DM9601 adapters to the same board using udev rules:
#/etc/udev/rules.d/70-persistent-net.rules
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:e0:4c:53:44:58", DEVPATH=="*1-1.2*", NAME="enx00e04c534413", RUN+="/sbin/ifconfig enx00e04c534413 hw ether 00:e0:4c:53:44:13"
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:e0:4c:53:44:58", DEVPATH=="*1-1.3*", NAME="enx00e04c534424", RUN+="/sbin/ifconfig enx00e04c534424 hw ether 00:e0:4c:53:44:24"Where DEVPATH is from udevadm info /sys/class/net/eth1 output and NAME is the interface name.
Here are more details and photos https://karser.dev/same-mac-kontron-dm9601/
mw9
commented
3 years ago Sorry for the off top, but this is no longer a problem. I have attached 7 Kontron DM9601 adapters to the same board using udev rules: \<snipped>
That looks like a neat solution. You might also want to set promiscuous mode if multicast is a requirement. This would be required to participate properly in, for example, mDNS activity. At least, that was my finding.
Hello,
I'm experiencing kernel panics with a Noname USB to Ethernet Adapter. It is marked "USB2.0 to Fast Ethernet Adapter Model No:KY-RD9700". It uses a probably faked DM9601 chipset. Modules loaded are
sr9700anddm9601.lsusb output is:
The adapter works with a Ubuntu x86-64 with kernel version 3.13.0-53-generic.
Connected to a RPi Model B and RPi 2 Model B I get kernel panics as soon as there is some significant traffic. Ping works ok, but apt-get for example oops the kernel. This applies to the latest kernel (4.0.7-v7+) and an older version (3.18.16-v7+)
I am using a serial console to login into my RPis. See the full log attached
After a reboot I downgraded to
33a6707cf1c96b8a2b5dac2ac9dead590db9fcaawhich gives the same problem:Reboot
And then