In message <51480f20.6060...@bitfrost.no>, 
Hans Petter Selasky <h...@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().

OK.  So what am I supposed to do in order to enable those?

>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.

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?

>>
>> 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?

I'm sorry.  I just don't understand what point you were trying to make.

>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.

>> 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.)

>> 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?

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.
 */                      ^^^^^^^^^^


??

_______________________________________________
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"

Reply via email to