Opened 12 years ago
Last modified 5 years ago
#9624 assigned bug
AX88772B USB Ethernet. Read::MISMATCH of the frame length
Reported by: | kallisti5 | Owned by: | nobody |
---|---|---|---|
Priority: | normal | Milestone: | R1 |
Component: | Drivers/Network/usb_asix | Version: | R1/Development |
Keywords: | MISMATCH | Cc: | |
Blocked By: | Blocking: | ||
Platform: | All |
Description
Asus USB Ethernet dongle using the usb_asix driver.
Get a large number of the following error paired with stalling network communications:
KERN: usb_asix:06.09.160:Read::MISMATCH of the frame length: hdr 153; received:154
hdr is always one less than received.
Attachments (1)
Change History (20)
comment:1 by , 12 years ago
Summary: | Asus USB Ethernet. Read::MISMATCH of the frame length → AX88772B USB Ethernet. Read::MISMATCH of the frame length |
---|
comment:2 by , 12 years ago
comment:3 by , 12 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
#8238 may be related. testing some tweaks now.
comment:5 by , 12 years ago
Yeah, same result. My recent commit mostly cleared up the fact that the registers do different things on the A vs B models.
comment:6 by , 12 years ago
I purchased another USB ethernet adaptor. (D-Link DUB-E100 rev.C1)
Turns out it is the same idential chipset :( After adding the USB ID, I encountered the exact same error.. so it definitley looks like AX88772B is broken in general and it wasn't a one-off issue.
comment:7 by , 12 years ago
Why just to not ignore this extra byte? Probably this is some kind of CRC - anyway as soon as the length in header is not more than actal received amount you should be on the safe side. ;-) Have you tried this? It is always good idea to run two tcpdumps on the Haiku and outside of it to investigate packets content.
PS: How is your adapters are looking like? Yes, there are always difficult to find corresponding hardware to buy - all is masked by this marketing names. :-\ On the same reason I have postponed #8238 - just had no such hw.
comment:8 by , 12 years ago
Well, when compared to FreeBSD's if_axe.c/if_axeregs.h, it seems that each frame is 16bits aligned, which can explain these 153 vs 154 mismatches.
I'm also worried that the device is supposed to send frames in burst mode, but we only queue an USB bulk read for one frame max size (1536 or something). In such situation, if several small (think UDP) ethernet frames are really pending, the device will return *several* frames in one bulk read, but we only use the first one. It's clearly broken.
follow-up: 11 comment:9 by , 12 years ago
I found a AX88772 device (D-Link DUB-E100 rev.B1) and am seeing the same errors.. The AX88772 does seem to have minimal functionality though compared to the AX88772B.
KERN: usb_asix:05.10.198:Read::MISMATCH of the frame length: hdr 359; received:360 KERN: usb error ehci -1: qtd (0x9885600) error: 0x00048d50 KERN: usb_asix:05.12.328:Read::Device status error:0x8000a01a KERN: usb_asix:05.12.329:Read::Error: no place for TRXHeader:only 0 of 4 bytes. KERN: usb_asix:05.12.339:Read::Error:TRX Header is invalid: len:0x3047; ilen:0x316 KERN: usb_asix:05.13.073:Read::MISMATCH of the frame length: hdr 105; received:106 KERN: usb_asix:05.13.253:Read::MISMATCH of the frame length: hdr 125; received:126 KERN: usb_asix:05.16.918:Read::MISMATCH of the frame length: hdr 243; received:244 KERN: usb_asix:05.21.200:Read::MISMATCH of the frame length: hdr 216; received:280 KERN: usb_asix:05.21.201:Read::MISMATCH of the frame length: hdr 92; received:156 KERN: usb_asix:05.25.975:Read::MISMATCH of the frame length: hdr 243; received:244 KERN: usb_asix:05.27.522:Read::MISMATCH of the frame length: hdr 153; received:154 KERN: usb_asix:05.27.524:Read::MISMATCH of the frame length: hdr 153; received:154 KERN: usb_asix:05.27.525:Read::MISMATCH of the frame length: hdr 153; received:312 KERN: usb_asix:05.36.926:Read::MISMATCH of the frame length: hdr 185; received:186 KERN: usb_asix:05.38.543:Read::MISMATCH of the frame length: hdr 243; received:244 KERN: usb_asix:05.39.619:Read::MISMATCH of the frame length: hdr 165; received:166 KERN: usb_asix:05.39.620:Read::MISMATCH of the frame length: hdr 165; received:166
comment:10 by , 12 years ago
The MISMATCH errors are showing that either we've just facing 16bits alignment or, and it's here far worst, we've retrieved from USB controler more than a single frame but only consume the first one. And the reason is quite simple: our driver is clearly not Multi-Frame-Burst (MFB) mode aware... aka broken.
The three error at ~05.12.328 seems more related to an USB error condition, though.
comment:11 by , 12 years ago
Replying to kallisti5:
I found a AX88772 device (D-Link DUB-E100 rev.B1) and am seeing the same errors.
Are you working on this problem ATM? I see some bids on ebay.de and itching to squeeze out of this whistle all of its possibilities. ;-)
follow-up: 13 comment:12 by , 12 years ago
Owner: | changed from | to
---|---|
Status: | assigned → in-progress |
I'm moving this ticket to my top backlog right now :-), having found back my old DUB-E100 revB1. Expect change in the next few days.
comment:13 by , 11 years ago
Replying to phoudoin:
I'm moving this ticket to my top backlog right now :-), having found back my old DUB-E100 revB1. Expect change in the next few days.
Hows the backlog? :D
comment:14 by , 11 years ago
Two months old due to Real Life Issues(tm) I keep to always underestimate :\
One thing that held me too is the fact that I've to develop under VirtualBox (thanks to UEFI madness) and failed so far to find a way to expose that USB adapter from host to guest OS. So far, I've just started to change a bit the *Device classes hierarchy in order to split them between single-frame and multi-frame-burst devices, and I've a drafty (untested, see above why) MFB read support.
comment:15 by , 11 years ago
It would seem that phoudoin is right, packets are 16bits aligned, the driver should probably expect this additional byte and keep it for processing in the next packet...
comment:16 by , 11 years ago
I guessed wrong, packets are 16 bits aligned, just padded. I adjusted the logging in hrev45900, the stalling communications should still remain though, I can't reproduce them here on Intel EHCI. FWIW I have the device ids: 0x0b95:0x7e2b.
comment:17 by , 9 years ago
JFYI: the datasheet for AX88772B can be goodled by name AX88772B_Datasheet_v104.pdf. My copy is 1120745 bytes big and was received directly from Asix support 4 years ago. It is looking fairly detailed.
comment:18 by , 8 years ago
Owner: | changed from | to
---|---|
Status: | in-progress → assigned |
by , 6 years ago
Attachment: | vertu-syslog.txt added |
---|
comment:19 by , 5 years ago
Getting
KERN: [33musb_asix:[0m31.23.576:Read::Error of queue_bulk_v request:0x80000000 KERN: PMA: bad value for allocate (41231686064 bytes) KERN: usb error xhci 0: failed to allocate TRBs
The AX88772B based USB to Ethernet device does not get an IP address in Haiku (nightly build as of today).
Looking at recent changes, hrev44805 may be to blame for this. (as I swear this usb dongle has worked in the past)