[haiku-commits] Re: haiku: hrev52885 - src/add-ons/kernel/busses/usb
- From: waddlesplash <waddlesplash@xxxxxxxxx>
- Date: Tue, 19 Feb 2019 22:01:27 -0500
On Mon, Feb 18, 2019 at 12:23 PM waddlesplash <waddlesplash@xxxxxxxxx> wrote:
On Mon, Feb 18, 2019, 11:40 AM Greg Crain <gsc70@xxxxxxxxxxx wrote:
I'm trying to get back into the XHCI stuff.. I ran into the tracing problem
you fixed here, but didn't investigate deeper. I've been having trouble
compiling on my x64 machine.. It hard locks, and freezes with no debug
messages or anything.. It only happen while compiling Haiku!?
Yes, a user on the forums reported these symptoms, but nobody seems to have
got anywhere in investigating them. I've been slowly adding interrupt status
checks to functions that context-switch (in fact I added another yesterday,
so you might want to upgrade again and retest) to try and figure out what's
going on, but so far, no luck.
I just added a more comprehensive set of checks just now (hrev52902).
Try upgrading past that and see if you get a panic instead of a
deadlock.
If you manage to actually get a panic, or figure out if some specific
driver is causing it, I can help investigate further. It seems to
happen on one of the college workstation PCs, but of course I can't
touch the disk on that but only boot from USB3 ports, which fails most
of the time as one might expect...
I have an older version of the XHCI chip and it seems that the IRQ's stop
responding to SubmitNormalRequest's, after a few transfers. Actually, after
it seems right after getting the device name from usb_disk.
So, SubmitNormalRequest wasn't checking if the descriptor link failed, which
would make it look like the transfer was written successfully and then ring
the doorbell, but it would do nothing because the transfers queue was
actually full. I fixed that in my next commit.
Reports from users are that "stalls" seem to be greatly decreased on
hardware where XHCI seemed; however kallisti5 can still easily
reproduce (boot failure) on his Ryzen machine, which probably has a
not-so-ancient controller. So we really are just doing something
incorrectly here.
It seems stalled transfers aren't getting cleaned up properly. Most likely
that's your issue, also. I have absolutely no idea why or what to do about
that, though.
So, it turns out these aren't true stalls I guess, because they never
trigger an interrupt telling us that it stalled.
At this point I'm completely out of my depth and don't have much of a
clue how to proceed further; unless I have some brilliant insight, my
commits today probably are the end of that series. I'd be happy to
help you with general driver development stuff, or cross-comparing
between the BSDs (have you looked at OpenBSD's driver yet? It's much
clearer than Linux's or FreeBSD's, but it's less complete than either.
At this point I don't know how much FreeBSD's is to be trusted; in
fact I've heard it has similar bugs to our's) but I don't really have
much more to contribute directly here...
-waddlesplash
Other related posts:
