From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754012AbcKYJwu (ORCPT ); Fri, 25 Nov 2016 04:52:50 -0500 Received: from rtits2.realtek.com ([211.75.126.72]:37565 "EHLO rtits2.realtek.com.tw" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753246AbcKYJwm (ORCPT ); Fri, 25 Nov 2016 04:52:42 -0500 Authenticated-By: X-SpamFilter-By: BOX Solutions SpamTrap 5.56 with qID uAP9qK1V006089, This message is accepted by code: ctloc85258 From: Hayes Wang To: Mark Lord , Greg KH CC: David Miller , "netdev@vger.kernel.org" , 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+AwgAAm4ICAAaIjoP//1LUAgAfJkeCAAC16gIAAmNB+///IdICAAR1zgIAAiCTw//+4SQAAAMTjgAAA+GcAAALhTwAAEgpw+AAeU/VQ Date: Fri, 25 Nov 2016 09:52:20 +0000 Message-ID: <0835B3720019904CB8F7AA43166CEEB20105653D@RTITMBSV03.realtek.com.tw> References: <0835B3720019904CB8F7AA43166CEEB201055ED8@RTITMBSV03.realtek.com.tw> <20161124.112152.692025478489876693.davem@davemloft.net> <23e0c132-8844-0a34-3e0b-e412f76493ba@pobox.com> <20161124.121140.2054576632424977475.davem@davemloft.net> <20161124190055.GA3642@kroah.com> <9e8ff5b4-1c72-3106-7821-73484de133c2@pobox.com> In-Reply-To: <9e8ff5b4-1c72-3106-7821-73484de133c2@pobox.com> 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="utf-8" MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id uAP9r18L017782 Mark Lord [mailto:mlord@pobox.com] > Sent: Friday, November 25, 2016 3:11 AM [...] > On 16-11-24 02:00 PM, Greg KH wrote: > > On Thu, Nov 24, 2016 at 01:34:08PM -0500, Mark Lord wrote: > >> One thought: bulk data streams are byte streams, not packets. > >> Scheduling on the USB bus can break up larger transfers across > >> multiple in-kernel buffers. A "real" URB buffer on USB2 is max 512 bytes. > >> The driver is providing 16384-byte buffers, and assumes that data will > >> never spill over from one such buffer to the next. > >> Yet the observations here consistently show otherwise. > > > > Wait, how do you know that data will not spill over? What is making > > that guarantee? Will the USB device send a "zero packet" in order to > > show that all of the "logical" data is now sent for this specific > > endpoint? Is there some sort of "framing" that the device does with the > > USB data so that the driver "knows" where the end of packet is? > > Exactly my point. > > > Check the zero-packet stuff for this device, that's tripped up many a > > USB driver writer over the years, myself included. > > I haven't tripped over it myself, but only because we were careful > to allow for such in the USB drivers I have worked on. > > The r8152 driver just assumes it never happens. What is the value of /sys/bus/usb/devices/.../power/control ? Could you make sure it is "on" and try again? Or you could call usb_disable_autosuspend() in probe(). Best Regards, Hayes