linux-kernel - Re: Missing USB XHCI and EHCI reset for kexec

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]

Message-ID: <Pine.LNX.4.44L0.1404151521200.1310-100000@iolanthe.rowland.org>
Date:	Tue, 15 Apr 2014 15:34:44 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Stefani Seibold <stefani@...bold.net>
cc:	linux-usb <linux-usb@...r.kernel.org>,
	Kernel development list <linux-kernel@...r.kernel.org>,
	Greg KH <greg@...ah.com>,
	Sarah Sharp <sarah.a.sharp@...ux.intel.com>,
	<andreas.brief@...de-schwarz.com>
Subject: Re: Missing USB XHCI and EHCI reset for kexec

On Tue, 15 Apr 2014, Stefani Seibold wrote:

> > So two devices failed to initialize after the drivers were rebound: 3-4 
> > and 2-2.  We know that 3-4 was the mass-storage device, but I can't 
> > tell from this log what 2-2 was.  
> > 
> 
> 2-2 is a custom HID device which handles the front panel and the rotary
> knop.

A custom device?  Maybe it's not behaving the way it should.

> Both of this devices are connect thru a HUB.

No.  You can tell from the device paths.  3-4 is the device plugged
directly into port 4 of the host controller for bus 3.  Similarly, 2-2
is the device plugged directly into port 2 of the host controller for
bus 2.

A good example of a device connected through a hub is the Rohde&Schwarz 
FrontPanel USB Keyboard, 1-2.2.  This means it is plugged into port 2 
of the hub that is plugged into port 2 of the host controller for bus 
1.

Also, the fact that these two devices are on different buses means that 
they can't be connected to the same hub.  If they were, they would both 
be on the same bus as that hub.

> An other PPC board which
> nearly the same HW does not have this HUB and this can handle the USB
> bus without any problem.
> 
> So i think the HUB is the reason.

Under the circumstances, I don't see how it could be.

> Sorry, the HW is soldered on the board.

If you think there is a bad hub, can you remove it and re-solder the 
other components?

Unfortunately, your environment isn't very suitable for testing.  You 
can't attach the hardware to a different computer, you can't use any 
test equipment, and you can't even try out different kernel versions.

All together, the odds of solving this problem aren't good.

> Right, but i would prefer a solution for this. Since it works perfectly
> in kernel 3.4 i don't think it is a hardware issue.

Maybe yes, maybe no.  Without the ability to perform detailed tests, we 
can't tell.

What happens if you run the unbind/rebind test under 3.4?

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/