Date: Wed, 20 Mar 2013 12:53:29 +0100 From: Hans Petter Selasky <hps@bitfrost.no> To: "Ronald F. Guilmette" <rfg@tristatelogic.com> Cc: freebsd-usb@freebsd.org Subject: Re: Help please... More problems with USB 3.0 (kernel freezes) Message-ID: <5149A339.9070606@bitfrost.no> In-Reply-To: <64636.1363771346@server1.tristatelogic.com> References: <64636.1363771346@server1.tristatelogic.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 03/20/13 10:22, Ronald F. Guilmette wrote:
>
> In message <51480F20.6060601@bitfrost.no>,
> Hans Petter Selasky <hps@bitfrost.no> wrote:
>
>> On 03/18/13 23:39, Ronald F. Guilmette wrote:
>>> 1) What is the best way to debug this? I have seen HPS suggest to others
>>> with USB problems that they either (a) use the usbdump(8) command to get
>>> more info about the problems or else (b) compile and install a new kernel
>>> in which the option USB_DEBUG has been defined. Which should I do, and
>>> how may I interpret the results in either case?
>>
>> I see two kind of hangs:
>>
>> 1) IRQ is spinning
>> 2) DMA is going wild in the memory
>>
>> In sys/dev/usb/controller/xhci.c there are debug prints, DPRINTF() and
>> DPRINTFN().
>
Hi,
> OK. So what am I supposed to do in order to enable those?
You need "options USB_DEBUG" in the kernel config.
Then you need to execute:
sysctl hw.usb.xhci.debug=15
>
>> You probably want to have a print in the interrupt routine.
>
> Could you be a little more specific please? I do not do kernel coding,
> and thus, I don't know what things I should be calling in order to get
> some new kind of debug output.
You can use printf("MY printout\n"); to get printouts in the kernel.
> I also don't know where is the interrupt routine, and even if I found that,
> I would probably not have any idea where, within that, I should add some
> sort of statement to print ?something? let alone what sorts of something
> would be Good or Useful to print at that point.
>
>> Just search for "interrupt". Debug level is controlled via sysctl
>> hw.usb.xhci.debug=X
>
> OK, but what should I be setting that to in order to get useful but non-
> overwehlming debug information?
Just set it to the maximum and store everything. You won't get so much
unless you transfer a lot of data.
>>>
>>> 2) What are the command timeouts set to in the XHCI driver and how can I
>>> increase them? (Perhaps my card is just barely meeting the published
>>> USB standard timing specs, and just need a tiny bit more time?)
>>
>> The XHCI is an active USB controller.
>
> I have no idea what that means.
>
>> That means many high-level USB
>> commands must be fed into it using separate commands.
>
> You did not complete the sentence.
>
> That means many high-level USB commands must be fed into it using separate
> commands IN ORDER TO ACCOMPLISH WHAT?
To understand this you need to read about how the EHCI / OHCI / XHCI /
UHCI controllers work.
>
> I'm sorry. I just don't understand what point you were trying to make.
The point is that the command timeout is something bad happening in the
XHCI hardware / card you've got and not specific to the USB device you
plug in.
>
>> These have nothing to do with what is transferred to the USB device.
>
> OK. What has that fact got to do with my question about timeouts?
>
> I'm sorry to be so ignorant, but I am. You seem to be assuming that I have
> a lot of knowledge about either (a) how low-level hardware interfaces to
> USB things normally operate and/or (b) about FreeBSD drivers in particlar
> and/or your USB driver specifically. Although I am willing to learn, unfor-
> tuantely I do not currently know much if anything about any of this stuff.
> I just know that I want to do what it takes to get this USB hardware that
> I have here working under FreeBSD.
I'm not afraid to answer questions :-)
>
>>> 3) What exactly is "hw.usb.no_cs_fail" ?
>>
>> This just instructs the system to not re-enumerate the device on
>> repeated clear stall failures.
>
> I suppose that now I should go and google for "clear stall failures". (I'm
> sorry, but I have no idea what those are either, but I will try to read up
> on that on my own.)
Yes, that's a good idea.
>
>>> 4) What exactly is "hw.usb.u3g.debug" ?
>>
>> That's debugging for u3g driver module.
>
> Oh. OK. I think that seems to be utterly irrelevant to my attempts to
> use USB stuff.
>
>>> 5) What exactly is "diveration" ?
>>
>> Where did you find this?
That's a typo. It should be derivation
>
> Near the top of the driver source:
>
> /usr/src/sys/dev/usb/controller/xhci.c
>
> /*
> * A few words about the design implementation: This driver emulates
> * the concept about TDs which is found in EHCI specification. This
> * way we avoid too much diveration among USB drivers.
> */ ^^^^^^^^^^
>
>
Is this easier to understand:
/*
* A few words about the design implementation: This driver emulates
* the concept about TDs which is found in EHCI specification. This
* way we achieve that the USB controller drivers look similar to
* eachother which makes it easier to understand the code.
*/
--HPS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5149A339.9070606>