[haiku-bugs] Re: [Haiku] #11619: No USB on Poulsbo hardware
- From: "mmlr" <trac@xxxxxxxxxxxx>
- Date: Thu, 04 Jun 2015 22:03:52 -0000
#11619: No USB on Poulsbo hardware
--------------------------------+----------------------------
Reporter: edglex | Owner: mmlr
Type: bug | Status: new
Priority: normal | Milestone: R1
Component: Drivers/USB/EHCI | Version: R1/Development
Resolution: | Keywords:
Blocked By: | Blocking:
Has a Patch: 1 | Platform: x86
--------------------------------+----------------------------
Comment (by mmlr):
Replying to [comment:13 edglex]:
I've been poking at this for a while today. With the supplied patch,
we're in an infinite loop. Apparently this happens with some hardware, it
is reported as a bug in illumos (
https://www.illumos.org/issues/4225) and
Linux actually only ever loops 64 times here before giving up. I've
checked and booting Linux I get an error that BIOS handoff failed, but USB
still works in Linux.
In PCI getting a value of 255 generally means an error or not present
device. So an extended capability pointer of 255 likely hints at a failure
to actually read the corresponding register, not that the capability
pointer actually has a value of 255.
Also since the device doesn't advertise the PCIe capability it should be
treated like a normal PCI device (which is usual for EHCI devices). In
that case the config space is only 256 bytes to begin with, making an
offset of 255 bytes not useful.
The bug report you linked describes exactly the same issue.
I noticed that Linux also attempts to disable interrupts and take
control regardless of whether this worked, so I attempted to do the same
thing (as well as looping 64 times before giving up), but although this
allows me to boot, I get reports that at least one of the writes failed,
and I still don't have working USB.
That's what the Haiku implementation does as well. It does only do so if
it finds the corresponding legacy support register, because it can't unset
the semaphore if there isn't one.
Generally not using the hand off mechanism is unproblematic as long as the
firmware does not have any SMIs (System Management Interrupts) enabled on
the device. Since the SMI enabled registers are also within the legacy
support registers, the same as above applies.
A failing reset would further point towards not actually getting sensible
values from/to the registers at all, as a reset should always work (even
if legacy support was enabled).
To debug this, please enable full tracing in ehci.cpp and also output and
post the value of the full EHCI_HCCPARAMS register:
{{{
TRACE_ALWAYS("host controller parameters: %#" B_PRIx32 "\n",
ReadCapReg32(EHCI_HCCPARAMS));
}}}
If reading the register fails as suspected it should output 0xffffffff.
I also tried through a hub, to rule out it being the same problem as
9118.
#9118 is not related to this. It is the opposite case where the UHCI root
port doesn't work whereas the EHCI one does (and using a 2.0 hub causes
the root port to be driven by EHCI).
What I don't understand is why it is failing to read/write the PCI
config register, this seems to be crucial. Any idea? I'm having trouble
following the rest of the linux spaghetti code, so can't figure out what
they do next.
The BSDs usually have code that is much easier to follow if you want to
compare other implementations.
--
Ticket URL: <
https://dev.haiku-os.org/ticket/11619#comment:18>
Haiku <
https://dev.haiku-os.org>
Haiku - the operating system.
Other related posts:
