lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ