Re: broken EHCI USB on AMD chipset?

2017-12-01 Thread Paul B. Henson
> From: Stefan Sperling
> Sent: Friday, December 1, 2017 10:35 AM
> 
> Problems with ehci(4) on AMD SB700 are known.
> For instance, athn(4) USB devices don't work on such ports.

Interesting; that's a similar device to the LTE network modem I'm working
with.

> Could you try adding missing workarounds to our EHCI driver to fix
> your problem? That would probably help with other known issues, too.

Hmm, sadly low level device drivers aren't my area of expertise :(. I was
trying to compare the Linux driver, but it is structured quite differently
than the openbsd one. Now that I see that the FreeBSD one works, at least as
far as hot plug/remove, it is more similar to the openbsd driver, I'll see
if I can pick anything out of it that I can make sense out of to add to
openbsd.

I did find a section of code in OpenBSD's echi_pci.c with a comment of
"Enable workaround for dropped interrupts as required" which was being
applied to ATI chipsets; I was excited for a moment as that seems to be
exactly the problem being experienced and AMD bought ATI, so I hoped perhaps
enabling that for my AMD chipset would do something, but unfortunately all
it did was result in interrupt timed out messages .

There's another function called ehci_sb700_match that's looking for an ATI
chipset, which controls whether or not to "apply the ATI SB600/SB700
workaround", those are also the names of the AMD controllers, I'm going to
look to see if perhaps those should be applied or not and if they do
anything.

If my shooting in the dark comes up with anything promising I'll bring it
back to show somebody who knows what they're doing :).

Thanks.



Re: broken EHCI USB on AMD chipset?

2017-12-01 Thread Stefan Sperling
On Tue, Nov 28, 2017 at 08:03:05PM -0800, Paul B. Henson wrote:
> The EHCI ports seem to work fine under Linux, including the LTE modem
> when attached to them, so this seems to be an issue with openbsd, not
> faulty hardware per se. The Linux driver does have a couple of
> workarounds in their EHCI driver for AMD chipsets, I'm not sure if
> either of them are relevant for this; one involves disabling low power
> mode during transfers and the other says:
> 
> "EHCI controller on AMD SB700/SB800/Hudson-2/3 platforms may
> read/write memory space which does not belong to it when
> there is NULL pointer with T-bit set to 1 in the frame list
> table. To avoid the issue, the frame list link pointer
> should always contain a valid pointer to a inactive qh"
> 
> I don't see anything specifically discussing flaky interrupts. Any
> thoughts on what might be going on here with USB and how it fix it?
> 

Problems with ehci(4) on AMD SB700 are known.
For instance, athn(4) USB devices don't work on such ports.

Could you try adding missing workarounds to our EHCI driver to fix
your problem? That would probably help with other known issues, too.



Re: broken EHCI USB on AMD chipset?

2017-11-30 Thread Paul B. Henson
On Tue, Nov 28, 2017 at 08:03:05PM -0800, Paul B. Henson wrote:

> The EHCI ports seem to work fine under Linux, including the LTE modem
> when attached to them, so this seems to be an issue with openbsd, not
> faulty hardware per se.

I tested FreeBSD on this box as well, it detected the EHCI ports as:

usbus1: EHCI version 1.0
usbus1 on ehci0
usbus1: 480Mbps High Speed USB v2.0
usbus2: EHCI version 1.0
usbus2 on ehci1
usbus2: 480Mbps High Speed USB v2.0
ugen1.1:  at usbus1
ugen2.1:  at usbus2
uhub0:  on usbus1
 on usbus2
ugen1.2:  at usbus1
uhub3: 
on usb
us1
ugen2.2:  at usbus2
uhub4: 
on usb
us2

As far as I can tell the ports work ok under FreeBSD, detecting hot plug
and removal of devices, and the interrupt count from vmstat -i increases
when doing so. FreeBSD doesn't support the Sierra Wireless card I have
but I'm guessing it would work.

So it just seems to be an issue with OpenBSD and this board or USB
chipset or something. I turned on debugging in the ehci and uhub code,
but when I plug something in nothing whatsoever happens, so that wasn't
very useful. Any suggestions on other debugging to enable or any other
approach to figure out what's going on here?

Thanks...