Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752469AbcKRH5y convert rfc822-to-8bit (ORCPT ); Fri, 18 Nov 2016 02:57:54 -0500 Received: from rtits2.realtek.com ([211.75.126.72]:34223 "EHLO rtits2.realtek.com.tw" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751971AbcKRH5u (ORCPT ); Fri, 18 Nov 2016 02:57:50 -0500 Authenticated-By: X-SpamFilter-By: BOX Solutions SpamTrap 5.56 with qID uAI7vYuQ022725, This message is accepted by code: ctloc85258 From: Hayes Wang To: Mark Lord , "netdev@vger.kernel.org" CC: nic_swsd , "linux-kernel@vger.kernel.org" , "linux-usb@vger.kernel.org" Subject: RE: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable Thread-Topic: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable Thread-Index: AQHSO+t3nHKkZLLsBUqa3CUPsCXz6KDci+AwgAAm4ICAAaIjoA== Date: Fri, 18 Nov 2016 07:57:33 +0000 Message-ID: <0835B3720019904CB8F7AA43166CEEB201050B7E@RTITMBSV03.realtek.com.tw> References: <1394712342-15778-226-Taiwan-albertk@realtek.com> <1394712342-15778-227-Taiwan-albertk@realtek.com> <0835B3720019904CB8F7AA43166CEEB20105013E@RTITMBSV03.realtek.com.tw> In-Reply-To: Accept-Language: zh-TW, en-US Content-Language: zh-TW X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.21.177.128] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2301 Lines: 51 Mark Lord [mailto:mlord@pobox.com] > Sent: Thursday, November 17, 2016 9:42 PM [...] > What the above sample shows, is the URB transfer buffer ran out of space in the > middle > of a packet, and the hardware then tried to just continue that same packet in the > next URB, > without an rx_desc header inserted. The r8152.c driver always assumes the URB > buffer begins > with an rx_desc, so of course this behaviour produces really weird effects, and > system crashes, etc.. The USB device wouldn't know the address and size of buffer. Only the USB host controller knows. Therefore, the device sends the data to host, and the host fills the memory. According to your description, it seems the host splits the data from the device into two different buffers (or URB transfers). I wonder if it would occur. As far as I know, the host wouldn't allow the buffer size less than the data length. Our hw engineers need the log from the USB analyzer to confirm what the device sends to the host. However, I don't think you have USB analyzer to do this. I would try to reproduce the issue. But, I am busy, so I don't think I would response quickly. Besides, the maximum data length which the RTL8152 would send to the host is 16KB. That is, if the agg_buf_sz is 16KB, the host wouldn't split it. However, you still see problems for it. [...] > It is not clear to me how the chip decides when to forward an rx URB to the host. > If you could describe how that part works for us, then it would help in further > understanding why fast systems (eg. a PC) don't generally notice the issue, > while much slower embedded systems do see the issue regularly. The driver expects the rx buffer would be rx_desc + a packet + padding to 8 alignment + rx_desc + a packet + padding to 8 alignment + ... Therefore, when a urb transfer is completed, the driver parsers the buffer by this way. After the buffer is handled, it would be submitted to the host, until the transfer is completed again. If the submitting fail, the driver would try again later. The urb->actual_length means how much data the host fills. The drive uses it to check the end of the data. The urb->status mean if the transfer is successful. The driver submits the urb to the host directly if the status is not successful. Best Regards, Hayes