Aleksander Morgado <aleksander@xxxxxxxxxxxxx> writes: > On Tue, Feb 17, 2015 at 4:32 PM, Sami Farin <hvtaifwkbgefbaei@xxxxxxxxx> wrote: >> ifconfig >> wwp3s0u1c2: flags=4291<UP,BROADCAST,RUNNING,NOARP,MULTICAST> mtu 1500 >> inet 46.132.188.224 netmask 255.255.255.192 broadcast 46.132.188.255 >> inet6 fe80:: prefixlen 64 scopeid 0x20<link> >> ether 32:35:3a:64:2e:25 txqueuelen 1000 (Ethernet) >> RX packets 0 bytes 0 (0.0 B) >> RX errors 17764 dropped 0 overruns 0 frame 0 >> TX packets 6714 bytes 18446744073709268911 (1638.3 PiB) >> TX errors 1427 dropped 0 overruns 0 carrier 0 collisions 0 >> > > That's a ton of RX errors in there, and an... unusual number of TX > bytes as well. > > Bjørn, any idea? Not really... The TX bytes definitely looks we managed to end up with a negative count: 18446744073709268911 = 2^64 - 282705 Which I guess means that my new attempt to "correct" the tx_bytes counter in cdc_ncm_fill_tx_frame() must have gone bananas. Hmm, looks like that will happen if we fail to submit the urb for some reason. We do a premature subtraction of the framing overhead bytes, assuming that the urb will succeed so that usbnet increments the counter. This will not work if the urb status ends up with some error. And that's the only way to increment the tx_errors counter, so this has definitely happened. Don't know how to fix the negative byte count, though. The minidriver tries to compensate for the over-counting in usbnet, but it won't get any information about the submission errors. In any case, I believe that means that there is some urb submission error here which is most likely unrelated to the cdc_ncm driver. And given that fact, I do believe the rx_errors are caused by the same problem. Thta counter is incremented a number of places for different reasons, but one of the more likely reasons is in the urb callback: rx_complete(). Any EPIPE, EPROTO, ETIME or EILSEQ status will count as rx_errors along with any possibly unhandled status codes. So my conclusion is that there is some higher level USB communication problem here, not directly involving neither usbnet nor the minidriver. The weird tx_bytes count is a symptom of this. It should ideally be fixed, but I don't know how (without reverting to counting all framing overhead including the possibly extreme zero padding). Bjørn -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
