Re: USB Serial device disconnect causes IRQ disable after usingehci_info

From: Alan Stern
Date: Tue Aug 26 2008 - 11:02:03 EST


On Mon, 25 Aug 2008, amruth wrote:

> Hi
> Alan

Please don't include old email messages at the bottom of your own
messages. It's annoying to read them.

> > That was the full-speed device. Does it make any
> > difference if you use
> > only one of them instead of both?
> >
> The problem is seen when both are used.

That doesn't answer my question. I already know that the problem is
seen when both are used; the log you included before proves that.

What I don't know is whether the problem is seen when you use only
the high-speed device. Is it?

> > Try adding a statement saying:
> >
> >ehci_info(ehci, "irq status %x masked %x\n",
> > status,
> >status & INTR_MASK);
> >> to ehci-hcd.c inside ehci_irq(), just before the line that
> > does status &= INTR_MASK;
> >
> > Then let's see what happens.
> Here is the output after using ehci_info

> [ 469.389759] usb 5-2: New USB device found, idVendor=0801, idProduct=2231
> [ 469.389766] usb 5-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
> [ 469.389772] usb 5-2: Product: STX
> [ 469.389777] usb 5-2: Manufacturer: MagTek
> [ 469.389781] usb 5-2: SerialNumber: STX001
> [ 469.393023] ehci_hcd 0000:00:1d.7: irq status c028 masked 20
> [ 507.575453] ehci_hcd 0000:00:1d.7: irq status 600b masked 3
> [ 507.575465] ehci_hcd 0000:00:1d.7: devpath 2 ep2in 3strikes
> [ 507.575470] drivers/usb/serial/magtek.c: magtek_read_int_callback - port 1
> [ 507.575484] usb 5-2: unlink qh0-00ff/ded71100 start 0 [1/0 us]
> [ 507.576084] usb 5-2: link qh0-00ff/ded71100 start 0 [1/0 us]
> [ 507.576548] usb 5-2: unlink qh0-00ff/ded71100 start 0 [1/0 us]
> [ 507.576548] ehci_hcd 0000:00:1d.7: HC died; cleaning up

For some reason this "HC died" line doesn't appear in your previous
log. I wonder why not?

> I have observed that IRQ status has changed to c028, how do I decode the irq
> status. This causes the IRQ disabled.Detailed log is below.

No, you're wrong. Look at the timestamps. The status was c028 when
you plugged in the device; it changed to 600b when you unplugged it.
This didn't cause the the IRQ to be disabled, but it is an indication
of where the problem really lies.

To decode the IRQ status values you need to consult the EHCI
specification, section 2.3.2.

We need more information to track this down farther. Add three copies
of this statement:

ehci_info(ehci, "hcd state %d\n", hcd->state);

to the ehci_irq() function: one just before the line that says

/* PCI errors [4.15.2.4] */

then below that just before the line that says

spin_unlock (&ehci->lock);

and then just before the line that says

return IRQ_HANDLED;

Make one other change as well, also in ehci-hcd.c. In the function
handshake_on_error_set_halt(), change these lines:

if (error)
ehci_to_hcd(ehci)->state = HC_STATE_HALT;

to this:

if (error) {
ehci_to_hcd(ehci)->state = HC_STATE_HALT;
ehci_err(ehci, "Handshake failed; controller halted\n");
dump_stack();
}

Maybe these will help us find where the problem comes from.

Alan Stern

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