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] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.44L0.1307191119550.1055-100000@iolanthe.rowland.org>
Date:	Fri, 19 Jul 2013 11:26:56 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Gioh Kim <gioh.kim@....com>
cc:	'Ming Lei' <tom.leiming@...il.com>, <linux-usb@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>, 'Mark Salter' <msalter@...hat.com>,
	<namhyung.kim@....com>, 'Minchan Kim' <minchan.kim@....com>,
	'Chanho Min' <chanho.min@....com>,
	'Jong-Sung Kim' <neidhard.kim@....com>,
	'linux-arm-kernel' <linux-arm-kernel@...ts.infradead.org>,
	HyoJun Im <hyojun.im@....com>
Subject: RE: [PATCH] [RFC] EHCI: add to memory barrier to updating hw_next

On Fri, 19 Jul 2013, Gioh Kim wrote:

> > I was going to ask the same question.  This particular piece of code gets
> > executed _only_ when an URB is unlinked.  Not during any other kind of
> > error.
> 
> 
> I've got the problem when I listened to the mp3 file of USB HDD.
> I checked the urb data when the problem occurred, the last-status value of
> urb was EINPROGRESS and 
> urb->unlinked was ECONNRESET. 

Ah, so the URB _was_ unlinked.

> I think the 'stopped' case was occurred by the reset of USB port.
> The block device driver did reset USB port because there is no return from
> USB device.

Okay.

> If I made block device driver could not reset USB port, the EHCI driver
> codes were not executed.
> Finally the halt of HC makes 'stopped' case.

Why was the HC halted?  That should happen only when there is an 
extremely severe error.

> I think halt of the HC might be caused that store-buffer delays command for
> HC.
> When I applied the patch from https://lkml.org/lkml/2011/8/31/344 and added
> a mb() into hw_next updating
> to remove delay of store-buffer, My platform works well.
> 
> Can the store-buffer delay halt HC? Is it possible?

I don't see how.  It could slow things down but it should not cause any 
errors.

> IMHO, if the qTD list is broken the HC think there is no qTD to send.
> So I added mb() at hw_next update code.

At the time when the hw_next update gets executed, what is the value of 
"state"?  It should be QH_STATE_IDLE.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ