USB problem with Haswell+LynxPointLP motherboards

[Аладышев Константин]

I try to port coreboot on boards with Haswell CPU and Lynxpoint LP chipset
(IBASE IB908AF-4650 board, DFI HU968) and I've encountered a strange
problem. USB devices stop working shortly after OS boot (or after USB device
replug in OS) with flooding system with messages:

hub 1-1:1.0: cannot reset port 5 (err = -110)
hub 1-1:1.0: cannot reset port 5 (err = -110)
hub 1-1:1.0: Cannot enable port 5.  Maybe the USB cable is bad?
hub 1-1:1.0: cannot disable port 5 (err = -110)
hub 1-1:1.0: connect-debounce failed, port 5 disabled
hub 1-1:1.0: unable to enumerate USB device on port 5
hub 1-1:1.0: cannot disable port 5 (err = -110)
hub 1-1:1.0: hub_port_status failed (err = -110)
hub 1-1:1.0: hub_port_status failed (err = -110)

Through some digging I've found out that this problem persist on kernels
<3.5. I've investigated this problem more closely and come down to the fact
that the kernel commit that solves this problem is:

3d9545c EHCI: maintain the ehci->command value properly

https://github.com/torvalds/linux/commit/3d9545cc375d117554a9b35dfddadf9189c
62775?diff=split

And now I'm kinda stuck. The effect of this commit doesn't seem to interface
with bios for me. So how does original IBASE/DFI bios can overcome code
error before this commit?

What can be the source of my problem? What should I investigate more precise
based on result that I've got?

[Trammell Hudson]

On Mon, Oct 09, 2017 at 12:58:25PM +0300, Аладышев Константин wrote:
> I try to port coreboot on boards with Haswell CPU and Lynxpoint LP chipset
> (IBASE IB908AF-4650 board, DFI HU968) and I've encountered a strange
> problem. USB devices stop working shortly after OS boot (or after USB device
> replug in OS) with flooding system with messages:

Interesting -- I ran into the exact same bug with Haswell while porting
the NERF firmware and a 4.9.x kernel, and had attributed it to my not
setting up something right.  It's good to hear that maybe it isn't my
fault (maybe).
> [...]
> Through some digging I've found out that this problem persist on kernels
> <3.5. I've investigated this problem more closely and come down to the fact
> that the kernel commit that solves this problem is:
>
> 3d9545c EHCI: maintain the ehci->command value properly
>
> https://github.com/torvalds/linux/commit/3d9545cc375d117554a9b35dfddadf9189c 62775?diff=split

Does it work if you back out that patch?  For my purpose it might be
enough to maintain a patch until we figure out what is really going on.

[ron minnich]

this kind of thing is pretty common. Linux has intermittent problems
working on machines built without a real(TM) bios. Few people test in
unnatural(TM) coreboot environments so you see errors you might not expect.
I've had this off and on since we started in 1999 ....

On Mon, Oct 9, 2017 at 5:26 AM Trammell Hudson  wrote:
> On Mon, Oct 09, 2017 at 12:58:25PM +0300, Аладышев Константин wrote:
> > I try to port coreboot on boards with Haswell CPU and Lynxpoint LP
>
> chipset
> > (IBASE IB908AF-4650 board, DFI HU968) and I've encountered a strange
> > problem. USB devices stop working shortly after OS boot (or after USB
>
> device
> > replug in OS) with flooding system with messages:
>
> Interesting -- I ran into the exact same bug with Haswell while porting
> the NERF firmware and a 4.9.x kernel, and had attributed it to my not
> setting up something right.  It's good to hear that maybe it isn't my
> fault (maybe).
> > [...]
> > Through some digging I've found out that this problem persist on kernels
> > <3.5. I've investigated this problem more closely and come down to the
>
> fact
> > that the kernel commit that solves this problem is:
> >
> > 3d9545c EHCI: maintain the ehci->command value properly
>
> https://github.com/torvalds/linux/commit/3d9545cc375d117554a9b35dfddadf9189c
> 62775?diff=split
>
> Does it work if you back out that patch?  For my purpose it might be
> enough to maintain a patch until we figure out what is really going on.

[Zoran Stojsavljevic]

Potihon6ky rebjatiski... Tiho! Daite mne vremja razobratsja!

Thank you,
Zoran

On Mon, Oct 9, 2017 at 11:58 AM, Аладышев Константин 
wrote:
> I try to port coreboot on boards with Haswell CPU and Lynxpoint LP chipset
> (IBASE IB908AF-4650 board, DFI HU968) and I've encountered a strange
> problem. USB devices stop working shortly after OS boot (or after USB
> device
> replug in OS) with flooding system with messages:
>
> hub 1-1:1.0: cannot reset port 5 (err = -110)
> hub 1-1:1.0: cannot reset port 5 (err = -110)
> hub 1-1:1.0: Cannot enable port 5.  Maybe the USB cable is bad?
> hub 1-1:1.0: cannot disable port 5 (err = -110)
> hub 1-1:1.0: connect-debounce failed, port 5 disabled
> hub 1-1:1.0: unable to enumerate USB device on port 5
> hub 1-1:1.0: cannot disable port 5 (err = -110)
> hub 1-1:1.0: hub_port_status failed (err = -110)
> hub 1-1:1.0: hub_port_status failed (err = -110)
>
> Through some digging I've found out that this problem persist on kernels
> <3.5. I've investigated this problem more closely and come down to the fact
> that the kernel commit that solves this problem is:
>
> 3d9545c EHCI: maintain the ehci->command value properly
>
> https://github.com/torvalds/linux/commit/3d9545cc375d117554a9b35dfddadf
> 9189c
> 62775?diff=split
>
> And now I'm kinda stuck. The effect of this commit doesn't seem to
> interface
> with bios for me. So how does original IBASE/DFI bios can overcome code
> error before this commit?
>
> What can be the source of my problem? What should I investigate more
> precise
> based on result that I've got?

[Julius Werner]

> And now I'm kinda stuck. The effect of this commit doesn't seem to interface
> with bios for me. So how does original IBASE/DFI bios can overcome code
> error before this commit?
>
> What can be the source of my problem? What should I investigate more precise
> based on result that I've got?

My gut feeling would be to blame ACPI. The Linux patch is about
caching a host controller register in the kernel, and in some cases
(e.g. ehci_reset()), the patch re-reads the cached version from the
hardware whereas the previous code didn't. If some BIOS ACPI mucks
with that register, it's possible that this got the kernel's cached
copy out of sync before this patch, but with the patch the kernel will
re-read it from the hardware at the right time. Maybe only coreboot's
ACPI routines touch the register in that path, or maybe the vendor
BIOS' routines were more careful to restore the original state
afterwards.

Besides ACPI this could also be in SMM code, I guess (especially if
the problem occurs around system suspend/resume, although it sounds
like it doesn't for you).

[Zoran Stojsavljevic]

Hello Kostja,

We already had this discussion a while ago, didn't we?

https://mail.coreboot.org/pipermail/coreboot/2016-December/082772.html

(BTW, ATOM BYT has exactly the same problem)

Zoran

On Mon, Oct 9, 2017 at 11:58 AM, Аладышев Константин 
wrote:
> I try to port coreboot on boards with Haswell CPU and Lynxpoint LP chipset
> (IBASE IB908AF-4650 board, DFI HU968) and I've encountered a strange
> problem. USB devices stop working shortly after OS boot (or after USB
> device
> replug in OS) with flooding system with messages:
>
> hub 1-1:1.0: cannot reset port 5 (err = -110)
> hub 1-1:1.0: cannot reset port 5 (err = -110)
> hub 1-1:1.0: Cannot enable port 5.  Maybe the USB cable is bad?
> hub 1-1:1.0: cannot disable port 5 (err = -110)
> hub 1-1:1.0: connect-debounce failed, port 5 disabled
> hub 1-1:1.0: unable to enumerate USB device on port 5
> hub 1-1:1.0: cannot disable port 5 (err = -110)
> hub 1-1:1.0: hub_port_status failed (err = -110)
> hub 1-1:1.0: hub_port_status failed (err = -110)
>
> Through some digging I've found out that this problem persist on kernels
> <3.5. I've investigated this problem more closely and come down to the fact
> that the kernel commit that solves this problem is:
>
> 3d9545c EHCI: maintain the ehci->command value properly
>
> https://github.com/torvalds/linux/commit/3d9545cc375d117554a9b35dfddadf
> 9189c
> 62775?diff=split
>
> And now I'm kinda stuck. The effect of this commit doesn't seem to
> interface
> with bios for me. So how does original IBASE/DFI bios can overcome code
> error before this commit?
>
> What can be the source of my problem? What should I investigate more
> precise
> based on result that I've got?