[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150112133330.GA18351@hposo>
Date: Mon, 12 Jan 2015 14:33:30 +0100
From: Olivier Sobrie <olivier@...rie.be>
To: "Ahmed S. Darwish" <darwish.07@...il.com>
Cc: Marc Kleine-Budde <mkl@...gutronix.de>,
Oliver Hartkopp <socketcan@...tkopp.net>,
Wolfgang Grandegger <wg@...ndegger.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Linux-USB <linux-usb@...r.kernel.org>,
Linux-CAN <linux-can@...r.kernel.org>,
netdev <netdev@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v4 4/4] can: kvaser_usb: Retry first bulk transfer on
-ETIMEDOUT
Hello,
On Mon, Jan 12, 2015 at 05:14:07AM -0500, Ahmed S. Darwish wrote:
> On Sun, Jan 11, 2015 at 09:51:10PM +0100, Marc Kleine-Budde wrote:
> > On 01/11/2015 09:45 PM, Ahmed S. Darwish wrote:
> > > From: Ahmed S. Darwish <ahmed.darwish@...eo.com>
> > >
> > > (This is a draft patch, I'm not sure if this fixes the USB
> > > bug or only its psymptom. Feedback from the linux-usb folks
> > > is really appreciated.)
> > >
> > > When plugging the Kvaser USB/CAN dongle the first time, everything
> > > works as expected and all of the transfers from and to the USB
> > > device succeeds.
> > >
> > > Meanwhile, after unplugging the device and plugging it again, the
> > > first bulk transfer _always_ returns an -ETIMEDOUT. The following
> > > behaviour was observied:
> > >
> > > - Setting higher timeout values for the first bulk transfer never
> > > solved the issue.
> > >
> > > - Unloading, then loading, our kvaser_usb module in question
> > > __always__ solved the issue.
> > >
> > > - Checking first bulk transfer status, and retry the transfer
> > > again in case of an -ETIMEDOUT also __always__ solved the issue.
> > > This is what the patch below does.
> > >
> > > - In the testing done so far, this issue appears only on laptops
> > > but never on PCs (possibly power related?)
> > >
> > > Signed-off-by: Ahmed S. Darwish <ahmed.darwish@...eo.com>
> >
> > Does this patch apply apply between 3 and 4? If not, please re-arrange
> > the series. As this is a bug fix, patches 1, 2 and 4 will go via
> > net/master, 3 will go via net-next/master.
> >
>
> Since no one complained earlier, I guess this issue only affects
> USBCAN devices. That's why I've based it above patch #3: adding
> USBCAN hardware support.
>
> Nonetheless, it won't do any harm for the current Leaf-only
> driver. So _if_ this is the correct fix, I will update the commit
> log, refactor the check into a 'do { } while()' loop, and then
> base it above the Leaf-only net/master fixes on patch #1, and #2.
>
> Any feedback on the USB side of things?
Can you take a wireshark capture showing the problem?
It can maybe help people to figure out what happens.
What kind of usbcan device do you use?
Which firmware revision is loaded on the device?
Kr,
--
Olivier
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists