Re: EHCI host broken -- interrupts disabled

Re: EHCI host broken -- interrupts disabled

[Bjorn Helgaas]

[+cc linux-pci]

On Tue, Jan 14, 2014 at 11:47 AM, Alan Stern <stern@rowland.harvard.edu> wrote:
> On Tue, 14 Jan 2014, Sarah Sharp wrote:
>
>> Hi Alan,
>
> I'm not a good person to ask about this.  Maybe Bjorn can help.
>
>> All this info is second- or third-hand, so please excuse the extremely
>> vague bug report.
>>
>> A new Intel Atom system (Baytrail) comes with both an xHCI host and an
>> EHCI host, but the BIOS has an "EHCI only" option that hides the xHCI
>> host PCI device from the operating system.  It appears that when the
>> BIOS is in this mode, the EHCI PCI interrupt is disabled, and the host
>> simply doesn't work.
>>
>> Jamie and Gaggery have more details about the system and the exact
>> failure mode.  They can provide dmesg as well as a PCI register space
>> dump, if necessary.  (Jamie and Gaggery, please note, a publicly
>> archived mailing list is Cc'ed.)
>>
>> A customer reports that the following patch fixes the issue:
>>
>> diff --git a/drivers/usb/host/ehci-pci.c b/drivers/usb/host/ehci-pci.c
>> index 3e86bf4371b3..e77566a021ec 100644
>> --- a/drivers/usb/host/ehci-pci.c
>> +++ b/drivers/usb/host/ehci-pci.c
>> @@ -112,6 +112,9 @@ static int ehci_pci_setup(struct usb_hcd *hcd)
>>       case PCI_VENDOR_ID_INTEL:
>>               if (pdev->device == PCI_DEVICE_ID_INTEL_CE4100_USB)
>>                       hcd->has_tt = 1;
>> +             /* Baytrail BIOS in EHCI only mode fails to enable interrupts */
>> +             if (pdev->device == 0x0f34)
>> +                     pci_intx(pdev, 1);
>>               break;
>>       case PCI_VENDOR_ID_TDI:
>>               if (pdev->device == PCI_DEVICE_ID_TDI_EHCI)
>>
>> I looked through the USB PCI initialization code, and I can't find any
>> place where interrupts are enabled, so I assume the PCI core is supposed
>> to enable interrupts?  Or is it assumed that the system boots with all
>> PCI device interrupts enabled?  In that case, is it a BIOS issue?
>
> As I recall, the original PCI spec did not include any way to enable or
> disable interrupts -- a rather surprising omission.  It was added
> later on.
>
> Anyhow, this is all handled in the PCI core.  The device driver
> shouldn't need to do much more than pci_enable_device() (which handles
> power plus I/O and memory resources) and pci_set_master() (which
> handles DMA).  Nothing about enabling interrupt generation.
>
> A quick search did not show any place where the PCI core explicitly
> enables interrupts on new devices, so maybe it does assume that the
> firmware always enables them.  I don't know what guarantees (if any) a
> BIOS is supposed to fulfill.
>
> It seems like the best place to fix this is probably in the PCI core.

I think dev->irq is supposed to be valid after pci_enable_device(), so
it seems like it would make sense to clear PCI_COMMAND_INTX_DISABLE
there.

I don't know why a BIOS would leave PCI_COMMAND_INTX_DISABLE set for
the EHCI device.  Does it support MSI, and the BIOS assumes the OS
should use that?  I don't see any MSI support in the EHCI code.  In
any case, this doesn't seem like something we need to depend on the
BIOS to do for us.

Bjorn

Re: EHCI host broken -- interrupts disabled

[Alan Stern]

On Thu, 16 Jan 2014, Bjorn Helgaas wrote:

> I think dev->irq is supposed to be valid after pci_enable_device(), so
> it seems like it would make sense to clear PCI_COMMAND_INTX_DISABLE
> there.

Okay.

> I don't know why a BIOS would leave PCI_COMMAND_INTX_DISABLE set for
> the EHCI device.  Does it support MSI, and the BIOS assumes the OS
> should use that?  I don't see any MSI support in the EHCI code.  In

As far as I know, there aren't any EHCI designs that use MSI.  And
there is no particular reason why a BIOS would leave INTX_DISABLE set,
although come to think of it, there doesn't seem to be any reason why a
BIOS should leave that bit clear either.

> any case, this doesn't seem like something we need to depend on the
> BIOS to do for us.

Could you post a patch for Gaggery or Jamie to try out?

Alan Stern

Re: EHCI host broken -- interrupts disabled

[Bjorn Helgaas]

On Thu, Jan 16, 2014 at 02:40:35PM -0500, Alan Stern wrote:
> On Thu, 16 Jan 2014, Bjorn Helgaas wrote:
> 
> > I think dev->irq is supposed to be valid after pci_enable_device(), so
> > it seems like it would make sense to clear PCI_COMMAND_INTX_DISABLE
> > there.
> 
> Okay.
> 
> > I don't know why a BIOS would leave PCI_COMMAND_INTX_DISABLE set for
> > the EHCI device.  Does it support MSI, and the BIOS assumes the OS
> > should use that?  I don't see any MSI support in the EHCI code.  In
> 
> As far as I know, there aren't any EHCI designs that use MSI.  And
> there is no particular reason why a BIOS would leave INTX_DISABLE set,
> although come to think of it, there doesn't seem to be any reason why a
> BIOS should leave that bit clear either.
> 
> > any case, this doesn't seem like something we need to depend on the
> > BIOS to do for us.
> 
> Could you post a patch for Gaggery or Jamie to try out?

Can you try the patch below?  This is against 6e2d98dc1af4, the tip of the
PCI "next" branch, but it should apply easily to any recent kernel.

Can you also collect the dmesg and "lspci -vv" output for reference, in
case we need to tweak or rework this in the future?  Please remove any
non-public details from that information before posting it.

Bjorn


PCI: Enable INTx if BIOS left it disabled

From: Bjorn Helgaas <bhelgaas@google.com>

Some firmware leaves the Interrupt Disable bit set even if the device uses
INTx interrupts.  Clear Interrupt Disable so we get those interrupts.

Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
---
 drivers/pci/pci.c |   10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index b6d4afa8ba40..0b6a1119b818 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -1181,6 +1181,8 @@ EXPORT_SYMBOL_GPL(pci_load_and_free_saved_state);
 static int do_pci_enable_device(struct pci_dev *dev, int bars)
 {
 	int err;
+	u16 cmd;
+	u8 pin;
 
 	err = pci_set_power_state(dev, PCI_D0);
 	if (err < 0 && err != -EIO)
@@ -1190,6 +1192,14 @@ static int do_pci_enable_device(struct pci_dev *dev, int bars)
 		return err;
 	pci_fixup_device(pci_fixup_enable, dev);
 
+	pci_read_config_byte(dev, PCI_INTERRUPT_PIN, &pin);
+	if (pin) {
+		pci_read_config_word(dev, PCI_COMMAND, &cmd);
+		if (cmd & PCI_COMMAND_INTX_DISABLE)
+			pci_write_config_word(dev, PCI_COMMAND,
+					      cmd & ~PCI_COMMAND_INTX_DISABLE);
+	}
+
 	return 0;
 }
 

RE: EHCI host broken -- interrupts disabled

[Chen, Jamie]

Try to apply this patch to kernel 3.8.0.

Make sure the ehci can work fine and lspci show that PCI_COMMAND_INTX_DISABLE is 0.

The patch can resolved this issue.

#lspci -vv

00:1d.0 USB controller: Intel Corporation Device 0f34 (rev 0a) (prog-if 20 [EHCI])
	Subsystem: Intel Corporation Device 7270
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin A routed to IRQ 23
	Region 0: Memory at 90612000 (32-bit, non-prefetchable) [size=1K]
	Capabilities: [50] Power Management version 3
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [58] Debug port: BAR=1 offset=00a0
	Capabilities: [98] PCI Advanced Features
		AFCap: TP+ FLR+
		AFCtrl: FLR-
		AFStatus: TP-
	Kernel driver in use: ehci-pci

dmesg:
[    1.014556] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    1.014559] ehci-pci: EHCI PCI platform driver
[    1.014612] ehci-pci 0000:00:1d.0: setting latency timer to 64
[    1.014618] ehci-pci 0000:00:1d.0: EHCI Host Controller
[    1.014629] ehci-pci 0000:00:1d.0: new USB bus registered, assigned bus number 1
[    1.014652] ehci-pci 0000:00:1d.0: debug port 2
[    1.018562] ehci-pci 0000:00:1d.0: cache line size of 64 is not supported
[    1.018594] ehci-pci 0000:00:1d.0: irq 23, io mem 0x90612000
[    1.029238] ehci-pci 0000:00:1d.0: USB 2.0 started, EHCI 1.00
[    1.029274] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[    1.029279] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    1.029283] usb usb1: Product: EHCI Host Controller
[    1.029286] usb usb1: Manufacturer: Linux 3.8.13.13-pci ehci_hcd
[    1.029290] usb usb1: SerialNumber: 0000:00:1d.0
[    1.029469] hub 1-0:1.0: USB hub found
[    1.029785] ehci-platform: EHCI generic platform driver
[    1.340641] usb 1-1: new high-speed USB device number 2 using ehci-pci
[    1.473442] usb 1-1: New USB device found, idVendor=8087, idProduct=07e6
[    1.473447] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[    1.475095] hub 1-1:1.0: USB hub found
[    1.749587] usb 1-1.2: new high-speed USB device number 3 using ehci-pci
[    1.841046] usb 1-1.2: New USB device found, idVendor=05e3, idProduct=0608
[    1.841052] usb 1-1.2: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[    1.841056] usb 1-1.2: Product: USB2.0 Hub
[    1.841469] hub 1-1.2:1.0: USB hub found
[    2.115558] usb 1-1.2.1: new high-speed USB device number 4 using ehci-pci
[    2.208321] usb 1-1.2.1: New USB device found, idVendor=05e3, idProduct=0608
[    2.208327] usb 1-1.2.1: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[    2.208331] usb 1-1.2.1: Product: USB2.0 Hub
[    2.209113] hub 1-1.2.1:1.0: USB hub found
[    2.283104] usb 1-1.2.3: new low-speed USB device number 5 using ehci-pci
[    2.378487] usb 1-1.2.3: New USB device found, idVendor=03f0, idProduct=0c4a
[    2.378492] usb 1-1.2.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[    2.378496] usb 1-1.2.3: Product: HP
[    2.378500] usb 1-1.2.3: Manufacturer: HP
[    2.385945] usbcore: registered new interface driver usbhid
[    2.385950] usbhid: USB HID core driver
[   11.550722] input: HP HP as /devices/pci0000:00/0000:00:1d.0/usb1/1-1/1-1.2/1-1.2.3/1-1.2.3:1.0/input/input5
[   11.550963] hid-generic 0003:03F0:0C4A.0001: input,hidraw0: USB HID v1.11 Mouse [HP HP] on usb-0000:00:1d.0-1.2.3/input0


Jamie

Re: EHCI host broken -- interrupts disabled

[Sarah Sharp]

On Mon, Jan 20, 2014 at 12:15:47PM +0000, Chen, Jamie wrote:
> Try to apply this patch to kernel 3.8.0.
> 
> Make sure the ehci can work fine and lspci show that PCI_COMMAND_INTX_DISABLE is 0.
> 
> The patch can resolved this issue.

Great!  Thanks for testing, Jamie.

Bjorn, can you add me to the Cc list for this patch?  I'd like to notify
other Linux distros when it lands so they can pick it up.

Sarah Sharp

> 
> #lspci -vv
> 
> 00:1d.0 USB controller: Intel Corporation Device 0f34 (rev 0a) (prog-if 20 [EHCI])
> 	Subsystem: Intel Corporation Device 7270
> 	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
> 	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
> 	Latency: 0
> 	Interrupt: pin A routed to IRQ 23
> 	Region 0: Memory at 90612000 (32-bit, non-prefetchable) [size=1K]
> 	Capabilities: [50] Power Management version 3
> 		Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
> 		Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
> 	Capabilities: [58] Debug port: BAR=1 offset=00a0
> 	Capabilities: [98] PCI Advanced Features
> 		AFCap: TP+ FLR+
> 		AFCtrl: FLR-
> 		AFStatus: TP-
> 	Kernel driver in use: ehci-pci
> 
> dmesg:
> [    1.014556] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
> [    1.014559] ehci-pci: EHCI PCI platform driver
> [    1.014612] ehci-pci 0000:00:1d.0: setting latency timer to 64
> [    1.014618] ehci-pci 0000:00:1d.0: EHCI Host Controller
> [    1.014629] ehci-pci 0000:00:1d.0: new USB bus registered, assigned bus number 1
> [    1.014652] ehci-pci 0000:00:1d.0: debug port 2
> [    1.018562] ehci-pci 0000:00:1d.0: cache line size of 64 is not supported
> [    1.018594] ehci-pci 0000:00:1d.0: irq 23, io mem 0x90612000
> [    1.029238] ehci-pci 0000:00:1d.0: USB 2.0 started, EHCI 1.00
> [    1.029274] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
> [    1.029279] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
> [    1.029283] usb usb1: Product: EHCI Host Controller
> [    1.029286] usb usb1: Manufacturer: Linux 3.8.13.13-pci ehci_hcd
> [    1.029290] usb usb1: SerialNumber: 0000:00:1d.0
> [    1.029469] hub 1-0:1.0: USB hub found
> [    1.029785] ehci-platform: EHCI generic platform driver
> [    1.340641] usb 1-1: new high-speed USB device number 2 using ehci-pci
> [    1.473442] usb 1-1: New USB device found, idVendor=8087, idProduct=07e6
> [    1.473447] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
> [    1.475095] hub 1-1:1.0: USB hub found
> [    1.749587] usb 1-1.2: new high-speed USB device number 3 using ehci-pci
> [    1.841046] usb 1-1.2: New USB device found, idVendor=05e3, idProduct=0608
> [    1.841052] usb 1-1.2: New USB device strings: Mfr=0, Product=1, SerialNumber=0
> [    1.841056] usb 1-1.2: Product: USB2.0 Hub
> [    1.841469] hub 1-1.2:1.0: USB hub found
> [    2.115558] usb 1-1.2.1: new high-speed USB device number 4 using ehci-pci
> [    2.208321] usb 1-1.2.1: New USB device found, idVendor=05e3, idProduct=0608
> [    2.208327] usb 1-1.2.1: New USB device strings: Mfr=0, Product=1, SerialNumber=0
> [    2.208331] usb 1-1.2.1: Product: USB2.0 Hub
> [    2.209113] hub 1-1.2.1:1.0: USB hub found
> [    2.283104] usb 1-1.2.3: new low-speed USB device number 5 using ehci-pci
> [    2.378487] usb 1-1.2.3: New USB device found, idVendor=03f0, idProduct=0c4a
> [    2.378492] usb 1-1.2.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
> [    2.378496] usb 1-1.2.3: Product: HP
> [    2.378500] usb 1-1.2.3: Manufacturer: HP
> [    2.385945] usbcore: registered new interface driver usbhid
> [    2.385950] usbhid: USB HID core driver
> [   11.550722] input: HP HP as /devices/pci0000:00/0000:00:1d.0/usb1/1-1/1-1.2/1-1.2.3/1-1.2.3:1.0/input/input5
> [   11.550963] hid-generic 0003:03F0:0C4A.0001: input,hidraw0: USB HID v1.11 Mouse [HP HP] on usb-0000:00:1d.0-1.2.3/input0
> 
> 
> Jamie

Re: EHCI host broken -- interrupts disabled

[Greg KH]

On Mon, Jan 20, 2014 at 11:39:18AM -0800, Sarah Sharp wrote:
> On Mon, Jan 20, 2014 at 12:15:47PM +0000, Chen, Jamie wrote:
> > Try to apply this patch to kernel 3.8.0.
> > 
> > Make sure the ehci can work fine and lspci show that PCI_COMMAND_INTX_DISABLE is 0.
> > 
> > The patch can resolved this issue.
> 
> Great!  Thanks for testing, Jamie.
> 
> Bjorn, can you add me to the Cc list for this patch?  I'd like to notify
> other Linux distros when it lands so they can pick it up.

Might as well mark it for stable@vger.kernel.org, so that it does
automatically get propagated to the distros...

thanks,

greg k-h

Re: EHCI host broken -- interrupts disabled

[Bjorn Helgaas]

On Mon, Jan 20, 2014 at 5:15 AM, Chen, Jamie <jamie.chen@intel.com> wrote:
> Try to apply this patch to kernel 3.8.0.
>
> Make sure the ehci can work fine and lspci show that PCI_COMMAND_INTX_DISABLE is 0.
>
> The patch can resolved this issue.

Thanks for testing it.  Can you collect the complete dmesg output or
dmidecode output?  (Remove secret details from it, of course.)

I'm going to put this info into a bugzilla report for future reference.

Bjorn

Re: EHCI host broken -- interrupts disabled

[Bjorn Helgaas]

On Wed, Jan 29, 2014 at 5:04 PM, Bjorn Helgaas <bhelgaas@google.com> wrote:
> On Mon, Jan 20, 2014 at 5:15 AM, Chen, Jamie <jamie.chen@intel.com> wrote:
>> Try to apply this patch to kernel 3.8.0.
>>
>> Make sure the ehci can work fine and lspci show that PCI_COMMAND_INTX_DISABLE is 0.
>>
>> The patch can resolved this issue.
>
> Thanks for testing it.  Can you collect the complete dmesg output or
> dmidecode output?  (Remove secret details from it, of course.)
>
> I'm going to put this info into a bugzilla report for future reference.

Ping, I'm ready to apply this, just waiting for the dmesg log.

Bjorn

Re: EHCI host broken -- interrupts disabled

[Bjorn Helgaas]

On Fri, Feb 14, 2014 at 9:36 AM, Chen, Jamie <jamie.chen@intel.com> wrote:
> Sorry for late response.
>
> The dmesg attach in the mail.

Thanks, I put this info in
https://bugzilla.kernel.org/show_bug.cgi?id=70601 and applied the
patch to pci/misc.

This seems like a potentially important fix, so I think I'll
cherry-pick it into for-linus for v3.14.

Bjorn

>> -----Original Message-----
>> From: Bjorn Helgaas [mailto:bhelgaas@google.com]
>> Sent: Wednesday, February 12, 2014 7:24 AM
>> To: Chen, Jamie
>> Cc: Alan Stern; Sarah Sharp; USB list; Tsai, Gaggery; linux-pci@vger.kernel.org
>> Subject: Re: EHCI host broken -- interrupts disabled
>>
>> On Wed, Jan 29, 2014 at 5:04 PM, Bjorn Helgaas <bhelgaas@google.com>
>> wrote:
>> > On Mon, Jan 20, 2014 at 5:15 AM, Chen, Jamie <jamie.chen@intel.com>
>> wrote:
>> >> Try to apply this patch to kernel 3.8.0.
>> >>
>> >> Make sure the ehci can work fine and lspci show that
>> PCI_COMMAND_INTX_DISABLE is 0.
>> >>
>> >> The patch can resolved this issue.
>> >
>> > Thanks for testing it.  Can you collect the complete dmesg output or
>> > dmidecode output?  (Remove secret details from it, of course.)
>> >
>> > I'm going to put this info into a bugzilla report for future reference.
>>
>> Ping, I'm ready to apply this, just waiting for the dmesg log.
>>
>> Bjorn

Re: EHCI host broken -- interrupts disabled

[Sarah Sharp]

On Fri, Feb 14, 2014 at 01:47:48PM -0700, Bjorn Helgaas wrote:
> On Fri, Feb 14, 2014 at 9:36 AM, Chen, Jamie <jamie.chen@intel.com> wrote:
> > Sorry for late response.
> >
> > The dmesg attach in the mail.
> 
> Thanks, I put this info in
> https://bugzilla.kernel.org/show_bug.cgi?id=70601 and applied the
> patch to pci/misc.
> 
> This seems like a potentially important fix, so I think I'll
> cherry-pick it into for-linus for v3.14.

Thanks, Bjorn!

Do you think this patch is a candidate for stable as well?  Anyone with
an EHCI-only Baytrail system won't have working USB without this patch,
and the patch itself seems relatively small.

Sarah Sharp

Re: EHCI host broken -- interrupts disabled

[Bjorn Helgaas]

On Fri, Feb 14, 2014 at 3:27 PM, Sarah Sharp
<sarah.a.sharp@linux.intel.com> wrote:
> On Fri, Feb 14, 2014 at 01:47:48PM -0700, Bjorn Helgaas wrote:
>> On Fri, Feb 14, 2014 at 9:36 AM, Chen, Jamie <jamie.chen@intel.com> wrote:
>> > Sorry for late response.
>> >
>> > The dmesg attach in the mail.
>>
>> Thanks, I put this info in
>> https://bugzilla.kernel.org/show_bug.cgi?id=70601 and applied the
>> patch to pci/misc.
>>
>> This seems like a potentially important fix, so I think I'll
>> cherry-pick it into for-linus for v3.14.
>
> Thanks, Bjorn!
>
> Do you think this patch is a candidate for stable as well?  Anyone with
> an EHCI-only Baytrail system won't have working USB without this patch,
> and the patch itself seems relatively small.

Yep, I marked it for stable.  I'll ask Linus to pull it early next
week, after it has appeared in at least one -next kernel.

Bjorn

Re: USB EHCI broken on Celeron N2920 (Bay Trail)

[Sarah Sharp]

Hi Chris,

We think the Baytrail BIOS has an issue where it doesn't set the EHCI
PCI interrupt enable bit when the computer is in "EHCI only mode".
Please try this patch:

http://marc.info/?l=linux-usb&m=138998295909608&w=2

Sarah Sharp

On Tue, Jan 21, 2014 at 10:04:41PM +0800, Chris Cheng wrote:
> I'm sorry forgot kernel version: 3.13.0 .
> --
> Chris Cheng  鄭宇廷
> Atrust Computer Corp.  冠信電腦股份有限公司
> http://www.atrustcorp.com
> Tel: +886-3-3288837 ext.1074
> 3F., No.361, Fusing 1st Rd., Gueishan Township, Taoyuan County 333, Taiwan
> 333 桃園縣龜山鄉復興一路361號3F
> 
> 
> 2014/1/21 Chris Cheng <chris.cheng@atrustcorp.com>:
> > Here is kernel message:
> >
> > [    2.939251] usb 1-1: new high-speed USB device number 2 using ehci-pci
> > [   18.490987] usb 1-1: device not accepting address 2, error -110
> > [   18.595095] usb 1-1: new high-speed USB device number 3 using ehci-pci
> > [   34.182233] usb 1-1: device not accepting address 3, error -110
> > [   34.286352] usb 1-1: new high-speed USB device number 4 using ehci-pci
> > [   44.744589] usb 1-1: device not accepting address 4, error -110
> > [   44.849590] usb 1-1: new high-speed USB device number 5 using ehci-pci
> > [   55.307858] usb 1-1: device not accepting address 5, error -110
> > [   55.310239] hub 1-0:1.0: unable to enumerate USB device on port 1
> >
> > Thanks.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB EHCI broken on Celeron N2920 (Bay Trail)

[Chris Cheng]

Hi Sarah,
    The patch is useful, thanks for your help.

Thanks.
--
Chris Cheng  鄭宇廷
Atrust Computer Corp.  冠信電腦股份有限公司
http://www.atrustcorp.com
Tel: +886-3-3288837 ext.1074
3F., No.361, Fusing 1st Rd., Gueishan Township, Taoyuan County 333, Taiwan
333 桃園縣龜山鄉復興一路361號3F


2014/1/22 Sarah Sharp <sarah.a.sharp@linux.intel.com>:
> Hi Chris,
>
> We think the Baytrail BIOS has an issue where it doesn't set the EHCI
> PCI interrupt enable bit when the computer is in "EHCI only mode".
> Please try this patch:
>
> http://marc.info/?l=linux-usb&m=138998295909608&w=2
>
> Sarah Sharp
>
> On Tue, Jan 21, 2014 at 10:04:41PM +0800, Chris Cheng wrote:
>> I'm sorry forgot kernel version: 3.13.0 .
>> --
>> Chris Cheng  鄭宇廷
>> Atrust Computer Corp.  冠信電腦股份有限公司
>> http://www.atrustcorp.com
>> Tel: +886-3-3288837 ext.1074
>> 3F., No.361, Fusing 1st Rd., Gueishan Township, Taoyuan County 333, Taiwan
>> 333 桃園縣龜山鄉復興一路361號3F
>>
>>
>> 2014/1/21 Chris Cheng <chris.cheng@atrustcorp.com>:
>> > Here is kernel message:
>> >
>> > [    2.939251] usb 1-1: new high-speed USB device number 2 using ehci-pci
>> > [   18.490987] usb 1-1: device not accepting address 2, error -110
>> > [   18.595095] usb 1-1: new high-speed USB device number 3 using ehci-pci
>> > [   34.182233] usb 1-1: device not accepting address 3, error -110
>> > [   34.286352] usb 1-1: new high-speed USB device number 4 using ehci-pci
>> > [   44.744589] usb 1-1: device not accepting address 4, error -110
>> > [   44.849590] usb 1-1: new high-speed USB device number 5 using ehci-pci
>> > [   55.307858] usb 1-1: device not accepting address 5, error -110
>> > [   55.310239] hub 1-0:1.0: unable to enumerate USB device on port 1
>> >
>> > Thanks.
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>