ched patch utilizes that assumption and just turns the pr_warn into
pr_debug to quiet things down.
Tested on my Intel box.
Signed-off-by: Don Zickus
---
v2: modified patch to just quiet down the warns instead of skipping the ports
---
drivers/usb/core/port.c | 4 ++--
1 file changed, 2 insert
On Mon, Nov 30, 2015 at 12:57:17PM -0800, Dan Williams wrote:
> On Tue, Nov 17, 2015 at 1:00 PM, Don Zickus wrote:
> > My recent Intel box is spewing these messages:
> >
> > xhci_hcd :00:14.0: xHCI Host Controller
> > xhci_hcd :00:14.0: new USB bus regist
On Mon, Nov 30, 2015 at 03:49:51PM -0500, Alan Stern wrote:
> On Mon, 30 Nov 2015, Don Zickus wrote:
>
> > On Tue, Nov 17, 2015 at 04:00:58PM -0500, Don Zickus wrote:
> > > My recent Intel box is spewing these messages:
> >
> > poke?
> >
> > Chee
On Tue, Nov 17, 2015 at 04:00:58PM -0500, Don Zickus wrote:
> My recent Intel box is spewing these messages:
poke?
Cheers,
Don
>
> xhci_hcd :00:14.0: xHCI Host Controller
> xhci_hcd :00:14.0: new USB bus registered, assigned bus number 2
> usb usb2: New USB device found
ched patch utilizes that assumption and just skips the
find_and_link_peer setup if a port is determined to be unused. This further
assumes that port's status will never change.
Tested on my Intel box.
Signed-off-by: Don Zickus
---
drivers/usb/core/port.c | 7 +++
1 file changed, 7 insertions
Bump. :-)
On Mon, Aug 10, 2015 at 12:06:53PM -0400, Don Zickus wrote:
> It was reported that after 10-20 reboots, a usb keyboard plugged
> into a docking station would not work unless it was replugged in.
>
> Using usbmon, it turns out the interrupt URBs were streaming with
> cal
reset, but the reset wasn't really happening.
The check for HID_NO_BANDWIDTH was inverted. Fix was simple.
Tested by reporter and locally by me by unplugging a keyboard halfway until I
could recreate a stream of errors but no disconnect.
Signed-off-by: Don Zickus
---
I mistyped th
On Wed, Oct 01, 2014 at 09:15:23PM -0400, Don Zickus wrote:
> Recently our build environment changed and started turning some warnings into
> errors. One of the fallouts is this warning:
>
> CC [M] drivers/usb/misc/usb3503.o
> drivers/usb/misc/usb3503.c: In function ‘usb3503_pr
this function
Fixed it by using the proper error. Compiled only as I don't have the hardware
to test correctly.
Signed-off-by: Don Zickus
---
drivers/usb/misc/usb3503.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/misc/usb3503.c b/drivers/usb/misc/us
On Wed, Jan 22, 2014 at 02:04:19PM -0800, Sarah Sharp wrote:
> On Wed, Jan 22, 2014 at 09:18:27AM -0500, Prarit Bhargava wrote:
> >
> >
> > > Don Zickus writes:
> > >
> > > Some co-workers of mine bought Samsung laptops that had mostly usb3 ports.
On Mon, Jan 13, 2014 at 03:17:48PM -0800, Sarah Sharp wrote:
> On Mon, Jan 13, 2014 at 10:49:49AM -0500, Don Zickus wrote:
> > Some co-workers of mine bought Samsung laptops that had mostly usb3 ports.
> > Those ports did not resume correctly (the driver would timeout communicati
chipset and the
resume started working. Reloading the xhci_hcd module had been the temporary
workaround.
Not sure if I should restrict this further or not. Probably should be sent
to stable too.
Signed-off-by: Don Zickus
---
drivers/usb/host/xhci-pci.c |2 ++
1 files changed, 2 insertions
On Tue, Oct 08, 2013 at 11:10:52AM -0500, Dan Williams wrote:
> On Tue, 2013-10-08 at 11:29 -0400, Don Zickus wrote:
> > Hi Oliver,
> >
> > I am trying to verify a fix for the cdc-wdm driver and am having trouble
> > figuring out what devices requires that driver
On Tue, Oct 08, 2013 at 05:36:46PM +0200, Bjørn Mork wrote:
> Don Zickus writes:
>
> > I am trying to verify a fix for the cdc-wdm driver and am having trouble
> > figuring out what devices requires that driver. It seems related to cell
> > phones but I wasn't sure
Hi Oliver,
I am trying to verify a fix for the cdc-wdm driver and am having trouble
figuring out what devices requires that driver. It seems related to cell
phones but I wasn't sure if there was a particular one or all of them in
general (I couldn't get my cell to use it). Thanks in advance!
Ch
On Wed, May 29, 2013 at 12:38:28PM -0700, Sarah Sharp wrote:
> On Tue, May 28, 2013 at 02:41:18PM -0700, Julius Werner wrote:
> > The policy we want to achieve is to disable runtime PM iff there is a
> > device connected that doesn't have persist_enabled or a reset_resume()
> > handler and whose pa
On Tue, Mar 05, 2013 at 03:14:10PM -0800, Sarah Sharp wrote:
> > */
> > static void compliance_mode_recovery_timer_init(struct xhci_hcd *xhci)
> > {
> > + if (timer_pending(&xhci->comp_mode_recovery_timer)) {
> > + xhci_dbg(xhci, "Compliance Mode Recovery Timer already
> > active.\
On Wed, Feb 20, 2013 at 10:54:40AM -0500, Alan Stern wrote:
> On Wed, 20 Feb 2013, Tony Camuso wrote:
>
> > On 02/20/2013 10:15 AM, Alan Stern wrote:
> > > On Tue, 19 Feb 2013, Sarah Sharp wrote:
> > >
> > >> The one thing I wanted to check was my understanding of the hibernate
> > >> flow path.
On Tue, Feb 19, 2013 at 01:48:51PM -0800, Sarah Sharp wrote:
> Hi Tony,
>
> Greg closed the usb-next tree for 3.9 two weeks ago. The bug fix
> patches will have to go in after the 3.9 merge window closes
> (approximately two weeks from now).
>
> Sorry for the lack of response, I was on vacation.
On Tue, Jan 22, 2013 at 06:17:00AM +, Huang, Adrian (ISS Linux TW) wrote:
> Hi Alan,
>
> Recently, I'm debugging this issue (the same symptom described by Don) on my
> server. Fortunately, the issue was fixed by applying your patch posted in
> this email thread. Just checked the latest kerne
On Thu, Oct 18, 2012 at 03:59:44PM -0400, Alan Stern wrote:
> On Tue, 16 Oct 2012, Don Zickus wrote:
>
> > > > I did not get a chance to test the patch yet.
> > >
> > > Let me know what happens.
> >
> > It might take a while as our customer
On Tue, Oct 16, 2012 at 12:01:29PM -0400, Alan Stern wrote:
> On Tue, 16 Oct 2012, Don Zickus wrote:
>
> > > I dislike adding an extra test to a hot path, but there doesn't seem to
> > > be any way around it. Some of the other HCDs may need a similar
> > &
On Mon, Oct 15, 2012 at 05:31:01PM -0400, Alan Stern wrote:
> >
> > uhci_scan_schedule->
> > uhci_clear_next_interrupt->
> > uhci->term_td->status &= ~cpu_to_hc32(uhci, TD_CTRL_IOC);
> >
> > This panics becase term_td is not allocated yet.
> >
> > Now I could be wrong about the interrupts
Hi Alan,
I am seeing an odd panic with uhci when a 160 cpu box panics and starts
running a kdump kernel (which is the same exact image as the boot kernel)
for our RHEL-6 (2.6.32) kernel. Now I understand 2.6.32 is not something
upstream supports.
However, my question is what is expected to happe
cular link state if we find its
> corresponding exit latency is zero.
>
> Signed-off-by: Sarah Sharp
> Reported-by: Don Zickus
> ---
> drivers/usb/core/hub.c | 14 ++
> 1 files changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/usb/co
On Tue, Oct 02, 2012 at 02:42:41PM -0700, Sarah Sharp wrote:
> > > USB 3.0 devices are required to support Link PM. However, some of
> > > them don't support U1, or don't support U2, or don't support either.
> > > There is no way in the USB 3.0 specification to say that a device
> > > doesn't supp
On Tue, Oct 02, 2012 at 12:15:46PM -0700, Sarah Sharp wrote:
> Hi Don,
>
> The WD drive arrived today, but I can't reproduce your I/O errors on
> 3.6. I didn't try with 3.5 yet. However, I did notice that the device
> really doesn't want to enter U1, but it will enter U2.
I did update the firmw
On Fri, Sep 28, 2012 at 11:39:48AM -0400, Alan Stern wrote:
> On Fri, 28 Sep 2012, Don Zickus wrote:
>
> > > Probably the device was already hung. The log showed that an earlier
> > > transfer completed with a STALL. The reason wasn't apparent, although
> >
On Thu, Sep 27, 2012 at 04:42:52PM -0400, Alan Stern wrote:
> On Thu, 27 Sep 2012, Sarah Sharp wrote:
>
> > On Wed, Sep 26, 2012 at 02:03:06PM -0400, Don Zickus wrote:
> > > Hi Sarah,
> > >
> > > As discussed privately, here is the debug output of what happ
On Wed, Sep 26, 2012 at 12:55:26PM -0400, Alan Stern wrote:
> On Wed, 26 Sep 2012, Don Zickus wrote:
>
> > Hi Alan,
> >
> > This patch seemed to be successful. I copied and pasted the response from
> > our customer (we backported the patch to RHEL-6/2.6.32):
>
On Mon, Sep 24, 2012 at 12:59:51PM -0400, Alan Stern wrote:
> > If you want to track down what's going wrong, you'll have to add some
> > debugging code to usb_device_read() and usb_remove_hcd(). By the time
> > usb_device_dump() starts running, it's already too late.
>
> After thinking about t
On Mon, Sep 24, 2012 at 12:59:51PM -0400, Alan Stern wrote:
> On Mon, 17 Sep 2012, Alan Stern wrote:
>
> > On Mon, 17 Sep 2012, Don Zickus wrote:
> >
> > > I have added some in-depth analysis from our customer.
> > >
> > >
> > > The problem
On Thu, Sep 13, 2012 at 04:31:34PM -0400, Alan Stern wrote:
> On Thu, 13 Sep 2012, Don Zickus wrote:
>
> > Hi Alan,
> >
> > I adapted your patch to our 2.6.32 tree and the customer tested it without
> > success. The output panic is attached below. I will work on
On Thu, Sep 13, 2012 at 04:31:34PM -0400, Alan Stern wrote:
> On Thu, 13 Sep 2012, Don Zickus wrote:
>
> > Hi Alan,
> >
> > I adapted your patch to our 2.6.32 tree and the customer tested it without
> > success. The output panic is attached below. I will work on
On Tue, Sep 11, 2012 at 11:34:56AM -0400, Alan Stern wrote:
> > Deregistering the bus first to prevent future readers from accessing the
> > device
> > before cleaning up the hcd, seemed like an appropriate way to go. I'll
> > leave
> > it to the experts to validate that or provide a better solu
On Tue, Sep 11, 2012 at 11:34:56AM -0400, Alan Stern wrote:
> On Mon, 10 Sep 2012, Don Zickus wrote:
>
> > A customer of ours noticed that after a bunch of hot removals of the EHCI
> > PCI device, a panic occurs. This happened on a 2.6.32 RHEL-6 kernel, but
> > I bel
r provide a better solution. :-)
I adapted their usb_remove_hcd fix for usb_add_hcd error path too to mimic
the same behaviour (a little code shuffling to handle the gotos cleanly).
Signed-off-by: Don Zickus
---
drivers/usb/core/hcd.c | 20 ++--
1 files changed, 10 insertion
On Wed, Aug 01, 2012 at 10:42:37AM -0400, Alan Stern wrote:
> On Tue, 31 Jul 2012, Don Zickus wrote:
>
> > We ran into an interesting deadlock on RHEL-5 (2.6.18) that I believe
> > still appiles to the current kernel involving the ehci->lock.
> >
> > CPU A
ted.
[dzickus - rewrote the description, ported to v3.5]
Signed-off-by: Casey Dahlin
Signed-off-by: Don Zickus
---
drivers/usb/host/ehci-hcd.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index 800be38..
39 matches
Mail list logo
