linux-kernel - Re: USB Serial device disconnect causes IRQ disable after using ehci

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.0808261036020.2493-100000@iolanthe.rowland.org>
Date:	Tue, 26 Aug 2008 11:01:51 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	amruth <amruth_pv@...oo.com>
cc:	Oliver Neukum <oliver@...kum.org>,
	USB list <linux-usb@...r.kernel.org>,
	Kernel development list <linux-kernel@...r.kernel.org>
Subject: Re: USB Serial device disconnect causes IRQ disable after using
 ehci_info

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/